struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wes Wannemacher <w...@wantii.com>
Subject Re: struts 2.2 and guice
Date Tue, 08 Dec 2009 18:08:34 GMT
Don,

I would argue the opposite... I understand that you are going to have
trouble in a resource-constrained environment, and as Musachy mentions
later in the thread, there are things we could dump to regain space...
But! Most of our users aren't resource-constrained... At least, if
they are, they aren't complaining about it. If we moved infrequently
used interceptors, results and all their supporting classes into
plugins (which would be pretty easy, mostly due to your hard work),
then that would just make it more difficult for the vast majority of
users.

If you want to start a struts2-lite project, I'd be happy to jump in
and help out, but I think that resource-constrained environments are
the exception, not a rule to live by.

-Wes

On Mon, Dec 7, 2009 at 6:33 PM, Don Brown <mrdon@twdata.org> 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 <musachy@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 <mrdon@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 <musachy@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 <gielen@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 <musachy@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 <brian@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 <brian@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
<thechrispratt@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
<brian@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 <brian@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-unsubscribe@struts.apache.org
>>>>>>>>>>>>>>>> For additional commands,
e-mail: dev-help@struts.apache.org
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail:
dev-help@struts.apache.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail:
dev-help@struts.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>



-- 
Wes Wannemacher

Head Engineer, WanTii, Inc.
Need Training? Struts, Spring, Maven, Tomcat...
Ask me for a quote!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message