Is this 299 or 330? I have been meaning to read the spec, and this
confused me... On jcp.org, there is a DI spec that is JSR330, is that
the one we're talking about? JSR299 seems to refer to JSF.
-Wes
On Mon, Dec 7, 2009 at 11:32 AM, rgie...@apache.org wrote:
Author: rgielen
Date: Mon Dec 7
Nevermind, I think I've figured it out... The JSR 299 description is
somewhat ambiguous here -
http://www.jcp.org/en/jsr/all
the description reads - 299, Web Beans,
Description:The purpose of this specification is to unify the JSF
managed bean component model with the EJB component model,
It looks like this code is against the JEE WebBeans injection stuff (299). The
JSR that Guice will be implementing is 330, which is a JSE injection model.
-bp
On Dec 7, 2009, at 9:35 AM, Wes Wannemacher wrote:
Is this 299 or 330? I have been meaning to read the spec, and this
confused me...
Actually it's against Contexts and Dependency Injection, JSR 299. Of
course it implicitly uses JSR330, but the BeanManager stuff is part of
the JSR299 API, with JBoss Weld being the RI. Notice the
javax.enterprise package prefixes of the imports :)
I'll commit the classical NumberGuess
I've put my initial works on a Struts2 CDI plugin into the sandbox. It
implements a JEE6 compliant ObjectFactory, making Actions etc. being
wired up by the EE container, with all the good stuff like scoped
managed beans, EJBs and such.
The plugin is built against current S2 trunk
sweet. when xwork finally lands on struts I will start looking at
replacing our guice, with the api from jsr-330 and using guice as
the default implementation, that should go nicely with this plugin.
musachy
On Mon, Dec 7, 2009 at 11:29 AM, Rene Gielen rgie...@apache.org wrote:
I've put my
Now that Websphere application server is available for free for development
purposes, are there any plans to test this against Websphere?
You can check the following site for free download of Webshpere :
http://www.ibm.com/developerworks/downloads/ws/wasdevelopers/index.html
(originally posted
Yes, replacing Guice 1-pre with Guice 2 would be the great. I've got
some comments, though - will put them to the Struts 2.2 + Guice 2 thread.
Musachy Barroso wrote:
sweet. when xwork finally lands on struts I will start looking at
replacing our guice, with the api from jsr-330 and using guice
AFAIK WS7 is JEE5 only. Do they have a working JSR299 implemntation? If
yes, a test might be interesting.
Struts Two wrote:
Now that Websphere application server is available for free for development
purposes, are there any plans to test this against Websphere?
You can check the following
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
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
I am almost positive WAS V7 does not have working implementation of JSR299 :(
(I will try to dig more). Looking on Ballot results for this JSR, It seems IBM
is the only one who voted against this JSR.
I think if there is going to be an implementation of this JSR, It will be
probably WAS V7.1.
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
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
I can't think of any bug, and I hope there isn't any because that code
looks like voodoo to me. Using the same container for both is
arguable, as I said before I am not sold either way.If you have a
resource constrained environment there are other things that we can do
to reduce the size, which I
15 matches
Mail list logo
