struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pontarelli <>
Subject Re: struts 2.2 and guice
Date Wed, 09 Dec 2009 15:23:57 GMT
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. 


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 <> 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 <> 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 <> wrote:
>>>>> Late to the party, but I'm not clear why you would want to use Guice
>>>>> 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 <>
>>>>>> I don't know about dropping Object factory, in this case it would
>>>>>> 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 <>
>>>>>>> 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
>>>>>>> JSR330 DI - as this would imply that Struts 2.2 would not integrate
>>>>>>> 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 <>
>>>>>>>>> It is good that you brought this up, because the double
object factory
>>>>>>>>> is annoying and creates a lot of unexpected situations(problems
>>>>>>>>> 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 <>
>>>>>>>>>> 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
<> 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
>>>>>>>>>>>>> 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 <> 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 <>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 <>
>>>>>>>>>>>>>>> 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:
>>>>>>>>>>>>>>>>>> For additional commands,
>>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>> To unsubscribe, e-mail:
>>>>>>>>>>>>>>>>> For additional commands,
>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>> To unsubscribe, e-mail:
>>>>>>>>>>>>>>>> For additional commands,
>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>> To unsubscribe, e-mail:
>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail:
>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail:
>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail:
>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail:
>>>>>>>>>> For additional commands, e-mail:
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail:
>>>>>>>> For additional commands, e-mail:
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail:
>>>>>>> For additional commands, e-mail:
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail:
>>>>>> For additional commands, e-mail:
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail:
>>>>> For additional commands, e-mail:
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message