Mods...
On infra, this came up for another mailing list and it was said that a
mod can unsubscribe an email address... Maybe someone already tried,
but it looks like the address is "02211...@mail.bjtu.edu.cn"
These have been showing up for a while now, I don't think that it will
work itself out.
FYI, you can reach the moderators directly with '-owner' (e.g. dev-ow...@s.a.o).
--
Martin Cooper
2009/12/8 Wes Wannemacher :
> Mods...
>
> On infra, this came up for another mailing list and it was said that a
> mod can unsubscribe an email address... Maybe someone already tried,
> but it looks
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. Ther
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
will this mean that struts 2.2 will support MVP
or any idea to put GWT also :)
F
In my opinion, current DI support is sufficient (it can be made more
readable, but that's it ;-), I really don't get it what's the problem with
double ObjectFactory issue???
Regards
--
Lukasz
http://www.lenart.org.pl/
I've been loosely following the thread. It sounds like three DI
projects are being/will be supported:
* XWork
* Guice
* JSR-299/JSR-330
Why three? I can understand the last because it's EE, but the other
two are proprietary.
Paul
On Tue, Dec 8, 2009 at 4:08 PM, Lukasz Lenart
wrote:
> In my opin
what we are proposing/talking is to use only JSR 330, which is the
spec. The actual implementation (default) would be guice.
musachy
On Tue, Dec 8, 2009 at 3:12 PM, Paul Benedict wrote:
> I've been loosely following the thread. It sounds like three DI
> projects are being/will be supported:
> *
JSR 299 is EE while 330 is SE.
-bp
On Dec 8, 2009, at 4:12 PM, Paul Benedict wrote:
> I've been loosely following the thread. It sounds like three DI
> projects are being/will be supported:
> * XWork
> * Guice
> * JSR-299/JSR-330
>
> Why three? I can understand the last because it's EE, but th
Then what was the point of getting the IP for XWork?
On Tue, Dec 8, 2009 at 5:30 PM, Brian Pontarelli wrote:
> JSR 299 is EE while 330 is SE.
>
> -bp
>
>
> On Dec 8, 2009, at 4:12 PM, Paul Benedict wrote:
>
>> I've been loosely following the thread. It sounds like three DI
>> projects are being/w
XWork is more than DI. If drives the workflow under the hoods of Struts. We
would need all of that code in addition to the DI. The idea is to drop the DI
part of XWork and replace it with Guice 2.1 (which should support JSR 330) and
just pull in the rest of it.
-bp
On Dec 8, 2009, at 4:32 PM,
Since the XWork code is now owned by Apache (right?), you could split
it into two jars (workflow and DI). Then deprecate the DI artifact
unless someone here as aspirations to continue such support. Split in
two, this would hopefully also address Don's concern of the code base
being too big.
Lastl
I believe that the simplest route would be to collapse everything into a single
core JAR, which includes the workflow and other core APIs. This JAR would would
use the JSR 330 annotations and a provide a couple of Module implementations. I
would then have the Struts servlet filter wire everythin
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'
On Wed, Dec 9, 2009 at 11:34 AM, Paul Benedict wrote:
> Lastly, because Bob Lee is a Struts committer, you should get pretty
> good support from him on.
Don't count on it. Bob has moved on from Struts 2, so I would count
on anything beyond moral support. :)
Don
>
> Paul
>
> On Tue, Dec 8, 2009
It isn't about needing a "struts-light", it is adding unnecessary
bulk. When I was more active, I spent a lot of time trying to kick
out dependencies, tighten up our weak API's, and overall simplify
interactions with the framework. If you look at the framework space
right now, your best bet for a
Remember, there are quite a few places that have the Container
instance injected, as they need to query it directly. JSR 330 is too
narrowly scoped to fully abstract DI, as folks like Gavin have been
quick to point out.
Don
On Wed, Dec 9, 2009 at 2:47 PM, Brian Pontarelli wrote:
> I believe tha
Don,
> JSR 330 is not the magic bullet here.
Agreed, but I would have to say it would be foolish not to support it.
As companies perform internal tech evaluations, people will eventually
realize "standard" DI injection is not supported: "Oh, our company has
to learn XWork DI? What the heck is XWo
18 matches
Mail list logo
