I thought I'd add my 2 cents. I'm trying to port a plugin to Struts and have
been totally stumped on how to get an instance of the object I need because
Struts uses a proprietary framework. If we were using Guice, I'd have no
problem because of the plethora of docs and other users. So I'd stron
On Thursday 10. December 2009 20.28.48 Musachy Barroso wrote:
> guys, can you start a different thread for this? :)
You have a point there, talk about hijacking a thread:-)
--
Andreas Joseph Krogh
Senior Software Developer / CTO
+-
On Thursday 10. December 2009 20.27.32 Gabriel Belingueres wrote:
> Granted, most people implement wizards this way, but the most
> compelling use of storing state in conversation scope (IMO) is to
> allow correct behavior when a user clones a browser window, and then
> allow better support for the
guys, can you start a different thread for this? :)
On Thu, Dec 10, 2009 at 11:27 AM, Gabriel Belingueres
wrote:
> Granted, most people implement wizards this way, but the most
> compelling use of storing state in conversation scope (IMO) is to
> allow correct behavior when a user clones a browse
Chris Pratt wrote:
That seems like a very imperfect fix for an almost impossible problem.
Having an extra parameter on the link won't stop a user from right clicking
on the link and saying "open in another window" and having 2 "conversations"
with the same conversation key.
If the link followed
That seems like a very imperfect fix for an almost impossible problem.
Having an extra parameter on the link won't stop a user from right clicking
on the link and saying "open in another window" and having 2 "conversations"
with the same conversation key. To my knowledge there's just no way to
acc
Granted, most people implement wizards this way, but the most
compelling use of storing state in conversation scope (IMO) is to
allow correct behavior when a user clones a browser window, and then
allow better support for the back button. Even with conversation
support the pages still need to pass
On Thursday 10. December 2009 17.37.04 Alex Siman wrote:
>
> What if application needs expirable and parallel (say 5 instances at a time)
> wizard?
The point is that you have to save the state using the session (or DB or other
persistent storage, but I assume that's more trouble than it's worth)
What if application needs expirable and parallel (say 5 instances at a time)
wizard?
andreak wrote:
>
> On Thursday 10. December 2009 15.31.15 Alex Siman wrote:
>>
>> Wes Wannemacher wrote:
>> >
>> > "Everything is tied to either the request
>> > or the session, I can't build wizard-style view
On Thursday 10. December 2009 15.31.15 Alex Siman wrote:
>
> Wes Wannemacher wrote:
> >
> > "Everything is tied to either the request
> > or the session, I can't build wizard-style views"
> >
> Yeah, we need wizards sometimes.
I would argue that it would be nice to have, but not a must. Most
i
Wes Wannemacher wrote:
>
> "Everything is tied to either the request
> or the session, I can't build wizard-style views"
>
Yeah, we need wizards sometimes.
--
View this message in context:
http://old.nabble.com/struts-2.2-and-guice-tp26594350p26728156.html
Sent from the Struts - Dev mailing l
On Dec 9, 2009, at 2:47 PM, Wes Wannemacher wrote:
> Don,
>
> I started another thread to talk about the API issue, but for this I
> want to give you my take. The "Managed Beans" JSR I started reading
> the other day does offer a few useful features that we don't have. One
> is the "conversation
On Tue, Dec 8, 2009 at 11:22 PM, Don Brown wrote:
> 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
Don,
I started another thread to talk about the API issue, but for this I
want to give you my take. The "Managed Beans" JSR I started reading
the other day does offer a few useful features that we don't have. One
is the "conversation" scope, which I think Struts 2 could really
benefit from. That's
First, injecting the Container (or Injector as it is called) is allowed in the
JSR and the API is abstracted well enough that it shouldn't cause major
concerns.
On the flip-side, I contend that those instances are broken and can be fixed.
I also don't agree that 330 is too narrow. It should s
Without too long of a reply, here are a few thoughts:
- Solid, unchanging public APIs are possible
- Refactoring and using the latest technologies is the only way to
survive
- This would not break separation or dictate it for that matter
- It would force necessary
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
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
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
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
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'
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
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
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,
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
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
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:
> *
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
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/
will this mean that struts 2.2 will support MVP
or any idea to put GWT also :)
F
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
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
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 h
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
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 do
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 shoc
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 wrote:
> I'm a huge fan of moving to Guice 2 internally, although I'
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
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 wrote:
> It is good that you brought this up, because the do
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
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 wh
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 th
Because you don't want to use separate containers. In Guice you can have
child-parent injector relationships. My thought is to just have a single DI
container that builds everything. Struts no longer has any concept of an
ObjectFactory and doesn't create actions or anything like that. It would j
I have mixed feelings about it. making it pluggeable is not a priority
I would say. But if there are standard annotations for it now, then
there is no reason why we shouldn't use them. If the day comes when
guice is no longer supported (I don't really mean it crazybob :)), it
would be easier to fin
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 t
On Tue, Dec 1, 2009 at 10: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.
If it
I don't see a clear distinction between the Struts injector and the
App injector. One thing to keep in mind is that user often request how
to access struts internal stuff, like action mapping etc, which in
theory should not happen, but it does.
musachy
On Tue, Dec 1, 2009 at 10:21 AM, Brian Ponta
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 wrote:
> I wouldn't have
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 wrote:
> They'll
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
|
|
_
| |
| |
StrutsApp
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 T
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 s
52 matches
Mail list logo
