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
