Hi guys,
JSR 330 is cool and shall be definitely supported - but you still need
fallback metadata mechanism.
Drawback of annotatioj is that it is class bound, and thus you can not have
two of something without
subclassing. Neither can you reconfigure classes coming as jar dependency.
Am 27.11.12 22:55, schrieb Johannes Geppert:
It looks there is a broad agreement related to the projects links and the
Roadmap FAQ.
So i have dropped it from the site.
Also I have added a Facebook and G+ Integration beside the Twitter
Integration.
Looks like this is our current News
Does that mean that it won't be part of future releases? Then we should
be careful with commenting things out here...
Am 22.11.12 10:09, schrieb Lukasz Lenart:
2012/11/22 Lukasz Lenart lukaszlen...@apache.org:
Or I can comment them out in plugins pom.xml.
After commenting out, build is
I have to second Matt here. Even though Struts 3.x is about introducing
a platform for breaking changes, we should carefully consider what we
actually break.
The discussion seems to be a variation of are we going for 2.5 or
3.0?. Since now there seems to be major support for going 3.0, all the
You have to differentiate between XWork's internal injection and the
injection abstraction towards user code to support pluggable dependency
injection implementations. The latter one we surely would not want to
drop, and as a matter of fact we are already supporting JSR 330 with the
Spring, Guice
Konstantin,
you make a valid point that JSR 330 by itself is no solution to our
problems with internal injection. As I tried to explain in another post
to this thread, we have to differentiate between internal injection and
injection abstraction towards user side.
As for how to evolve internal
See https://builds.apache.org/job/Struts2-JDK6/570/
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
2012/11/28 Rene Gielen gie...@it-neering.net:
Does that mean that it won't be part of future releases? Then we should
be careful with commenting things out here...
Yes, but with them project cannot be build on JDK5
EmbeddedJSP uses classes that are available as from JDK6 - there is no
way to
Perhaps I am too old and have been in the consulting business too long, but to
change the internal DI facility -- which is working beautifully -- merely for
the sake of changing seems to be an unnecessary risk.
My two cents.
Jeff
From: Rene Gielen
IMO I'd rather see the internal mechanism be able to evolve and make use of
vetted improvements instead of remaining in the land of Guice of 5+ years
ago. Newer Guice has more capabilities.
Dave
On Nov 28, 2012 10:27 AM, Jeff Black jeffrey.bl...@yahoo.com wrote:
Perhaps I am too old and have
Also I think our core competence here at Struts is building web
frameworks, not dependency injection frameworks. The original
maintainers aren't active any more. The current code is in a state of
don't touch, it might blow up without warning. Fiddling out a memory
leak in the DI code lately took
Can I get some clarification on internal mechanism? I may have
misspoke; I would like Struts users to use Commons DI over XWork
injection. That's something different than the way Struts wires up
itself, right?
On Wed, Nov 28, 2012 at 9:53 AM, Rene Gielen gie...@it-neering.net wrote:
Also I think
Internal means everything consuming the c.o.xwork.Inject annotation and
of course the providing mechanism for this one.
As a user, even today I would never ever (ok, unless I really know what
I'm doing) consume this annotation. And I don't have to, since Spring,
Guice and CDI plugin provide me
Folks,
I think right at this point we should fork discussion on methodology
(Git) from new features as in the rest of this thread.
Moving development to the Git infrastructure ASF / Infra now provides is
*not* a no-brainer, and it requires a little bit more than just a few +1s :)
Let's step
2012/11/28 Rene Gielen rgie...@apache.org:
Moving development to the Git infrastructure ASF / Infra now provides is
*not* a no-brainer, and it requires a little bit more than just a few +1s :)
Let's step back, hold breath, and dive into serious discussion about
that. I'm preparing a more
2012/11/28 Dave Newton davelnew...@gmail.com:
IMO I'd rather see the internal mechanism be able to evolve and make use of
vetted improvements instead of remaining in the land of Guice of 5+ years
ago. Newer Guice has more capabilities.
I thought (and still do) a lot about that and I'm not
Hi,
Do we have a place where we can deploy a pre-release version of site
to test it ? Maybe just to struts.a.o/next ?
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
-
To unsubscribe, e-mail:
We'll always rely on external libraries--and as has been mentioned,
our core competency isn't DI frameworks, nor should it be.
I'm not sure an XML config layer would be that difficult to build, but
even if it is, wouldn't it be preferable to use a substantially
more-mature DI implementation,
Would it be possible to write the internal code to use the JSR-330 API and
supply Guice as the default, rather than tying the system directly to
Guice? It seems like there would be an advantage to allowing the internal
and external injections to potentially share an injection library rather
than
2012/11/28 Dave Newton davelnew...@gmail.com:
We'll always rely on external libraries--and as has been mentioned,
our core competency isn't DI frameworks, nor should it be.
Always something new :-)
I'm not sure an XML config layer would be that difficult to build, but
even if it is, wouldn't
2012/11/28 Chris Pratt thechrispr...@gmail.com:
Would it be possible to write the internal code to use the JSR-330 API and
supply Guice as the default, rather than tying the system directly to
Guice? It seems like there would be an advantage to allowing the internal
and external injections to
On Wed, Nov 28, 2012 at 8:36 PM, Lukasz Lenart lukaszlen...@apache.org wrote:
2012/11/28 Rene Gielen rgie...@apache.org:
Moving development to the Git infrastructure ASF / Infra now provides is
*not* a no-brainer, and it requires a little bit more than just a few +1s :)
Let's step back, hold
On Wed, Nov 28, 2012 at 4:42 PM, Christian Grobmeier wrote:
http://nvie.com/posts/a-successful-git-branching-model/
https://github.com/nvie/gitflow
Yeah, I like the workflow quite a bit, although I've only used it on a
couple of smallish projects.
Dave
On Wed, Nov 28, 2012 at 4:39 PM, Dave Newton davelnew...@gmail.com wrote:
IMO I'd rather see the internal mechanism be able to evolve and make use of
vetted improvements instead of remaining in the land of Guice of 5+ years
ago. Newer Guice has more capabilities.
I would like to mention the
On Wed, Nov 28, 2012 at 8:57 PM, Lukasz Lenart lukaszlen...@apache.org wrote:
Do we have a place where we can deploy a pre-release version of site
to test it ? Maybe just to struts.a.o/next ?
I think a people.a.o user directory would do the trick.
Cheers
Christian
Regards
--
Łukasz
+ 48
25 matches
Mail list logo
