Re: Conversations (continued from struts 2.2 and guice)
This is how most frameworks do it, with continuations. This is essentially trying to do client side storage on the server. The reason it stores information like that is because of the Back/Forward buttons and multiple windows. All of which are client side interactions without a server-side notification (one of the pains of HTTP). You can handle most wizards using client side storage as well and reduce the complexity of server-side state management. This also allows more transparent scaling as the server could be stateless (sometimes). The tricky part is security becomes an issue unless you encrypt all the data and the store it using Base64 or something. With HTML5 and the client side databases (yeah I know they are a ways off) I would expect to see less requirements for continuations and web-flows. -bp On Dec 10, 2009, at 6:22 PM, Gabriel Belingueres wrote: I think this case is correctly handled in SWF: Each time a request fires a state transition, SWF saves a continuation of the current data (think the Memento pattern) Serialized for later use. When the user right-click the next link opening a new window, the state transition put the flow in a new state and as such a new continuation is saved (keeping the last one too.) From now on, the 2 windows execute on different data sets and no interference is possible. SWF only delete all continuations when the flow reaches an end state: if a new request is received on that deleted flow an exception is raised (then protecting from multiple submits, back buttons or as in this case, submits from different windows.) This works because it saves multiple (potentially costly?) copies of the data. As you say, I think JBoss Seam which does support conversations but has no support for continuations can not detect this case. Gabriel 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 accomplish it cleanly and completely, so you might as well embrace the way the web works and go with it rather than trying to swim upstream. But that's just one man's opinion. (*Chris*) - 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
Re: struts 2.2 and guice
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 clean up The benefit is that as Java 7 and JEE6 roll out and JSR 330 possibly gains momentum (which I believe is guaranteed), people will look to the frameworks to support them. Here's a few others that Struts should be using: 303 - Bean validation 315/316 - Async support I'm sure there are others as well. -bp On Dec 8, 2009, at 9:13 PM, Don Brown wrote: 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's just use Guice 2 just like Struts, then what happens down the line when Struts 2 goes to Guice 2.1, which is incompatible? What if that app needed to customize Guice 2.0 or build specific functionality deep into the library? Now, if they wanted to upgrade Struts 2? They'd be stuck until they could upgrade their version of Guice 2? This is not a hypothetical situation. At Atlassian, we have apps like JIRA that are 7 or 8 years old. JIRA, for example, uses a forked version of PicoContainer 1.0 they had to customize for various reasons. Why would they spend a month or two upgrading PicoContainer without gain when they could be building kick-ass features? For this reason, Confluence is running Spring 2.0, Hibernate 2, and WebWork 2.1.7-atlassian-2. It isn't that these products can never change dependencies, just the cost is really high for little to no gain, and if one major upgrade requires another, it is all the more reason not to do the upgrade at all. JSR 330 is not the magic bullet here. Yes, services would then not be tied to a specific DI container, but all the configuration and direct DI container usage sure would be, and in Struts 2, we have heaps. Furthermore, this gives breaks the abstraction between the framework and the host app. We already have enough problems in Struts 2 because we lack an proper API. Externalizing our DI only exasperates this problem. We might as well encourage devs to copy/paste Struts 2 into their project because upgrading sure will be a pain. Again, there are significant costs to this proposal, and I have yet to hear a substantial, real-world benefit. Earlier, we went so far as to define our own logging API because we wanted to keep that boundary between the app and the framework. Sometimes, strict boundaries are a very good thing. Don On Wed, Dec 9, 2009 at 4:38 AM, Brian Pontarelli br...@pontarelli.com wrote: 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. There are many applications and developers using it without major issues. I wonder how many users are actually swapping out the ObjectFactory at this point and wouldn't be fine with either Guice or Spring? There is also nothing stopping other DI containers from implementing JSR 330 and I would expect most will. I think the way to approach this is to have struts get out of the business of DI completely. If everything in Struts uses the JSR annotations and APIs, then Struts is really just a component of the web app and not really the owner. The webapp would declare its primary DI provider and then Struts would just wire up using that. The JSR also supports tiered injectors, which could be used to isolate Struts. If Struts defines generic modules, the webapp can easily place all those modules in a child injector if it wants. Or if could place it the main injector if it wants access to everything. Struts shouldn't be dictating its place in the webapp, the webapp should be dictating Struts place. Moving to JSR 330 should fix a lot of this. -bp On Dec 7, 2009, at 4:33 PM, Don Brown wrote: 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 is almost 5 megs means it is a no-go for me to use in our embedded OSGi container. I was hoping to get it back down under 2 megs, but with Guice 2, that would be quite unlikely. What features exactly do we need or how many bugs have cropped up in our DI container that we would be avoiding? Don On Tue, Dec 8
Re: struts 2.2 and guice
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 support everything that XWork does and more, considering XWork is Guice 0.0. I'm not sure what Gavin's objections are, but perhaps someone should shoot Bob, Kevin or Rod an email and get their thoughts on this. -bp On Dec 8, 2009, at 9:24 PM, Don Brown wrote: 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 br...@pontarelli.com wrote: 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 everything up as needed using a JSR 330 compliant implementation. -bp On Dec 8, 2009, at 5:34 PM, Paul Benedict wrote: 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. Lastly, because Bob Lee is a Struts committer, you should get pretty good support from him on. Paul On Tue, Dec 8, 2009 at 5:37 PM, Brian Pontarelli br...@pontarelli.com wrote: 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, Paul Benedict wrote: Then what was the point of getting the IP for XWork? On Tue, Dec 8, 2009 at 5:30 PM, Brian Pontarelli br...@pontarelli.com 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/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 lukasz.len...@googlemail.com wrote: 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/ - 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 - 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
Re: struts 2.2 and guice
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 scope, which I think Struts 2 could really benefit from. That's usually the first thing I have to hear from WebWork / Struts 2 users - Everything is tied to either the request or the session, I can't build wizard-style views I've always wondered about these things. I tend to use the request and page storage just because it seems simple and provides we with back button protections cheaply. I've wondered how complex they are to implement server side and the benefits of doing it on the server. The obvious one is security. Are there any others? Another benefit is that our current DI is limiting... In every case that I've used the Container directly, it was because I wanted to pick one instance out of a few possible implementation candidates. It's sort of silly that you have to grab the Container to say - give me the implementation of interface X called 'foo' Guice and the JSR have a number of things to help with this now. -bp - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
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. There are many applications and developers using it without major issues. I wonder how many users are actually swapping out the ObjectFactory at this point and wouldn't be fine with either Guice or Spring? There is also nothing stopping other DI containers from implementing JSR 330 and I would expect most will. I think the way to approach this is to have struts get out of the business of DI completely. If everything in Struts uses the JSR annotations and APIs, then Struts is really just a component of the web app and not really the owner. The webapp would declare its primary DI provider and then Struts would just wire up using that. The JSR also supports tiered injectors, which could be used to isolate Struts. If Struts defines generic modules, the webapp can easily place all those modules in a child injector if it wants. Or if could place it the main injector if it wants access to everything. Struts shouldn't be dictating its place in the webapp, the webapp should be dictating Struts place. Moving to JSR 330 should fix a lot of this. -bp On Dec 7, 2009, at 4:33 PM, Don Brown wrote: 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 is almost 5 megs means it is a no-go for me to use in our embedded OSGi container. I was hoping to get it back down under 2 megs, but with Guice 2, that would be quite unlikely. What features exactly do we need or how many bugs have cropped up in our DI container that we would be avoiding? Don On Tue, Dec 8, 2009 at 10:11 AM, Musachy Barroso musa...@gmail.com wrote: 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 does it, like we usually do. Also, guice 2 main jar is 651 kbs, so I don't see much of a problem there. musachy On Mon, Dec 7, 2009 at 2:55 PM, Don Brown mr...@twdata.org wrote: 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 shocked at the size of the jar nowadays...seems we went a bit crazy with the shading. I'd generally advise against adding more bulk without obvious gains. Don On Tue, Dec 8, 2009 at 7:09 AM, Musachy Barroso musa...@gmail.com wrote: 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 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 expect every Struts2 user and his company will be able to move to JSR330 compliant DI within the next months? I doubt that, and I'd rather not sacrifice our DI abstraction for that reason... - Rene Musachy Barroso wrote: 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 musa...@gmail.com wrote: 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 could be too big for a 2.x release I think musachy On Tue, Dec 1, 2009 at 10:44 AM, Brian Pontarelli br...@pontarelli.com wrote: 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 what we need, which I am not sure
Re: struts 2.2 and guice
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 the other two are proprietary. Paul On Tue, Dec 8, 2009 at 4:08 PM, Lukasz Lenart lukasz.len...@googlemail.com wrote: 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/ - 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
Re: struts 2.2 and guice
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, Paul Benedict wrote: Then what was the point of getting the IP for XWork? On Tue, Dec 8, 2009 at 5:30 PM, Brian Pontarelli br...@pontarelli.com 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/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 lukasz.len...@googlemail.com wrote: 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/ - 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
Re: struts 2.2 and guice
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 everything up as needed using a JSR 330 compliant implementation. -bp On Dec 8, 2009, at 5:34 PM, Paul Benedict wrote: 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. Lastly, because Bob Lee is a Struts committer, you should get pretty good support from him on. Paul On Tue, Dec 8, 2009 at 5:37 PM, Brian Pontarelli br...@pontarelli.com wrote: 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, Paul Benedict wrote: Then what was the point of getting the IP for XWork? On Tue, Dec 8, 2009 at 5:30 PM, Brian Pontarelli br...@pontarelli.com 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/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 lukasz.len...@googlemail.com wrote: 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/ - 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 - 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
Re: svn commit: r887991 - in /struts/sandbox/trunk/struts2-cdi-plugin: ./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/ src/main/java/org/apache/struts2/ src/main/java/org
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... 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 16:32:40 2009 New Revision: 887991 URL: http://svn.apache.org/viewvc?rev=887991view=rev Log: Initial work on a CDI / JSR299 plugin [snip] -- Wes Wannemacher Head Engineer, WanTii, Inc. Need Training? Struts, Spring, Maven, Tomcat... Ask me for a quote! - 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
Re: struts 2.2 and guice
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
Re: struts 2.2 and guice
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 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
Re: struts 2.2 and guice
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 to allow the application and framework to use the same DI container, just different Injectors. The default could be Guice but allow Spring to be pluggable (or even discoverable). As long as the internals of Struts are compliant, it should work fine. This also provides the benefit of configuration reduction in web.xml and a more comprehensive solution. It would also get Struts out of the business of building objects and requiring additional configuration and plugins for different DI containers. I would guess it would clean up the double ObjectFactory issues as well. -bp On Dec 1, 2009, at 11: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. On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt thechrispr...@gmail.com wrote: 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 br...@pontarelli.comwrote: 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 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 - 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
Re: struts 2.2 and guice
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 just invoke actions created by the DI container. Plus, if folks are asking for access to internals, this makes it simpler. You could also take the JCatapult approach and just have a single injector for everything. I personally like that approach the best, but Struts has had issues with public API breakage in the past and that would no longer be allowed if you have a single Injector. That is unless you roll a major version and follow a strict runtime compatibility methodology for a single major version's lineage. -bp On Dec 1, 2009, at 11:34 AM, Martin Cooper wrote: On Tue, Dec 1, 2009 at 10:31 AM, Musachy Barroso musa...@gmail.com 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's internal use only, so to speak, then why do we care about whether it's JSR annotations versus Guice annotations, and why would we want to make it pluggable? Those are things that app authors might care about, but not something we need to complicate the internal implementation with. -- Martin Cooper On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt thechrispr...@gmail.com wrote: 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 br...@pontarelli.comwrote: 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 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 - 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
Re: struts 2.2 and guice
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 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 think off the top of my head. musachy On Tue, Dec 1, 2009 at 10:38 AM, Brian Pontarelli br...@pontarelli.com wrote: 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 to allow the application and framework to use the same DI container, just different Injectors. The default could be Guice but allow Spring to be pluggable (or even discoverable). As long as the internals of Struts are compliant, it should work fine. This also provides the benefit of configuration reduction in web.xml and a more comprehensive solution. It would also get Struts out of the business of building objects and requiring additional configuration and plugins for different DI containers. I would guess it would clean up the double ObjectFactory issues as well. -bp On Dec 1, 2009, at 11: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. On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt thechrispr...@gmail.com wrote: 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 br...@pontarelli.comwrote: 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 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 - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h
Re: ognl 2.7.3 performance
I still think that the simplest approach is still to do nothing except
for EL and let the view technology do it all (JSP, FTL, VM, etc.). The
only time you need anything remotely similar to EL is for getting and
setting values out of beans. This is generally not EL handling, but
basic JavaBean handling. This topic has come up so many times and I
still feel it is a major barrier to entry for Struts.
-bp
On Nov 3, 2009, at 10:22 AM, Musachy Barroso wrote:
Well yes, that's by default, but with the new EL api you can plugin a
new EL resolver like:
JspApplicationContext jspApplicationContext =
JspFactory.getDefaultFactory().getJspApplicationContext
(servletContext);
jspApplicationContext.addELResolver(new CompoundRootELResolver());
and the container will delegate to that resolver. BTW the JUEL plugin
is in better shape than I thought, Tom are you out there?
musachy
On Tue, Nov 3, 2009 at 8:55 AM, Antonio Petrelli
antonio.petre...@gmail.com wrote:
2009/11/3 Antonio Petrelli antonio.petre...@gmail.com:
2009/11/3 Musachy Barroso musa...@gmail.com:
We also have FreeMarker , Velocity and we have a lot of expression
evaluations from Struts code itself.
And in this case you're right, EL at Struts-side is obligatory.
But exactly, is a bad idea to use the capability of the container to
resolve EL expressions into values?
This is just an idea.
Another thing, sorry for the noise :-D
If EL Expressions are interpreted Struts-side, this means that in JSP
tags the attributes that represent expressions should not be rtexpr
activated.
This means that they might not have an expression, so you cannot
write:
struts:tag expression=${myexpr} /
because it is not interpreted as a string, but as an expression
illegally placed.
So you should do funny things, like string composition, to let it
work.
Antonio
-
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
Re: ognl 2.7.3 performance
It's been a while, but that is really more of an current action stack
(I call it the ActionInvocation stack). I recall that I was able to
get most of the functionality I needed into JCatapult while still
using the FTL/JSP expression languages.
-bp
On Nov 3, 2009, at 11:10 AM, Musachy Barroso wrote:
That would be ok except for one thing: the value stack. To support the
value stack in those view technologies is the problem. I have tried so
many things, and failed in all of them that it is lame. I will finally
merge my parameters-binder branch in xwork into trunk, and see if I
can get some folks to look at it. With the parameters problem solved,
the rest is not *that* hard.
On Tue, Nov 3, 2009 at 10:00 AM, Brian Pontarelli br...@pontarelli.com
wrote:
I still think that the simplest approach is still to do nothing
except for
EL and let the view technology do it all (JSP, FTL, VM, etc.). The
only time
you need anything remotely similar to EL is for getting and setting
values
out of beans. This is generally not EL handling, but basic JavaBean
handling. This topic has come up so many times and I still feel it
is a
major barrier to entry for Struts.
-bp
On Nov 3, 2009, at 10:22 AM, Musachy Barroso wrote:
Well yes, that's by default, but with the new EL api you can
plugin a
new EL resolver like:
JspApplicationContext jspApplicationContext =
JspFactory.getDefaultFactory().getJspApplicationContext
(servletContext);
jspApplicationContext.addELResolver(new CompoundRootELResolver());
and the container will delegate to that resolver. BTW the JUEL
plugin
is in better shape than I thought, Tom are you out there?
musachy
On Tue, Nov 3, 2009 at 8:55 AM, Antonio Petrelli
antonio.petre...@gmail.com wrote:
2009/11/3 Antonio Petrelli antonio.petre...@gmail.com:
2009/11/3 Musachy Barroso musa...@gmail.com:
We also have FreeMarker , Velocity and we have a lot of
expression
evaluations from Struts code itself.
And in this case you're right, EL at Struts-side is obligatory.
But exactly, is a bad idea to use the capability of the
container to
resolve EL expressions into values?
This is just an idea.
Another thing, sorry for the noise :-D
If EL Expressions are interpreted Struts-side, this means that in
JSP
tags the attributes that represent expressions should not be
rtexpr
activated.
This means that they might not have an expression, so you cannot
write:
struts:tag expression=${myexpr} /
because it is not interpreted as a string, but as an expression
illegally placed.
So you should do funny things, like string composition, to let it
work.
Antonio
-
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
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
Re: The future of sitemesh integration with struts 2...
I was never big on the Servlet or Filter models. It seems to me that Struts2 is moving heavily towards conventions and the more things are just pluggable the easier it will be for users. I feel that the best approach would be for Struts2 to discover SiteMesh in the class path and wire it up automatically. I'd also wonder if this could be another case for some additional annotations in addition to XML configuration for defining templates. Anyways, this is how I would proceed and leverage SiteMesh 3. This is my plan for JCatapult. -bp On Oct 23, 2009, at 8:38 AM, Christian Stone wrote: I have a working Struts 2 application where I am using Velocity AND Freemarker decorators now intechangeably and SiteMesh is dispatching them. The full value stacks are available in each, as the same Configurations are running on both the decorators and the struts results. You can now have decorators in Freemarker, Velocity, and JSP as long as the servlets are defined in your web.xml. I had to make a lot of changes to bring the plugin up to date with the modern freemarker, so good that this will be getting in early! Note that the old plugin fix I did is still there, so you can use either of the two published solutions you wish, and you no longer are using a crippled Freemarker with the new solution (shown below). I think my chin dropped when I saw all the decorators mixed in one decorator.xml and compiling. I am accessing all my statics in my freemarker decorator (velocity 1.3 does not support such things), so that is fixed as well. Absolutely sweet! On another note, I was able to streamline the process a bit, so there should be a subtle speed improvement as well. Here is an example web.xml snippet with the new changes hilighted. Currently I read the configuration from freemarker.properties as well as velocity.properties, and add any parameters present in the servlet, so the init phase for the two technologies is a bit more flexible and dynamic. filter filter-namestruts-prepare/filter-name filter- classorg.apache.struts2.dispatcher.ng.filter.StrutsPrepareFilter/ filter-class init-param param-nameactionPackages/param-name param-valuenet.stonescape.renegade20.presentation/ param-value /init-param /filter filter filter-namesitemesh/filter-name filter- classcom.opensymphony.sitemesh.webapp.SiteMeshFilter/filter-class /filter filter filter-namestruts-execute/filter-name filter- classorg.apache.struts2.dispatcher.ng.filter.StrutsExecuteFilter/ filter-class /filter filter filter-nametiming/filter-name filter-classnet.stonescape.common.filter.TimerFilter/ filter-class /filter filter-mapping filter-nametiming/filter-name url-pattern/*/url-pattern dispatcherREQUEST/dispatcher /filter-mapping filter-mapping filter-namestruts-prepare/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namesitemesh/filter-name url-pattern/*/url-pattern dispatcherREQUEST/dispatcher dispatcherFORWARD/dispatcher dispatcherINCLUDE/dispatcher /filter-mapping filter-mapping filter-namestruts-execute/filter-name url-pattern/*/url-pattern /filter-mapping servlet servlet-namesitemesh-freemarker/servlet-name servlet- classorg.apache.struts2.sitemesh.FreemarkerDecoratorServlet/ servlet-class init-param param-namedefault_encoding/param-name param-valueUTF-8/param-value /init-param load-on-startup1/load-on-startup /servlet servlet-mapping servlet-namesitemesh-freemarker/servlet-name url-pattern*.ftl/url-pattern /servlet-mapping servlet servlet-namesitemesh-velocity/servlet-name servlet- classorg.apache.struts2.sitemesh.VelocityDecoratorServlet/servlet- class init-param param-namedefault_encoding/param-name param-valueUTF-8/param-value /init-param load-on-startup1/load-on-startup /servlet servlet-mapping servlet-namesitemesh-velocity/servlet-name url-pattern*.vm/url-pattern /servlet-mapping -- Christian Stone On Oct 22, 2009, at 4:00 PM, Musachy Barroso wrote: that sounds pretty reasonable to me. if you are up for the task, go for it. 2.2 is far in the horizon and this would be a good time for this kind of stuff. musachy -- _,-- cws`-._-___ _'--''--'_ //_| | \ Christian Stone, Software Engineer / | |_\\ (_|_|__= xt...@stonescape.net =__|_|_) _\_=__ http://xtian.stonescape.net/___/_
Re: The future of sitemesh integration with struts 2...
I've done some work with it and it looks to be completely pluggable. I do this same thing in JCatapult with other libraries. Essentially, I define a workflow chain in a configuration file that is the default and it contains items that might not exists on the classpath. If a specific workflow isn't there, I just de-activate it. This is essentially how Struts2 would want to determine if SiteMesh 3 is in the classpath. If it is, it would wire things up. If not, it would de- activate that part of the filter-chain. In terms of SiteMesh 3 being capable of being called programmatically, last time I looked this was one of the primary goals. The API was well defined and it allowed SiteMesh to be invoked from nearly any code. I recall some discussion of allowing it to be used outside of a servlet container as well. I'll have to circle back and see if that is possible. I was also planning on incorporating SiteMesh into the JCatapult email library so that emails could also be decorated. Once I get that stuff going, I'll let you know. I also will try and work with the SiteMesh developers on ensuring the integration is as generic and simple as possible. -bp On Oct 23, 2009, at 9:35 AM, Christian Stone wrote: There is some time before SiteMesh 3 comes prime time, so there is plenty of time for thought here. I do love the idea of wiring it up directly... However, since SiteMeshFilter requires the dispatcher to handle requests, you would have to incorporate the SiteMesh filter directly into the struts filter chain, and I think this would require struts to absorb much of the sitemesh codebase (unless the SiteMesh developer were to refactor the code a whole lot more to allow it to plug in to other filters and not be a filter on its own). The same thing would go for the dispatchers, since struts would have to insert them on the chain as well. It does seem like a lot of work without a noticeable benefit to the users (they still have to configure a decorators file, etc., and which filters/dispatchers are potentially causing conflicts would be hidden from the user). Additionally, they still would have to configure the dispatcher, at least for the request mapping, and I think it is less intuitive to put it into a struts config file than web.xml where they are used to such configurations (again, at this time). With all that said, if you want to take on the task of working with SiteMesh 3 and making it truly pluggable and modular (such as a JCatapult module), that would be awesome. Once that happens the work on the Struts side shouldn't be so bad (presuming the core architecture is in place)! If the convention of Struts is to configure and deploy everything, including JSP dispatcher, etc. then I love the idea! -- Christian On Oct 23, 2009, at 11:13 AM, Brian Pontarelli wrote: I was never big on the Servlet or Filter models. It seems to me that Struts2 is moving heavily towards conventions and the more things are just pluggable the easier it will be for users. I feel that the best approach would be for Struts2 to discover SiteMesh in the class path and wire it up automatically. I'd also wonder if this could be another case for some additional annotations in addition to XML configuration for defining templates. Anyways, this is how I would proceed and leverage SiteMesh 3. This is my plan for JCatapult. -bp -- _,-- cws`-._-___ _'--''--'_ //_| | \ Christian Stone, Software Engineer / | |_\\ (_|_|__= xt...@stonescape.net =__|_|_) _\_=__ http://xtian.stonescape.net/___/_ \/-(o)-~~-(o)-~~-(o)-`--'-(o)-~~-(o)-~~-(o)-\/ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: The future of sitemesh integration with struts 2...
On Oct 23, 2009, at 10:10 AM, Christian Stone wrote: On Oct 23, 2009, at 12:01 PM, Brian Pontarelli wrote: I've done some work with it and it looks to be completely pluggable. I do this same thing in JCatapult with other libraries. Essentially, I define a workflow chain in a configuration file that is the default and it contains items that might not exists on the classpath. If a specific workflow isn't there, I just de-activate it. This is essentially how Struts2 would want to determine if SiteMesh 3 is in the classpath. If it is, it would wire things up. If not, it would de-activate that part of the filter-chain. In terms of SiteMesh 3 being capable of being called programmatically, last time I looked this was one of the primary goals. The API was well defined and it allowed SiteMesh to be invoked from nearly any code. I recall some discussion of allowing it to be used outside of a servlet container as well. I'll have to circle back and see if that is possible. I was also planning on incorporating SiteMesh into the JCatapult email library so that emails could also be decorated. Once I get that stuff going, I'll let you know. I also will try and work with the SiteMesh developers on ensuring the integration is as generic and simple as possible. -bp This sounds great! I was just reviewing the alpha SiteMesh3 and while it is far from complete it still seems to be tied to the same filter/dispatcher architecture. Perhaps if SiteMesh allowed for configurable renderers... now that would be great! Check out all the offline and builder stuff in there. You can build a Context yourself or use the offline or webapp Contexts. Plus, everything passed to the Context's constructors are interfaces. There are a number of implementations of these interfaces that you can use or you can provide your own implementations. In SiteMesh 3 the decorators are just HTML. This means that I can use this process to handle everything: 1. Render the result FTL into HTML 2. Render the decorator FTL into HTML 3. Pass the result and decorator HTML to SiteMesh 3 4. SiteMesh spits out the final HTML 5. Push final HTML to client Should be very straight-forward in fact. -bp - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: The future of sitemesh integration with struts 2...
From my conversations with Joe, integration will be much simpler with the next version. I'm looking at using the next version so that all the templates are FreeMarker and I will be able to create my own FreeMarker root context. It also looked like everything was going to be extendable or overridable and it will also provide programmatic access to everything so that it can be invoked from nearly anywhere. SiteMesh has moved out of Open Symphony to Github and the new sitemesh.org site. It doesn't look like anything new has happened since September. Perhaps we need to rally around SiteMesh and help get that project to 3.0 since it will benefit so many projects, including Struts 2. -bp On Oct 22, 2009, at 12:48 PM, Christian Stone wrote: I spent some time rethinking the architecture, and it seems like there is a strong case to rethink the future of the struts2-sitemesh plugin. The current plugin uses and has used a new filter to override the SiteMeshFilter code. SiteMeshFilter eventually leaves the dispatcher to handle the request. This works for JSP, as it can easily access things like static resources, but is a bit more difficult for Freemarker and Velocity which do not compile against the java codebase before execution. The problem is that struts would like to inject things like properties and static class variables into the value stack, and it does so with the FreemarkerManager and VelocityManager classes. These two classes provide the resources for evaluation of the appropriate files within the struts result handling, but they do not provide the managers for the SiteMesh decorators. After rethinking things a bit, I am wondering why the path of providing filters to integrate into SiteMesh were used as opposed to providing a custom Struts 2 FreemarkerServlet and VelocityServlet dispatcher. If the latter choice were made, you could likely override the preTemplateProcess(...) in the FreemarkerServlet class as an example of how you can add the needed properties into Freemarker to evaluate without having to dig inside of SiteMesh and other technologies. The second concern that I have is that you have a separate manager for every technology you wish to support. If a developer wishes to include statics and use both technologies, they have to include them twice. Perhaps a custom manager for providing mapped and static resources would be better that would be incorporated into the Freemarker and Velocity Managers. Simply put, the TemplateMapProvider (or whatever it should be called), would include all the statics resources and dynamic resources needed for any template processing. I understand that I do not have a deep knowledge of the architecture of Struts 2, so I ask why the first and not second path was chosen (the one of providing filters). More specifically, given the path of SiteMesh and how it will be mixing velocity and freemarker in SiteMesh 3, it seems that the best path would be to use the Servlet model and not the filter model in the future. So what am I missing? -- Christian Stone - 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
Re: XWork: Real UTF-8 in *.properties
I just finished a massive license audit for some internal things. It is an enormous pain. GPL is incompatible with ASL because of the redistribution portions of the licenses. ASL lets you redistribute without any restrictions. This allows commercial software to ship ASL Jar files inside the software. GPL doesn't allow this unless it has an exception. GPL states that if you want to redistribute a piece of GPL software, it can only be redistributed inside another GPL piece of software. This means that if you ship Struts with anything GPL inside it, it auto-magically becomes GPL and then no one developing a commercial software product would use Struts anymore. In most cases with Java, GPL should be avoided like the plague. I personally think this is one of the reasons people are switching to Postgres from MySQL (among other reasons as well). -bp On Oct 14, 2009, at 9:52 AM, Martin Cooper wrote: On Wed, Oct 14, 2009 at 3:07 AM, Alex Siman aleksandr.si...@gmail.com wrote: What is the problem with that GPL? From http://www.apache.org/licenses/GPL-compatibility.html GPLv3 software cannot be included in Apache projects. The licenses are incompatible in one direction only, and it is a result of ASF's licensing philosophy and the GPLv3 authors' interpretation of copyright law. -- Martin Cooper Maybe we can ask the j18n author to add Apache kind license? BTW I used to think that open source is really open. I am bored w/ all those licenses. IMHO it's like native2ascii to me. Philip Luppens wrote: On Wed, Oct 14, 2009 at 11:09 AM, Alex Siman aleksandr.si...@gmail.com wrote: I hacked class [com.opensymphony.xwork2.util.LocalizedTextUtil] and now it uses [http://sourceforge.net/projects/j18n/] to load resource bundles. J18n allows *.properties files to be in UTF-8 encoding and contain not escaped UTF-8 characters. This is very usable in comparison with Java's native2ascii. native2ascii is a very big mess! I fully agree - the native2ascii approach is a mess and even with IntelliJ's transparent support, I still find myself encountering issues. I never understood why the XML properties are read by default in UTF-8 and the line based properties use latin-1. But I digress ... All that needs to be replaced in LocalizedTextUtils is: ResourceBundle.getBundle - J18n.getBundle I know that there were some plans on UTF-8 in XWork, but I do not how the current status of them. Contacting issues aside, the problem here is the GPL license. Cheers, Phil -- View this message in context: http://www.nabble.com/XWork%3A-Real-UTF-8-in-*.properties-tp25887706p25887706.html Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org -- We cannot change the cards we are dealt, just how we play the hand. - Randy Pausch - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org -- View this message in context: http://www.nabble.com/XWork%3A-Real-UTF-8-in-*.properties-tp25887706p25888384.html Sent from the Struts - Dev mailing list archive at Nabble.com. - 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
Re: Struts2 validation
Actually, I think this is in regards to the JSF validation attributes yo can specify on the JSF tags. I believe that this either does some serialization magic or some session magic to connect the attributes specified on the tags with the server-side validator. I think it looks like: jsf:text ... jsf:validatorLength minimum=3 maximum=20/ /jsf:text I've always wondered if validation belongs there or not. I personally like to see validation closer to the data itself and would rather use the validation JSR for everything moving forward. -bp On Aug 24, 2009, at 9:41 AM, Chris Pratt wrote: Yes, the workflow interceptor handles programmatic validation. Unless you are talking about client side validation (since you mention the JSP), then I would suggest looking at jQuery Validate. (*Chris*) On Mon, Aug 24, 2009 at 5:19 AM, Arthur Neves arthu...@gmail.com wrote: Tks Chris, however I'm asking here because I'd like to know if there are some way to make validations like in the JSF. Making validation directly in JSP. If there isn't a similar way in Struts2, It will be cool to create! Because in struts1, I've already had some problems with validation.xml, like in dynamic JSPs, or in JSPs that some fields can't be rendering. So, do we have this in Struts2? ..Regards. 2009/8/24 Chris Pratt thechrispr...@gmail.com Yes there is, but you'll need to ask that question over on the User list. This list is for the development of Struts itself. (*Chris*) On Sun, Aug 23, 2009 at 7:59 PM, Arthur Neves arthu...@gmail.com wrote: Is there any way to make validations on struts2 not through xml validation. - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: embedded JSPs plugin
Does this plugin provide for executing the JSPs in unit tests? Embedding is really nice, but unit testing is even better. -bp On Aug 13, 2009, at 12:27 PM, Wes Wannemacher wrote: I think it is a good idea, as much as I dislike JSP (because it is so non-portable, which this very plugin addresses), it is ubiquitous. -Wes On Thu, Aug 13, 2009 at 2:16 PM, Musachy Barrosomusa...@gmail.com wrote: The JSP plugin turned out to work better than I expected(tags and includes work), so I would like to bring it out of the sandbox and label it as experimental until we get more people to try it out. Any objections/comments (this is not a vote thread, that will be later if there are no objections)? musachy -- Hey you! Would you help me to carry the stone? Pink Floyd - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org -- Wes Wannemacher Head Engineer, WanTii, Inc. Need Training? Struts, Spring, Maven, Tomcat... Ask me for a quote! - 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
Re: Let's kill xwork (was Re: 2.1.8 release?)
Except the API changes. Remember that any API change that breaks someone should be a major release. That's why people work so hard on keeping old APIs around. Sent from my iPhone On Aug 12, 2009, at 3:45 PM, Wendy Smoak wsm...@gmail.com wrote: On Wed, Aug 12, 2009 at 2:36 PM, Paul Benedictpbened...@apache.org wrote: I definitely agree that Struts 3 would be a good candidate to do this XWork migration. It is not an appropriate candidate for 2.1, or 2.2. However, if you like to do a 2.5 (I dislike superficial jumps in versions though), then it might be acceptable in the 2.x branch. IMO Struts 3 would imply a major change in Struts itself, the possibility of backwards incompatible changes, etc. This isn't... community aspects aside, it's just moving some code from one svn repo to another. -Wendy - 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
Re: Let's kill xwork (was Re: 2.1.8 release?)
On Aug 10, 2009, at 11:52 PM, Don Brown wrote: On Tue, Aug 11, 2009 at 3:38 PM, Paul Benedictpbened...@apache.org wrote: On Tue, Aug 11, 2009 at 12:22 AM, Don Brown donald.br...@gmail.com wrote: By forking XWork, we can a) bring core Struts 2 code into the project where it belongs and b) still leave it available for other users in OpenSymphony. If you fork XWork, it obviously won't be XWork anymore. If that's what you want to do to cut the apron strings, then I can agree to that. However, I thought you guys were saying you actually want to make Apache *OWN* XWork. That's something completely different and am against. If the code is copied into Struts as fork, the whole XWork branding should wash away and Struts should have no more reference to xwork anywhere. Awesome - that is exactly what I'm saying. Kill it with fire! :) Oh yeah! Burn baby burn! Maybe its time to branch Struts core, drop in xwork, refactor the heck out of it, and call it struts 3. Code name the release Phoenix. :) -bp - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Personally, I feel that struts top to bottom should be web centric and not try to abstract out JEE. This makes life cumbersome and difficult in many cases. Often this also leads to hacking interfaces or writing tricky new semantics on top of more general interfaces in order to get access to the web APIs. I'd vote for dropping it into core and slowly rewriting it to be 100% web centric. This is also my feeling about OGNL/MVEL or any expression language. The expression language for struts should be written to handle all the crazy cases that come up with the web, specifically type conversions. -bp On Aug 10, 2009, at 11:32 AM, Martin Cooper wrote: If we bring XWork here and it becomes its own subproject, it will have its own release cycle. This will allow people to use XWork independently of Struts, but it means there is still a separate release cycle, independent of the Struts 2 release cycle. Thus we're in pretty much the same situation as we are now, except for the location of the code base. If we bring it here and embed it within the Struts 2 core, then it will become part of the Struts 2 release, but will no longer be available as an independent entity. This means it probably will not be usable outside of Struts 2, will not be identifiable as an independent entity, and almost certainly will lose its identity as a separately usable library. Which are we trying to do? I am hearing advocates of both approaches, each with their own pros and cons... Also, are all of the existing XWork committers already Struts committers? If not, what do we plan to do about that? -- Martin Cooper On Wed, Aug 5, 2009 at 10:12 PM, Don Brown donald.br...@gmail.com wrote: XWork was left at OpenSymphony, because at the time, there were a number of WebWork developers still around and we wanted to continue to work together. Today, WebWork activity seems all but dead, leaving us with no advantages having the code hosted over there. Furthermore, having critical code in different packages is really confusing for developers of the framework and its apps with no apparent benefit. Ideally, I'd like to bring xwork trunk into the core jar and be done with the theoretically useful yet practically painful split. However, that would break Struts 2 apps without tedious backwards- compatibility code, but getting the code bases integrated is the first step. Maybe at first, we keep two artifacts, but I think we should think about a serious migration to just one. XWork itself will always be around, but trying to put a framework at our core that is meant for ambiguous theoretical users brings unnecessary complexity and problems to all parties. Can I start planning the funeral? :) Don On Thu, Aug 6, 2009 at 11:55 AM, Wes Wannemacherw...@wantii.com wrote: On Wednesday 05 August 2009 09:44:45 pm Musachy Barroso wrote: [snip] I was going to ask if anyone was using it outside struts, but that doesn't prevent us from making it it's own artifact. [snip] I don't think this would fix the problem, which is the duplicated effort on the builds. A good compromise would be to keep it under its own artifact under struts, just like core, that way we would need just one release and it could still be used independently. I haven't cared much before, but if it will make our releases easier/smoother, then I am +1 for it. being its own artifact makes more sense, it would make releasing the two much easier, on second thought I agree with this. My only real concern is that I can get to it w/o struts. The context I am working with now doesn't fit well with struts, and adding struts means I would have to do even more work getting a base configuration so that xwork can run actions. One example that sticks out in my mind is that when I run actions, each action execution gets its own thread and one of the results I built for this project launches from 1 to infinite more actions. Obviously it wouldn't make sense to chain to multiple actions in a web-app and since a view is rendered in struts, having actions run in a separate thread wouldn't work well in a web-app. -W -- Wes Wannemacher Head Engineer, WanTii, Inc. Need Training? Struts, Spring, Maven, Tomcat... Ask me for a quote! - 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
Re: Let's kill xwork (was Re: 2.1.8 release?)
I'm all for this ;) (http://markmail.org/message/nykgr354ts4hlkif) -bp On Aug 5, 2009, at 11:12 PM, Don Brown wrote: XWork was left at OpenSymphony, because at the time, there were a number of WebWork developers still around and we wanted to continue to work together. Today, WebWork activity seems all but dead, leaving us with no advantages having the code hosted over there. Furthermore, having critical code in different packages is really confusing for developers of the framework and its apps with no apparent benefit. Ideally, I'd like to bring xwork trunk into the core jar and be done with the theoretically useful yet practically painful split. However, that would break Struts 2 apps without tedious backwards-compatibility code, but getting the code bases integrated is the first step. Maybe at first, we keep two artifacts, but I think we should think about a serious migration to just one. XWork itself will always be around, but trying to put a framework at our core that is meant for ambiguous theoretical users brings unnecessary complexity and problems to all parties. Can I start planning the funeral? :) Don On Thu, Aug 6, 2009 at 11:55 AM, Wes Wannemacherw...@wantii.com wrote: On Wednesday 05 August 2009 09:44:45 pm Musachy Barroso wrote: [snip] I was going to ask if anyone was using it outside struts, but that doesn't prevent us from making it it's own artifact. [snip] I don't think this would fix the problem, which is the duplicated effort on the builds. A good compromise would be to keep it under its own artifact under struts, just like core, that way we would need just one release and it could still be used independently. I haven't cared much before, but if it will make our releases easier/smoother, then I am +1 for it. being its own artifact makes more sense, it would make releasing the two much easier, on second thought I agree with this. My only real concern is that I can get to it w/o struts. The context I am working with now doesn't fit well with struts, and adding struts means I would have to do even more work getting a base configuration so that xwork can run actions. One example that sticks out in my mind is that when I run actions, each action execution gets its own thread and one of the results I built for this project launches from 1 to infinite more actions. Obviously it wouldn't make sense to chain to multiple actions in a web-app and since a view is rendered in struts, having actions run in a separate thread wouldn't work well in a web-app. -W -- Wes Wannemacher Head Engineer, WanTii, Inc. Need Training? Struts, Spring, Maven, Tomcat... Ask me for a quote! - 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
Re: [SUNDAY] Struts 2 and EL
I would say the reason you don't want to dive into 233 would be primarily because of performance. You'd either need to have a compiled statement cache or pre-compile. Most of the scripting frameworks that comply with 233 are full blow languages (Groovy, JavaScript, etc) and have pretty slow parsers compared to EL parsers out there. You could give them a try and see, but I would guess you would see a large drop in performance using them. I personally think MVEL is one of the better ways to go once they finish some of the new features they have in mind for the next version (i.e. annotations and such). Or just write your own. I wrote one for JCatapult and it took about a day. It isn't as fast as MVEL, but it works fine for what I need and it doesn't mean it can't be improved on. The primary reason I did that exercise was to fully support 1.5 and generics as well as provide a better type conversion API with annotation support. The way I wrote it you can specify additional attributes using the taglibs or via an annotation that tell the API how to convert Strings to things like Money, dates, and JODA classes. -bp On Jul 5, 2009, at 4:13 PM, Musachy Barroso wrote: After fighting OGNL and MVEL for a while I've got to the conclusion that they aren't the best horses to bet my money on, some of the reasons are not even technical so I won't go into them. So I have been playing with a new idea, why should we couple struts to an EL, when we can use JSR 223 (Scripting for the Java platform, some docs here: http://java.sun.com/developer/technicalArticles/J2SE/Desktop/scripting/) , and just make Struts EL agnostic? I know security would be a concern, but at least we got standard ways to limit what these scripts can do or not. it would be very cool if I could just set constant name=struts.scriptEngine value=groovy / and then just use all of groovy's cool stuff in the tags. So if people can just pick their favorite engine, instead of being stuck with our supported implementation. What do you think? musachy -- Hey you! Would you help me to carry the stone? Pink Floyd - 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
Re: [SUNDAY] Struts 2 and EL
I sorta figured it would be pretty slow. You might also run into some issues with the APIs depending on how you want to handle type conversion stuff. The JCatapult EL is mostly decoupled from the rest of the framework except that I use the JCatapult ObjectFactory to create instances of the type converters. However, that would be simple to replace. Eventually I'd like to figure out where my slow-down is compared to MVEL and see if I can get it to perform the same. I think my caching needs a bit of love and also it might be helpful to compile the statements into Java classes at some point. -bp On Jul 6, 2009, at 11:28 AM, Musachy Barroso wrote: yes, I was testing different engines yesterday, and groovy is around 30 times slower than OGNL, and Rhino around 17 times. JEXL seemed to be the faster one, around 7x slower. That being said, it doesn't change anything because what I am suggesting is decoupling the actual implementation, OGNL could still be used thru jsr 223, as an option and default implementation. we would need the value stack just to lookup values, for setting values we could use the new binder implementation, to which I just added bytecode generation for setters/getters. is your EL decoupled fro jcatapult? musachy On Mon, Jul 6, 2009 at 10:13 AM, Brian Pontarellibr...@pontarelli.com wrote: I would say the reason you don't want to dive into 233 would be primarily because of performance. You'd either need to have a compiled statement cache or pre-compile. Most of the scripting frameworks that comply with 233 are full blow languages (Groovy, JavaScript, etc) and have pretty slow parsers compared to EL parsers out there. You could give them a try and see, but I would guess you would see a large drop in performance using them. I personally think MVEL is one of the better ways to go once they finish some of the new features they have in mind for the next version (i.e. annotations and such). Or just write your own. I wrote one for JCatapult and it took about a day. It isn't as fast as MVEL, but it works fine for what I need and it doesn't mean it can't be improved on. The primary reason I did that exercise was to fully support 1.5 and generics as well as provide a better type conversion API with annotation support. The way I wrote it you can specify additional attributes using the taglibs or via an annotation that tell the API how to convert Strings to things like Money, dates, and JODA classes. -bp On Jul 5, 2009, at 4:13 PM, Musachy Barroso wrote: After fighting OGNL and MVEL for a while I've got to the conclusion that they aren't the best horses to bet my money on, some of the reasons are not even technical so I won't go into them. So I have been playing with a new idea, why should we couple struts to an EL, when we can use JSR 223 (Scripting for the Java platform, some docs here: http://java.sun.com/developer/technicalArticles/J2SE/Desktop/scripting/) , and just make Struts EL agnostic? I know security would be a concern, but at least we got standard ways to limit what these scripts can do or not. it would be very cool if I could just set constant name=struts.scriptEngine value=groovy / and then just use all of groovy's cool stuff in the tags. So if people can just pick their favorite engine, instead of being stuck with our supported implementation. What do you think? musachy -- Hey you! Would you help me to carry the stone? Pink Floyd - 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 -- Hey you! Would you help me to carry the stone? Pink Floyd - 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
Re: [SUNDAY] Struts 2 and EL
Yeah, same here. Everything broke down when it came to two use cases:
- The difference between a user type conversion error (user puts in
'a' in a text box that is mapped to an Integer field property) and a
developer type conversion error (developer didn't specify the date
format for a specific field)
- Generics
I figured as long as I was in there, I might as well make my type
converters handle most anything. The only thing they don't handle well
right now is when you have two fields that map to a single immutable
property:
public class MyAction {
// For select
public ListString currencies = ...;
// From the form (requires a currency code to be valid)
public Money amount;
}
[...@jc.form action=/my-action]
[...@jc.text name=amount/]
[...@jc.select items=currencies name=amount.currencyCode/]
[/@jc.form]
This one is tricky because it requires that the properties both be
passed to the type converter. Right now you can do this:
[...@jc.form action=/my-action]
[...@jc.text name=amount _currencyCode=USD/]
[/@jc.form]
And the currencyCode attribute is passed to the type converter, but I
haven't figured out a way to do the other case quite yet.
Anyways, thanks for the pointer to the accessor helper. I'll
definitely add it and see if it shaves off some processing time.
-bp
On Jul 6, 2009, at 12:04 PM, Musachy Barroso wrote:
yes, type conversion has been a pain for me, and the reason why I
couldn't just use MVEL. Implementing value look ups is easy with any
of the ELs, setting values is a different matter, because other ELs
don't have an API as flexible as OGNL.
If you are not using bytecode for getting/seeting values, you can use
asm easily:
http://svn.opensymphony.com/svn/xwork/branches/parameter-binder/core/src/main/java/com/opensymphony/xwork2/parameters/bytecode/AccessorBytecodeUtil.java
musachy
On Mon, Jul 6, 2009 at 10:41 AM, Brian
Pontarellibr...@pontarelli.com wrote:
I sorta figured it would be pretty slow. You might also run into
some issues
with the APIs depending on how you want to handle type conversion
stuff.
The JCatapult EL is mostly decoupled from the rest of the framework
except
that I use the JCatapult ObjectFactory to create instances of the
type
converters. However, that would be simple to replace. Eventually
I'd like to
figure out where my slow-down is compared to MVEL and see if I can
get it to
perform the same. I think my caching needs a bit of love and also
it might
be helpful to compile the statements into Java classes at some point.
-bp
On Jul 6, 2009, at 11:28 AM, Musachy Barroso wrote:
yes, I was testing different engines yesterday, and groovy is around
30 times slower than OGNL, and Rhino around 17 times. JEXL seemed to
be the faster one, around 7x slower.
That being said, it doesn't change anything because what I am
suggesting is decoupling the actual implementation, OGNL could still
be used thru jsr 223, as an option and default implementation.
we would need the value stack just to lookup values, for setting
values we could use the new binder implementation, to which I just
added bytecode generation for setters/getters.
is your EL decoupled fro jcatapult?
musachy
On Mon, Jul 6, 2009 at 10:13 AM, Brian Pontarellibr...@pontarelli.com
wrote:
I would say the reason you don't want to dive into 233 would be
primarily
because of performance. You'd either need to have a compiled
statement
cache
or pre-compile. Most of the scripting frameworks that comply with
233 are
full blow languages (Groovy, JavaScript, etc) and have pretty slow
parsers
compared to EL parsers out there. You could give them a try and
see, but
I
would guess you would see a large drop in performance using them. I
personally think MVEL is one of the better ways to go once they
finish
some
of the new features they have in mind for the next version (i.e.
annotations
and such).
Or just write your own. I wrote one for JCatapult and it took
about a
day.
It isn't as fast as MVEL, but it works fine for what I need and it
doesn't
mean it can't be improved on. The primary reason I did that
exercise was
to
fully support 1.5 and generics as well as provide a better type
conversion
API with annotation support. The way I wrote it you can specify
additional
attributes using the taglibs or via an annotation that tell the
API how
to
convert Strings to things like Money, dates, and JODA classes.
-bp
On Jul 5, 2009, at 4:13 PM, Musachy Barroso wrote:
After fighting OGNL and MVEL for a while I've got to the
conclusion
that they aren't the best horses to bet my money on, some of the
reasons are not even technical so I won't go into them. So I
have been
playing with a new idea, why should we couple struts to an EL,
when we
can use JSR 223 (Scripting for the Java platform, some docs here:
http://java.sun.com/developer/technicalArticles/J2SE/Desktop/scripting/)
,
and just make Struts EL agnostic? I know security
Re: Google App Engine support?
Probably looking for configuration or something like that. On Apr 13, 2009, at 7:11 AM, Musachy Barroso wrote: I was working on the OSGi plugin this weekend so I didn't look at it, but this got me thinking, what is SiteMesh doing with JNDI anyway? musachy On Mon, Apr 13, 2009 at 7:27 AM, Al Sutton a...@funkyandroid.com wrote: At the moment I'm giving http://groups.google.com/group/google-appengine-java/browse_thread/thread/1e 3868a6a2661585 a spin. Al. --- * Written an Android App? - List it at http://andappstore.com/ * == Funky Android Limited is registered in England Wales with the company number 6741909. The registered head office is Kemp House, 152-160 City Road, London, EC1V 2NX, UK. The views expressed in this email are those of the author and not necessarily those of Funky Android Limited, it's associates, or it's subsidiaries. -Original Message- From: Brian Pontarelli [mailto:br...@pontarelli.com] Sent: 10 April 2009 16:12 To: Struts Developers List Subject: Re: Google App Engine support? Interesting. On the Guice list there is another thread about GAE. You should submit a bug for Sitemesh to Google and to the Sitemesh maintainers. Google seems to be up for fixing some of these issues. This one looks like either a JNDI bug or JNDI security measure (my guess is the later). Either way, it should be simple to fix. You could also roll a new Sitemesh JAR that smothers JNDI lookup errors. -bp On Apr 10, 2009, at 12:40 AM, Al Sutton wrote: Great. Nice work!!! Unfortunately most of my apps use sitemesh, so there's still some things for me to sort out before I can make full use of GAE :(. Al. --- * Written an Android App? - List it at http://andappstore.com/ * == Funky Android Limited is registered in England Wales with the company number 6741909. The registered head office is Kemp House, 152-160 City Road, London, EC1V 2NX, UK. The views expressed in this email are those of the author and not necessarily those of Funky Android Limited, it's associates, or it's subsidiaries. -Original Message- From: Don Brown [mailto:mr...@twdata.org] Sent: 10 April 2009 05:26 To: Struts Developers List Subject: Re: Google App Engine support? Huzzah, it works. Once I removed sitemesh, the simple starter app works: http://struts2-demo.appspot.com/index.action I want to add a new option that allows the user to disable the ognl permission checks, so I'm guessing I'll do that in trunk. Any objections? Don On Fri, Apr 10, 2009 at 1:54 AM, Musachy Barroso musa...@gmail.com wrote: thanks. I got it to work and uploaded to struts-demo, and yeah I also got the classnotfound exception. I will piggyback on Don's research ;) musachy On Thu, Apr 9, 2009 at 11:47 AM, Al Sutton a...@funkyandroid.com wrote: Appcfg is a script which just runs a java app and uses wherever it picks Java up from as the java.home variable. This means if it picks up the jre java version it won't find javac and bail on you about 10 or 20-odd percent in. AppEngine invite on its' way btw, I don't know if Don wants to add you as a comitter to his git repo. Al. --- * Written an Android App? - List it at http://andappstore.com/ * == Funky Android Limited is registered in England Wales with the company number 6741909. The registered head office is Kemp House, 152-160 City Road, London, EC1V 2NX, UK. The views expressed in this email are those of the author and not necessarily those of Funky Android Limited, it's associates, or it's subsidiaries. -Original Message- From: Musachy Barroso [mailto:musa...@gmail.com] Sent: 09 April 2009 16:44 To: Struts Developers List Subject: Re: Google App Engine support? yeah sure. Let me try that, it is probably getting confused with one of the 1234e10 SDKs/JREs I have around. musachy On Thu, Apr 9, 2009 at 11:34 AM, Al Sutton a...@funkyandroid.com wrote: Set JDK_HOME\bin first on your path. If it picks up the JRE version of java you're stuffed. Do you want an invite the project I set up that Don is working on? Al. --- * Written an Android App? - List it at http://andappstore.com/ * == Funky Android Limited is registered in England Wales with the company number 6741909. The registered head office is Kemp House, 152-160 City Road, London, EC1V 2NX, UK. The views expressed in this email are those of the author and not necessarily those of Funky Android Limited, it's associates, or it's subsidiaries. -Original Message- From: Musachy Barroso [mailto:musa...@gmail.com] Sent: 09 April 2009 16:24 To: Struts Developers List Subject: Re: Google App Engine support? I am trying it also, but I can't get appcfg to find javac. musachy On Thu, Apr 9, 2009 at 11:17 AM, Al Sutton a...@funkyandroid.com wrote: No worries. Enjoy, Al. --- * Written an Android App? - List it at http://andappstore.com/ * == Funky Android Limited is registered in England Wales with the company number 6741909
Re: Google App Engine support?
Interesting. On the Guice list there is another thread about GAE. You should submit a bug for Sitemesh to Google and to the Sitemesh maintainers. Google seems to be up for fixing some of these issues. This one looks like either a JNDI bug or JNDI security measure (my guess is the later). Either way, it should be simple to fix. You could also roll a new Sitemesh JAR that smothers JNDI lookup errors. -bp On Apr 10, 2009, at 12:40 AM, Al Sutton wrote: Great. Nice work!!! Unfortunately most of my apps use sitemesh, so there's still some things for me to sort out before I can make full use of GAE :(. Al. --- * Written an Android App? - List it at http://andappstore.com/ * == Funky Android Limited is registered in England Wales with the company number 6741909. The registered head office is Kemp House, 152-160 City Road, London, EC1V 2NX, UK. The views expressed in this email are those of the author and not necessarily those of Funky Android Limited, it's associates, or it's subsidiaries. -Original Message- From: Don Brown [mailto:mr...@twdata.org] Sent: 10 April 2009 05:26 To: Struts Developers List Subject: Re: Google App Engine support? Huzzah, it works. Once I removed sitemesh, the simple starter app works: http://struts2-demo.appspot.com/index.action I want to add a new option that allows the user to disable the ognl permission checks, so I'm guessing I'll do that in trunk. Any objections? Don On Fri, Apr 10, 2009 at 1:54 AM, Musachy Barroso musa...@gmail.com wrote: thanks. I got it to work and uploaded to struts-demo, and yeah I also got the classnotfound exception. I will piggyback on Don's research ;) musachy On Thu, Apr 9, 2009 at 11:47 AM, Al Sutton a...@funkyandroid.com wrote: Appcfg is a script which just runs a java app and uses wherever it picks Java up from as the java.home variable. This means if it picks up the jre java version it won't find javac and bail on you about 10 or 20-odd percent in. AppEngine invite on its' way btw, I don't know if Don wants to add you as a comitter to his git repo. Al. --- * Written an Android App? - List it at http://andappstore.com/ * == Funky Android Limited is registered in England Wales with the company number 6741909. The registered head office is Kemp House, 152-160 City Road, London, EC1V 2NX, UK. The views expressed in this email are those of the author and not necessarily those of Funky Android Limited, it's associates, or it's subsidiaries. -Original Message- From: Musachy Barroso [mailto:musa...@gmail.com] Sent: 09 April 2009 16:44 To: Struts Developers List Subject: Re: Google App Engine support? yeah sure. Let me try that, it is probably getting confused with one of the 1234e10 SDKs/JREs I have around. musachy On Thu, Apr 9, 2009 at 11:34 AM, Al Sutton a...@funkyandroid.com wrote: Set JDK_HOME\bin first on your path. If it picks up the JRE version of java you're stuffed. Do you want an invite the project I set up that Don is working on? Al. --- * Written an Android App? - List it at http://andappstore.com/ * == Funky Android Limited is registered in England Wales with the company number 6741909. The registered head office is Kemp House, 152-160 City Road, London, EC1V 2NX, UK. The views expressed in this email are those of the author and not necessarily those of Funky Android Limited, it's associates, or it's subsidiaries. -Original Message- From: Musachy Barroso [mailto:musa...@gmail.com] Sent: 09 April 2009 16:24 To: Struts Developers List Subject: Re: Google App Engine support? I am trying it also, but I can't get appcfg to find javac. musachy On Thu, Apr 9, 2009 at 11:17 AM, Al Sutton a...@funkyandroid.com wrote: No worries. Enjoy, Al. --- * Written an Android App? - List it at http://andappstore.com/ * == Funky Android Limited is registered in England Wales with the company number 6741909. The registered head office is Kemp House, 152-160 City Road, London, EC1V 2NX, UK. The views expressed in this email are those of the author and not necessarily those of Funky Android Limited, it's associates, or it's subsidiaries. -Original Message- From: Don Brown [mailto:mr...@twdata.org] Sent: 09 April 2009 16:16 To: Struts Developers List Subject: Re: Google App Engine support? Hmm...bad sitemesh... java.lang.NoClassDefFoundError: Could not initialize class com .google.apphosting.runtime.security.shared.stub.javax.naming.Ini ti a lConte xt at com .opensymphony.module.sitemesh.Factory.getEnvEntry(Factory.java:8 8) at com .opensymphony.module.sitemesh.Factory.getInstance(Factory.java:4 2) at com .opensymphony.module.sitemesh.filter.PageFilter.init(PageFilter. ja v a:87) Cool, I'll look into it this weekend. Thanks for the help! Don On Fri, Apr 10, 2009 at 1:04 AM, Al Sutton a...@funkyandroid.com wrote: It's given me a 500, but I've added you as a collaborator on the project so
Re: Struts2 and joda-time
Those will need NPE checks by the way.
:)
-bp
On Dec 19, 2008, at 9:58 AM, Miguel wrote:
Something you can allways do, is to define a parallel set of
getter/setter in your bean with type java.util.Date that internally
does the conversion.
public Date getStartDate() {
return start.toDate();
}
public void setStartDate(Date start) {
this.start = new DateTime( start) ;
}
Si quieres ser más positivo, pierde un electrón
Miguel Ruiz Velasco S.
On Wed, Dec 17, 2008 at 09:46, Brian Pontarelli
br...@pontarelli.com wrote:
Date is pretty much deprecated except for a way to carry a long
primitive
around because of the TZ and conversions it lacks. It fails in some
cases
and most of the core API on Date is deprecated. Most folks should
be using
Calendar for date and time correctness if they don't want to use
Joda and
stick with the JDK classes. Calendar however is very clunky and
mutable.
Therefore, most people I know that need to internationalize or
localize use
Joda because it is correct, simple and immutable. Also, something
very
similar to the Joda date/time API is probably going to be in Java
8.0 or
something like that via JSR 310, unless it gets squashed or no one
pushes it
forward. Even still, Joda is the benchmark these days for a date/
time API.
-bp
On Dec 16, 2008, at 3:30 PM, Martin Cooper wrote:
On Tue, Dec 16, 2008 at 2:23 PM, Andreas Joseph Krogh
andr...@officenet.nowrote:
On Tuesday 16 December 2008 23:14:50 Musachy Barroso wrote:
It doesn't mean that it will convert from string to a joda
object, it
means that it will convert a string in ISO 8601 format, to a Date
object. The patch in that ticket used joda lib to create the ISO
8601,
if I don't remember wrong.
Ok, so you're saying that Struts2 (even in trunk) is unable to
handle
joda-time dates out of the box? That's a pitty. In 2008, is anyone
actually
using pure java.util.Date anymore?
I was wondering the opposite - are enough people using Joda Time
to make
it
worth the support / time / energy in S2? Everyone I know is, in
fact,
using
java.util.Date.
--
Martin Cooper
Previously I've created container-objects to wrap joda-classes,
which
works
but shouldn't be necessary. I kind of hoped that Struts-2 in its
most
modern
form (trunk) included converters for the most common object-
types. I
think,
for what it's worth, the ticket is missleading and that it should
be
commented somewhere that Struts-2.1 will not support joda-time.
I know this sounds kind of rant-ish, but there are so many good
things
about Struts2 that missing out-of-the-box joda-support is kind of
hard to
swallow...
--
Andreas Joseph Krogh andr...@officenet.no
Senior Software Developer / CEO
+-+
OfficeNet AS| The most difficult thing in the world
is to |
Karenslyst Allé 11 | know how to do a thing and to
watch |
PO. Box 529 Skøyen | somebody else doing it wrong,
without |
0214 Oslo |
comment.|
NORWAY
| |
Tlf:+47 24 15 38 90
| |
Fax:+47 24 15 38 91
| |
Mobile: +47 909 56 963
| |
+-+
-
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
Re: Struts2 and joda-time
Date is pretty much deprecated except for a way to carry a long primitive around because of the TZ and conversions it lacks. It fails in some cases and most of the core API on Date is deprecated. Most folks should be using Calendar for date and time correctness if they don't want to use Joda and stick with the JDK classes. Calendar however is very clunky and mutable. Therefore, most people I know that need to internationalize or localize use Joda because it is correct, simple and immutable. Also, something very similar to the Joda date/ time API is probably going to be in Java 8.0 or something like that via JSR 310, unless it gets squashed or no one pushes it forward. Even still, Joda is the benchmark these days for a date/time API. -bp On Dec 16, 2008, at 3:30 PM, Martin Cooper wrote: On Tue, Dec 16, 2008 at 2:23 PM, Andreas Joseph Krogh andr...@officenet.nowrote: On Tuesday 16 December 2008 23:14:50 Musachy Barroso wrote: It doesn't mean that it will convert from string to a joda object, it means that it will convert a string in ISO 8601 format, to a Date object. The patch in that ticket used joda lib to create the ISO 8601, if I don't remember wrong. Ok, so you're saying that Struts2 (even in trunk) is unable to handle joda-time dates out of the box? That's a pitty. In 2008, is anyone actually using pure java.util.Date anymore? I was wondering the opposite - are enough people using Joda Time to make it worth the support / time / energy in S2? Everyone I know is, in fact, using java.util.Date. -- Martin Cooper Previously I've created container-objects to wrap joda-classes, which works but shouldn't be necessary. I kind of hoped that Struts-2 in its most modern form (trunk) included converters for the most common object-types. I think, for what it's worth, the ticket is missleading and that it should be commented somewhere that Struts-2.1 will not support joda-time. I know this sounds kind of rant-ish, but there are so many good things about Struts2 that missing out-of-the-box joda-support is kind of hard to swallow... -- Andreas Joseph Krogh andr...@officenet.no Senior Software Developer / CEO +-+ OfficeNet AS| The most difficult thing in the world is to | Karenslyst Allé 11 | know how to do a thing and to watch | PO. Box 529 Skøyen | somebody else doing it wrong, without | 0214 Oslo | comment.| NORWAY | | Tlf:+47 24 15 38 90 | | Fax:+47 24 15 38 91 | | Mobile: +47 909 56 963 | | +-+ - 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
MSDN subscriptions
Anyone that had contacted Garrett about MSDN subscriptions, I talked with MSDN support the other day and it looks like the subscriptions were created on 10/31, just not activated and associated with each persons account. I sent Garrett an email this morning to inquire and I'll let you all know what I find out. -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Concerned Strutszien: A Manifesto
* OGNL - Is is staying? Is it going? Can it be secure? Is it fast enough? I say drop it completely. No more evaluation in the JSPs or FTL files at all and use MVEL for the parameters interceptor. FTL has a good enough language and you have Java in JSPs if you need it. OGNL in there is just confusing clutter that isn't necessary. I'd also make all the taglibs type safe and well validated. You should have to pass in a Map to the taglib for it work, rather than an expression that evaluates to the Map. * Convention - Buzz factor to me, but buzz none the less. I type pretty fast. Convention is a must. Drop a lot of the annotations because all they do is move configuration into code. Simplify in convention and leave XML if you need to tweak. * REST - Great way to organize web based applications Definitely finish this off in a manner that completely integrates with convention. Handle REST parameters and all the REST conventions such as URI notation and such. * Lower Level Customization Documentation - ActionMapper, Configuration Manager, Plugin Patterns -- How to get the most out of Struts2 by understanding not only how it works but how customize it to meet your needs. If you use Guice, abstract out all creation, interface everything really well and provide good ways to override, you'll be in a much better place. I'd also rip out a lot of the extra cruft around and just inject everything linearly, no circular injection and drop the multiple configuration files. I'd also drop a lot of the plugin stuff and stream-line plugins via interface injection. * Model and Service Layer - We know Struts2 is a web framework and its good at it. So there is Appfuse and that is something I have worked on. Stripping down Appfuse and hopefully making some kind of Groovy- based Model, Service, Action, View generator. More on that here: http://www.nabble.com/RE%3A-Getting-ready-for-Struts-2.1.1-td17446803s2369.html#a17461105 . I think the plan is good, but I haven't done as much as I need to yet I'd skip this. If you want a better platform, use something that is a platform like Spring with their MVC. This was one of the big driving factors behind JCatpault and our shift from Struts to our own MVC. * AJAX - Never been a fan of the Dojo tags -- DWR? Prototype/ Scriptaculous? JQuery? I used proto and scriptac for a while but I have moved to JQuery recently. I'd remove this completely as well. Folks should be able to add in their own templates and make their own AJAX integration. This would also mean simplifying the mess that is the current theme templates. Templates should also not support inheritance, just makes it worse. The template files need to be simple to create and replace. There shouldn't be complex logic in the template files. JCatapult uses template files and they are generally pretty simple and easy to tweak. * Stable and public API to keep backward compatibility Yeah, this is a must. Things are moving targets in the API. If it has the word public in it, it just can't change, period. I'd also drop XWork completely. Move the XWork code into Struts, clean it up and make it web centric, and drop all unnecessary extras. Struts is only for the web and everything should act that way. Generic code just makes it harder to work with. * Portlets are still first class citizens? No opinion. -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MVEL?
In terms of the cache though, this what Struts and other MVCs would
use to store compiled expressions for parameter setting (in the
ParameterInterceptor and other places). So, I would assume the trade
off could be well worth it considering the relatively low number of
expressions in an application. Using a Map with locking per key would
also reduce contention.
The only other way I could think of is to compile the expressions into
classes and then load them into the ClassLoader and let that thing do
the synchronization. As long as the name of the class could be
uniquely constructed from the expression, this could also work.
As for the parsing strategy, which I always call linear parsing
because I never go backwards, but sliding window is much cooler,
that's how I had started writing it originally and then in favor of
time and simplicity, changed it to a StringTokenizer. I'll look at
changing it back and see what the difference is. Thanks for the help.
-bp
On Oct 12, 2008, at 9:23 PM, Chris Brock wrote:
Well, that's one way of implementing a cache. Even if you did do
that, the
performance gain from compiling the expression is on the order of a
magnitude (or greater), so any contention in the hash lookup would
be far
worth it. However, there are other more efficient strategies that
have been
employed through the use of external code generation, and tying
compiled
expressions directly to the instance of a JSP tag.
But we're talking about web-based stuff here. MVEL is used for a
broad
range of stuff, like actual scripting in Smooks and JBoss Drools.
It's used
for straight-up data binding in jBPM and JBoss ESB. It's used for
some
custom UI stuff in Mule Galaxy, etc.
To you P.S.: MVEL works directly on the expression by using a
sliding window
algorithm. Think of it like this.
0 { f }
1 { o }
2 { o }
3 { . }
4 { b }
5 { a }
6 { r }
7 { [ }
8 { 0 }
9 { ] }
MVEL takes the string as an array. It holds a start position, and a
cursor
position.
When it starts parsing, it starts scanning until it finds the first
non-identifier character, which is '.'. At this point it does a
capture. At
this point: start=0; cursor=3; This represents the boundary of the
first
token. We then process the token by converting it to a String,
marking the
start position as cursor+1 and repeat. When we hit the next non-
identifier
which is '[' MVEL knows this is a index accessor and acts
appropriately,
following the same principle.
MVEL does this inline with actual evaluation. It works out to be
significantly more efficient than StringTokenizer and also allows
you to
incrementally add complexity over time.
Unfortunately, it becomes increasing more difficult to maintain a
design
like this, especially as it evolves into more sophisticated
constructs.
You're welcome to contact me directly in e-mail to discuss this, as
I don't
want to pollute the Struts mailing list with non-Struts related talk.
Brian Pontarelli wrote:
Not sure I follow. If I compile an expression, how can I reuse the
compiled version? I would assume it would need to be in a cache where
the key is the expression String and the value is the compiled
version. Correct me if I'm wrong.
-bp
P.S. based on your knowledge, I'm wondering if JCatapult would
perform
better if the expression wasn't divided into its pieces but rather
evaluated character by character until a boundary is hit, at which
time that portion is evaluated? I wouldn't think this would increase
performance drastically, but you would know much better than I.
On Oct 12, 2008, at 8:38 PM, Chris Brock wrote:
I'd also be interested to hear a
good discussion about caching compiled MVEL expressions and
whether or
not thread contention for the cache is an issue at all
There is no contention in the cache. MVEL returns self-contained,
stateless, evaluation trees (or bytecode via the JIT) that do not
require
synchronization or contention in multi-threaded scenarios. The
payload
returned by the compiler is essentially stateless code, and there is
no
cache that is used such as reflection cache or otherwise as there
is in
things like Commons EL, or JEXL. This is actually, from an
architectural
perspective what makes MVEL stand apart from these technologies.
Brian Pontarelli wrote:
Sure. But OGNL will return similar results with 50 tests. Yet
people have
run into performance problems. The issue is that you're not
looking
at
performance in terms of resource contention, and in terms of
aggregate
resource usage.
I'd say that for web application expressions OGNL and MVEL are
about
equal then. In fact, I've never wanted to replace OGNL for
performance
reasons. It was for primarily other reasons.
Say you have a page which contains 20 expressions. And your pages
are
getting hit 15 times a second (a reality in some high traffic
sites).
That's 300 expressions running every second. Now, in insolation
that's
Re: MVEL?
Right, but you can receive similar or better performance using a linear runtime evaluation if the language is simple enough and tuned for the web. And as you and I say, MVEL and most other languages aren't targeted to the web and have many extra features. I can't really believe that JUEL is that slow though. And if it really is, it should be extremely simple to make it just as fast as MVEL. But I couldn't say for certain because I don't know the code. I ran some simple tests on getting and setting properties for the JCatapult expression evaluator and here's what I got: Retrieving from a JavaBean property (user.age) 1ms Retrieving from a public member field (user.age)1ms Retrieving from a nested JavaBean property within a collection (user.addresses['home'].zipcode) 1ms Retrieving from a nested public member field within a collection (user.addresses['home'].zipcode) 1ms Setting a JavaBean property with type conversion (user.age) 1ms Setting a nested JavaBean property, with collections and Object creation (user.addresses['home'].zipcode) 2ms That's definitely fast enough for my web applications. ;) JCatapult does support using public member fields of classes and it does shave a little bit of time, but nothing that would make a huge difference. These are all runtime parsing and handling, nothing is compiled or cached. -bp On Oct 11, 2008, at 3:09 PM, Chris Brock wrote: The singleton pattern is used in MVEL, with knowledge of the tradeoff. MVEL has a strong emphasis on maintaining interpreted-mode performance. MVEL contains two runtime systems: an interpreter, and a compiler/ runtime. Unlike other ELs, MVEL does not simply bootstrap the compiler, and execute that way. Instead, MVEL has a real-time interpreter which evaluates to a stack during parsing. Therefore, the general design decisions, particularly around extendability tend to favor singleton-patterns, instead of heavyweight configuration sessions which would completely bog down the performance. http://artexpressive.blogspot.com/2007/11/juel-vs-mvel.html For an example of how performant MVEL's interpreter is with no factory caching. In a simple property expression, with no caching (so parsing before executing every time), MVEL was able to parse/reduce the expression foo.bar 100,000 times in 94ms. It took JUEL 2749ms to do the same. Compiled performance was: 5.8ms to 34.2ms in favor of MVEL too. So I would err on the side of performance here. If that doesn't cut it for web applications, I guess that's fine. I don't really target MVEL towards web applications, really. Brian Pontarelli wrote: Taking a brief look at the MVEL type conversion API it could be somewhat difficult to get this information into the converter on a per request basis, especially if converters are singleton scoped. This information isn't available on the source in most cases. It is usually externalized in the request or the container object. The API looks a pretty lightweight, which is nice, but also restrictive. From what I could see I would have to monkey around with things and use something like a ThreadLocal to pass this information to the converter. The source-from-many pattern seems to be somewhat backwards for the web. It is more likely the case that a single converter will convert to many classes from a String or String[]. The JCatapult type converter passes in the type being converted to and then the String value(s). Although this is very web centric, it cleans up the API and makes things simpler to implement. MVEL is obviously more generic, which means some massaging is necessary to tune it for the web. It also seems to be lacking a good set of exceptions thrown out of the API. At least from the docs, since I couldn't find JavaDoc and the distribution only has source (ouch). This doesn't mean that Struts can't provide good runtime exceptions and then just catch those, but it leaves things much more open for developers writing new converters. I'd rather see the API define these exceptions clearly and for them to be checked. I think that using generic languages like OGNL or MVEL are decent solutions, but a web centric solution would be best. I'm also in favor or dropping most if not all of the extra features and only providing property/field getting and setting. I think adding in another language just clouds the waters. FreeMarker and JSP both have languages that cover most of the common cases. Feel free to take a look at the JCatapult MVC expression evaluator for what I feel should be supported. -bp On Oct 11, 2008, at 12:52 PM, Chris Brock wrote: MVEL has a pluggable type-conversion API, just like OGNL. Since it's source-from-many in it's design, you can easily design converters that perform as much introspection as necessary to determine formatting, etc. Brian Pontarelli wrote: Yeah. That's good. The last thing I would toss in as criteria
Re: MVEL?
We could do that if you like. Those are pretty simple numbers with
very straight-forward cases. So, please run those against MVEL and let
me know what you get. StringTokenizer is obviously quite fast, and I
could easily remove it if it would mean sub-millisecond times,
although the work probably isn't worth the effort with such small
numbers.
Just create three classes:
An action
A user object
An address object
The action has a user and the user has a generic Map of addresses
keyed off a String. This should work:
public class Action
public User user;
}
public class User {
public int age;
public MapString, Address addresses;
}
public class Address {
public String zipcode;
}
Then, just get and set some values without any pre-compile or caching
and let me know what the times are. My guess is that you will be
slightly slower or the same. To get truly accurate, we might have to
go sub-millisecond or create some more dramatic tests.
Also, I doubt that StringTokenizer is impacting my performance any. In
fact the numbers clearly state otherwise. Besides, with things
happening sub-millisecond or just above that, I just don't see any
benefit in spending a lot of time making it faster.
-bp
On Oct 12, 2008, at 11:46 AM, Chris Brock wrote:
Well, I'd like to see an actual comparison. I somehow doubt your
parser,
which I note is using StringTokenizer will perform as well as MVEL's
parser,
which is a much more computationally efficient sliding-window parser.
Brian Pontarelli wrote:
Right, but you can receive similar or better performance using a
linear runtime evaluation if the language is simple enough and tuned
for the web. And as you and I say, MVEL and most other languages
aren't targeted to the web and have many extra features.
I can't really believe that JUEL is that slow though. And if it
really
is, it should be extremely simple to make it just as fast as MVEL.
But
I couldn't say for certain because I don't know the code.
I ran some simple tests on getting and setting properties for the
JCatapult expression evaluator and here's what I got:
Retrieving from a JavaBean property (user.age) 1ms
Retrieving from a public member field (user.age)1ms
Retrieving from a nested JavaBean property within a collection
(user.addresses['home'].zipcode) 1ms
Retrieving from a nested public member field within a collection
(user.addresses['home'].zipcode) 1ms
Setting a JavaBean property with type conversion (user.age) 1ms
Setting a nested JavaBean property, with collections and Object
creation (user.addresses['home'].zipcode) 2ms
That's definitely fast enough for my web applications. ;)
JCatapult does support using public member fields of classes and it
does shave a little bit of time, but nothing that would make a huge
difference. These are all runtime parsing and handling, nothing is
compiled or cached.
-bp
On Oct 11, 2008, at 3:09 PM, Chris Brock wrote:
The singleton pattern is used in MVEL, with knowledge of the
tradeoff. MVEL
has a strong emphasis on maintaining interpreted-mode performance.
MVEL contains two runtime systems: an interpreter, and a compiler/
runtime.
Unlike other ELs, MVEL does not simply bootstrap the compiler, and
execute
that way. Instead, MVEL has a real-time interpreter which evaluates
to a
stack during parsing. Therefore, the general design decisions,
particularly
around extendability tend to favor singleton-patterns, instead of
heavyweight configuration sessions which would completely bog down
the
performance.
http://artexpressive.blogspot.com/2007/11/juel-vs-mvel.html
For an example of how performant MVEL's interpreter is with no
factory
caching.
In a simple property expression, with no caching (so parsing before
executing every time), MVEL was able to parse/reduce the expression
foo.bar 100,000 times in 94ms. It took JUEL 2749ms to do the
same.
Compiled performance was: 5.8ms to 34.2ms in favor of MVEL too.
So I would err on the side of performance here. If that doesn't cut
it for
web applications, I guess that's fine. I don't really target MVEL
towards
web applications, really.
Brian Pontarelli wrote:
Taking a brief look at the MVEL type conversion API it could be
somewhat difficult to get this information into the converter on a
per
request basis, especially if converters are singleton scoped. This
information isn't available on the source in most cases. It is
usually
externalized in the request or the container object. The API
looks a
pretty lightweight, which is nice, but also restrictive. From
what I
could see I would have to monkey around with things and use
something
like a ThreadLocal to pass this information to the converter.
The source-from-many pattern seems to be somewhat backwards for the
web. It is more likely the case that a single converter will
convert
to many classes from a String or String[]. The JCatapult type
converter passes in the type being converted
Re: MVEL?
Just as a quick update. I realized my tests weren't insulated from
other code running and create a separate unit test to get performance.
The results are now:
Retrieving from a JavaBean property (user.age) 0ms
Retrieving from a field (user.age) 0ms
Retrieving from a JavaBean property (user.address['home'].zipcode) 0ms
Retrieving from a field (user.address['home'].zipcode) 0ms
Setting a JavaBean property (user.age) 0ms
Setting a field (user.age) 0ms
Setting a JavaBean property (user.address['home'].zipcode) 0ms
Setting a field (user.address['home'].zipcode) 0ms
I also ran a test setting the address zipcode field 50 times, which is
about the highest number of HTTP parameters I could envision and that
was 2ms.
Here's the code:
public void testPerformance() {
// Set cases
Object action = new ActionField();
long start = System.currentTimeMillis();
evaluator.setValue(user.age, action, array(32), null);
long end = System.currentTimeMillis();
System.out.println(Setting field time was + (end - start));
start = System.currentTimeMillis();
evaluator.setValue(user.addresses['home'].zipcode, action,
array(80020), null);
end = System.currentTimeMillis();
System.out.println(Setting field time was + (end - start));
action = new Action();
start = System.currentTimeMillis();
evaluator.setValue(user.age, action, array(32), null);
end = System.currentTimeMillis();
System.out.println(Setting property time was + (end -
start));
start = System.currentTimeMillis();
evaluator.setValue(user.addresses['home'].zipcode, action,
array(80020), null);
end = System.currentTimeMillis();
System.out.println(Setting proeprty time was + (end -
start));
// Get cases
action = new ActionField();
start = System.currentTimeMillis();
evaluator.getValue(user.age, action);
end = System.currentTimeMillis();
System.out.println(Getting field time was + (end - start));
start = System.currentTimeMillis();
evaluator.getValue(user.addresses['home'].zipcode, action);
end = System.currentTimeMillis();
System.out.println(Getting field time was + (end - start));
action = new Action();
start = System.currentTimeMillis();
evaluator.getValue(user.age, action);
end = System.currentTimeMillis();
System.out.println(Getting property time was + (end -
start));
start = System.currentTimeMillis();
evaluator.getValue(user.addresses['home'].zipcode, action);
end = System.currentTimeMillis();
System.out.println(Getting property time was + (end -
start));
// Loop
start = System.currentTimeMillis();
for (int i = 0; i 50; i++) {
evaluator.getValue(user.addresses['home'].zipcode,
action);
}
end = System.currentTimeMillis();
System.out.println(50 times was + (end - start));
}
And the output:
[junit] Setting field time was 0
[junit] Setting field time was 0
[junit] Setting property time was 0
[junit] Setting proeprty time was 0
[junit] Getting field time was 0
[junit] Getting field time was 0
[junit] Getting property time was 0
[junit] Getting property time was 0
[junit] 50 times was 2
That's definitely fast enough for any web application.
-bp
On Oct 12, 2008, at 11:46 AM, Chris Brock wrote:
Well, I'd like to see an actual comparison. I somehow doubt your
parser,
which I note is using StringTokenizer will perform as well as MVEL's
parser,
which is a much more computationally efficient sliding-window parser.
Brian Pontarelli wrote:
Right, but you can receive similar or better performance using a
linear runtime evaluation if the language is simple enough and tuned
for the web. And as you and I say, MVEL and most other languages
aren't targeted to the web and have many extra features.
I can't really believe that JUEL is that slow though. And if it
really
is, it should be extremely simple to make it just as fast as MVEL.
But
I couldn't say for certain because I don't know the code.
I ran some simple tests on getting and setting properties for the
JCatapult expression evaluator and here's what I got:
Retrieving from a JavaBean property (user.age) 1ms
Retrieving from a public member field (user.age)1ms
Retrieving from a nested JavaBean property within a collection
(user.addresses['home'].zipcode) 1ms
Retrieving from a nested public member field within a collection
(user.addresses['home'].zipcode) 1ms
Setting a JavaBean property with type conversion (user.age) 1ms
Setting a nested JavaBean property, with collections and Object
creation (user.addresses['home'].zipcode) 2ms
That's definitely fast enough for my web applications
Re: MVEL?
Send me code for MVEL and I'll run both. It will be much easier for
you to write good MVEL code than me.
-bp
On Oct 12, 2008, at 6:18 PM, Chris Brock wrote:
I actually tried to do this really quickly earlier. I didn't have
time to
figure it out, as your EL stuff has dependencies on
HttpServletRequest and
outward dependencies to your framework. I tried to check-out
everything,
but SVN kept dying while checking out (I think Google's SVN server was
acting up).
One of the problems of trying to do a simple performance test with
your
stuff is that (like you say) it's not generic, and a bit of a pain
in the
butt to test in isolation.
Brian Pontarelli wrote:
We could do that if you like. Those are pretty simple numbers with
very straight-forward cases. So, please run those against MVEL and
let
me know what you get. StringTokenizer is obviously quite fast, and I
could easily remove it if it would mean sub-millisecond times,
although the work probably isn't worth the effort with such small
numbers.
Just create three classes:
An action
A user object
An address object
The action has a user and the user has a generic Map of addresses
keyed off a String. This should work:
public class Action
public User user;
}
public class User {
public int age;
public MapString, Address addresses;
}
public class Address {
public String zipcode;
}
Then, just get and set some values without any pre-compile or caching
and let me know what the times are. My guess is that you will be
slightly slower or the same. To get truly accurate, we might have to
go sub-millisecond or create some more dramatic tests.
Also, I doubt that StringTokenizer is impacting my performance any.
In
fact the numbers clearly state otherwise. Besides, with things
happening sub-millisecond or just above that, I just don't see any
benefit in spending a lot of time making it faster.
-bp
On Oct 12, 2008, at 11:46 AM, Chris Brock wrote:
Well, I'd like to see an actual comparison. I somehow doubt your
parser,
which I note is using StringTokenizer will perform as well as MVEL's
parser,
which is a much more computationally efficient sliding-window
parser.
Brian Pontarelli wrote:
Right, but you can receive similar or better performance using a
linear runtime evaluation if the language is simple enough and
tuned
for the web. And as you and I say, MVEL and most other languages
aren't targeted to the web and have many extra features.
I can't really believe that JUEL is that slow though. And if it
really
is, it should be extremely simple to make it just as fast as MVEL.
But
I couldn't say for certain because I don't know the code.
I ran some simple tests on getting and setting properties for the
JCatapult expression evaluator and here's what I got:
Retrieving from a JavaBean property (user.age) 1ms
Retrieving from a public member field (user.age)1ms
Retrieving from a nested JavaBean property within a collection
(user.addresses['home'].zipcode) 1ms
Retrieving from a nested public member field within a collection
(user.addresses['home'].zipcode) 1ms
Setting a JavaBean property with type conversion (user.age) 1ms
Setting a nested JavaBean property, with collections and Object
creation (user.addresses['home'].zipcode) 2ms
That's definitely fast enough for my web applications. ;)
JCatapult does support using public member fields of classes and it
does shave a little bit of time, but nothing that would make a huge
difference. These are all runtime parsing and handling, nothing is
compiled or cached.
-bp
On Oct 11, 2008, at 3:09 PM, Chris Brock wrote:
The singleton pattern is used in MVEL, with knowledge of the
tradeoff. MVEL
has a strong emphasis on maintaining interpreted-mode performance.
MVEL contains two runtime systems: an interpreter, and a compiler/
runtime.
Unlike other ELs, MVEL does not simply bootstrap the compiler, and
execute
that way. Instead, MVEL has a real-time interpreter which
evaluates
to a
stack during parsing. Therefore, the general design decisions,
particularly
around extendability tend to favor singleton-patterns, instead of
heavyweight configuration sessions which would completely bog down
the
performance.
http://artexpressive.blogspot.com/2007/11/juel-vs-mvel.html
For an example of how performant MVEL's interpreter is with no
factory
caching.
In a simple property expression, with no caching (so parsing
before
executing every time), MVEL was able to parse/reduce the
expression
foo.bar 100,000 times in 94ms. It took JUEL 2749ms to do the
same.
Compiled performance was: 5.8ms to 34.2ms in favor of MVEL too.
So I would err on the side of performance here. If that doesn't
cut
it for
web applications, I guess that's fine. I don't really target MVEL
towards
web applications, really.
Brian Pontarelli wrote:
Taking a brief look at the MVEL type conversion API it could be
somewhat difficult to get this information into the converter
on a
per
Re: MVEL?
BTW, I've got everything setup for using the 2.0-beta1 JAR file.
-bp
On Oct 12, 2008, at 6:18 PM, Chris Brock wrote:
I actually tried to do this really quickly earlier. I didn't have
time to
figure it out, as your EL stuff has dependencies on
HttpServletRequest and
outward dependencies to your framework. I tried to check-out
everything,
but SVN kept dying while checking out (I think Google's SVN server was
acting up).
One of the problems of trying to do a simple performance test with
your
stuff is that (like you say) it's not generic, and a bit of a pain
in the
butt to test in isolation.
Brian Pontarelli wrote:
We could do that if you like. Those are pretty simple numbers with
very straight-forward cases. So, please run those against MVEL and
let
me know what you get. StringTokenizer is obviously quite fast, and I
could easily remove it if it would mean sub-millisecond times,
although the work probably isn't worth the effort with such small
numbers.
Just create three classes:
An action
A user object
An address object
The action has a user and the user has a generic Map of addresses
keyed off a String. This should work:
public class Action
public User user;
}
public class User {
public int age;
public MapString, Address addresses;
}
public class Address {
public String zipcode;
}
Then, just get and set some values without any pre-compile or caching
and let me know what the times are. My guess is that you will be
slightly slower or the same. To get truly accurate, we might have to
go sub-millisecond or create some more dramatic tests.
Also, I doubt that StringTokenizer is impacting my performance any.
In
fact the numbers clearly state otherwise. Besides, with things
happening sub-millisecond or just above that, I just don't see any
benefit in spending a lot of time making it faster.
-bp
On Oct 12, 2008, at 11:46 AM, Chris Brock wrote:
Well, I'd like to see an actual comparison. I somehow doubt your
parser,
which I note is using StringTokenizer will perform as well as MVEL's
parser,
which is a much more computationally efficient sliding-window
parser.
Brian Pontarelli wrote:
Right, but you can receive similar or better performance using a
linear runtime evaluation if the language is simple enough and
tuned
for the web. And as you and I say, MVEL and most other languages
aren't targeted to the web and have many extra features.
I can't really believe that JUEL is that slow though. And if it
really
is, it should be extremely simple to make it just as fast as MVEL.
But
I couldn't say for certain because I don't know the code.
I ran some simple tests on getting and setting properties for the
JCatapult expression evaluator and here's what I got:
Retrieving from a JavaBean property (user.age) 1ms
Retrieving from a public member field (user.age)1ms
Retrieving from a nested JavaBean property within a collection
(user.addresses['home'].zipcode) 1ms
Retrieving from a nested public member field within a collection
(user.addresses['home'].zipcode) 1ms
Setting a JavaBean property with type conversion (user.age) 1ms
Setting a nested JavaBean property, with collections and Object
creation (user.addresses['home'].zipcode) 2ms
That's definitely fast enough for my web applications. ;)
JCatapult does support using public member fields of classes and it
does shave a little bit of time, but nothing that would make a huge
difference. These are all runtime parsing and handling, nothing is
compiled or cached.
-bp
On Oct 11, 2008, at 3:09 PM, Chris Brock wrote:
The singleton pattern is used in MVEL, with knowledge of the
tradeoff. MVEL
has a strong emphasis on maintaining interpreted-mode performance.
MVEL contains two runtime systems: an interpreter, and a compiler/
runtime.
Unlike other ELs, MVEL does not simply bootstrap the compiler, and
execute
that way. Instead, MVEL has a real-time interpreter which
evaluates
to a
stack during parsing. Therefore, the general design decisions,
particularly
around extendability tend to favor singleton-patterns, instead of
heavyweight configuration sessions which would completely bog down
the
performance.
http://artexpressive.blogspot.com/2007/11/juel-vs-mvel.html
For an example of how performant MVEL's interpreter is with no
factory
caching.
In a simple property expression, with no caching (so parsing
before
executing every time), MVEL was able to parse/reduce the
expression
foo.bar 100,000 times in 94ms. It took JUEL 2749ms to do the
same.
Compiled performance was: 5.8ms to 34.2ms in favor of MVEL too.
So I would err on the side of performance here. If that doesn't
cut
it for
web applications, I guess that's fine. I don't really target MVEL
towards
web applications, really.
Brian Pontarelli wrote:
Taking a brief look at the MVEL type conversion API it could be
somewhat difficult to get this information into the converter
on a
per
request basis, especially if converters
Re: MVEL?
Send me the code to set values which will require object construction
and generic inspection and handling as well.
Thanks,
-bp
On Oct 12, 2008, at 6:35 PM, Chris Brock wrote:
Assuming you're using a context-root, you'd write it like this:
long start = System.currentTimeMillis();
for (int i = 0; i iterations; i++ {
MVEL.eval(foo.bar, entityObj); // equivalent of:
entityObj.getFoo().getBar();
}
System.out.println(interpreted time: +
(System.currentTimeMillis()-start));
You can also compare MVEL's compiled performance like so:
Serializable s = MVEL.compileExpression(foo.bar);
long start = System.currentTimeMillis();
for (int i = 0; i iterations; i++) {
MVEL.executeExpression(s, entityObj);
}
System.out.println(compiled time: + (System.currentTimeMillis()-
start));
Brian Pontarelli wrote:
Send me code for MVEL and I'll run both. It will be much easier for
you to write good MVEL code than me.
-bp
On Oct 12, 2008, at 6:18 PM, Chris Brock wrote:
I actually tried to do this really quickly earlier. I didn't have
time to
figure it out, as your EL stuff has dependencies on
HttpServletRequest and
outward dependencies to your framework. I tried to check-out
everything,
but SVN kept dying while checking out (I think Google's SVN server
was
acting up).
One of the problems of trying to do a simple performance test with
your
stuff is that (like you say) it's not generic, and a bit of a pain
in the
butt to test in isolation.
Brian Pontarelli wrote:
We could do that if you like. Those are pretty simple numbers with
very straight-forward cases. So, please run those against MVEL and
let
me know what you get. StringTokenizer is obviously quite fast,
and I
could easily remove it if it would mean sub-millisecond times,
although the work probably isn't worth the effort with such small
numbers.
Just create three classes:
An action
A user object
An address object
The action has a user and the user has a generic Map of addresses
keyed off a String. This should work:
public class Action
public User user;
}
public class User {
public int age;
public MapString, Address addresses;
}
public class Address {
public String zipcode;
}
Then, just get and set some values without any pre-compile or
caching
and let me know what the times are. My guess is that you will be
slightly slower or the same. To get truly accurate, we might have
to
go sub-millisecond or create some more dramatic tests.
Also, I doubt that StringTokenizer is impacting my performance any.
In
fact the numbers clearly state otherwise. Besides, with things
happening sub-millisecond or just above that, I just don't see any
benefit in spending a lot of time making it faster.
-bp
On Oct 12, 2008, at 11:46 AM, Chris Brock wrote:
Well, I'd like to see an actual comparison. I somehow doubt your
parser,
which I note is using StringTokenizer will perform as well as
MVEL's
parser,
which is a much more computationally efficient sliding-window
parser.
Brian Pontarelli wrote:
Right, but you can receive similar or better performance using a
linear runtime evaluation if the language is simple enough and
tuned
for the web. And as you and I say, MVEL and most other languages
aren't targeted to the web and have many extra features.
I can't really believe that JUEL is that slow though. And if it
really
is, it should be extremely simple to make it just as fast as
MVEL.
But
I couldn't say for certain because I don't know the code.
I ran some simple tests on getting and setting properties for the
JCatapult expression evaluator and here's what I got:
Retrieving from a JavaBean property (user.age) 1ms
Retrieving from a public member field (user.age)1ms
Retrieving from a nested JavaBean property within a collection
(user.addresses['home'].zipcode) 1ms
Retrieving from a nested public member field within a collection
(user.addresses['home'].zipcode) 1ms
Setting a JavaBean property with type conversion (user.age)
1ms
Setting a nested JavaBean property, with collections and Object
creation (user.addresses['home'].zipcode) 2ms
That's definitely fast enough for my web applications. ;)
JCatapult does support using public member fields of classes
and it
does shave a little bit of time, but nothing that would make a
huge
difference. These are all runtime parsing and handling, nothing
is
compiled or cached.
-bp
On Oct 11, 2008, at 3:09 PM, Chris Brock wrote:
The singleton pattern is used in MVEL, with knowledge of the
tradeoff. MVEL
has a strong emphasis on maintaining interpreted-mode
performance.
MVEL contains two runtime systems: an interpreter, and a
compiler/
runtime.
Unlike other ELs, MVEL does not simply bootstrap the compiler,
and
execute
that way. Instead, MVEL has a real-time interpreter which
evaluates
to a
stack during parsing. Therefore, the general design decisions,
particularly
around extendability tend to favor singleton-patterns, instead
of
heavyweight
Re: MVEL?
Sure. But OGNL will return similar results with 50 tests. Yet people have run into performance problems. The issue is that you're not looking at performance in terms of resource contention, and in terms of aggregate resource usage. I'd say that for web application expressions OGNL and MVEL are about equal then. In fact, I've never wanted to replace OGNL for performance reasons. It was for primarily other reasons. Say you have a page which contains 20 expressions. And your pages are getting hit 15 times a second (a reality in some high traffic sites). That's 300 expressions running every second. Now, in insolation that's probably chump change. But as resource contention rises in these situation, the overall efficiency drops and resource usage is exaggerated as a result. I've worked with this level of traffic and higher and it is still not an issue to be setting 20 values for 1ms per request. You might in term start to find that what is only 0ms in an isolate closed-loop test (which is not a very good way to benchmark in Java, by the way) could very well be something that contributes to a significant amount of CPU time in systems with high load. Probably not in this case though and the scale between 1 iteration and 50 is decent testament to that. It the CPU was pinned it would be more linear. Take these real benchmarks (from MVEL 1.2--which is old): Test Name: Deep Property Expression : foo.bar.name Iterations : 5 Interpreted Results : (OGNL) : 1955.20ms avg. (mem delta: -790kb) [1936,1949,1943,1994,1954] (MVEL) : 114.80ms avg. (mem delta: -112kb) [119,113,110,117,115] Compiled Results : (OGNL Compiled) : 92.80ms avg. (mem delta: -580kb) [92,92,92,92,96] (MVEL Compiled) : 1.80ms avg. (mem delta: -18kb) [1,2,2,2,2] Here's what I got for 50K on my box using MVEL and JCatapult side by side: MVEL 808ms JCatapult 1200ms MVEL had a hit for the first method call, but it was only 40ms. Otherwise, they performed exactly the same for anything up to 50 iterations. MVEL often poked above 1ms for single iterations, while JCatapult never did, but that's negligible for both. JCatapult is definitely slower as the iterations go up. I tossed in a thread test with 50 threads each running 50K iterations and the averages were: MVEL 8000ms JCatapult 23000ms However, under one test condition, MVEL never returned and caused a load of 50 on my box. It was quite distressing, but it looked like MVEL got into a bunch of infinite loops or something. I let it run at a load of 50 for a while and then I had to kill it, but none of the threads had finished yet. I also did a 50 thread and 50 iteration test and the averages were roughly: MVEL 30ms JCatapult 120ms Except for the case above, MVEL definitely out-performs JCatapult. ... 50,000 iterations on MVEL interpreted in 114.80ms. This is a 1000x more iterations than your benchmark. If I divide 114.8ms / 1000 ... I get 0.1ms (or what would otherwise be rounded down to 0ms). In OGNL's case, it did 50 iterations in 1.95ms (or what would be measured as 1ms -- as these time measurements always round down because of the fact currentTimeMillis() returns the result in MS). Although JCatapult is slower, I'd be careful with such math because it isn't always as linear as this. You can talk about good enough all you want, but faster is always better when it comes to scale. :) I know a lot about scale and this is not the only truth. In fact, for what we are talking about, good enough should be just fine. Most scale problems occur because of bottlenecks and I doubt that our case of web applications and setting parameters is a bottleneck. However, I'm definitely welcome to suggestions on improvements for my quite simple expression evaluator. I'd also be interested to hear a good discussion about caching compiled MVEL expressions and whether or not thread contention for the cache is an issue at all. Unfortunately, because JCatapult uses my concept of dynamic attributes quite heavily, it might be difficult to swap in MVEL without some tweaks to the type conversion API. But I could look into it. -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MVEL?
Not sure I follow. If I compile an expression, how can I reuse the compiled version? I would assume it would need to be in a cache where the key is the expression String and the value is the compiled version. Correct me if I'm wrong. -bp P.S. based on your knowledge, I'm wondering if JCatapult would perform better if the expression wasn't divided into its pieces but rather evaluated character by character until a boundary is hit, at which time that portion is evaluated? I wouldn't think this would increase performance drastically, but you would know much better than I. On Oct 12, 2008, at 8:38 PM, Chris Brock wrote: I'd also be interested to hear a good discussion about caching compiled MVEL expressions and whether or not thread contention for the cache is an issue at all There is no contention in the cache. MVEL returns self-contained, stateless, evaluation trees (or bytecode via the JIT) that do not require synchronization or contention in multi-threaded scenarios. The payload returned by the compiler is essentially stateless code, and there is no cache that is used such as reflection cache or otherwise as there is in things like Commons EL, or JEXL. This is actually, from an architectural perspective what makes MVEL stand apart from these technologies. Brian Pontarelli wrote: Sure. But OGNL will return similar results with 50 tests. Yet people have run into performance problems. The issue is that you're not looking at performance in terms of resource contention, and in terms of aggregate resource usage. I'd say that for web application expressions OGNL and MVEL are about equal then. In fact, I've never wanted to replace OGNL for performance reasons. It was for primarily other reasons. Say you have a page which contains 20 expressions. And your pages are getting hit 15 times a second (a reality in some high traffic sites). That's 300 expressions running every second. Now, in insolation that's probably chump change. But as resource contention rises in these situation, the overall efficiency drops and resource usage is exaggerated as a result. I've worked with this level of traffic and higher and it is still not an issue to be setting 20 values for 1ms per request. You might in term start to find that what is only 0ms in an isolate closed-loop test (which is not a very good way to benchmark in Java, by the way) could very well be something that contributes to a significant amount of CPU time in systems with high load. Probably not in this case though and the scale between 1 iteration and 50 is decent testament to that. It the CPU was pinned it would be more linear. Take these real benchmarks (from MVEL 1.2--which is old): Test Name: Deep Property Expression : foo.bar.name Iterations : 5 Interpreted Results : (OGNL) : 1955.20ms avg. (mem delta: -790kb) [1936,1949,1943,1994,1954] (MVEL) : 114.80ms avg. (mem delta: -112kb) [119,113,110,117,115] Compiled Results : (OGNL Compiled) : 92.80ms avg. (mem delta: -580kb) [92,92,92,92,96] (MVEL Compiled) : 1.80ms avg. (mem delta: -18kb) [1,2,2,2,2] Here's what I got for 50K on my box using MVEL and JCatapult side by side: MVEL 808ms JCatapult 1200ms MVEL had a hit for the first method call, but it was only 40ms. Otherwise, they performed exactly the same for anything up to 50 iterations. MVEL often poked above 1ms for single iterations, while JCatapult never did, but that's negligible for both. JCatapult is definitely slower as the iterations go up. I tossed in a thread test with 50 threads each running 50K iterations and the averages were: MVEL 8000ms JCatapult 23000ms However, under one test condition, MVEL never returned and caused a load of 50 on my box. It was quite distressing, but it looked like MVEL got into a bunch of infinite loops or something. I let it run at a load of 50 for a while and then I had to kill it, but none of the threads had finished yet. I also did a 50 thread and 50 iteration test and the averages were roughly: MVEL 30ms JCatapult 120ms Except for the case above, MVEL definitely out-performs JCatapult. ... 50,000 iterations on MVEL interpreted in 114.80ms. This is a 1000x more iterations than your benchmark. If I divide 114.8ms / 1000 ... I get 0.1ms (or what would otherwise be rounded down to 0ms). In OGNL's case, it did 50 iterations in 1.95ms (or what would be measured as 1ms -- as these time measurements always round down because of the fact currentTimeMillis() returns the result in MS). Although JCatapult is slower, I'd be careful with such math because it isn't always as linear as this. You can talk about good enough all you want, but faster is always better when it comes to scale. :) I know a lot about scale and this is not the only truth. In fact, for what we are talking about, good enough should be just fine. Most scale problems
Re: MVEL?
I'll send you my unit test that does it on my box directly. -bp On Oct 12, 2008, at 8:34 PM, Chris Brock wrote: However, under one test condition, MVEL never returned and caused a load of 50 on my box. It was quite distressing, but it looked like MVEL got into a bunch of infinite loops or something. I let it run at a load of 50 for a while and then I had to kill it, but none of the threads had finished yet. This is the first public beta of MVEL. Much of the code has not been publicly flushed out. So we do expect bugs. But I'd be particularly interested in trying to recreate the conditions of this. Brian Pontarelli wrote: Sure. But OGNL will return similar results with 50 tests. Yet people have run into performance problems. The issue is that you're not looking at performance in terms of resource contention, and in terms of aggregate resource usage. I'd say that for web application expressions OGNL and MVEL are about equal then. In fact, I've never wanted to replace OGNL for performance reasons. It was for primarily other reasons. Say you have a page which contains 20 expressions. And your pages are getting hit 15 times a second (a reality in some high traffic sites). That's 300 expressions running every second. Now, in insolation that's probably chump change. But as resource contention rises in these situation, the overall efficiency drops and resource usage is exaggerated as a result. I've worked with this level of traffic and higher and it is still not an issue to be setting 20 values for 1ms per request. You might in term start to find that what is only 0ms in an isolate closed-loop test (which is not a very good way to benchmark in Java, by the way) could very well be something that contributes to a significant amount of CPU time in systems with high load. Probably not in this case though and the scale between 1 iteration and 50 is decent testament to that. It the CPU was pinned it would be more linear. Take these real benchmarks (from MVEL 1.2--which is old): Test Name: Deep Property Expression : foo.bar.name Iterations : 5 Interpreted Results : (OGNL) : 1955.20ms avg. (mem delta: -790kb) [1936,1949,1943,1994,1954] (MVEL) : 114.80ms avg. (mem delta: -112kb) [119,113,110,117,115] Compiled Results : (OGNL Compiled) : 92.80ms avg. (mem delta: -580kb) [92,92,92,92,96] (MVEL Compiled) : 1.80ms avg. (mem delta: -18kb) [1,2,2,2,2] Here's what I got for 50K on my box using MVEL and JCatapult side by side: MVEL 808ms JCatapult 1200ms MVEL had a hit for the first method call, but it was only 40ms. Otherwise, they performed exactly the same for anything up to 50 iterations. MVEL often poked above 1ms for single iterations, while JCatapult never did, but that's negligible for both. JCatapult is definitely slower as the iterations go up. I tossed in a thread test with 50 threads each running 50K iterations and the averages were: MVEL 8000ms JCatapult 23000ms However, under one test condition, MVEL never returned and caused a load of 50 on my box. It was quite distressing, but it looked like MVEL got into a bunch of infinite loops or something. I let it run at a load of 50 for a while and then I had to kill it, but none of the threads had finished yet. I also did a 50 thread and 50 iteration test and the averages were roughly: MVEL 30ms JCatapult 120ms Except for the case above, MVEL definitely out-performs JCatapult. ... 50,000 iterations on MVEL interpreted in 114.80ms. This is a 1000x more iterations than your benchmark. If I divide 114.8ms / 1000 ... I get 0.1ms (or what would otherwise be rounded down to 0ms). In OGNL's case, it did 50 iterations in 1.95ms (or what would be measured as 1ms -- as these time measurements always round down because of the fact currentTimeMillis() returns the result in MS). Although JCatapult is slower, I'd be careful with such math because it isn't always as linear as this. You can talk about good enough all you want, but faster is always better when it comes to scale. :) I know a lot about scale and this is not the only truth. In fact, for what we are talking about, good enough should be just fine. Most scale problems occur because of bottlenecks and I doubt that our case of web applications and setting parameters is a bottleneck. However, I'm definitely welcome to suggestions on improvements for my quite simple expression evaluator. I'd also be interested to hear a good discussion about caching compiled MVEL expressions and whether or not thread contention for the cache is an issue at all. Unfortunately, because JCatapult uses my concept of dynamic attributes quite heavily, it might be difficult to swap in MVEL without some tweaks to the type conversion API. But I could look into it. -bp - To unsubscribe, e-mail: [EMAIL
Re: MVEL?
Taking a brief look at the MVEL type conversion API it could be
somewhat difficult to get this information into the converter on a per
request basis, especially if converters are singleton scoped. This
information isn't available on the source in most cases. It is usually
externalized in the request or the container object. The API looks a
pretty lightweight, which is nice, but also restrictive. From what I
could see I would have to monkey around with things and use something
like a ThreadLocal to pass this information to the converter.
The source-from-many pattern seems to be somewhat backwards for the
web. It is more likely the case that a single converter will convert
to many classes from a String or String[]. The JCatapult type
converter passes in the type being converted to and then the String
value(s). Although this is very web centric, it cleans up the API and
makes things simpler to implement. MVEL is obviously more generic,
which means some massaging is necessary to tune it for the web.
It also seems to be lacking a good set of exceptions thrown out of the
API. At least from the docs, since I couldn't find JavaDoc and the
distribution only has source (ouch). This doesn't mean that Struts
can't provide good runtime exceptions and then just catch those, but
it leaves things much more open for developers writing new converters.
I'd rather see the API define these exceptions clearly and for them to
be checked.
I think that using generic languages like OGNL or MVEL are decent
solutions, but a web centric solution would be best. I'm also in favor
or dropping most if not all of the extra features and only providing
property/field getting and setting. I think adding in another language
just clouds the waters. FreeMarker and JSP both have languages that
cover most of the common cases.
Feel free to take a look at the JCatapult MVC expression evaluator for
what I feel should be supported.
-bp
On Oct 11, 2008, at 12:52 PM, Chris Brock wrote:
MVEL has a pluggable type-conversion API, just like OGNL. Since it's
source-from-many in it's design, you can easily design converters that
perform as much introspection as necessary to determine formatting,
etc.
Brian Pontarelli wrote:
Yeah. That's good. The last thing I would toss in as criteria is a
good type conversion interface. In JCatapult, I actually took
things a
step further. I found that complex types usually needed more
information than just the data to perform the type conversion. For
example, conversion of dates generally requires the date format.
Likewise, conversion to money generally requires the currency code.
In
many MVCs this information is statically configured for the entire
application, configured per action in XML or properties files or
fixed
and not configurable at all.
For maximum flexibility, I built a system where tags could provide
this additional data via extra attributes (it can also be configured
application wide as well). My tags look like this:
[EMAIL PROTECTED] name=user.lifeSavings currencyCode=USD/]
[EMAIL PROTECTED] name=user.birthDay dateTimeFormat=MM/dd//]
This information then gets passed to the type converters as part of
the API.
This then reveals another shortcoming of OGNL and the wrapper in
Struts, what if a required attribute is missing? This is a different
case then if the type conversion fails. So, I created two distinct
checked exceptions to handle these two cases. This makes the type
conversion system more powerful and easy to interact with. Plus, it
reveals good exceptions for coding problems.
-bp
On Oct 10, 2008, at 3:00 AM, Chris Brock wrote:
MVEL will handle type coercion for method parameters, properties,
and even on
egress of those values if the generic type information can be
deduced on
ingress. In situtations where the generic type is dependent on the
root of
the object graph though, MVEL cannot infer generic type data (ie. a
bound
variable, that's say a Map) because of erasure. There is no generic
type
information held on a per-instance basis.
However, if the parameterized type is a class member say:
class Foo {
public MapString, Integer map;
}
And you use an instance of Foo as a context or as a bound variable,
MVEL's
compiler can certainly extract the generic type information, and
provide
automatic coercion and verification accordingly. MVEL's type
verifier will
always extrapolate whatever type data is available.
Brian Pontarelli wrote:
This is not quite the same unless it can detect generics while
setting
values and creating values. An example might be values from a form
going into something like:
ListString
or
MapString, ListInteger
or the always fun
ListListInteger
that sorta thing. I know that OGNL had (might not any longer) many
issues with generics in this respect. I think OGNL also got mad
when
it encountered something simple like:
int[]
or
String
Re: MVEL?
Yeah. That's good. The last thing I would toss in as criteria is a
good type conversion interface. In JCatapult, I actually took things a
step further. I found that complex types usually needed more
information than just the data to perform the type conversion. For
example, conversion of dates generally requires the date format.
Likewise, conversion to money generally requires the currency code. In
many MVCs this information is statically configured for the entire
application, configured per action in XML or properties files or fixed
and not configurable at all.
For maximum flexibility, I built a system where tags could provide
this additional data via extra attributes (it can also be configured
application wide as well). My tags look like this:
[EMAIL PROTECTED] name=user.lifeSavings currencyCode=USD/]
[EMAIL PROTECTED] name=user.birthDay dateTimeFormat=MM/dd//]
This information then gets passed to the type converters as part of
the API.
This then reveals another shortcoming of OGNL and the wrapper in
Struts, what if a required attribute is missing? This is a different
case then if the type conversion fails. So, I created two distinct
checked exceptions to handle these two cases. This makes the type
conversion system more powerful and easy to interact with. Plus, it
reveals good exceptions for coding problems.
-bp
On Oct 10, 2008, at 3:00 AM, Chris Brock wrote:
MVEL will handle type coercion for method parameters, properties,
and even on
egress of those values if the generic type information can be
deduced on
ingress. In situtations where the generic type is dependent on the
root of
the object graph though, MVEL cannot infer generic type data (ie. a
bound
variable, that's say a Map) because of erasure. There is no generic
type
information held on a per-instance basis.
However, if the parameterized type is a class member say:
class Foo {
public MapString, Integer map;
}
And you use an instance of Foo as a context or as a bound variable,
MVEL's
compiler can certainly extract the generic type information, and
provide
automatic coercion and verification accordingly. MVEL's type
verifier will
always extrapolate whatever type data is available.
Brian Pontarelli wrote:
This is not quite the same unless it can detect generics while
setting
values and creating values. An example might be values from a form
going into something like:
ListString
or
MapString, ListInteger
or the always fun
ListListInteger
that sorta thing. I know that OGNL had (might not any longer) many
issues with generics in this respect. I think OGNL also got mad when
it encountered something simple like:
int[]
or
String[]
coming from checkbox lists and multiple selects. I believe that it
would stuff the values into the String[] like this:
{value1,value2,value3}
rather than
{value1, value2, value3}
This was a while ago, so all of this might be fixed.
-bp
On Oct 9, 2008, at 7:32 PM, Chris Brock wrote:
MVEL 2.0 has full support for generics (and static typing):
http://mvel.codehaus.org/Strong+Typing+Mode
Brian Pontarelli wrote:
On Oct 7, 2008, at 3:08 PM, Dave Newton wrote:
Just to muddy the EL/templating waters:
http://mvel.codehaus.org/Performance+of+MVEL
(v. OGNL)
Not sure about MVEL or OGNL at this point, but everything was
lacking
in support for generics, collections and arrays. I wrote my own for
the JCatapult MVC and it was really not all that hard. It only
handles
getting and setting, but I figure that's all that should be allowed
at
that point anyways.
-bp
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/MVEL--tp19867360p19910418.html
Sent from the Struts - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/MVEL--tp19867360p19914597.html
Sent from the Struts - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: MVEL?
This is not quite the same unless it can detect generics while setting
values and creating values. An example might be values from a form
going into something like:
ListString
or
MapString, ListInteger
or the always fun
ListListInteger
that sorta thing. I know that OGNL had (might not any longer) many
issues with generics in this respect. I think OGNL also got mad when
it encountered something simple like:
int[]
or
String[]
coming from checkbox lists and multiple selects. I believe that it
would stuff the values into the String[] like this:
{value1,value2,value3}
rather than
{value1, value2, value3}
This was a while ago, so all of this might be fixed.
-bp
On Oct 9, 2008, at 7:32 PM, Chris Brock wrote:
MVEL 2.0 has full support for generics (and static typing):
http://mvel.codehaus.org/Strong+Typing+Mode
Brian Pontarelli wrote:
On Oct 7, 2008, at 3:08 PM, Dave Newton wrote:
Just to muddy the EL/templating waters:
http://mvel.codehaus.org/Performance+of+MVEL
(v. OGNL)
Not sure about MVEL or OGNL at this point, but everything was lacking
in support for generics, collections and arrays. I wrote my own for
the JCatapult MVC and it was really not all that hard. It only
handles
getting and setting, but I figure that's all that should be allowed
at
that point anyways.
-bp
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/MVEL--tp19867360p19910418.html
Sent from the Struts - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: MVEL?
On Oct 7, 2008, at 3:08 PM, Dave Newton wrote: Just to muddy the EL/templating waters: http://mvel.codehaus.org/Performance+of+MVEL (v. OGNL) Not sure about MVEL or OGNL at this point, but everything was lacking in support for generics, collections and arrays. I wrote my own for the JCatapult MVC and it was really not all that hard. It only handles getting and setting, but I figure that's all that should be allowed at that point anyways. -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: If your evaluating new template engines, what about ZipScript
As I'm never a big fan of relying solely on the fact that technologies have been used, I'd compare feature sets. Here's what I like from GXP: - Pre-compile for performance - Type safe - Injectable - White space reduction - l10n and i18n support (although difficult to determine exactly how they work) - Componentized - Auto-escaping Here's what I don't like - XML syntax yet again - Somewhat complex - Lacking sufficient documentation for all features I haven't yet, but I would be comparing feature sets rather than usage. At the same time though, they can both be used for results. I'd probably only want to use one of them for tag files to reduce complexity, but anyone interested in writing a pluggable tag system could easily support both for tag files as well. -bp On Aug 1, 2008, at 6:35 AM, Joe Hudson wrote: Thank you for taking the time to evaluate zipscript. This is not currently being used in any real world apps because it is new. That is certainly a valid concern. It is kind of a catch 22 because how can you ever be used in a real world app if people only want an engine that is being used in a real world app? Anyway, I'd like to address my assumption of your main concerns regarding real world app usage: 1) Is it reliable? All of the functionality is unit tested before a release is performed and there are many unit tests which can be seen here: - Unit Tests: http://code.google.com/p/zipscript/source/browse/#svn/ trunk/core/src/main/test/test/hudson/zipscript - Referenced Templates and Results: http://code.google.com/p/zipscript/source/browse/#svn/trunk/core/src/ main/test/templates 2) How does it perform? There is a unit test that merges a template consisting of multiple macro references (called PerformanceTest) http://code.google.com/p/zipscript/source/browse/trunk/core/src/main/test/test/hudson/zipscript/PerformanceTestCase.java This test, when performed on my laptop, can perform 1000 merges in about 1 second. As to the other issues of porting to other languages. That isn't currently in the plan now but certainly would be something on the plate if this language got a foothold. Joe On Fri, Aug 1, 2008 at 6:20 AM, Ted Husted [EMAIL PROTECTED] wrote: For me, it's the real world apps, *plus* the interest in porting GXP to other platforms, like C++, and Ruby. Personally, I'd like to add C# to that list. ASPX, like JSF, has its charms, but many .NET developers (including me) would like alternatives. I do find the zipscript YUI examples interesting, since we are also looking for an alternative approach to supporting Ajax with the Struts tags. -Ted. On Fri, Aug 1, 2008 at 1:30 AM, Al Sutton [EMAIL PROTECTED] wrote: Joe, My main reason for backing GXP is that it's been used in high volume real world apps by Google and so has been proven to scale. Does ZipScript have the same real world testing, and if so where is it used? Al. Joe Hudson wrote: Hello, With all the talk about GXP, I wanted to let you know about another template engine called ZipScript (zipscript.org). Ok, you're probably saying... another one??? but this has some distinct advantages and I would love for you to give it a try - I really think you'll be happy you did. 1) it can be used to create complex UI components 2) it has a powerful non XML-based syntax (which is helpful since the most common output is XML) 3) it can also be used to get more than just text from expressions (like booleans or objects) - great for having smarter config properties Here are some quick links: - homepage: http://zipscript.googlecode.com - Yahoo! UI macro examples: http://code.google.com/p/zipscript/wiki/YUIMacros - Language Syntax Examples http://code.google.com/p/zipscript/wiki/SyntaxExamples Thanks Joe Hudson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Google XML Pages (GXP) to replace Freemarker in tags?
IJ 8.0 has built in FTL support. EAPs are currently available. -bp On Jul 27, 2008, at 8:36 AM, Rene Gielen wrote: I Like it very much, from what I can tell from a first glance. In addition to the interesting features, it should be nice to work with an IDE like IDEA (which still lacks fm support). Al Sutton schrieb: P.S. If you want to know more about GXP there is a history available from http://google-opensource.blogspot.com/2008/07/google-xml-pages-functional-markup.html Al Sutton wrote: Gets my vote. GXP will have had real-world thrashing and monitoring whereas as we've seen recently freemarkers scalability issues aren't always found and fixed that quickly. Al. Don Brown wrote: It is pretty well known that Google uses WebWork 2 and Struts 2 in many of its applications, but for the view layer, they use Google XML Pages (GXP) [1], which was just opened source yesterday or so. There is a lot to like in GXP like type safety, speed, correct HTML generation, automatic support for HTML and XHTML (one of our frequent tickets), automatic encoding of untrusted content, and even things like mulitiple language support. This might be a perfect replacement for Freemarker in our tags as the templates can be compiled, have better error reporting, don't introduce yet another expression language, and solve a number of our outstanding feature requests around tags. Thoughts? Don [1] http://code.google.com/p/gxp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL and parameters
I wrote my own for the JCatapult MVC and it does most of the parameter setting stuff that OGNL does and a few other things like handling generics correctly and completely. It also has a pretty solid type conversion API. Took about 3 days to write, test and complete. Feel free to grab the code from the project. It should work well in any MVC with some tweaks at the type-conversion layer. http://code.google.com/p/jcatapult -bp On Jul 16, 2008, at 11:56 AM, Musachy Barroso wrote: Should we continue to use OGNL for parameter binding? This creates so many possible security holes, in exchange for pretty much nothing, when parameter names should be simple (indexing + the old A.B.C notation). Are there any uses cases where the full OGNL power is needed, for parameter binding? musachy -- Hey you! Would you help me to carry the stone? Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: environment awareness (project stage in JSF)
I think we both agree that configuration is best. In fact I think you even support environment awareness in configuration system. So, from that perspective we are solid. The rest is just debating personal style and developer freedom. I will answer a few things below, but I think we can close out this thread or take it off-list. The key thing here is that S2 *suggests* it, it doesn't impose it. My point is that it is fine to suggest it something that the user can alter, but it is bad to do something which alters program behaviour without the environment managers involvement as would be the case with a conditional branch dependant on it's environment. I would also ask the question of If a developer has seen the framework exihbit a behaviour, are they really a bad citizen for making use of it?. Suggestions aside, S2 still doesn't make this easy. It needs environment awareness and it should probably default a ton of stuff when in production mode. This one being the top on the list. I'm also not a fan of just accepting something as good if it's a de- facto standard because I know from experience that not all decisions which make it into the wild are teh right thing to do. Would S1 have been released if WebWork had already been floating around?, Would the Java UI Event model in 1.0 ever had seen the light of day if someone had already started work on what became the 1.1 model?, and you just need to look at the history of EJBs to see things which were de-facto standards which have now been retired (Home/Remote interfaces, Message beans that could only get messages from JMS). Not accepting crap is one thing. Not accepting something that is outside our comfort zone is something else entirely. To me the big switch idea is like hard wiring your headlights and a speed limiter into your windscreen wipers. Whilst it might seem a good idea, there are situations when you'll just want the wipers on or off. Haha. Not even sure that's similar enough to the cases I mentioned to make sense. Humorous though. You may not be happy about it, but a production issue may neccessitate it. My previous message had a real world example of where a database was moved to a smaller system because the performance of many apps was poor due to the total load on the database cluster. Orbitz was slightly different. No one made environment changes without consulting a developer. We had it happen a few times and it didn't go well because the complexity was too high. It always looked like an acceptable change, but the developers who wrote the code always knew something that others didn't. That's why nearly all of the developers wore pagers and everything was setup to allow developers to help make decisions. Now, that's just Orbitz and I'm certain there are different environments that this would be okay. But I figure call the developer first and double check to see if any flags go up. In the UK and the US almost all major banks aim to be able to fail over to a DR site within 2 hours for all critical applications, if you add in the requirement for a developer to make a new release for any configuration change that needs to be made you're wasting valuable time. Yeah, we didn't do releases to change configuration or the environment. It took days to do a release. We just patched things. I know people are feeling a little sick at the thought of ad hoc patching, but it worked for our situation. But if you dictate behaviour why should your choice change just because the app has changed environment?, if it's a useful feature for you in dev it will most likley be a useful feature to a techie trying to resolve in issue in support, so it should be a configurable switch, not a cast-iron decision that allows you to access features which help you debug the program in dev but provent the techie checking for the source of a problem in production or test . Might be useful, but in some cases if you turn on cache checking it will crush the entire system. Again, I'm just advocating being pragmatic and protecting the system. However, most cases aren't like Obritz and I could definitely see that leaving cache checking turned on won't impact things too much. But, I'm sorta stuck now and so I do a lot of my work thinking about massive scale up front. Whilst I repect your position I still hold my view that it will encourage developer lazyness because why would you include code that you know will never run once you've released the application?, in my view thats just unncessary bloat because a developer was too lazy to develop a solution where the code can be removed from the app prior to release. Fair enough. I still hold that there are a lot of other cases and ways to tackle things. -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
Re: [OT] Re: environment awareness (project stage in JSF)
application was dumped to disk and moved to another available database server, and that individual applications configuration was updated to point at the new server (the other apps on the app server remained pointing at the original cluster). If the techies at DR just had a dev, test, or prod switch how could they have done that? Yes configuration is a feature of the environment, but it should be up to the environment manager to manage the configuration, and not up to the developer to dictate what is correct. Al. Brian Pontarelli wrote: Wow. This got way off topic, but I'm compelled to answer. ;) Your assumption about QA being the only problem is incorrect. It is environment based. The application should not be changed in anyway when it is migrated across boundaries. It should be able to determine where it is and how it should behave. If you look at the differences between environments, you'll see that this is true for many things. Your example of LDAP appears to support my case. You are providing an environment based configuration source. In addition, your LDAP is configured per environment via an IP constraint. Lastly, you've just moved the configuration from files to LDAP. It is still different for different environments. This could have been as easily done using JNDI. What you are talking about IS environment awareness. In terms of payment processing, to be specific, we hit the gateway using a different message that indicates it is a test. How do you propose to determine if we should use a test message? The only way is via configuration and that configuration must be different between environments. However, you could as easily mock things out. But you still have to contact a different URL. This is all based on environment. Again, I think you are simplifying this and by saying that people are lazy. Trust me when I say that writing environment aware configuration is not a reduction of work or management. Furthermore, you assume only two environments it seems. We had 5 different environments and they all had different configuration. -bp On Jun 28, 2008, at 10:06 AM, Al Sutton wrote: Brian, From what I can see your only real problem is QA on config files and given that how can you you can guarentee that all of your servers will never have their config drifted between zones because a certain problem occurr in dev but does in production. I've previously worked on a project that used LDAP directories for everything (data storage and configuration). The app servers were only given the LDAP FQDN to bind to and pulled all of their config data from there. The LDAP servers had IP access control rules which prevented any machine outside of the domain attaching to them, this meant a server on the dev network couldn't get the production configuration and vice versa. You could use an HTTP URL and web server as an alternative, but the principal is the same, protect the data which can cause things to go wrong (i.e. the config file), and don't try to code to prevent every screw-up a support techie will make (they can be pretty inventive when it comes to how to screw things up). I can also see concerns over where do you draw the line between environments. With your example of credit card processing where would you say dev and production separate, do you write the code to return dummy auths and/or declines in dev mode, or do you call out to the payment gateway? One means that anyone with a spare machine can test something, the other means you need them to have the correct config and equipment to talk to the payment gateway?, what happens if someone wants to switch between the two in order to test the gateway interface, do you create another environment label? All in all it does seem like a lazy solution to me, whats needed is better QA, not a solution which makes people sloppy because they think that the code will catch their mistakes. Al. Brian Pontarelli wrote: I think this is an over-simplification of a complex problem. Here are a few examples from orbitz.com: - Thread pool sizes. We couldn't replicate production (1500+ servers) in staging, so instead, we created as many VMs as we could handle on the limited number of machines we had (~100) to get an accurate simulation. This required smaller thread pools to not kill the OS - Different back end host connections to the GDSs. You can't book a real flight in staging or development. - Different server names. We had around 7 tiers that spanned multiple servers. Each request to Orbitz hits anywhere from 10-20 different machines. Although we used Jini to discover the services, we still had to configure the Jini lookup servers differently between environments - A classic example that everyone uses is database configuration and SMTP servers. These are could be in a JNDI entry or the application might create
Re: [OT] Re: environment awareness (project stage in JSF)
I'll reply inline quickly. I'm coming from the other side of the configuration debate; the side that says you should have the configuration file which shows whats happening as opposed to having intelligent defaults which hide configuration options from the deployer/support person. In my experience, this is painful for any application of size. I've even written frameworks to ensure configuration setup like this is correct. It's not a good way to manage large complex applications from my perspective. So, for your class reloading example, if someone takes your framework, uses it in dev, does something which relies on the class being reloaded, and when the app is moved into production it suddently doesn't you'll end up with the person building on your code going It works for me. You can't rely on people reading documents, you can't rely on them knowing a few years down the line what you choice of dev, test, and production settings were, and therefore knowing what behaviour to expect. You appear to aggressively debate things that are de-facto in other languages and many situations. Look at Rails, Grails, Turbogears, Django, etc. Heck, even Struts2 suggests that for a production system you disable caching of FTLs. Most production systems don't check JSPs for reloading. If developers want to make assumptions around things that are conventions, they need to figure them out on their own or use a different system. Assuming your audience aren't going to be good citizens is not a good place to start in my opinion. I disagree that there is configuration defined by environment deployment people but managed by developers. Managers of the environment should be able to manage the configuration, developers should only have an advisory role. The product my company produces is running in well over a hundred different companies, can you imagine the reponse we would get if we said that we were the only people who could change it's configuration?, if we had to be involved if their changed their servers, clustering solution, database, or anything else related to the app?, and the increase in support work for us because we imposed that rule? we wouldn't make anywhere near the sales of the product we do. One of the things companies look for is the solution to the If the development company goes bust can we run without them?, and how can they do that if the development company is the only people who can make changes to configuration? Defined = Filled out or selected or configured. Managed = Code against. They still shouldn't go changing things without asking the developer. If I coded an application to expect the configuration they are defining to hit an specific type of JMS server or distributed cache and then they change it to hit a different cluster or smaller cluster I might not be too happy about that. You can set some best guess values for things like cache sizes, thread pools, etc., but the end user should still be able to alter them hopefully with the advice of a developer. You put disclaimers saying things like Altering these values without our involvements is not advised and may result in an non-working application, but you still shouldn't stop them doing it. If there is spare techie time and they want to test a P4 server against a Q6600 server against a virtualised multi-core machine on a massive multi-CPU box then thats something they should be able to do without having to call the developer every time they want to try something new. Yep. But I'm not certain this applies for everything. I'd much rather be able to dictate certain behavior in some cases. The Inversoft Profanity WebService, which customers can purchase and deploy, can be set into production mode which dictates certain types of behavior. That's really all I'm saying. This could be a difference in viewpoint that we have based on our experience (I get the feeling your app is designed for deployment in environments you t have a fair amount of control over), but for me apps should never enforce configuration changes on users purely based on what environment they in, the deployment/support folk should always be able to change things when neccessary (including dropping down thread pool sizes if they need to run the app on a less powerful server in an emergency). Yes and no. I just think it is not very pragmatic to discount certain things. I can understand the need for other folks to manage some configuration, but this is not always the case. I just feel you are being too strict in your analysis. Your situation might call for certain things but saying that adding environmental awareness to JSF makes people lazy is rather short-sighted in my opinion. -bp Al. Brian Pontarelli wrote: I've written code that uses environment. Of course, I mainly write frameworks, so it probably makes more sense there, but I have
Re: [OT] Re: environment awareness (project stage in JSF)
I've kind of lost track of the original point anyway :/ Al mentioned that adding environment awareness to JSF makes people lazy. I jumped in and stated I disagreed and that adding this just allows people that need it to use it. From what I've gathered thus far (Al correct me if I'm wrong), Al thinks it should NEVER be used from code at all and only configuration should be environment aware and mainly managed by configuration management engineers for each environment. I just wish everything had the concept of environment. That way if I needed it I could use it. -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: environment awareness (project stage in JSF)
on each machine. Plus each entry can be scoped by environment (production, test, development), machine, or application name (in case multiple applications are sharing a library component). We have log4j and spring configurers so that it is tightly integrated into the tools we use. It's saved us an eternity of time tracking down bugs from one environment to the next since we deploy the same WAR file that was accepted by the quality assurance group into production and let the configuration take care of itself. I've often thought of creating a Google Code project to open source it, but wasn't sure if there would be enough interest. (*Chris*) On Fri, Jun 27, 2008 at 1:38 PM, Brian Pontarelli [EMAIL PROTECTED] wrote: Yeah, I found that environment resolution was a key feature for any large application. At Orbitz we could deploy the same bundle to any server and the bundle would figure out where it was and configure itself for that environment. Worked really well. I have also provided this type of feature in JCatapult using an API that can be implemented however developers need. The default implementation uses JNDI, but it is simple to change it. The nice thing about that is you can assume at all times that the environment is available and make assumptions around that. -bp On Jun 27, 2008, at 1:53 PM, Frank W. Zammetti wrote: We d something similar as well, but we decided to use a simple env var in all environments... So the exact same EAR can deploy to any environment and the code within simply looks for that var and acts accordingly. Simple but highly effective. Frank -Original Message- From: Ian Roughley [EMAIL PROTECTED] Sent: Friday, June 27, 2008 2:59 PM To: Struts Developers List dev@struts.apache.org Subject: Re: environment awareness (project stage in JSF) I've actually had to implement this type of feature in multiple enterprise applications. However, I would say that it's not knowing the environment, but being able to change configuration elements per environment that is important (for what I did, and in rails I think this is the most important elements). i.e. change the SMTP, temp file dir, admin user email address, etc. depending on whether you are testing locally vs. production. If developers are using spring, there is a way to load property files with a hostname extension (which is one solution) - but should we always expect users to be using Spring? The other question is being able to modify struts.property properties depending on env (i.e. devMode=true in development and never in production). /Ian Antonio Petrelli wrote: 2008/6/27 James Holmes [EMAIL PROTECTED]: http://blogs.sun.com/rlubke/entry/jsf_2_0_new_feature2 I like it. This is one of the features of RoR that I really found useful - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: environment awareness (project stage in JSF)
Wow. This got way off topic, but I'm compelled to answer. ;) Your assumption about QA being the only problem is incorrect. It is environment based. The application should not be changed in anyway when it is migrated across boundaries. It should be able to determine where it is and how it should behave. If you look at the differences between environments, you'll see that this is true for many things. Your example of LDAP appears to support my case. You are providing an environment based configuration source. In addition, your LDAP is configured per environment via an IP constraint. Lastly, you've just moved the configuration from files to LDAP. It is still different for different environments. This could have been as easily done using JNDI. What you are talking about IS environment awareness. In terms of payment processing, to be specific, we hit the gateway using a different message that indicates it is a test. How do you propose to determine if we should use a test message? The only way is via configuration and that configuration must be different between environments. However, you could as easily mock things out. But you still have to contact a different URL. This is all based on environment. Again, I think you are simplifying this and by saying that people are lazy. Trust me when I say that writing environment aware configuration is not a reduction of work or management. Furthermore, you assume only two environments it seems. We had 5 different environments and they all had different configuration. -bp On Jun 28, 2008, at 10:06 AM, Al Sutton wrote: Brian, From what I can see your only real problem is QA on config files and given that how can you you can guarentee that all of your servers will never have their config drifted between zones because a certain problem occurr in dev but does in production. I've previously worked on a project that used LDAP directories for everything (data storage and configuration). The app servers were only given the LDAP FQDN to bind to and pulled all of their config data from there. The LDAP servers had IP access control rules which prevented any machine outside of the domain attaching to them, this meant a server on the dev network couldn't get the production configuration and vice versa. You could use an HTTP URL and web server as an alternative, but the principal is the same, protect the data which can cause things to go wrong (i.e. the config file), and don't try to code to prevent every screw-up a support techie will make (they can be pretty inventive when it comes to how to screw things up). I can also see concerns over where do you draw the line between environments. With your example of credit card processing where would you say dev and production separate, do you write the code to return dummy auths and/or declines in dev mode, or do you call out to the payment gateway? One means that anyone with a spare machine can test something, the other means you need them to have the correct config and equipment to talk to the payment gateway?, what happens if someone wants to switch between the two in order to test the gateway interface, do you create another environment label? All in all it does seem like a lazy solution to me, whats needed is better QA, not a solution which makes people sloppy because they think that the code will catch their mistakes. Al. Brian Pontarelli wrote: I think this is an over-simplification of a complex problem. Here are a few examples from orbitz.com: - Thread pool sizes. We couldn't replicate production (1500+ servers) in staging, so instead, we created as many VMs as we could handle on the limited number of machines we had (~100) to get an accurate simulation. This required smaller thread pools to not kill the OS - Different back end host connections to the GDSs. You can't book a real flight in staging or development. - Different server names. We had around 7 tiers that spanned multiple servers. Each request to Orbitz hits anywhere from 10-20 different machines. Although we used Jini to discover the services, we still had to configure the Jini lookup servers differently between environments - A classic example that everyone uses is database configuration and SMTP servers. These are could be in a JNDI entry or the application might create connections directly, depends. If the application creates this stuff it will need different configuration per environment. - Not charging credit cards in development, but charging them in staging and production. And we also had specific merchant accounts to test in staging that were full transactions, but they didn't charge us the full amount. We also had many different bank accounts setup to test all the different types of cards and transaction boundaries. And the list continues. I might agree that an MVC might not need to know the environment
Re: environment awareness (project stage in JSF)
Yeah, I found that environment resolution was a key feature for any large application. At Orbitz we could deploy the same bundle to any server and the bundle would figure out where it was and configure itself for that environment. Worked really well. I have also provided this type of feature in JCatapult using an API that can be implemented however developers need. The default implementation uses JNDI, but it is simple to change it. The nice thing about that is you can assume at all times that the environment is available and make assumptions around that. -bp On Jun 27, 2008, at 1:53 PM, Frank W. Zammetti wrote: We d something similar as well, but we decided to use a simple env var in all environments... So the exact same EAR can deploy to any environment and the code within simply looks for that var and acts accordingly. Simple but highly effective. Frank -Original Message- From: Ian Roughley [EMAIL PROTECTED] Sent: Friday, June 27, 2008 2:59 PM To: Struts Developers List dev@struts.apache.org Subject: Re: environment awareness (project stage in JSF) I've actually had to implement this type of feature in multiple enterprise applications. However, I would say that it's not knowing the environment, but being able to change configuration elements per environment that is important (for what I did, and in rails I think this is the most important elements). i.e. change the SMTP, temp file dir, admin user email address, etc. depending on whether you are testing locally vs. production. If developers are using spring, there is a way to load property files with a hostname extension (which is one solution) - but should we always expect users to be using Spring? The other question is being able to modify struts.property properties depending on env (i.e. devMode=true in development and never in production). /Ian Antonio Petrelli wrote: 2008/6/27 James Holmes [EMAIL PROTECTED]: http://blogs.sun.com/rlubke/entry/jsf_2_0_new_feature2 I like it. This is one of the features of RoR that I really found useful - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: UknownHandlers
Al Sutton wrote: Brian, Dependencies can be reduced to simple ordered lists unless there is a requirement for two plugins to be run in parallel (which is pretty rare), or you have a circular dependency. Reduction of dependency graphs is something I've come accros dependency declaration handling several times in my last couple of decades of development, and in all that time I've not seen a dependency evaluation system which couldn't run as an ordered list as long as you state it can't have parallel tasks or circular dependencies. I know that they can always be reduced to an ordered list, but that list is not always the same depending on the graph. Having written Savant, I know quite a bit about dependencies and graph traversal and in my opinion it is not a suitable solution for this problem. There are too many root nodes and traversal edge cases. Not to mention plugins would eventually have to be knowledgable about most plugins in order to reduce traversal complexity and guessing. Plugins will have to define their dependencies if they want to be handled correctly, so if G needs to be run after D then D is a dependancy, and if the author of G does not declare it as such then that is an bug in plugin G. Similarly if B needs to be run after G then B needs to declare G as a dependency. Right. That's my main point. Otherwise, they end up being root nodes in the graph and traversal is based on parse order and that means it could be different each time if the parse order changes. When you have four root nodes, which goes first? That's a tough question to answer and guessing means it could be right during one pass and wrong during another, especially as you introduce other root nodes. If you are talking about optional tasks then you then enter the more complex world of mandatory and optional dependencies (e.g. G should be run after D if D is configured, but if D isn't configured then we don't need to put it in the list). That is something to be handled on either a second pass once all of the configured plugins and their dependencies are known and have an initial order. During the second pass the entries are shuffled if neccessary to satisfy the option dependencies. Nope, I'm assuming everything is mandatory. I'm just assuming incomplete graph knowledge up front and having to make choices in a sort of fuzzy manner. I understand there are situations where the user may want to run G between D and B and they can't modify B to declare G as a dependency, but thats where the manual configuration options come in. If a user wants to specify an order they can do so and the core should only verify the order satisfies the dependency requirements. Agreed. But the trade off of complexity here isn't worth it it seems. The configuration is minimal and the complexity of a dependency management graph and traversal seems to be too much. Furthermore, it adds a bit of magic that users might find disconcerting. Savant on the other hand is based purely on this magic and integral to the system. This means users need to fully understand it to use Savant. Struts on the other hand would probably suffer from this to some degree. I would think it would be like the JBoss infrastructure. Some folks would love it because of all its dependency management coolness but most folks would hate it for the complexity and inability to quickly figure out what the heck is going on. -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: UknownHandlers
In most cases dependencies rarely fall into simple lists. They often
form graphs, which can still be traversed, but it is slightly more
complex. The reason for the graph is that two plugins might have the
same dependencies and there might be multiple root nodes forming a graph
like:
A - B - C
|^
F - D|
\/
That being said, this solution doesn't solve the issue with specific
ordering based on dependencies of the plugin because you might have
complex situations like:
A - B - C
D - B
E - A
F - C
G
The trickiest part is when G doesn't have dependencies defined ahead of
time, but after all is said and done, G really needs to run before B but
after D. Therefore, the final order might be:
E - A - G - D - B - F - C
But there is some flexibility because some dependencies could be swapped
according to the limited knowledge of each plugin and the final graph.
-bp
Al Sutton wrote:
With UnknownHandler each plugin can define an unknown handler which is
suitable for it and the code scans the list of plugins in reverse
order (i.e. last one first to ensure that plugins can be listed in
order of growing dependency needs) and uses the first one it finds.
As for the dependency graph construction, it's just a list. Basically
it goes something like this;
ListPlugin orderDependencies(Plugin[] plugins) {
ListPlugin orderedList = new ArrayListPlugin();
if( plugins.length 0 ) {
addPluginAndDependencies(orderedList, plugins[0]);
}
return orderedList;
}
void addPluginAndDependencies(ListPlugin orderedList, Plugin plugin) {
if( orderedList.contains(plugin) ) {
return;
}
for( Plugin thisPlugin : plugin.getDependencies() ) {
addPluginAndDependencies(orderedList, plugin);
}
orderedList.add(plugin);
}
Al.
Musachy Barroso wrote:
I think plugin dependencies are a no-go. We don't want to reinvent yet
another plugin mechanism with dependency resolution and all. If there
is something I like about S2 plugins it is how easy they are so
write/use, lets not complicate it much. I think the UnknowHandler
problem calls for an easy solution, and over-architecturing the whole
thing would be bad. BTW, specifying the order in which plugins will be
loaded wouldn't solved the UnknowHandler problem.
my 2 pesos :)
musachy
On Tue, Jun 3, 2008 at 11:37 AM, Brian Pontarelli
[EMAIL PROTECTED] wrote:
I thought about a dependency list of JCatapult workflows and it can
become
complex if a plugin doesn't know the entire set of other plugins
that might
need to be invoked before it. In some cases what would happen is
that 90% of
the plugins wouldn't list any dependencies but there might be some
type of
underlying order that the application needs.
I think it is better to just force the configuration on the users if
they
have conflicting plugins. But if you could hash out the algorithm
for the
dependency graph and ordering we could see if it would work.
-bp
Al Sutton wrote:
Why not expand it out and allow users to specify a plugin processing
order?, that way any potential conflict of plugin handling method
could be
resolved by specifying an order.
If we also introduced a dependency list in struts-plugin.xml the
core code
could not only take a stab at the right order if the user doesn't
specify
one, it could also verify that if a user specifies a plugin order
the order
given is valid and satisfies the dependencies.
I know plugins are ideally not suppose to know or rely on other
plugins,
but there are some situations (such as this one) where it's useful
to be
able to specify an order.
Al.
Musachy Barroso wrote:
I like Dusty's suggestion, or something like it:
unknown-handlers
unknown-handler name=UH1 /
unknown-handler name=UH2 /
/unknown-handlers
musachy
On Mon, Jun 2, 2008 at 2:36 PM, Brian Pontarelli
[EMAIL PROTECTED]
wrote:
Not yet. Just thinking about how I'm going to pull it off.
I'm using Guice for all the injection in JCatapult and we have
this same
situation in our Filter. There are a number of Workflow
implementations
that
need to be called in order such as: JPA (open-session-in-view),
static-resource, security, etc. Right now we are just managing
the order
in
code. However, as I've been building out the MVC for JCatapult,
I've run
into the situation that these workflows are pluggable and still
have a
specific order.
I've considered using a dependency graph to figure it out
dynamically or
some type of integer based indexing for each Workflow, but these all
seem
pretty lame.
-bp
Musachy Barroso wrote:
Do you have an implementation of this already?
musachy
On Mon, Jun 2, 2008 at 1:21 PM, Brian Pontarelli
[EMAIL PROTECTED]
wrote:
Musachy Barroso wrote:
For those of you ignoring the spam on the Convention vote
thread :).
I
mentioned that the framework should support more than one
UnknownHandler, which would eventually make Convention
Re: UknownHandlers
I thought about a dependency list of JCatapult workflows and it can become complex if a plugin doesn't know the entire set of other plugins that might need to be invoked before it. In some cases what would happen is that 90% of the plugins wouldn't list any dependencies but there might be some type of underlying order that the application needs. I think it is better to just force the configuration on the users if they have conflicting plugins. But if you could hash out the algorithm for the dependency graph and ordering we could see if it would work. -bp Al Sutton wrote: Why not expand it out and allow users to specify a plugin processing order?, that way any potential conflict of plugin handling method could be resolved by specifying an order. If we also introduced a dependency list in struts-plugin.xml the core code could not only take a stab at the right order if the user doesn't specify one, it could also verify that if a user specifies a plugin order the order given is valid and satisfies the dependencies. I know plugins are ideally not suppose to know or rely on other plugins, but there are some situations (such as this one) where it's useful to be able to specify an order. Al. Musachy Barroso wrote: I like Dusty's suggestion, or something like it: unknown-handlers unknown-handler name=UH1 / unknown-handler name=UH2 / /unknown-handlers musachy On Mon, Jun 2, 2008 at 2:36 PM, Brian Pontarelli [EMAIL PROTECTED] wrote: Not yet. Just thinking about how I'm going to pull it off. I'm using Guice for all the injection in JCatapult and we have this same situation in our Filter. There are a number of Workflow implementations that need to be called in order such as: JPA (open-session-in-view), static-resource, security, etc. Right now we are just managing the order in code. However, as I've been building out the MVC for JCatapult, I've run into the situation that these workflows are pluggable and still have a specific order. I've considered using a dependency graph to figure it out dynamically or some type of integer based indexing for each Workflow, but these all seem pretty lame. -bp Musachy Barroso wrote: Do you have an implementation of this already? musachy On Mon, Jun 2, 2008 at 1:21 PM, Brian Pontarelli [EMAIL PROTECTED] wrote: Musachy Barroso wrote: For those of you ignoring the spam on the Convention vote thread :). I mentioned that the framework should support more than one UnknownHandler, which would eventually make Convention and Codebehind compatible, as well as other plugins in the future. The bad side effect is that some configuration would be needed for the order of evaluation of the UnknownHandlers, as well as a default(first UH that can handle the request will be the one used). Comment away. musachy This is a large problem that I have been trying to solve for JCatapult. How do you allow plugins to be dropped in but somehow organize themselves correctly? The only solution I can think of is to have a configuration parameter that is a ordered list of named beans to use. If someone is going to be using both plugins, but will need to set this property by hand. If they only use one, then XWork can ignore the property because there aren't multiple UnknownHandlers in the container. If someone has other cool ideas that don't require configuration, let me know! -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: UknownHandlers
Musachy Barroso wrote: For those of you ignoring the spam on the Convention vote thread :). I mentioned that the framework should support more than one UnknownHandler, which would eventually make Convention and Codebehind compatible, as well as other plugins in the future. The bad side effect is that some configuration would be needed for the order of evaluation of the UnknownHandlers, as well as a default(first UH that can handle the request will be the one used). Comment away. musachy This is a large problem that I have been trying to solve for JCatapult. How do you allow plugins to be dropped in but somehow organize themselves correctly? The only solution I can think of is to have a configuration parameter that is a ordered list of named beans to use. If someone is going to be using both plugins, but will need to set this property by hand. If they only use one, then XWork can ignore the property because there aren't multiple UnknownHandlers in the container. If someone has other cool ideas that don't require configuration, let me know! -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: UknownHandlers
Not yet. Just thinking about how I'm going to pull it off. I'm using Guice for all the injection in JCatapult and we have this same situation in our Filter. There are a number of Workflow implementations that need to be called in order such as: JPA (open-session-in-view), static-resource, security, etc. Right now we are just managing the order in code. However, as I've been building out the MVC for JCatapult, I've run into the situation that these workflows are pluggable and still have a specific order. I've considered using a dependency graph to figure it out dynamically or some type of integer based indexing for each Workflow, but these all seem pretty lame. -bp Musachy Barroso wrote: Do you have an implementation of this already? musachy On Mon, Jun 2, 2008 at 1:21 PM, Brian Pontarelli [EMAIL PROTECTED] wrote: Musachy Barroso wrote: For those of you ignoring the spam on the Convention vote thread :). I mentioned that the framework should support more than one UnknownHandler, which would eventually make Convention and Codebehind compatible, as well as other plugins in the future. The bad side effect is that some configuration would be needed for the order of evaluation of the UnknownHandlers, as well as a default(first UH that can handle the request will be the one used). Comment away. musachy This is a large problem that I have been trying to solve for JCatapult. How do you allow plugins to be dropped in but somehow organize themselves correctly? The only solution I can think of is to have a configuration parameter that is a ordered list of named beans to use. If someone is going to be using both plugins, but will need to set this property by hand. If they only use one, then XWork can ignore the property because there aren't multiple UnknownHandlers in the container. If someone has other cool ideas that don't require configuration, let me know! -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: classpath scanner
Secondly, I was wondering about the advantages of having fewer dependencies, especially in this maven era. If something's really great, it's fine to depend on it, surely? And there is still a large number of folks using Ant, Ivy and Savant. -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: classpath scanner
Just a quick question. How did you modify ClasFinder to check for
implementation of the XWork Action interface? Doesn't this need to parse
up the inheritance chain as well as the implementation chain? It didn't
look like ClassFinder currently did that, unless I missed it.
-bp
Musachy Barroso wrote:
Thanks for the tips, I wasn't using UrlSet at yet, but that looks
great . I am using ASM 3 with it, I don't know about new features you
could take advantage of, but it is easy to get it running. I think
this method is wrong on ClassInfo:
public String getPackageName(){
return name.substring(name.lastIndexOf(.)+1, name.length());
}
musachy
On Wed, May 28, 2008 at 9:04 PM, David Blevins [EMAIL PROTECTED] wrote:
On May 28, 2008, at 4:54 PM, Musachy Barroso wrote:
It is a standalone library, used heavily by the OpenEJB and Geronimo
guys.
oops.
Personally, I favor copying the code over and jarjar'ing the asm
dependency.
+1
+1 :)
Just wanted to throw my support in for fun.
I'd pull in the ClassFinder and UrlSet. ClassFinder.java is a standalone
class (aside from ASM), but the UrlSet is really useful for narrowing down
the scope of jars that you search which of course makes things even faster.
If you know the exact jar(s) you want to search, you're set. But if you
simply have a classloader and want to search everything in it, you might
want to rip out some standard vm jars and other jars you know you do not
care about. Here's an example usage:
// Just this line right here is good as is will diff the classpath of the
// parent classloader against the classpath of the supplied classloader and
// give you the difference.
UrlSet urlSet = new UrlSet(classLoader);
// If you happen to need to search the system classloader, the difference
// still leaves a lot of useless garbage
urlSet = urlSet.exclude(ClassLoader.getSystemClassLoader().getParent());
urlSet = urlSet.excludeJavaExtDirs();
urlSet = urlSet.excludeJavaEndorsedDirs();
urlSet = urlSet.excludeJavaHome();
urlSet = urlSet.excludePaths(System.getProperty(sun.boot.class.path,
));
urlSet = urlSet.exclude(.*/JavaVM.framework/.*);
// If the remainder contains a lot of third party libraries required by you
// that you know don't contain annotations you're interested in, then it
can
// be good to aggressively cut those out.
urlSet = urlSet.exclude(.*/activemq-(core|ra)-[\\d.]+.jar(!/)?);
urlSet = urlSet.exclude(.*/catalina-[\\d.]+.jar(!/)?);
urlSet =
urlSet.exclude(.*/commons-(logging|cli|pool|lang|collections|dbcp)-[\\d.]+.jar(!/)?);
urlSet = urlSet.exclude(.*/derby-[\\d.]+.jar(!/)?);
urlSet =
urlSet.exclude(.*/geronimo-(connector|transaction)-[\\d.]+.jar(!/)?);
urlSet = urlSet.exclude(.*/geronimo-[^/]+_spec-[\\d.]+.jar(!/)?);
urlSet =
urlSet.exclude(.*/geronimo-javamail_([\\d.]+)_mail-[\\d.]+.jar(!/)?);
urlSet = urlSet.exclude(.*/hsqldb-[\\d.]+.jar(!/)?);
urlSet = urlSet.exclude(.*/idb-[\\d.]+.jar(!/)?);
urlSet = urlSet.exclude(.*/jaxb-(impl|api)-[\\d.]+.jar(!/)?);
urlSet = urlSet.exclude(.*/junit-[\\d.]+.jar(!/)?);
urlSet = urlSet.exclude(.*/log4j-[\\d.]+.jar(!/)?);
urlSet =
urlSet.exclude(.*/openjpa-(jdbc|kernel|lib|persistence|persistence-jdbc)(-5)?-[\\d.]+.jar(!/)?);
// then eventually
ListURL urls = urlSet.getUrls();
ClassFinder classFinder = new ClassFinder(classloader, urls);
As far as the stability of the API, it hasn't changed in months and months.
I do have one planned change involving the use of ASM 3 and new flag that
will speed up the scanning by allowing ASM to skip by large chunks of the
byte code.
Let me see if I can't get that in there real quick.
-David
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: classpath scanner
But does that include all of the interfaces including those implemented
by super-classes and those which interfaces the class directly
implements extend?
Musachy Barroso wrote:
ClassFinder.ClassInfo has a list of implemented interfaces, so I am
checking if com.opensymphony.xwork2.Action is one of them
musachy
On Thu, May 29, 2008 at 11:47 AM, Brian Pontarelli [EMAIL PROTECTED] wrote:
Just a quick question. How did you modify ClasFinder to check for
implementation of the XWork Action interface? Doesn't this need to parse up
the inheritance chain as well as the implementation chain? It didn't look
like ClassFinder currently did that, unless I missed it.
-bp
Musachy Barroso wrote:
Thanks for the tips, I wasn't using UrlSet at yet, but that looks
great . I am using ASM 3 with it, I don't know about new features you
could take advantage of, but it is easy to get it running. I think
this method is wrong on ClassInfo:
public String getPackageName(){
return name.substring(name.lastIndexOf(.)+1, name.length());
}
musachy
On Wed, May 28, 2008 at 9:04 PM, David Blevins [EMAIL PROTECTED]
wrote:
On May 28, 2008, at 4:54 PM, Musachy Barroso wrote:
It is a standalone library, used heavily by the OpenEJB and Geronimo
guys.
oops.
Personally, I favor copying the code over and jarjar'ing the asm
dependency.
+1
+1 :)
Just wanted to throw my support in for fun.
I'd pull in the ClassFinder and UrlSet. ClassFinder.java is a standalone
class (aside from ASM), but the UrlSet is really useful for narrowing
down
the scope of jars that you search which of course makes things even
faster.
If you know the exact jar(s) you want to search, you're set. But if you
simply have a classloader and want to search everything in it, you
might
want to rip out some standard vm jars and other jars you know you do not
care about. Here's an example usage:
// Just this line right here is good as is will diff the classpath of
the
// parent classloader against the classpath of the supplied classloader
and
// give you the difference.
UrlSet urlSet = new UrlSet(classLoader);
// If you happen to need to search the system classloader, the
difference
// still leaves a lot of useless garbage
urlSet = urlSet.exclude(ClassLoader.getSystemClassLoader().getParent());
urlSet = urlSet.excludeJavaExtDirs();
urlSet = urlSet.excludeJavaEndorsedDirs();
urlSet = urlSet.excludeJavaHome();
urlSet = urlSet.excludePaths(System.getProperty(sun.boot.class.path,
));
urlSet = urlSet.exclude(.*/JavaVM.framework/.*);
// If the remainder contains a lot of third party libraries required by
you
// that you know don't contain annotations you're interested in, then it
can
// be good to aggressively cut those out.
urlSet = urlSet.exclude(.*/activemq-(core|ra)-[\\d.]+.jar(!/)?);
urlSet = urlSet.exclude(.*/catalina-[\\d.]+.jar(!/)?);
urlSet =
urlSet.exclude(.*/commons-(logging|cli|pool|lang|collections|dbcp)-[\\d.]+.jar(!/)?);
urlSet = urlSet.exclude(.*/derby-[\\d.]+.jar(!/)?);
urlSet =
urlSet.exclude(.*/geronimo-(connector|transaction)-[\\d.]+.jar(!/)?);
urlSet = urlSet.exclude(.*/geronimo-[^/]+_spec-[\\d.]+.jar(!/)?);
urlSet =
urlSet.exclude(.*/geronimo-javamail_([\\d.]+)_mail-[\\d.]+.jar(!/)?);
urlSet = urlSet.exclude(.*/hsqldb-[\\d.]+.jar(!/)?);
urlSet = urlSet.exclude(.*/idb-[\\d.]+.jar(!/)?);
urlSet = urlSet.exclude(.*/jaxb-(impl|api)-[\\d.]+.jar(!/)?);
urlSet = urlSet.exclude(.*/junit-[\\d.]+.jar(!/)?);
urlSet = urlSet.exclude(.*/log4j-[\\d.]+.jar(!/)?);
urlSet =
urlSet.exclude(.*/openjpa-(jdbc|kernel|lib|persistence|persistence-jdbc)(-5)?-[\\d.]+.jar(!/)?);
// then eventually
ListURL urls = urlSet.getUrls();
ClassFinder classFinder = new ClassFinder(classloader, urls);
As far as the stability of the API, it hasn't changed in months and
months.
I do have one planned change involving the use of ASM 3 and new flag
that
will speed up the scanning by allowing ASM to skip by large chunks of the
byte code.
Let me see if I can't get that in there real quick.
-David
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: classpath scanner
it's all Apache license and only 3 classes so we could just pull it into XWork and manage it there. On Wed, May 28, 2008 at 3:24 PM, dusty [EMAIL PROTECTED] wrote: If you already have it working, then great! I don't know anything about it, so my question is only how likely are the authors to update/nurse this library? -D Musachy Barroso wrote: Stating new thread for this topic. Don suggested to use this classpath scanner: http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/ in xwork and plugins. It uses ASM to extract class information and annotations,so loading classes can be avoided until the last minute (when you actually need it). I modified convention to use it(not committed), and it is pretty good. Comment away here. musachy -- Hey you! Would you help me to carry the stone? Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/classpath-scanner-tp17519827p17522489.html Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Bring Convention plugin into trunk and deprecate Zero Config
The plugin will scan the entire classpath, but that's not to large of an issue and pretty fast (considering). The issue is when it starts loading classes into the perm space to determine if the class is in fact an Action or not. This is the part where your perm space can become full and then you start getting strange errors. The best way to fix this and still employ scanning (which I much prefer) is to set the struts.convention.package.locators constant to the name of packages you want your actions to reside in. This is only a single package and not the fully qualified package name. For example, I put all my actions in packages named *actions* or sub-packages like this: com.example.actions.MyCoolAction In this case, I just set the struts.convention.package.locators value to *actions* only. This will help increase speed and decrease strange errors. However, this isn't always enoug. Next, you need to correctly set the struts.convention.exclude.packages constant to the list of packages that you wish to exclude from processing. In my case, there are 3rd party libraries with packages that contain *actions* and I just list those out like this: org.springframework.*,org.jcatapult.* This tells the plugin to ignore any packages that start with the given Strings (minus the * character). Hope that helps. -bp dusty wrote: Musachy, First off, Hi.. My name is Dusty Pearce and I am long time webwork user. How do I pronounce your name? In my head its something like Moose-atch-ee With that out of the way, I feel like I am missing something simple, but if you have spring-jdbc in your pom.xml (dependency of spring security) the convention plugin throws NoClassDefError about not finding com/ibm/wsspi/uow/UOWAction which is an inner class of [org.springframework.transaction.jta.WebSphereUowTransactionManager. So its scanning all packages for the Action keyword. I tried to set struts.convention.action.packages and that did not fix it. I was not sure what other options to try (struts.convention.action.disableGlobalScanning?). I also thought that when I have the REST plugin with the convention plugin exclusion, that it would look for Controller rather than Action. Can you try and add spring-jdbc (2.0.8 and 2.5.4 did the same thing) to your pom.xml and see if you get the same result. I feel like I should be able to just figure out the right configurationbut any help would be appreciated. Musachy Barroso wrote: Convention does needs the views to be in the same directory structure as the namespace of the action. Yes, all the convention code is committed, a change to struts-plugin.xml in REST would be needed: Index: C:/src/struts2/plugins/rest/src/main/resources/struts-plugin.xml === --- C:/src/struts2/plugins/rest/src/main/resources/struts-plugin.xml (revision 652924) +++ C:/src/struts2/plugins/rest/src/main/resources/struts-plugin.xml (working copy) @@ -24,7 +24,7 @@ !DOCTYPE struts PUBLIC -//Apache Software Foundation//DTD Struts Configuration 2.0//EN http://struts.apache.org/dtds/struts-2.0.dtd; - + struts bean type=com.opensymphony.xwork2.ActionProxyFactory name=rest class=org.apache.struts2.rest.RestActionProxyFactory / @@ -29,8 +29,6 @@ bean type=com.opensymphony.xwork2.ActionProxyFactory name=rest class=org.apache.struts2.rest.RestActionProxyFactory / bean type=org.apache.struts2.dispatcher.mapper.ActionMapper name=rest class=org.apache.struts2.rest.RestActionMapper / - - bean type=com.opensymphony.xwork2.config.PackageProvider name=rest class=org.apache.struts2.rest.ControllerClasspathPackageProvider / bean class=org.apache.struts2.rest.ContentTypeHandlerManager / @@ -43,13 +41,16 @@ constant name=struts.mapper.class value=rest / constant name=struts.mapper.idParameterName value=id / constant name=struts.action.extension value=xhtml,,xml,json / - +constant name=struts.convention.action.suffix value=Controller / +constant name=struts.convention.action.mapAllMatches value=true/ +constant name=struts.convention.action.checkImplementsAction value=false/ + !-- Disable the scanning by the codebehind plugin to prevent duplicates -- constant name=struts.configuration.classpath.disableActionScanning value=true / - + constant name=struts.configuration.rest.disableControllerScanning value=false / constant name=struts.configuration.classpath.defaultParentPackage value=rest-default / - + package name=rest-default extends=struts-default result-types result-type name=redirect class=org.apache.struts2.dispatcher.ServletRedirectResult @@ -108,7 +109,7 @@ input,back,cancel,browse,index,show,edit,editNew /interceptor-ref /interceptor-stack - + /interceptors default-interceptor-ref name=restDefaultStack/ musachy On Thu, May
Re: [VOTE] Bring Convention plugin into trunk and deprecate Zero Config
BTW, I'd like to thank Musachy for taking charge of this. Having started my own company in Feb. I have barely had time for anything open source. Hopefully this can make it over and users can jump on board with it. It really makes Struts2 development so much simpler and JCatapult is essentially only supporting Struts2 with this plugin. -bp Musachy Barroso wrote: That's what the vote is for :) (of course there is the issue of REST which I am looking into) musachy On Thu, May 15, 2008 at 11:01 AM, Al Sutton [EMAIL PROTECTED] wrote: From a 10,000 ft view it looks like Convention would be the successor to Zero-Config and Code-behind based on functionality. Possibly a deprecate in 2.1.3+ and 2.2, with a view to drop in 2.3/3.0? - Original Message - From: Musachy Barroso [EMAIL PROTECTED] To: Struts Developers List dev@struts.apache.org Sent: Thursday, May 15, 2008 2:21 PM Subject: Re: [VOTE] Bring Convention plugin into trunk and deprecate Zero Config I don't think there is any page that compares them, quick overview: Code-behind: Provides default mappings for pages without actions, default results (finds templates based on action name and result) Zero-Conf: Provides annotations: @Result, @Namespace and @ParentPackage to create action mappings Convention: Provides default mapping for actions and results. Annotations: @Action (results, interceptorRefs...), @Result, @InterceptorRefs, @Namespace,@ParentPackage, @ResultPath, it also created default package actions based on convention (Index) musachy //maybe some stuff missing on them... On Thu, May 15, 2008 at 1:07 AM, Al Sutton [EMAIL PROTECTED] wrote: Has anyone made a web page comparing the plugins?, if it took a while to get to grips with it's probably worth offering users a page with something like a checkbox grid feature comparison. It could also help some of us understand what each one does ;). Al. - Original Message - From: Bob Tiernay [EMAIL PROTECTED] To: Struts Developers List dev@struts.apache.org Sent: Wednesday, May 14, 2008 8:43 PM Subject: RE: [VOTE] Bring Convention plugin into trunk and deprecate Zero Config +1 I think that this plugin is of great worth to every day development. I would like to echo some other people's sentiments that a unified plugin would be a significant value add to new struts developers. I know that there is much overlap and confusion between: 1. Zero-config 2. Code behind 3. Smart urls 4. REST 5. Convention It took me a while to mentally model the differences / similarities between them all , and surely I can't be the only one :) I understand that ideally plugins should have high cohesion and low coupling... but having so many options does more harm than good in this case. IMO this is an example of plugin fragmentation that should be resolved with a unified, best-of-breed approach, leaving the other plugins as they are for those concerned about deprecation. Bob Date: Tue, 13 May 2008 23:39:39 -0400 From: [EMAIL PROTECTED] To: dev@struts.apache.org Subject: [VOTE] Bring Convention plugin into trunk and deprecate Zero Config With the addition of @IntereceptorRefs to the Convention plugin, it is now possible to do most of the action mapping using annotations. Also having 2 plugins to do the same thing is really confusing for users, so we should deprecate Zero Config (good thing is that it was always experimental). If you have had a chance to look at the Convention plugin, please vote: [+1] Move the Convention plugin to trunk and deprecate Zero Configuration plugin [-1] Leave it in sandbox. (reasons?) regards musachy -- Hey you! Would you help me to carry the stone? Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Hey you! Would you help me to carry the stone? Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Bring Convention plugin into trunk and deprecate Zero Config
+1 Here are the goals of this plugin. Any movement to integrate plugins and make all things compatible (which I gracefully disagree with) MUST satisfy these goals: - Simple API that is fixed and will not change anytime soon - Usable with absolutely no configuration or annotations - Minimize the ways to solve a single problem - Support actions and results inside classpath - Provide excellent SEO -bp Musachy Barroso wrote: With the addition of @IntereceptorRefs to the Convention plugin, it is now possible to do most of the action mapping using annotations. Also having 2 plugins to do the same thing is really confusing for users, so we should deprecate Zero Config (good thing is that it was always experimental). If you have had a chance to look at the Convention plugin, please vote: [+1] Move the Convention plugin to trunk and deprecate Zero Configuration plugin [-1] Leave it in sandbox. (reasons?) regards musachy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Convention Plugin Status
Agreed. Musachy Barroso wrote: Another thing is that the convention plugin is using java.util.logging.*. I think we should stick to what we have in core and everywhere else. musachy On Mon, May 12, 2008 at 6:26 PM, Musachy Barroso [EMAIL PROTECTED] wrote: Ok, I will let Brian clean that up then. musachy On Mon, May 12, 2008 at 6:15 PM, Don Brown [EMAIL PROTECTED] wrote: You can remove the author tags, but only the author can remove copyright headers, unfortunately. BTW, how did code get checked into our SVN with copyright headers? Don On Tue, May 13, 2008 at 6:42 AM, Musachy Barroso [EMAIL PROTECTED] wrote: FYI the convention plugin still has copyright headers in some files and @Author tags, I will remove them. musachy On Mon, May 12, 2008 at 3:05 PM, Musachy Barroso [EMAIL PROTECTED] wrote: I will be looking at the Convention plugin for the next few days. What is broken/missing that is blocking its merge into trunk? I am going thru the documentation trying the examples myself, and everything seems to be working so far. musachy On Sun, May 11, 2008 at 11:07 PM, Musachy Barroso [EMAIL PROTECTED] wrote: I think doing an mvn -pAll once fixes the parent pom problem. musachy On Sun, May 11, 2008 at 7:27 PM, Bob Tiernay [EMAIL PROTECTED] wrote: Hi Brian, Seeing as how I am new to both maven and svn, I'm probably not the best person for the job. I'm actually trying to build the project now from svn and I' m running into issues with the missing parent pom. Any help getting this into the next release would be greatly appreciated :) Also, does this plugin effectively make codebehind and smarturls obsolete? Thanks again. -- From: Brian Pontarelli [EMAIL PROTECTED] Sent: Wednesday, April 23, 2008 10:20 AM To: Struts Developers List dev@struts.apache.org Subject: Re: Convention Plugin Status Bob Tiernay wrote: Anyone know what the status of the Convention plugin is? Is there anyways we can get it out of the sandbox and into a formal release? I'm willing to help out :) The plugin is stable and running in production. It can probably be moved out of the sandbox whenever we want. At this point, I'm completely fine with pulling it out of the sandbox. I've been using it for a number of months and it is fine. Anyone else adverse to moving it out? Bob, if you have sometime, the move should be as simple as an svn mv and maybe a little build tweaking. The other thing that needs to be done is to figure out the documentation home and move the docs from the plugin wiki to that location. That is if we want to move them. -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Hey you! Would you help me to carry the stone? Pink Floyd -- Hey you! Would you help me to carry the stone? Pink Floyd -- Hey you! Would you help me to carry the stone? Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Hey you! Would you help me to carry the stone? Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Convention Plugin Status
It was a port of SmartURLs and I didn't get everything totally cleaned up before getting so busy I could barely check my email ;). I'll remove them. -bp Don Brown wrote: You can remove the author tags, but only the author can remove copyright headers, unfortunately. BTW, how did code get checked into our SVN with copyright headers? Don On Tue, May 13, 2008 at 6:42 AM, Musachy Barroso [EMAIL PROTECTED] wrote: FYI the convention plugin still has copyright headers in some files and @Author tags, I will remove them. musachy On Mon, May 12, 2008 at 3:05 PM, Musachy Barroso [EMAIL PROTECTED] wrote: I will be looking at the Convention plugin for the next few days. What is broken/missing that is blocking its merge into trunk? I am going thru the documentation trying the examples myself, and everything seems to be working so far. musachy On Sun, May 11, 2008 at 11:07 PM, Musachy Barroso [EMAIL PROTECTED] wrote: I think doing an mvn -pAll once fixes the parent pom problem. musachy On Sun, May 11, 2008 at 7:27 PM, Bob Tiernay [EMAIL PROTECTED] wrote: Hi Brian, Seeing as how I am new to both maven and svn, I'm probably not the best person for the job. I'm actually trying to build the project now from svn and I' m running into issues with the missing parent pom. Any help getting this into the next release would be greatly appreciated :) Also, does this plugin effectively make codebehind and smarturls obsolete? Thanks again. -- From: Brian Pontarelli [EMAIL PROTECTED] Sent: Wednesday, April 23, 2008 10:20 AM To: Struts Developers List dev@struts.apache.org Subject: Re: Convention Plugin Status Bob Tiernay wrote: Anyone know what the status of the Convention plugin is? Is there anyways we can get it out of the sandbox and into a formal release? I'm willing to help out :) The plugin is stable and running in production. It can probably be moved out of the sandbox whenever we want. At this point, I'm completely fine with pulling it out of the sandbox. I've been using it for a number of months and it is fine. Anyone else adverse to moving it out? Bob, if you have sometime, the move should be as simple as an svn mv and maybe a little build tweaking. The other thing that needs to be done is to figure out the documentation home and move the docs from the plugin wiki to that location. That is if we want to move them. -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Hey you! Would you help me to carry the stone? Pink Floyd -- Hey you! Would you help me to carry the stone? Pink Floyd -- Hey you! Would you help me to carry the stone? Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Convention Plugin Status
I committed all of the copyright changes and author tags changes. It seems that all of the copyrights were correct, however, the IntelliJ copyright plugin decided to add in the old copyright in addition to the new ASF copyright. So, everything was still all ASL v2, but some files had dual assignee's. All is well now. -bp Musachy Barroso wrote: Done On Tue, May 13, 2008 at 10:58 AM, Brian Pontarelli [EMAIL PROTECTED] wrote: Agreed. Musachy Barroso wrote: Another thing is that the convention plugin is using java.util.logging.*. I think we should stick to what we have in core and everywhere else. musachy On Mon, May 12, 2008 at 6:26 PM, Musachy Barroso [EMAIL PROTECTED] wrote: Ok, I will let Brian clean that up then. musachy On Mon, May 12, 2008 at 6:15 PM, Don Brown [EMAIL PROTECTED] wrote: You can remove the author tags, but only the author can remove copyright headers, unfortunately. BTW, how did code get checked into our SVN with copyright headers? Don On Tue, May 13, 2008 at 6:42 AM, Musachy Barroso [EMAIL PROTECTED] wrote: FYI the convention plugin still has copyright headers in some files and @Author tags, I will remove them. musachy On Mon, May 12, 2008 at 3:05 PM, Musachy Barroso [EMAIL PROTECTED] wrote: I will be looking at the Convention plugin for the next few days. What is broken/missing that is blocking its merge into trunk? I am going thru the documentation trying the examples myself, and everything seems to be working so far. musachy On Sun, May 11, 2008 at 11:07 PM, Musachy Barroso [EMAIL PROTECTED] wrote: I think doing an mvn -pAll once fixes the parent pom problem. musachy On Sun, May 11, 2008 at 7:27 PM, Bob Tiernay [EMAIL PROTECTED] wrote: Hi Brian, Seeing as how I am new to both maven and svn, I'm probably not the best person for the job. I'm actually trying to build the project now from svn and I' m running into issues with the missing parent pom. Any help getting this into the next release would be greatly appreciated :) Also, does this plugin effectively make codebehind and smarturls obsolete? Thanks again. -- From: Brian Pontarelli [EMAIL PROTECTED] Sent: Wednesday, April 23, 2008 10:20 AM To: Struts Developers List dev@struts.apache.org Subject: Re: Convention Plugin Status Bob Tiernay wrote: Anyone know what the status of the Convention plugin is? Is there anyways we can get it out of the sandbox and into a formal release? I'm willing to help out :) The plugin is stable and running in production. It can probably be moved out of the sandbox whenever we want. At this point, I'm completely fine with pulling it out of the sandbox. I've been using it for a number of months and it is fine. Anyone else adverse to moving it out? Bob, if you have sometime, the move should be as simple as an svn mv and maybe a little build tweaking. The other thing that needs to be done is to figure out the documentation home and move the docs from the plugin wiki to that location. That is if we want to move them. -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Hey you! Would you help me to carry the stone? Pink Floyd -- Hey you! Would you help me to carry the stone? Pink Floyd -- Hey you! Would you help me to carry the stone? Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Hey you! Would you help me
Re: FilterDispatcher and static resources
Musachy Barroso wrote: I think FilterDispatcher should be changed to allow other implementations to lookup static resources and be more flexible in general. As it stands right now, static resources cannot be served from plugins unless you put them in org.apache.struts2.static in a jar loaded by the filter's class loader (this is a problem for bundles loaded with the OSGi plugin) thoughts? Yeah, JCatapult actually has its own static resource handler because of this. Should be made pluggable and generic. -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] A thought - next generation OSGi-based?
Jeromy Evans wrote: Putting aside the technology for a moment: - ability to deploy new actions/replace actions and pages without a container restart: highly desirable Only at development stage right? There are tools that use JDPA and other methods to do this with Struts and other frameworks. However, Groovy is probably the best way to go moving forward for this type of handling if you want more language features. OSGi will help with this as well since it can reload bundles. Just have to ensure that whatever you are using works in conjunction with all the other frameworks you've got in the application, like Spring/Guice. Some tools will do this without changes to Struts while others (OSGi from what I know about it) will require changes to Struts or implementation of APIs like ObjectFactory. - ability to deploy new/replace business-layer services without a container restart: highly desirable Same tools as above will help in this department, including OSGi. The trick again is injection and other frameworks. Spring and Guice have good adoption in most tools and will work well. - ability to evolve Struts2 without fear of breaking an API; highly desirable Developers need to do this. The API needs to be frozen and then the implementation can change without fear of breaking applications and plugins. To date this has not occurred and from my perspective nothing but good programming will solve this one. -bp If, through appropriate packaging, OSGi facilities those requirements that them I'm all for it. At this point I don't have a good appreciation of what *actually exists* in this area. I'd take care to ensure Struts2 continues to target entry-level containers though (ie. Tomcat rather than Glassfish). Don Brown wrote: As I learn more and more about OSGi, I wonder if it might be the solution to several big problems we seem to have at the moment: poor reloadability and the lack of a solid API. With OSGi, you can drop bundles in and out of the system at runtime, even running multiple versions of the same bundle side-by-side, but the feature I'm most interested in right now is how it would allow us to put in a proper API while maintaining full backwards-compatibility. Evolving a web framework is hard because apps tend to be written on a specific version, and to migrate them to new versions has two problems: development may not be continuously funded and the upgrade may require too many changes to the application. On the other hand, if you don't evolve your web framework, you quickly go out-of-date and lose interest from new developers. In our case, despite being a relatively new framework, we have legacy code around from 2004 that we can't just remove, yet we want to provide an attractive, modern, clean framework for new development. The specific issue it hand that I've been thinking about is how to get a proper API into Struts 2 yet keep backwards compatibility, and I think OSGi might provide a solution. What about this: 1. Struts 2 and its plugins remain the way they are now - 100% backwards-compatibility 2. An OSGi plugin provides the platform for the next generation of Struts 2 3. A new API bundle is created, implemented by the underlying Struts 2 framework 4. Old apps can continue to write and deploy code against Struts 2, yet new development can start to use the new API 5. Later, when we want to write API version 2, we create a new bundle that runs side-by-side the old bundle, both implemented by Struts 2 Basically, OSGi would allow us to write a clean layer on top of a framework, much like how Grails builds on Spring, but we get, as a side benefit, all the architectural advantages of OSGi for free. Furthermore, if we do it right, users don't have to know or care that OSGi is under the hood - all they know is they write a jar, drop it in a directory or upload it via a form and they just installed part of their application at runtime. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] A thought - next generation OSGi-based?
Don Brown wrote: I'll respond in more detail later, but I wanted to correct a quick misconception. OSGi allows you to deploy multiple versions of the same API via different bundles. No special package namespace, no hassles from the standpoint of the user - just declare what version you need and it all just works. Here is how it could look: Struts 2 - OSGi plugin (with container) - API impl bundles - API bundles Therefore, multiple API versions and multiple implementations could be running at the same time, with OSGi hooking them together as appropriate. This is only possible with OSGi. I think either I'm mis-understanding the point of this thread or you are mis-understanding what I feel the issue is. In either case, there is a disconnect. I'll jump off the thread because my main concern is still API compatibility and breaking compatibility at the API level can't be solved by a tool. This problem is a compile time problem that needs to be handled by developers. OSGi is a runtime dynamic loader, not a compile time dynamic method binder or a runtime dynamic method invocation layer. -bp Don On Sat, Apr 26, 2008 at 3:45 AM, Brian Pontarelli [EMAIL PROTECTED] wrote: Ian Roughley wrote: Maybe I'm overstepping my knowledge from fact, but I thought the benefit of OSGi was that you could have completely different implementations (i.e. PackageConfig) running on the same JVM, with OSGi providing the classloading magic so that the implementations don't collide. It actually is a compile time issue first and then later is a method invocation issue and has nothing to do with OSGi. Think of it this way, you have an interface: org.apache.struts.api.SomeInterface It has two versions 1.0 and 2.0. They are very different and look like: 1.0 -- public void method1(); public String method2(); public Object method3(String); public Object method4(String, int); 2.0 -- public void method1(); public int method2(); public Object method4(int, String); public Object method5(long); As you can see, method1 is the same, but the rest of it is changed drastically. The issue is now that the interface is still in the same package and has the same name. How do you compile against both versions? Furthermore, how would OSGi be able to resolve the method invocations at runtime to the two different versions? Very difficult problems that I've done some work on. There isn't any good solution. The only way to make it work is to follow the Java Virtual Machine specifications for compatibility or implement dynamic method translation at runtime. I've done that for fun to see if it works and it does, but requires translators for each interface and then you have loads of more code to manage and TONS of edge cases. But, it was a cool weekend project I whipped up to see if it was possible using CGLIB and some other tools. My question with Don's proposal is with item #4. Is it new features of the same webapp that use new APIs or new webapps that use the new APIs? Option one is going to be hard, and may not be possible even with OSGi. For option 2, I'm wondering if OSGi is overkill (i.e. would webapps be separated enough via the container). A better question might be is it the webapps that need to change the APIs they are using, or is it the plugins? Yeah, my thoughts were along the same lines. Not sure OSGi really helps that much. Here's the main case I want to cover and OSGi doesn't really provide a solution: You are writing something that uses Struts2 (plugin, extension, fork, webapp, whatever) and want to upgrade from 2.0 to 2.1. Since traditionally these are minor versions, the changes should be minor, meaning they should be compatible. Therefore, you should be able to just drop the JAR in the classpath and everything should work. This is the ultimate definition of compatibility and something I feel Struts needs to start ensuring. -bp /Ian Brian Pontarelli wrote: Yours and mine are the same because you still have implementations inside Struts for some of the API interfaces. For example, org.apache.struts2.config.PackageProvider (yeah, I did move this from XWork to Struts for my example ;), will be an API interface that applications can implement. Struts2 also implements this API. Another case is a non-interface POJO like PackageConfig. This class can be instantiated by app1 and then passed back to struts. Likewise, app4 might instantiate a different version and pass it back. You have to separate these into namespaces in order to compile Struts if the versions of PackageConfig are fundamentally different. If we take the concrete example of 2.0.* and 2.1 for PackageConfig, one is mutable, the other is immutable with the Builder pattern. However, they have the same package and classname. The issue is that at compile time Struts needs to import and use
Re: [s2] A thought - next generation OSGi-based?
Here's a few things I think about when considering API versioning: 1. How many implementors are there? It sounds like there will be one - Struts2 2. Do you want to allow implementors to implement multiple APIs? Sounds like yes. 3. How much is shared between APIs? Probably a lot. From what it sounds like, and correct me if I'm wrong, you are looking to do something like this: API 1.0--\ |--- Struts2 API 2.0--/ If this is the case, it will require some interesting coding tactics. Sun and IBM have some white papers on these types of cases. OSGi will shield the two APIs from each other so there aren't any conflicts, however, the implementor will have the unfortunate task of implementing both. This becomes difficult without proper structure at compile time because struts2 will need to implement multiple interfaces from both versions and these interfaces might overlap. I've done some of this type of work before and in order to truly break compatibility between 1.0 and 2.0, you need namespaces in order to allow Struts2 to implement both. Otherwise you get naming conflicts that cannot be resolved by the compiler. I've do things like this before: org.apache.struts.api1.SomeInterface org.apache.struts.api2.SomeInterface This is the same interface, but breaks compatibility between the API versions. Only by separating the namespaces will you be able to implement both at compile time. I've also worked with other situations like this: org.apache.struts.api.SomeInterface_1_0 org.apache.struts.api.SomeInterface_2_0 What it comes down to is that if you are going to break compatibility at the API level you need to actually create a brand new API. When you look at it from this perspective, OSGi really isn't needed, just nice to have. Since the two API versions are in different namespaces, there aren't any collisions at compile-time or runtime, eliminating the need for bundle separation. Having done some of these types of solutions before, I can attest to the pain that they can cause. They can also become complex to manage. Which sorta leads back to my original statements about compatibility. I'd much rather see something like this: 1. The APIs locked down 2. These APIs called Struts3 3. No APIs break compatibility until Struts4 Therefore, 3.0, 3.1, 3.2, etc are all compatible. Then when Struts4 start wanting to break compatibility, you branch Struts3, and start breaking away on Trunk. -bp Don Brown wrote: As I learn more and more about OSGi, I wonder if it might be the solution to several big problems we seem to have at the moment: poor reloadability and the lack of a solid API. With OSGi, you can drop bundles in and out of the system at runtime, even running multiple versions of the same bundle side-by-side, but the feature I'm most interested in right now is how it would allow us to put in a proper API while maintaining full backwards-compatibility. Evolving a web framework is hard because apps tend to be written on a specific version, and to migrate them to new versions has two problems: development may not be continuously funded and the upgrade may require too many changes to the application. On the other hand, if you don't evolve your web framework, you quickly go out-of-date and lose interest from new developers. In our case, despite being a relatively new framework, we have legacy code around from 2004 that we can't just remove, yet we want to provide an attractive, modern, clean framework for new development. The specific issue it hand that I've been thinking about is how to get a proper API into Struts 2 yet keep backwards compatibility, and I think OSGi might provide a solution. What about this: 1. Struts 2 and its plugins remain the way they are now - 100% backwards-compatibility 2. An OSGi plugin provides the platform for the next generation of Struts 2 3. A new API bundle is created, implemented by the underlying Struts 2 framework 4. Old apps can continue to write and deploy code against Struts 2, yet new development can start to use the new API 5. Later, when we want to write API version 2, we create a new bundle that runs side-by-side the old bundle, both implemented by Struts 2 Basically, OSGi would allow us to write a clean layer on top of a framework, much like how Grails builds on Spring, but we get, as a side benefit, all the architectural advantages of OSGi for free. Furthermore, if we do it right, users don't have to know or care that OSGi is under the hood - all they know is they write a jar, drop it in a directory or upload it via a form and they just installed part of their application at runtime. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
Re: [s2] A thought - next generation OSGi-based?
Yours and mine are the same because you still have implementations
inside Struts for some of the API interfaces. For example,
org.apache.struts2.config.PackageProvider (yeah, I did move this from
XWork to Struts for my example ;), will be an API interface that
applications can implement. Struts2 also implements this API.
Another case is a non-interface POJO like PackageConfig. This class can
be instantiated by app1 and then passed back to struts. Likewise, app4
might instantiate a different version and pass it back. You have to
separate these into namespaces in order to compile Struts if the
versions of PackageConfig are fundamentally different.
If we take the concrete example of 2.0.* and 2.1 for PackageConfig, one
is mutable, the other is immutable with the Builder pattern. However,
they have the same package and classname. The issue is that at compile
time Struts needs to import and use PackageConfig. The only way I know
how to pull this off is extract a common interface (Java interface that
is - public interface IPackageConfig) and make adapters OR to separate
them into namespaces.
org.apache.struts.config.PackageConfig_2_0
org.apache.struts.config.PackageConfig_2_1
Then you can see the ensuing code inside Struts to deal with these:
org.apache.struts.config.ConfigurationManager_2_0
org.apache.struts.config.ConfigurationManager_2_1
And then you need some method of determining the version of the API that
the application is using and then select a configuration manager based
on that.
Now, there might be some type of tricks and things that OSGi can provide
to make this happen, but I'm not familiar enough with advanced bundling
and classloading to know how it would work. From what I understand of
OSGi, any bundle can only use a version of a dependent bundle that is
compatible with the version of that dependent bundle it compiled against.
For example, if I compiled against log4j 1.0, I can use 1.3 because they
are compatible at runtime and compile time. However, I can't use log4j
2.0 because the interfaces changed and things will blow up nicely at
runtime. What OSGi does provide is the ability to have one bundle using
log4j 1.x and another bundle using log4j 2.x in the same VM. I'm not
aware that they have gone any further than that.
Ian Roughley wrote:
Is this the case, or was the thinking more like:
- app 1
- api 1.0 --{
/ - app 2
Struts ---{
\ - app 4
- api 2.0 --{
- app 3
I think this is how I perceived it. I also agree with Brian that
there will be a burden on s2 to provide the necessary features for all
APIs, but I think it's less of a burden in this layout.
/Ian
Brian Pontarelli wrote:
Here's a few things I think about when considering API versioning:
1. How many implementors are there? It sounds like there will be one
- Struts2
2. Do you want to allow implementors to implement multiple APIs?
Sounds like yes.
3. How much is shared between APIs? Probably a lot.
From what it sounds like, and correct me if I'm wrong, you are
looking to do something like this:
API 1.0--\
|--- Struts2
API 2.0--/
If this is the case, it will require some interesting coding tactics.
Sun and IBM have some white papers on these types of cases. OSGi will
shield the two APIs from each other so there aren't any conflicts,
however, the implementor will have the unfortunate task of
implementing both. This becomes difficult without proper structure at
compile time because struts2 will need to implement multiple
interfaces from both versions and these interfaces might overlap.
I've done some of this type of work before and in order to truly
break compatibility between 1.0 and 2.0, you need namespaces in order
to allow Struts2 to implement both. Otherwise you get naming
conflicts that cannot be resolved by the compiler. I've do things
like this before:
org.apache.struts.api1.SomeInterface
org.apache.struts.api2.SomeInterface
This is the same interface, but breaks compatibility between the API
versions. Only by separating the namespaces will you be able to
implement both at compile time. I've also worked with other
situations like this:
org.apache.struts.api.SomeInterface_1_0
org.apache.struts.api.SomeInterface_2_0
What it comes down to is that if you are going to break compatibility
at the API level you need to actually create a brand new API. When
you look at it from this perspective, OSGi really isn't needed, just
nice to have. Since the two API versions are in different namespaces,
there aren't any collisions at compile-time or runtime, eliminating
the need for bundle separation.
Having done some of these types of solutions before, I can attest to
the pain that they can cause. They can also become complex to manage
Re: [s2] A thought - next generation OSGi-based?
Ian Roughley wrote: Maybe I'm overstepping my knowledge from fact, but I thought the benefit of OSGi was that you could have completely different implementations (i.e. PackageConfig) running on the same JVM, with OSGi providing the classloading magic so that the implementations don't collide. It actually is a compile time issue first and then later is a method invocation issue and has nothing to do with OSGi. Think of it this way, you have an interface: org.apache.struts.api.SomeInterface It has two versions 1.0 and 2.0. They are very different and look like: 1.0 -- public void method1(); public String method2(); public Object method3(String); public Object method4(String, int); 2.0 -- public void method1(); public int method2(); public Object method4(int, String); public Object method5(long); As you can see, method1 is the same, but the rest of it is changed drastically. The issue is now that the interface is still in the same package and has the same name. How do you compile against both versions? Furthermore, how would OSGi be able to resolve the method invocations at runtime to the two different versions? Very difficult problems that I've done some work on. There isn't any good solution. The only way to make it work is to follow the Java Virtual Machine specifications for compatibility or implement dynamic method translation at runtime. I've done that for fun to see if it works and it does, but requires translators for each interface and then you have loads of more code to manage and TONS of edge cases. But, it was a cool weekend project I whipped up to see if it was possible using CGLIB and some other tools. My question with Don's proposal is with item #4. Is it new features of the same webapp that use new APIs or new webapps that use the new APIs? Option one is going to be hard, and may not be possible even with OSGi. For option 2, I'm wondering if OSGi is overkill (i.e. would webapps be separated enough via the container). A better question might be is it the webapps that need to change the APIs they are using, or is it the plugins? Yeah, my thoughts were along the same lines. Not sure OSGi really helps that much. Here's the main case I want to cover and OSGi doesn't really provide a solution: You are writing something that uses Struts2 (plugin, extension, fork, webapp, whatever) and want to upgrade from 2.0 to 2.1. Since traditionally these are minor versions, the changes should be minor, meaning they should be compatible. Therefore, you should be able to just drop the JAR in the classpath and everything should work. This is the ultimate definition of compatibility and something I feel Struts needs to start ensuring. -bp /Ian Brian Pontarelli wrote: Yours and mine are the same because you still have implementations inside Struts for some of the API interfaces. For example, org.apache.struts2.config.PackageProvider (yeah, I did move this from XWork to Struts for my example ;), will be an API interface that applications can implement. Struts2 also implements this API. Another case is a non-interface POJO like PackageConfig. This class can be instantiated by app1 and then passed back to struts. Likewise, app4 might instantiate a different version and pass it back. You have to separate these into namespaces in order to compile Struts if the versions of PackageConfig are fundamentally different. If we take the concrete example of 2.0.* and 2.1 for PackageConfig, one is mutable, the other is immutable with the Builder pattern. However, they have the same package and classname. The issue is that at compile time Struts needs to import and use PackageConfig. The only way I know how to pull this off is extract a common interface (Java interface that is - public interface IPackageConfig) and make adapters OR to separate them into namespaces. org.apache.struts.config.PackageConfig_2_0 org.apache.struts.config.PackageConfig_2_1 Then you can see the ensuing code inside Struts to deal with these: org.apache.struts.config.ConfigurationManager_2_0 org.apache.struts.config.ConfigurationManager_2_1 And then you need some method of determining the version of the API that the application is using and then select a configuration manager based on that. Now, there might be some type of tricks and things that OSGi can provide to make this happen, but I'm not familiar enough with advanced bundling and classloading to know how it would work. From what I understand of OSGi, any bundle can only use a version of a dependent bundle that is compatible with the version of that dependent bundle it compiled against. For example, if I compiled against log4j 1.0, I can use 1.3 because they are compatible at runtime and compile time. However, I can't use log4j 2.0 because the interfaces changed and things will blow up nicely at runtime. What OSGi does provide is the ability to have one
Re: Convention Plugin Status
Bob Tiernay wrote: Anyone know what the status of the Convention plugin is? Is there anyways we can get it out of the sandbox and into a formal release? I'm willing to help out :) The plugin is stable and running in production. It can probably be moved out of the sandbox whenever we want. At this point, I'm completely fine with pulling it out of the sandbox. I've been using it for a number of months and it is fine. Anyone else adverse to moving it out? Bob, if you have sometime, the move should be as simple as an svn mv and maybe a little build tweaking. The other thing that needs to be done is to figure out the documentation home and move the docs from the plugin wiki to that location. That is if we want to move them. -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: xwork and DI
You can definitely inject from any of the XWork files,
struts-default.properties, struts.properties, struts.xml,
struts-default.xml, struts-plugin.xml. These are all configured in the
Dispatcher when the Container is created (I think).
-bp
Musachy Barroso wrote:
I tried that, I think the problem is where to define the constant. I
used default.properties, where the others are defined, but the
container complains that it cannot satisfy the dependency. Of all
examples I found on xwork, only one references the bean to be injected
by name (which might not be working either).
musachy
On Mon, Apr 21, 2008 at 10:57 PM, Jeromy Evans
[EMAIL PROTECTED] wrote:
Musachy Barroso wrote:
If I want to add a constant that can be injected in one of xwork
classes (like devMode for example), what do I need to do? Just
adding @Inject and defining the constant in default.properties in core
doesn't work. I don't know much about this whole guice black magic
thing :)
musachy
Here's some simple examples:
Setup some beans and constants in the Container with unique names:
http://code.google.com/p/struts2urlplugin/source/browse/trunk/struts2-url-plugin/src/main/resources/struts-plugin.xml
eg. 1. Inject constant into a bean
http://code.google.com/p/struts2urlplugin/source/browse/trunk/struts2-url-plugin/src/main/java/com/blueskyminds/struts2/urlplugin/URLPatternActionMapper.java
Line 333
@Inject(struts.urlplugin.actionMapConfiguration)
public void setMappingConfigurationName(String mappingConfigurationName)
{
this.mappingConfigurationName = mappingConfigurationName;
}
eg. 2. Inject Container into a bean to enable run-time lookup by name and
class:
@Inject
public void setContainer(Container container) {
this.container = container;
}
Line 116
mappingConfiguration = container.getInstance(ActionMapConfiguration.class,
mappingConfigurationName);
eg. 3. Inject Bean into another bean directly: exactly as per the container
injection. If there's only one instance it will bind, otherwise specify the
name, otherwise it will fail.
@Inject(defaultActionMapper)
public void setActionMapper(ActionMapper actionMapper) {...
It only gets complicated when you need to mix injection with beans created
outside the container, as described by Wes.
cheers,
Jeromy Evans
PS. this is far inferior to the current functionality of Guice.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.1 build
Yeah, I was hoping to have time to get the convention plugin into the main repository, but I just haven't had anytime at all. It will have to wait until 2.2 unless someone else wants to move it over. At this point I can't even recall the outstanding issues and design changes that were being discussed before. Anyone else remember those? -bp Musachy Barroso wrote: It would be easier to ask if anyone is working on something that needs to be included (SmartUrls?). regards musachy On Thu, Apr 3, 2008 at 8:20 AM, Ted Husted [EMAIL PROTECTED] wrote: I'm still heads-down, but I could run a build through the gauntlet. Can anyone confirm that everything else we want to do is done, and we're at the tag and roll point? -Ted. On Tue, Apr 1, 2008 at 7:21 AM, Rainer Hermanns [EMAIL PROTECTED] wrote: Ted, others, xwork 2.1.1 is out and should be in the repos shortly. So we should be ready for a Struts 2.1.1 release build now. thanks for waiting, Rainer On Apr 1, 2008, at 12:24 AM, Ted Husted wrote: And, if we're ready to roll a Struts after that, I'd be happy to step through the process Wednesday night. -Ted. On Mon, Mar 31, 2008 at 4:05 PM, Rainer Hermanns [EMAIL PROTECTED] wrote: Sorry, but I have to delay the xwork release until tomorrow. cheers, Rainer Hey there, I am working on the open issues for xwork 2.1.1 over the weekend, so that the release could be out on monday. Since lots of fixes and changes were done affecting S2.1 core features, testing S2.1 with latest xwork snapshots would help to get both codebases stablelized. Please report xwork errors to XWork Jira [1]. Ted, if you have some time next week for getting out the release, that would be awesome. cheers, Rainer [1] http://jira.opensymphony.com I will help testing it (I don't have any application on production tho). Ted if you could do it, it would be great, I think it is about time we get a build out there. regards musachy On Fri, Mar 28, 2008 at 6:38 AM, Ted Husted [EMAIL PROTECTED] wrote: Is there much to do beside tag it, build it, and sign it? I could help with that much, so long as other people are testing it. -Ted. On Fri, Mar 28, 2008 at 5:35 AM, Pedro Herrera [EMAIL PROTECTED] wrote: good question . . . Musachy Barroso wrote: Hi all, Any news on the 2.1 build? Is anyone looking into it? regards musachy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Hey you! Would you help me to carry the stone? Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Rainer Hermanns aixcept Mariahilfstrasse 9 52062 Aachen - Germany w: http://aixcept.de/ t: +49-241-4012247 m: +49-170-3432912 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Rainer Hermanns aixcept Mariahilfstrasse 9 52062 Aachen - Germany w: http://aixcept.de/ t: +49-241-4012247 m: +49-170-3432912 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted http://husted.com/ted/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted http://husted.com/ted/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Freekmarker vs. Velocity
Haroon Rafique wrote: On Yesterday at 11:37am, BP=Brian Pontarelli [EMAIL PROTECTED] wrote: BP BP BTW, some of the JetBrains folks said that FreeMarker support will be BP in 8 and should be available in EAP soon! This will definitely help BP move me farther away from JSPs. :) BP BP -bp This is a topic near and dear to my heart. I was on the watch list for IDEADEV-24154 (jira item for adding freemarker support in IDEA [1]) and the jira got the status of resolved on March 21st. The fix version says Diana Next EAP. Any one have access to that? I'm still on version 6. [1] http://www.jetbrains.net/jira/browse/IDEADEV-24154 All EAPs are available from JetBrains.net. You just have to hunt around to find them. They are full working versions that expire after 30 days. Usually they expire before or during the next EAP release so you can just keep using the latest EAP until 8.0 is released. Then you'll have to fork over the cash or get an open source license. -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Freekmarker vs. Velocity
BTW, some of the JetBrains folks said that FreeMarker support will be in 8 and should be available in EAP soon! This will definitely help move me farther away from JSPs. :) -bp Jeromy Evans wrote: Jonathan Revusky wrote: Thanks for the detailed argument Jonathon. Jeromy Evans wrote: Niall Pemberton wrote: I just saw the following comment FreeMarker is very similar to Velocity, as both are template languages that can be used outside of a Servlet container. The framework utilizes FreeMarker because FreeMarker has better error reporting. However, both are good alternatives to JSP. I've questioned that a few times myself. The paragraph doesn't do FreeMarker much justice from a technical sense, but then again, most Struts 2 users won't exploit the features FreeMarker offers above Velocity, What is your basis for thinking this? It's clear enough from the freemarker-user list that people do use advanced features of the tool that are not in Velocity. I just don't see offhand why the usage patterns of people using FreeMarker in conjunction with Struts 2 would be particularly different from users in general. Though, the other thing is that, even if the assertion were true, I don't know how you would know it was... it seems like a seat of the pants conjecture... The basis of my conjecture is that Struts 2 provides little support for FreeMarker's more advanced features, so most users won't exploit those features. The model provided to FreeMarker is a map containing the request, response, ValueStack and a few other basic structures, where access to the ValueStack (Struts2's core model) is limited to Struts2 tags to in order to access OGNL. I don't know the history, but it appears the FreeMarkerResult[1] was designed to be equivalent to the Velocity implementation rather than to exploit FreeMarker features. Similarly, although the Struts 2 tags use FreeMarker templates, the model is limited and the templates don't encourage what I think you'd consider to be best-practice. My conjecture still stands, that as built, most Struts 2 users won't exploit FreeMaker's better features. That's not meant as a criticism of FreeMarker. Take a quick look at the source: [1] http://svn.apache.org/viewvc/struts/struts2/trunk/core/src/main/java/org/apache/struts2/views/freemarker/ [2] http://svn.apache.org/viewvc/struts/struts2/trunk/core/src/main/resources/template/css_xhtml/ FreeMarker is technically superior in (almost?) every way, but not always appropriate. I have heard this before, but I cannot conceive of a usage scenario in which Velocity would be indicated over FreeMarker. In terms of JSP, that has the obvious advantages associated with being a standard, greater tool support, more people out there who already know it. That said, there are plenty of people who prefer FreeMarker. The reasons vary, but I think they just find that it's a a lot cleaner... conceptually, I guess. As for things like JRuby or Groovy results, I think that is something so different that a direct comparison with FreeMarker or Velocity doesn't make much sense. I agree with most of your statements but there are many cases where technically superiority does not mean it is the most appropriate solution. Perhaps you have the good fortune of only working with experienced java developers and don't have to trade-off development costs, but the learning curve, familiarly with the syntax and tools support are issues that do exist and are impediments to the take-up and cost-of-development with FreeMarker. We should link to/provide something that helps users decide what best suits their circumstances, Anything you link to would be just somebody else's opinion. There is no reason that you could not offer your own opinion. I'd infer that you don't want to point out there that a fellow ASF project is abjectly inferior, so, okay, you provide a link where some 3rd party says it, but you know ;-) I'm not sure if biases exist like that; the PMC would have to comment. I've never noticed anything like that, especially with Struts2's heavy dependency an opensymphony projects and the project's core dependency on FreeMarker. I'm expressing a personal opinion, which was that FreeMarker is technically superior but not always appropriate. I personally would rarely choose Velocity, but I also can't recommend FreeMarker with a broad-stroke. including the argument for and against JSP. I don't think there will ever consensus to recommend one. I think that in terms of FreeMarker vs. Velocity, there is a pretty strong consensus among technically informed people in favor of FreeMarker. As for JSP or other things, like XSLT maybe, or Groovy or JRuby, they aren't directly comparable in the same way that FreeMarker and Velocity are. They're comparable within the context of Struts 2 at alternative approaches to implement the action or result. My point was to
Re: If I had 1000 hours to give...
- Overhaul message passing so that action errors and action messages could be persisted through redirects with no user configuration or validation issues. Scopes plugin works pretty well from what I've heard. - Overhaul zero configuration to allow results to be defined at method level Convention plugin does this (if I understand correctly). -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: If I had 1000 hours to give...
Here's my list: - Collapse XWork into Struts - Rewrite XWork to be a servlet workflow engine and less abstract (i.e. remove thread locals and contexts) - Fix nasty circular XWork injections and setter injections - Generics - Update all public APIs no matter how infrequently used and then hard API freeze until 4.0 (assuming all this work would be 3.0) - Rewrite tags with better support for writing new/custom tags inside apps and other frameworks - Rewrite XWork container with Guice 2.0 (once released) - Drop OGNL in favor of a UEL that supports type conversion (nothing does this really well quite yet) - Make actions easier to write (no getters/setters, support Groovy, support reloading) - Make form prepare better and reusable across actions and results - Support real code-behind that reuses actions to display and submit a form and distinguishes between GET and POST with no coding - Rewrite all docs top down to cover all configuration, usages, etc. including javadocs and online docs How much is 1000 hours anyways? I think this is like a years worth of work or something. ;) -bp Jeromy Evans wrote: It's been quiet lately so I thought I'd throw something out there. If you could give 1000 hours to the Struts 2 project, what would you do? I would like to it become the SOA framework of choice through : - SEO-friendly URLs become the default and users never have to think about it again; - allow action methods to be bound to an http method and allow results to be easily bound to the result code and requested content type (as per REST plugin) - support content in the request (eg text/xml or text/json content-type), deserialize and set the model of the action (the reverse of the REST plugin) - allow actions to be pojos and delete ActionSupport (without losing implicit i18n and validation functionality) - allow hot deployment run-time management of actions (OSGi??) - refactor UIBean XWork component so there's only one model and one template per tag and they're easy to unit test (code-generate the wrappers/template models/taglibs) - action scope and component scope become first-class concepts (integrate the plugins) - add run-time developer tools; configuration browser becomes standard in developer mode and add a resource bundle browser - delete all ajax-like tags and funky tags; add standard interceptors models to ease integration with the client-side libraries, groovy, grails, JSF, struts1 (and others?). tags move to plugin. - I don't have an opinion about portal support but I'm sure it's important I think I ran out of hours already! cheers, Jeromy Evans - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Help with UIBeanTest
Can someone that has a lot of experience with ValueStack evaluation help me get a test working? The test in question is currently commented out at the bottom of the UIBeanTest. The purpose is to verify that if the 'key' attribute contains any single quotes they are correctly escaped prior to OGNL evaluation. My thought was to set the TestCase as the root of the ValueStack and add a String getText(String) method to it so that OGNL would invoke that method to render the label. However, it isn't working and I'm not sure why. Thanks, -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issue WW-2107 question - Is JSTL disable or not?
There are two discussions going on here that could probably be split: 1. OGNL vs. JUEL 2. Taglibs #1 has already come up a number of times and I believe that there is enough support to move the JUEL plugin forward and start removing OGNL once a roadmap is clear. The wiki page Dale pointed to is the best place to add your thoughts to the roadmap. #2 This has also come up before, but just so folks know... there is very little stopping anyone from implementing their own taglib. JCatapult is going to do this and I would think it would make sense to have a few others out there. Remember that the taglib is a distinct component and not necessary to use the core. It has very few side-effects and is mostly pulling data and generating HTML. Rarely does it effect application state. In fact, some have argued the current tags in core should be a plugin. Perhaps two new threads should continue this discussion. -bp Felipe Rodrigues wrote: But we have that situation in most pages that we develop. Since the Struts tags are not all encompassing, we must supplement our framework with other tags, like DisplayTag and other standard JSP tags. So, allowing the full use of JUEL (or JSTL EL) in the Struts tags, actually reduces confusion since it allows us to use one EL for an entire page. Yes, but OGNL is a base for Struts2 stack. And EL is only removed because of the security problem. I'm not saying that use of EL is bad. We can't stop the confusion without either expanding the Struts taglib so that you would never need an outside tag or convert all the other tag libraries to OGNL. I don't see either of these as being possible. It is a good point. But again, the position of Struts leaders is to show that Struts2 is secure. Show that you should not use EL in Struts2 without concerns, because Struts2 tags evaluates everything as OGNL after the EL evaluation. So, I still believe this thread should be talking about an alternate build of Struts2, or at least an open documentation about how to enable EL to be used and telling the risks to be taken for that. Chris Pratt wrote: On Thu, Mar 6, 2008 at 7:51 AM, Felipe Rodrigues [EMAIL PROTECTED] wrote: Your suggestion for question 1 is good, since we have more description on struts documentation. The 2 point is the most important, from my view. Use JSP EL in Struts2 tag is not a best pratice. Match these kind of languages could make the code confuse to be maintained. Sometimes you use OGNL, othertimes you use JSTL EL. But we have that situation in most pages that we develop. Since the Struts tags are not all encompassing, we must supplement our framework with other tags, like DisplayTag and other standard JSP tags. So, allowing the full use of JUEL (or JSTL EL) in the Struts tags, actually reduces confusion since it allows us to use one EL for an entire page. We can make this stop now, buy forcing people to use OGNL or leave it possible to use and keep trying to make them understand that it is a bad pratice. We can't stop the confusion without either expanding the Struts taglib so that you would never need an outside tag or convert all the other tag libraries to OGNL. I don't see either of these as being possible. I think lot of people can say that match it is not a bad pratice, but... well, somebody have to decide it. You can call it bad practice if you want, but I prefer JSTL EL to OGNL since it is ubiquitous, powerful, consistent and much easier to train Web Developers to use. But then again, that's just one man's opinion. (*Chris*) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Code does not use generics too much
Correct me if I'm wrong but I believe that restricts the map to only accepting values that are exactly Object. It will not allow things that extend Object, only Object themselves. You could use: MapString,? extends Object Which is just a long-hand way of saying: MayString,? You can't put things into Maps that have wildcards. The compiler complains because Object really isn't '?'. Although most language pragmatist would tell you it is. But the language zealots say otherwise, and those are the folks who wrote generics. :) If you use Object, you can put anything into the Map because the compiler will insert a cast to (Object), which with autoboxing allows everything in the Java language to be used. The key to remembering generics for me is that up-casting is cool, down-casting isn't and wildcards are read-only. -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Code does not use generics too much
David Durham, Jr. wrote: On Thu, Mar 6, 2008 at 2:42 PM, Brian Pontarelli [EMAIL PROTECTED] wrote: You can't put things into Maps that have wildcards. The compiler complains because Object really isn't '?'. Although most language pragmatist would tell you it is. But the language zealots say otherwise, and those are the folks who wrote generics. :) The general rule is that you don't use wildcard if you need to 'get' and 'put'. You use extends when you only 'get' and super when you only 'put'. Yeah, I didn't want to toss in super because it can really rattle people's brains if they don't know what it means. :) -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-dev] Issue WW-2107 question - Is JSTL disable or not?
Dale Newfield wrote:
Chris Pratt wrote:
The proposed flow (with rtexprvaluefalse/rtexprvalue):
The bit you're missing is that if you have a tag attribute with
rtexprvalue set to false that contains what the container thinks is an
EL expression (i.e., ${foo}), the jsp compilation will fail, so it
will never execute and pass the string ${foo} on to your tag. As
previous posters suggested, I believe the only way to prevent this is
to tell the container to never evaluate these el expressions, which
has the previously mentioned down-sides.
Or to use the JSP delayed evaluation syntax of #{} which is part of UEL
and JSP 2.1 (or 2.2 or whichever spec we are currently on).
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Struts 2.1.1 delayed
Wendy Smoak wrote: On Sun, Feb 24, 2008 at 1:04 AM, Don Brown [EMAIL PROTECTED] wrote: Unfortunately, my computer is experiencing severe stability problems, so the Struts 2.1.1 build will be delayed. I'm hoping to give it a shot next weekend. Of course, anyone is free to give it a go in the meantime... What is the status of the Struts Annotations and XWork releases that go along with this one? I have what I consider a blocker open against XWork that I've been compiling and managing locally for the JCatapult releases. I think it is a required fix prior to 2.1.1. Here's the link: http://jira.opensymphony.com/browse/XW-599 -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API Compatibility
Before you start such a discussion, I would suggest that you take the time to look back, in the archives, through the several years worth of discussions in that got us to the point we're at today, so that you _fully_ understand the context and the reasoning behind the scheme that we have now. I really, really don't want to rehash those discussions, because they are always very prolonged, they consume vast amounts of time, energy and enthusiasm, and they seriously eat into the real development effort because of that. I'd much prefer to see the team's effort go into making Struts the best that it can be rather than go off down that rat hole. The one tip I will give you before you head to the archives is that our process is basically the same as the ones used by HTTPD and Tomcat, two of the most long-standing projects in all of the ASF, so it's not something we made up off the top of our heads. It's been proven in the real world for more than a decade. All of that said, once you fully understand all of the history, and if you still feel you have a really compelling reason for the project to switch to another scheme, you are of course absolutely free to propose it. But do spend the time first, so that you realise what you are letting yourself - and the rest of us - in for, and expect to significantly slow down progress on the code until that discussion comes to closure. I will have to drop off this discussion for the next few days to finish up a project I'm working on, but before that I would like to respond to folks so that I can still be active in the thread I started. Martin, I've actually be involved in these discussion before and read up on a number of them. I will certainly read the entire set when time allows. However, regardless of that reading the scheme is still broken and needs to be fixed. This is important to me because I am a maintainer of a dependency management tool and where we are today is extremely difficult to manage in these tools. Furthermore, just because other projects do something doesn't make it correct. HTTD is a full application not a library. Tomcat is also a full application and not a library. Struts is a library and that means people have compile and runtime dependencies on it in a much different manner. In addition, I don't think I've ever seen Tomcat break API across a minor release. This again comes back to developers understanding compatibility. -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API Compatibility
Al Sutton wrote: Just so we're all on the same page, can I put forward the following as a version numbering plan which would seem to reflect most peoples views; 2.0.x - New releases shouldn't alter the public API unless absolutley neccessary (e.g. something is a security risk). 2.1.x (pre-first GA) - Changes to the public API allowed, all pre-first GA releases are evolving and are released to allow users to get a feel for the direction 2.1 is going in and comment on it in the users list. 2.1.x (post-first GA) - New releases should not alter the public API unless absolutley neccessary (e.g. something is a security risk). 2.2 - Needed if there are post-first GA 2.1.x changes which will break parts of the public API and the changes are only functional enhancements. 3.x - Only needed if there are changes to large parts of the public API which would break almost every S2.x app out there (in the same way the 1.x to 2.x did). Does this sound OK? This scheme doesn't work because you can't tell a tool generically how things are compatible. The scheme needs a method for doing release while still breaking compatibility. This is where traditionally libraries tend towards alpha, beta, milestone and release candidate numbering. Savant uses this model: 1.0-Ax 1.0-Bx 1.0-Mx 1.0-RCx 1.0 1.0.x 1.x In order to support the current model you would need to tell tools like Savant and Ivy that 2.1.0 is not compatible with 2.1.1 but 2.1.1 is compatible with 2.1.2. In essence you would need a file that lists the compatibility that those tools could use when verifying the project. -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API Compatibility
Antonio Petrelli wrote: Wow what a long thread and all in the night :-) (well, at least for Europe). Sincerely I don't see the problem of changing the name of Struts 2.1.x to Struts 3.0.x. It's just a version name change. IMHO if you change the API (read: public, protected and package-friendly members) instead of deprecating them, we *cannot* release a 2.1.x version. If we developers are too lazy to deprecate members, well, we either choose to re-create deprecated members, or we should roll a 3.0 version In fact, if we roll out a 3.0 version, Struts users will be sure that these changes are incompatible. Same here. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API Compatibility
Al Sutton wrote: Antonio, I see where you're coming from, but I really don't think the leap from S2.0 to the current S2.1 is anywhere near the leap from S1 to S2, hence why I'm in favour of the 2.1 because I feel it reflects that although there are some changes, many of the core concepts are the same and, in many cases, changes will be limited to small sections of the app (such as config files an updates to specific API usage), as opposed to major changes to tag names, functionality, and design concepts. I think these are good points. The key isn't to never break things, but to structure it well. That is why I'd like to break everything, clean it all up and then move forward from something like 3.0 as the API freeze for all release up to 4.0. That's really what I'm after. Then I can tell the tools to check compatibility at the major number. -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API Compatibility
Piero Sartini wrote: Am Freitag, 22. Februar 2008 00:05:53 schrieb Don Brown: Yes, you are missing my original point #2 - We need to be able to do alpha releases to get new, experimental features into the community for testing. I need a way to create an alpha release for 2.1 to hand off to our community for feedback, but if all releases require a unique patch version, I'm forced to create 2.1.1, 2.1.2, 2.1.3, etc. Public API changes take a while and lots of feedback to really get right, so going six months without a release is not acceptable, IMO. If these changes need feedback .. why not put them in alpha releases? 2.2 Alpha1, 2.2 Alpha2, etc For me, s.th. like this would be great: A.B.C.D D - Error fixing, security patches, etc C - new features, smaller api changes even incompatible ones B - big changes, large refactorings, new approaches, etc. A - Struts version This would be sub-patch compatibility, which is fine and most tools currently or could easily support this. That would mean that 2.1.1.0 and 2.1.1.1 would be compatible, but 2.1.0 and 2.1.1 are not. Therefore, if your project depended on 2.1.1.0 and transitively depended on 2.1.0.0, the build would break, as it should. -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API Compatibility
This one looks good a good resource. Sun also has one here: http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html Section 13.4 of the java language specification covers compatibility stuff. Sun also has some good information about versioning of JAR files and distributed objects, which apply equally as well. -bp Paul Benedict wrote: I think it will benefit everyone to read this three part piece on evolving APIs: http://wiki.eclipse.org/index.php/Evolving_Java-based_APIs Paul On Thu, Feb 21, 2008 at 10:37 PM, Martin Cooper [EMAIL PROTECTED] wrote: On Thu, Feb 21, 2008 at 7:03 PM, Brian Pontarelli [EMAIL PROTECTED] wrote: Don Brown wrote: Yes, you are missing my original point #2 - We need to be able to do alpha releases to get new, experimental features into the community for testing. I need a way to create an alpha release for 2.1 to hand off to our community for feedback, but if all releases require a unique patch version, I'm forced to create 2.1.1, 2.1.2, 2.1.3, etc. Public API changes take a while and lots of feedback to really get right, so going six months without a release is not acceptable, IMO. I think we will have to disagree on this point. From my perspective these things are mutually exclusive. You can make experimental new features and changes without breaking compatibility. It still comes down to being pragmatic about your changes and ensuring things don't break severely. However, I want to make it clear that I'm NOT advocating never breaking compatibility. I just want a versioning scheme that ensures tools can figure it out. As a separate question, why can't the scheme be changed for Struts 2 specifically? I get a sense that everyone is saying, don't even think about changing it because it will never happen. If something isn't working and there are better ways to handle things, isn't it our jobs as engineers to fix them? Before you start such a discussion, I would suggest that you take the time to look back, in the archives, through the several years worth of discussions in that got us to the point we're at today, so that you _fully_ understand the context and the reasoning behind the scheme that we have now. I really, really don't want to rehash those discussions, because they are always very prolonged, they consume vast amounts of time, energy and enthusiasm, and they seriously eat into the real development effort because of that. I'd much prefer to see the team's effort go into making Struts the best that it can be rather than go off down that rat hole. The one tip I will give you before you head to the archives is that our process is basically the same as the ones used by HTTPD and Tomcat, two of the most long-standing projects in all of the ASF, so it's not something we made up off the top of our heads. It's been proven in the real world for more than a decade. All of that said, once you fully understand all of the history, and if you still feel you have a really compelling reason for the project to switch to another scheme, you are of course absolutely free to propose it. But do spend the time first, so that you realise what you are letting yourself - and the rest of us - in for, and expect to significantly slow down progress on the code until that discussion comes to closure. -- Martin Cooper -bp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
