Without too long of a reply, here are a few thoughts:
- Solid, unchanging public APIs are possible
- Refactoring and using the latest technologies is the only way to
survive
- This would not break separation or dictate it for that matter
- It would force necessary clean up
The benefit is that as Java 7 and JEE6 roll out and JSR 330 possibly gains
momentum (which I believe is guaranteed), people will look to the frameworks to
support them. Here's a few others that Struts should be using:
303 - Bean validation
315/316 - Async support
I'm sure there are others as well.
-bp
On Dec 8, 2009, at 9:13 PM, Don Brown wrote:
> Ok, here is how it works at Atlassian and most every software project
> I've been involved in - changing core dependencies is hard. It is
> especially hard if you needed to fork said dependencies, which we've
> had to do quite often at Atlassian. If a green-field Struts 2
> application decided, hey, let's just use Guice 2 just like Struts,
> then what happens down the line when Struts 2 goes to Guice 2.1, which
> is incompatible? What if that app needed to customize Guice 2.0 or
> build specific functionality deep into the library? Now, if they
> wanted to upgrade Struts 2? They'd be stuck until they could upgrade
> their version of Guice 2?
>
> This is not a hypothetical situation. At Atlassian, we have apps like
> JIRA that are 7 or 8 years old. JIRA, for example, uses a forked
> version of PicoContainer 1.0 they had to customize for various
> reasons. Why would they spend a month or two upgrading PicoContainer
> without gain when they could be building kick-ass features? For this
> reason, Confluence is running Spring 2.0, Hibernate 2, and WebWork
> 2.1.7-atlassian-2. It isn't that these products can never change
> dependencies, just the cost is really high for little to no gain, and
> if one major upgrade requires another, it is all the more reason not
> to do the upgrade at all.
>
> JSR 330 is not the magic bullet here. Yes, services would then not be
> tied to a specific DI container, but all the configuration and direct
> DI container usage sure would be, and in Struts 2, we have heaps.
> Furthermore, this gives breaks the abstraction between the framework
> and the host app. We already have enough problems in Struts 2 because
> we lack an proper API. Externalizing our DI only exasperates this
> problem. We might as well encourage devs to copy/paste Struts 2 into
> their project because upgrading sure will be a pain.
>
> Again, there are significant costs to this proposal, and I have yet to
> hear a substantial, real-world benefit. Earlier, we went so far as to
> define our own logging API because we wanted to keep that boundary
> between the app and the framework. Sometimes, strict boundaries are a
> very good thing.
>
> Don
>
> On Wed, Dec 9, 2009 at 4:38 AM, Brian Pontarelli <br...@pontarelli.com> wrote:
>> Why do you say that and do you have specific examples? JCatapult uses a
>> single container and it is actually effective and very helpful. This allows
>> you to easily get access to the public API of JCatapult and also to override
>> anything you want. It also makes things faster and lighter weight. There are
>> many applications and developers using it without major issues.
>>
>> I wonder how many users are actually swapping out the ObjectFactory at this
>> point and wouldn't be fine with either Guice or Spring? There is also
>> nothing stopping other DI containers from implementing JSR 330 and I would
>> expect most will.
>>
>> I think the way to approach this is to have struts get out of the business
>> of DI completely. If everything in Struts uses the JSR annotations and APIs,
>> then Struts is really just a component of the web app and not really the
>> "owner". The webapp would declare its primary DI provider and then Struts
>> would just wire up using that.
>>
>> The JSR also supports tiered injectors, which could be used to isolate
>> Struts. If Struts defines generic modules, the webapp can easily place all
>> those modules in a child injector if it wants. Or if could place it the main
>> injector if it wants access to everything. Struts shouldn't be dictating its
>> place in the webapp, the webapp should be dictating Struts place. Moving to
>> JSR 330 should fix a lot of this.
>>
>> -bp
>>
>>
>> On Dec 7, 2009, at 4:33 PM, Don Brown wrote:
>>
>>> Well, two things: sharing an IoC container with the app is almost
>>> always a bad idea in the long run, and two, maybe it is just me in a
>>> resource-constrained environment, but 651kb is definitely a big deal,
>>> especially if it brings in other dependencies like google collections.
>>> The fact that Struts 2 is almost 5 megs means it is a no-go for me to
>>> use in our embedded OSGi container. I was hoping to get it back down
>>> under 2 megs, but with Guice 2, that would be quite unlikely. What
>>> features exactly do we need or how many bugs have cropped up in our DI
>>> container that we would be avoiding?
>>>
>>> Don
>>>
>>> On Tue, Dec 8, 2009 at 10:11 AM, Musachy Barroso <musa...@gmail.com> wrote:
>>>> We could have just one container (no double object factory), and
>>>> probably the same one could be used for s2 and the app (still to be
>>>> seen if feasible or not), get any new features that get added or are
>>>> in jsr 330, and we don't have maintain our own implementation when
>>>> there is a lib that already does it, like we usually do. Also, guice 2
>>>> main jar is 651 kbs, so I don't see much of a problem there.
>>>>
>>>> musachy
>>>>
>>>> On Mon, Dec 7, 2009 at 2:55 PM, Don Brown <mr...@twdata.org> wrote:
>>>>> Late to the party, but I'm not clear why you would want to use Guice 2
>>>>> instead of our own. Is there some feature we need that Guice 2 has?
>>>>> If not, we are basically sucking in a pretty significantly sized
>>>>> library for no apparent reason. I tried to use Struts 2 on a project
>>>>> here, and was a bit shocked at the size of the jar nowadays...seems we
>>>>> went a bit crazy with the shading. I'd generally advise against
>>>>> adding more bulk without obvious gains.
>>>>>
>>>>> Don
>>>>>
>>>>> On Tue, Dec 8, 2009 at 7:09 AM, Musachy Barroso <musa...@gmail.com> wrote:
>>>>>> I don't know about dropping Object factory, in this case it would just
>>>>>> delegate to the jsr 330 implementation. But getting rid of the double
>>>>>> object factory problem would be very nice.
>>>>>>
>>>>>> On Mon, Dec 7, 2009 at 12:06 PM, Rene Gielen <gie...@it-neering.net>
>>>>>> wrote:
>>>>>>> I'm a huge fan of moving to Guice 2 internally, although I'm not sure if
>>>>>>> we would want to drop the ObjectFactory abstraction for plain pluggable
>>>>>>> JSR330 DI - as this would imply that Struts 2.2 would not integrate any
>>>>>>> more against Spring 2.x, Guice 1, Plexus, PicoContainer and what not. Do
>>>>>>> we really expect every Struts2 user and his company will be able to move
>>>>>>> to JSR330 compliant DI within the next months? I doubt that, and I'd
>>>>>>> rather not sacrifice our DI abstraction for that reason...
>>>>>>>
>>>>>>> - Rene
>>>>>>>
>>>>>>>
>>>>>>> Musachy Barroso wrote:
>>>>>>>> I am reading the spec and I am rather impressed, I thought it would be
>>>>>>>> a simple thing but it is really comprehensive. I doubt we will have a
>>>>>>>> use case that won't be covered there.
>>>>>>>>
>>>>>>>> musachy
>>>>>>>>
>>>>>>>> On Tue, Dec 1, 2009 at 10:49 AM, Musachy Barroso <musa...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>> It is good that you brought this up, because the double object factory
>>>>>>>>> is annoying and creates a lot of unexpected situations(problems with
>>>>>>>>> class reloading and OSGi). Having just one container would make it
>>>>>>>>> easier for everybody, users and s2 developers, if it can be pulled
>>>>>>>>> off.
>>>>>>>>>
>>>>>>>>> This kind of change could be too big for a 2.x release I think
>>>>>>>>>
>>>>>>>>> musachy
>>>>>>>>>
>>>>>>>>> On Tue, Dec 1, 2009 at 10:44 AM, Brian Pontarelli
>>>>>>>>> <br...@pontarelli.com> wrote:
>>>>>>>>>> We could probably make a list and verify. I think the API should be
>>>>>>>>>> pretty comprehensive about a lot of those things.
>>>>>>>>>>
>>>>>>>>>> -bp
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Dec 1, 2009, at 11:42 AM, Musachy Barroso wrote:
>>>>>>>>>>
>>>>>>>>>>> ah I see what you mean. yes that would be a good idea, I think that
>>>>>>>>>>> would work as long as all the containers have what we need, which I
>>>>>>>>>>> am
>>>>>>>>>>> not sure if it is in the spec or not (havent read it), like:
>>>>>>>>>>>
>>>>>>>>>>> * create/inject objects and statics (duh)
>>>>>>>>>>> * lookup all implementation by type
>>>>>>>>>>>
>>>>>>>>>>> that's all I can think off the top of my head.
>>>>>>>>>>>
>>>>>>>>>>> musachy
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Dec 1, 2009 at 10:38 AM, Brian Pontarelli
>>>>>>>>>>> <br...@pontarelli.com> wrote:
>>>>>>>>>>>> I was actually talking about expanding it out like Chris
>>>>>>>>>>>> mentioned. I don't see any reason why those who want to use the
>>>>>>>>>>>> container that Struts is using shouldn't be able to. Since the
>>>>>>>>>>>> annotations and APIs will be standard across Guice and Spring with
>>>>>>>>>>>> the JSR, it seems like it would be possible to allow the
>>>>>>>>>>>> application and framework to use the same DI container, just
>>>>>>>>>>>> different Injectors.
>>>>>>>>>>>>
>>>>>>>>>>>> The default could be Guice but allow Spring to be pluggable (or
>>>>>>>>>>>> even discoverable). As long as the internals of Struts are
>>>>>>>>>>>> compliant, it should work fine. This also provides the benefit of
>>>>>>>>>>>> configuration reduction in web.xml and a more comprehensive
>>>>>>>>>>>> solution. It would also get Struts out of the business of building
>>>>>>>>>>>> objects and requiring additional configuration and plugins for
>>>>>>>>>>>> different DI containers. I would guess it would clean up the
>>>>>>>>>>>> double ObjectFactory issues as well.
>>>>>>>>>>>>
>>>>>>>>>>>> -bp
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Dec 1, 2009, at 11:31 AM, Musachy Barroso wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> this is not related to the application itself, you can still use
>>>>>>>>>>>>> any
>>>>>>>>>>>>> IoC you want. This is for the IoC that is used internally to wire
>>>>>>>>>>>>> struts internals together, which at the moment is an old version
>>>>>>>>>>>>> of
>>>>>>>>>>>>> guice which is in xwork.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt
>>>>>>>>>>>>> <thechrispr...@gmail.com> wrote:
>>>>>>>>>>>>>> I wouldn't have a problem with it as long as I can still swap in
>>>>>>>>>>>>>> my trusty
>>>>>>>>>>>>>> Spring IoC container, I can't see my team moving away from it
>>>>>>>>>>>>>> any time soon,
>>>>>>>>>>>>>> but I still want to try to stay as current as possible on Struts.
>>>>>>>>>>>>>> (*Chris*)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli
>>>>>>>>>>>>>> <br...@pontarelli.com>wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> They'll be part of the Guice distribution and under ASLv2 since
>>>>>>>>>>>>>>> Guice uses
>>>>>>>>>>>>>>> that.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The real question is how to setup the Injector's. I tend to
>>>>>>>>>>>>>>> think this
>>>>>>>>>>>>>>> layout would be best:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Base
>>>>>>>>>>>>>>> |
>>>>>>>>>>>>>>> |
>>>>>>>>>>>>>>> _________
>>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>>> | |
>>>>>>>>>>>>>>> Struts App
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The Base injector will contain the JEE objects (request,
>>>>>>>>>>>>>>> response, etc.)
>>>>>>>>>>>>>>> and any Struts objects that can be used by the application. The
>>>>>>>>>>>>>>> Struts
>>>>>>>>>>>>>>> injector will contain all of the private objects that should
>>>>>>>>>>>>>>> not be
>>>>>>>>>>>>>>> accessible to the application. The App injector will contain
>>>>>>>>>>>>>>> all the
>>>>>>>>>>>>>>> application objects like Actions and such.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -bp
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> good point Brian, that has came up also. I have a couple of
>>>>>>>>>>>>>>>> concerns
>>>>>>>>>>>>>>>> about it, like what is the status of the jsr and will the API
>>>>>>>>>>>>>>>> (annotations) will be under a decent (read ASF compatible
>>>>>>>>>>>>>>>> license)
>>>>>>>>>>>>>>>> license and in maven central? which is usually a pain point
>>>>>>>>>>>>>>>> when it
>>>>>>>>>>>>>>>> comes to Sun APIs.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> musachy
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli
>>>>>>>>>>>>>>>> <br...@pontarelli.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> I'd suggest using Guice trunk and the JSR annotations rather
>>>>>>>>>>>>>>>>> than the
>>>>>>>>>>>>>>> Guice annotations. I'd also make the injector pluggable so that
>>>>>>>>>>>>>>> people can
>>>>>>>>>>>>>>> plug in Spring/Guice/etc easily.
>>>>>>>>>>>>>>>>> -bp
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I have talked to a couple of people before and everyone
>>>>>>>>>>>>>>>>>> seems to agree
>>>>>>>>>>>>>>>>>> that using guice instead of our internal IoC container
>>>>>>>>>>>>>>>>>> (guice pre 1.0
>>>>>>>>>>>>>>>>>> I think), would be a good idea. I don't have any experience
>>>>>>>>>>>>>>>>>> with guice
>>>>>>>>>>>>>>>>>> 2.0, but looking at the docs it seems like porting our stuff
>>>>>>>>>>>>>>>>>> would not
>>>>>>>>>>>>>>>>>> be that hard. Less code to maintain, and we get more
>>>>>>>>>>>>>>>>>> features/improvements. If we go with this idea, guice would
>>>>>>>>>>>>>>>>>> be shaded
>>>>>>>>>>>>>>>>>> into xwork to avoid classpath conflicts.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> what do you think?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> musachy
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
>>>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-h...@struts.apache.org
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
>>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-h...@struts.apache.org
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-h...@struts.apache.org
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail: dev-h...@struts.apache.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: dev-h...@struts.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-h...@struts.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-h...@struts.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-h...@struts.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
>>>>>>>> For additional commands, e-mail: dev-h...@struts.apache.org
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
>>>>>>> For additional commands, e-mail: dev-h...@struts.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
>>>>>> For additional commands, e-mail: dev-h...@struts.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
>>>>> For additional commands, e-mail: dev-h...@struts.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
>>>> For additional commands, e-mail: dev-h...@struts.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
>>> For additional commands, e-mail: dev-h...@struts.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
>> For additional commands, e-mail: dev-h...@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
> For additional commands, e-mail: dev-h...@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
