Re: [VOTE][FASTTRACK] Struts 2.3.16.3
+1 On Fri, May 2, 2014 at 1:58 PM, Dave Newton davelnew...@gmail.com wrote: +1 On May 2, 2014 3:52 PM, Lukasz Lenart lukaszlen...@apache.org wrote: The Struts 2.3.16.3 test build is now available. It includes the latest security patch which fixes one possible vulnerabilities: - Extends excluded params in CookieInterceptor to avoid manipulation of Struts' internals For details and the rationale behind these changes, please consult the corresponding security bulletins: * https://cwiki.apache.org/confluence/display/WW/S2-022 Release notes: * [https://cwiki.apache.org/confluence/display/WW/Version+Notes+2.3.16.3 ] Distribution: * [http://people.apache.org/builds/struts/2.3.16.3/] Maven 2 staging repository: * [ https://repository.apache.org/content/repositories/orgapachestruts-1003/ ] Once you have had a chance to review the test build, please respond with a vote on its quality: [ ] Leave at test build [ ] Alpha [ ] Beta [ ] General Availability (GA) Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and more +1s than -1s. This is a fast-track release vote. If we have a positive vote after 24 hours (at least three binding +1s and more +1s than -1s), the release may be submitted for mirroring and announced to the usual channels. The website download link will include the mirroring timestamp parameter [1], which limits the selection of mirrors to those that have been refreshed since the indicated time and date. (After 24 hours, we *must* remove the timestamp parameter from the website link, to avoid unnecessary server load.) In the case of a fast-track release, the email announcement will not link directly to download.cgi, but to downloads.html, so that we can control use of the timestamp parameter. [1] http://apache.org/dev/mirrors.html#use - The Apache Struts group. Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Fisheye
I could help find the right person. What do you need? Don On Tue, Feb 11, 2014 at 6:22 AM, Lukasz Lenart lukaszlen...@apache.orgwrote: I'm looking for some Atlassianer here to help me with reconfiguring https://fisheye6.atlassian.com/browse/struts2, any? Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Re: why Struts2 Dispatcher instance bind to ThreadLocal
Two servlet filters - one to do 95% of the work, the second to cleanup any thread locals. Don On Thu, Apr 25, 2013 at 1:06 AM, Lukasz Lenart lukaszlen...@apache.orgwrote: Thanks MrDon :-) What you mean by two filters? Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ 2013/4/24 Don Brown donald.br...@gmail.com: This all goes way back to the days of WebWork and how much they loved statics. WebWork basically used static singletons for everything, causing a) a really complicated startup order and b) the ability to only run one instance of the framework. In those days (and perhaps still?) there wasn't just one filter but at least two to allow proper thread-local cleanup, because what wasn't accessed statically was accessed statically using thread locals as the means (ActionContext.getContext() for example). Therefore, with two filters that contain state that needs to be accessed statically, we were limited to threadlocals to track that state. When I was working on it, I got it to the point that most statics were gone and we had a decent injection system to avoid all the static accessors, but they were still there in case you needed them. I don't know what the code is like now, but it sounds like perhaps it still hasn't completely gotten away from statics and threadlocals. As a side note, back then (2008?) we did some profiling and found that actually all the thread locals were eating up a bunch of time in the request, so it is more than just a general icky sense that should drive their removal. Again, my knowledge is pretty dated, but that's where things came from. Don On Tue, Apr 23, 2013 at 7:40 PM, ppm10103 ppm10...@163.com wrote: At 2013-04-24 03:44:22,Lukasz Lenart lukaszlen...@apache.org wrote: 2013/4/23 ppm10103 ppm10...@163.com: The Dispatcher will have only one instance, it bind to ThreadLocal is for what? For thread safety, then you can access Dispatcher from a thread without synchronisation. That's my opinion :-) Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org Thanks for your help,but I look into the sourcecode ,the Dispatcher will only be one instance, so even put it in the ThreadLocal,every thead alse access the same Dispatcher instance, so I think it's not for thread safe,so I still want to konw it's for what?
Re: Re: why Struts2 Dispatcher instance bind to ThreadLocal
This all goes way back to the days of WebWork and how much they loved statics. WebWork basically used static singletons for everything, causing a) a really complicated startup order and b) the ability to only run one instance of the framework. In those days (and perhaps still?) there wasn't just one filter but at least two to allow proper thread-local cleanup, because what wasn't accessed statically was accessed statically using thread locals as the means (ActionContext.getContext() for example). Therefore, with two filters that contain state that needs to be accessed statically, we were limited to threadlocals to track that state. When I was working on it, I got it to the point that most statics were gone and we had a decent injection system to avoid all the static accessors, but they were still there in case you needed them. I don't know what the code is like now, but it sounds like perhaps it still hasn't completely gotten away from statics and threadlocals. As a side note, back then (2008?) we did some profiling and found that actually all the thread locals were eating up a bunch of time in the request, so it is more than just a general icky sense that should drive their removal. Again, my knowledge is pretty dated, but that's where things came from. Don On Tue, Apr 23, 2013 at 7:40 PM, ppm10103 ppm10...@163.com wrote: At 2013-04-24 03:44:22,Lukasz Lenart lukaszlen...@apache.org wrote: 2013/4/23 ppm10103 ppm10...@163.com: The Dispatcher will have only one instance, it bind to ThreadLocal is for what? For thread safety, then you can access Dispatcher from a thread without synchronisation. That's my opinion :-) Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org Thanks for your help,but I look into the sourcecode ,the Dispatcher will only be one instance, so even put it in the ThreadLocal,every thead alse access the same Dispatcher instance, so I think it's not for thread safe,so I still want to konw it's for what?
Re: Plan for Struts 3
All support for Struts 1 meant, afaik, is the ability to deploy side-by-side. We used a different Java package to allow the code to co-exist, however, the proposal as I understand it is to go back to org.apache.struts Don On Tue, Mar 5, 2013 at 1:29 PM, Brian Holzer bhol...@sgi.sk.ca wrote: Hi all, If you drop support for S1, what about those people still using S1? I'm guessing there are a lot of them out there. Brian Lukasz Lenart lukaszlen...@apache.org 3/5/2013 2:22 PM Hi, I have few additional thoughts about S3 and the future. First with should drop support of S1 and use simple Struts as a project name - no more Struts2, Struts3, Struts4, ... Simple Struts and version 3.0.1, 4.1.0.1, etc. We should just keep support for one version back, so when we release 3.x, we should support just the latest version of 2.x branch (and drop support for S1) - critical issues and security vulnerabilities. Versioning: x.y.z.s x - major API changes, breaks backward compatibility y - minor API changes, can break backward compatibility (minor, one method replaced other, should be simple to adopt) z - maintenance, no API changes, no backward compatibility breaks s - security release With these two in mind we can more flexible handle changes and adopt new requirements. Also website can be keep much clearer, just /current and /previous ;-) Regards -- *ukasz + 48 606 323 122 http://www.lenart.org.pl/ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee, please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that using, disclosing, copying or distributing the contents of this information is strictly prohibited. - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: [VOTE] Struts Master 7 Vote
+1 GA On Mon, May 31, 2010 at 11:23 PM, Lukasz Lenart lukasz.len...@googlemail.com wrote: The Struts Master 7 test build is now available as a Maven artifact. https://repository.apache.org/content/repositories/orgapachestruts-018/ Release notes: * The main change is to allow to use the Nexus to make a Maven release of Struts project If you have had a chance to review the test build, please respond with a vote on its quality: [ ] Leave at test build [ ] Alpha [ ] Beta [ ] General Availability (GA) Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and more +1s than -1s. The vote will remain open for at least 72 hours, longer upon request. Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Kapituła Javarsovia 2010 http://javarsovia.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
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, 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
Re: struts 2.2 and guice
On Wed, Dec 9, 2009 at 11:34 AM, Paul Benedict pbened...@apache.org wrote: Lastly, because Bob Lee is a Struts committer, you should get pretty good support from him on. Don't count on it. Bob has moved on from Struts 2, so I would count on anything beyond moral support. :) Don Paul On Tue, Dec 8, 2009 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: struts 2.2 and guice
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
Re: struts 2.2 and guice
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 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 | | _ | | | | Struts App 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
Re: struts 2.2 and guice
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 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
Someone turn that hudson build off!
Surely the build isn't meant to spam my inbox so? Don - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Someone turn that hudson build off!
Also, could you ensure only one email gets sent for the whole project? The is how Bamboo is currently configured, though it was blocked by the same infra issue, iirc. I remember continuum used to be used for numerous Apache projects, and it used to drive me nuts how some random maven failure caused like 30 messages. Don On Sat, Oct 10, 2009 at 12:11 AM, Wes Wannemacher w...@wantii.com wrote: There is good news and bad news... The good news is that infra fixed up the comm...@struts.a.o spamassassin settings to accept email from *.apache.org, which had been blocking posts from hudson in the past. The bad news is that apparently, it sends one email for each artifact, which as we witnessed, is a little much. So, I changed the email notification to just send to me. Hudson had been broken for a little while and was recently fixed, so the emails should only come when the build breaks (or when it succeeds after a broken build, as in this case). Anyhow, sorry about that folks! -Wes On Fri, Oct 9, 2009 at 5:19 AM, Don Brown mr...@twdata.org wrote: Surely the build isn't meant to spam my inbox so? Don - 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
Seeking reflections on our tag library (as a framework)
At Atlassian, every application seems to have picked a different web framework and template engine to use. As we are finally starting to do some common UI work, I'm wondering if the Struts 2 tag library framework is worth basing our tag library on. Assume it wouldn't be too hard to extract mostly as-is: * Is the design solid? * How limiting do you find it over native tags/macros in the respective template engines? * How useful is the theme system really? For example, properties that are only used by some themes are confusing and error-prone. * Any performance bottlenecks outside all the OGNL usage? * Would Struts be interested in the result? The benefits I see are: * Support for Velocity, Freemarker, and JSP * Overridable, customizable Themes * Ability to plug in a new template engine * Generated tld and docs While I've worked a bit on the tags from a struts dev pov, I've haven't used them much myself. My gut feel is it would be worth it in the short and long term, however I remember some discussion about their design and value, so I'd like to revisit those concerns. BTW, was digging around in the javatemplate stuff...very impressive! It is cool to see simple prototype code turned into a full featured library. Any thoughts on how that sax-like design worked out? Should it have been a more DOM-like object model instead? Don - 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 Tue, Aug 11, 2009 at 3:15 PM, Martin Coopermart...@apache.org wrote: OK, here's a question that's been on my mind for a while. Why is it that, for almost every S2 release, we need to make changes to something as core as XWork? Why isn't XWork stable enough by now that we don't have to be changing it all the time? It's often bothered me that we always seem to need to wait for an XWork release, not so much because of the wait, but because we seem to be so dependent on constant change in that library. What's up with that? That is what seems to be the real issue here. This is exactly my point. XWork is such a core part of what Struts 2 is that it shouldn't be separate. Any non-trivial change to Struts 2 involves changes to XWork and I don't see that changing anytime soon. 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. Don - 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 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! :) Don - 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 Thu, Aug 6, 2009 at 4:22 PM, Musachy Barrosomusa...@gmail.com wrote: Sounds reasonable to me. Couple of question to fuel discussion: What would be the target version? Do we need to go through incubation, etc? (I have never known much about the ASF legal process) The code would definitely have to go through an IP clearance step, which I'd be happy to help with. The target version will just be the Struts version - no need for a separate release cycle. Don musachy On Wed, Aug 5, 2009 at 10:12 PM, Don Browndonald.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 -- 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: 2.1.8 release?
Ok, why aren't we bringing xwork into Struts 2 again? Don On Thu, Aug 6, 2009 at 8:44 AM, Musachy Barrosomusa...@gmail.com wrote: Free time on Rainer's hands, when xwork gets released then 2.1.8 can be released. musachy On Wed, Aug 5, 2009 at 3:35 PM, Andreas Joseph Kroghandr...@officenet.no wrote: What's keeping it from being released? -- Andreas Joseph Krogh andr...@officenet.no Senior Software Developer / CTO +-+ OfficeNet AS | The most difficult thing in the world is to | Rosenholmveien 25 | know how to do a thing and to watch | 1414 Trollåsen | somebody else doing it wrong, without | NORWAY | comment. | | | 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 -- 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
Let's kill xwork (was Re: 2.1.8 release?)
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
Re: Struts2 jQuery Plugin - Logo
On Tue, Jul 28, 2009 at 9:29 PM, Rainer Hermannsherma...@aixcept.de wrote: I'm really happy, that Johannes implemented this plugin and it is now ready to use and I will definitely use it. If we bring it into Struts2 core, I'm also willing to support this plugin and help to maintain and extend the functionality. Just to clarify, what you really mean is bring the plugin into Struts trunk? I'm guessing you don't mean you want to include the code in the struts2-core artifact... Don - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: [ANN] Confluence 2.10 migration for cwiki.a.o 11 July
Actually, Struts dev wasn't, so good idea. :) Don On Tue, Jul 7, 2009 at 11:08 PM, Wes Wannemacherw...@wantii.com wrote: Sorry, I didn't see that we were already copied :( [snip] -- Wes Wannemacher Author - Struts 2 In Practice Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more http://www.manning.com/wannemacher - 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: We may lose Confluence
Yes, then the files are rsynced to our regular www directory. Don On Thu, May 21, 2009 at 11:36 PM, Musachy Barroso musa...@gmail.com wrote: another thing, what generates the content under this? http://cwiki.apache.org/WW/ , is it the export plugin? musachy On Thu, May 21, 2009 at 9:31 AM, Musachy Barroso musa...@gmail.com wrote: I am playing with space export, but that thing is slower than windows 95. musachy On Wed, May 20, 2009 at 5:38 PM, Rene Gielen gie...@it-neering.net wrote: Since we have tons of content, combined with snippets and what not, losing confluence should not be an option. I think looking how to come over this issue - maybe XML export does the trick, or even working on the old plugin - should be the way to go. And maybe our historically good connections to the Atlassian guys could help - Don? If we don't have a sandbox/test instance available at Apache, I could provide one since I bought one of the 5$ / 5 users license from the Atlassian charity event a few weeks ago. But I'm sure that the Infra guys could help here ... Musachy Barroso schrieb: Is there some sort of test confluence instance, so we can play with the export plugin? The plugin wiki also mentions some perl script written by the folks at Codehaus, which does a similar job, but I can't find that anywhere. musachy On Wed, May 20, 2009 at 3:13 PM, Musachy Barroso musa...@gmail.com wrote: Actually I take it back, we dont have many people that like to spend time on the wiki (I am one of them), so yeah this would be a problem. musachy On Wed, May 20, 2009 at 1:52 PM, Wendy Smoak wsm...@gmail.com wrote: On Wed, May 20, 2009 at 10:47 AM, Musachy Barroso musa...@gmail.com wrote: If it comes down to the worst (we lose Confluence), what other wiki would we use? We could always try to come up with some script to try to port the pages. //this might be a good chance to re-organize and clean up the documentation My guess is MoinMoin, which is already running at Apache. (It's what we used to use before Confluence.) -- Wendy - 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 -- Rene Gielen IT-Neering.net Saarstrasse 100, 52062 Aachen, Germany Line: +49-(0)241-4010770 Cell: +49-(0)177-3194448 mailto:r...@it-neering.net - 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 -- 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: We may lose Confluence
If it hasn't been linked to already, see https://tracker.adaptavist.com/browse/GSE-1590 Don On Wed, May 20, 2009 at 2:27 PM, Martin Cooper mart...@apache.org wrote: Folks, Due to a long-standing issue with Confluence, there are discussions going on that could lead to us losing Confluence as a resource, both for generating our web site and for our wiki. This would be really bad for Struts, which is why I'm bringing this up now. The core issue is that we are on a very old version of Confluence, and there are serious scaling issues with that version. The infrastructure team very much wants to upgrade to the latest version of Confluence, but the issue there is that the Auto Export Plugin does not work with more recent versions than the one we are running. This is due to some structural changes that were made in Confluence, and the Auto Export Plugin not having been updated for those changes. The Auto Export Plugin is open source, but for a variety of reasons, the resources have not been brought to bear to update the Auto Export Plugin such that we can deploy it on a newer version of Confluence. If you care about our continued ability to use Confluence to generate our web site, and our wiki, please consider getting involved in at least the discussions on the infrastructure mailing lists. If you think you might be able to help with updating the plugin itself, your help would be very much appreciated. Again, joining the discussion on the infrastructure list would be the place to start. Personally, it horrifies me to think of how much work would be involved in migrating all of our content to a different wiki, let alone compensating for the loss of various Confluence plugins and macros (e.g. snippets). As mentioned, the Auto Export Plugin is open source, and lives here: http://code.google.com/p/couldit-autoexport/ious Your thoughts and comments can be brought up on the infrastruct...@a.omailing list. -- Martin Cooper - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: We may lose Confluence
Yes, get the auto-export plugin working with the latest version of Confluence, then we can upgrade like normal. Don On Fri, May 22, 2009 at 6:04 AM, Dave Newton newton.d...@yahoo.com wrote: Martin Cooper wrote: On Thu, May 21, 2009 at 6:31 AM, Musachy Barroso musa...@gmail.com wrote: I am playing with space export, but that thing is slower than windows 95. This is, in part, due to the old version of Confluence that we are running. Infra wants to upgrade, but can't because of the use of the Auto Export Plugin. That plugin has been the sticking point for a *very* long time now, hence no upgrade, hence very, very poor performance in some areas. (One of the most-affected areas is administration, which is very painful right now and won't improve until we can upgrade, hence infra's fix it or lose it approach right now.) is this something that could be resolved by creating an updated export plugin? Dave - 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 git mirrors now available
Being able to quickly create git repos of the Subversion projects is exactly what these are for. See this: http://wiki.apache.org/general/GitAtApache Don On Wed, May 6, 2009 at 7:48 PM, Rene Gielen gie...@it-neering.net wrote: Another scenario I recently experimented with came up when I was thinking about a feasible process to enable a local CI infrastructure for experimental changes on the s2 codebase. While we have our central CI builds set up, they only make sense for features which are targeted for immidiate improvements and soon production, you would not want to push highly experiental code that even might never make it into a release unless you are working on a fresh early branch like upcoming 2.2. Nevertheless, when your experiments turned out to be both stable and useful, you would want to push them as a whole to the main repository. The solution I found was to use git-svn, which is able to make a git repository mirror out of a svn repo (so far not that different from the new mirror infrastructure introduced her), but also to push changes back to the original svn. It helped me to introduce a very useful workflow, allowing me to commit small changes to my local git repository, triggering a Hudson build, while I went over to the next change. I'm also able to pull incoming svn changes easily, improving the quality of the integration test and solve merge issues upfront. After implementing and testing all changes, the commit to the svn repo then goes as a whole. The only downside was that, since our svn tree is part of the huge Apache svn repo containing all revisions of all projects, the initial creation of the git-svn repo took about one (!!) day - it scanned about 7.3 million revisions only to get our small tree synced. But once done, things run very fast. After all, I found this workflow also very useful for my client's projects - convincing some of them to move from cvs to svn took me ages, now telling them that they should move over to git would make them go mad on me, I guess. When I first saw the git mirror announcement, I had the still hope that the svn push would be possible too, which not seems to be the case now. But being a huge git fan now, I really appreciate this git integration step and how non-committers can use it to build a good development environment. - Rene Don Brown schrieb: On Mon, Apr 27, 2009 at 3:17 PM, Wes Wannemacher w...@wantii.com wrote: Don, I'm not familiar much with Git. I know of it, and have read a little about it. Is there a significant advantage to using Git over Subversion? While Atlassian still uses Subversion, I've moved over to using Git for all my work and personal projects, and I've found it a much better tool to keep me productive (great branching/merge, sane cli, super-fast, etc). However, why I'm particularly excited about having a Struts mirror is I hope it will be a way for the community to be much more active in its development. With Subversion, only committers can make any changes, so if you as a user wrote a feature, all you can do is attach it to JIRA and hope for the best. If you are more adventurous, you could fork Struts into your own Subversion repo, but then you have to deal with the pain of keeping them in sync. Git, as a distributed SCM tool, is built for this type of decentralized development, and in particular, Github makes it easy to track, both for the user and committer. In a perfect world, we'd have an official Github mirror of Struts. If a user wanted to get rid of OGNL, they can click the Fork button and have their own repo. Once they commit their changes, they send us a pull request or at least create a JIRA issue and link to their repo. What is cool about this is the user can start using their feature now with minimal hassles keeping up to date with Struts trunk, but better yet, any other user can fork that fork and build on that change. You could have a whole sub-community around a certain fork, say, one that gets rid of OGNL and all other Struts deps, all without any need to have commit access. As Struts committers, it allows us to take our philosophy of letting the community sift through ideas to the next level from just ideas and JIRA issues to actual code and forked releases. Our job then is to pick the creme of the crop, vet the legal stuff, and push the chosen features back to the official Struts repo. Therefore, I think git will help us empower our community, make the committers lives easier, and deliver better code quicker. Who could argue with that? :) Don - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org -- René Gielen IT-Neering.net Saarstrasse 100, 52062 Aachen, Germany Tel: +49-(0)241-4010770 Fax: +49-(0)241-4010771 http://twitter.com/rgielen
Struts git mirrors now available
Thanks to the git infra team, we have git mirrors for Struts: Here are mirrors created: * git://git.apache.org/struts1.git * git://git.apache.org/struts2.git * git://git.apache.org/struts-sandbox.git * git://git.apache.org/struts-maven.git See https://issues.apache.org/jira/browse/INFRA-1991 for more information. Don - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Struts git mirrors now available
On Mon, Apr 27, 2009 at 3:17 PM, Wes Wannemacher w...@wantii.com wrote: Don, I'm not familiar much with Git. I know of it, and have read a little about it. Is there a significant advantage to using Git over Subversion? While Atlassian still uses Subversion, I've moved over to using Git for all my work and personal projects, and I've found it a much better tool to keep me productive (great branching/merge, sane cli, super-fast, etc). However, why I'm particularly excited about having a Struts mirror is I hope it will be a way for the community to be much more active in its development. With Subversion, only committers can make any changes, so if you as a user wrote a feature, all you can do is attach it to JIRA and hope for the best. If you are more adventurous, you could fork Struts into your own Subversion repo, but then you have to deal with the pain of keeping them in sync. Git, as a distributed SCM tool, is built for this type of decentralized development, and in particular, Github makes it easy to track, both for the user and committer. In a perfect world, we'd have an official Github mirror of Struts. If a user wanted to get rid of OGNL, they can click the Fork button and have their own repo. Once they commit their changes, they send us a pull request or at least create a JIRA issue and link to their repo. What is cool about this is the user can start using their feature now with minimal hassles keeping up to date with Struts trunk, but better yet, any other user can fork that fork and build on that change. You could have a whole sub-community around a certain fork, say, one that gets rid of OGNL and all other Struts deps, all without any need to have commit access. As Struts committers, it allows us to take our philosophy of letting the community sift through ideas to the next level from just ideas and JIRA issues to actual code and forked releases. Our job then is to pick the creme of the crop, vet the legal stuff, and push the chosen features back to the official Struts repo. Therefore, I think git will help us empower our community, make the committers lives easier, and deliver better code quicker. Who could argue with that? :) Don - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Struts git mirrors now available
On Mon, Apr 27, 2009 at 3:38 PM, Wes Wannemacher w...@wantii.com wrote: After reading up on Git a bit and noticing right away that there are no more hidden '.svn' directories, I'm sold. :) (I'm an easy sell) Yeah, for me, it was a lot of little things too: * no .svn directories means easy searching and quick tab-completion when nagivating directories * git commands can be color-enhanced * git-log automatically pipes to less (or equiv) * git-blame is instant, which is nice for us devs in Sydney * git-rebase -i gives the ability to squash commits...so useful for cleaning up a lot of little commits for the push to the main server * git-stash puts your current changes on a shelf for when you need to quickly do something else I could go on... Don -Wes -- Wes Wannemacher Author - Struts 2 In Practice Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more http://www.manning.com/wannemacher - 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
Ready for Struts 2.2 and XWork 2.2?
Now that 2.1 is GA (thanks guys and gals), are we ready to branch it off and move trunk to 2.2? I was wanting to do some refactoring of how XWork configuration is loaded and parsed, but new classes and the like really isn't appropriate for a patch/micro release. Any objections to the branching? Don - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Ready for Struts 2.2 and XWork 2.2?
Off the top of my head: * Split out the XML parser from XmlConfigurationProvider so that you can parse XML from any source * Get rid of all the Class.forName() calls in XWork I'd rather not do this on a stable branch, particularly since new public classes will be created. How many changes are there in 2.1.7 and 2.1.3 that haven't been released? Could we get those releases out the door so we know we branch at a known good state? Don On Fri, Apr 10, 2009 at 11:25 PM, Musachy Barroso musa...@gmail.com wrote: I think we are good. What changes do you have in mind?, the OSGi plugin could take advantage of some refactoring of xwork so I am interested :) musachy On Fri, Apr 10, 2009 at 8:24 AM, Don Brown mr...@twdata.org wrote: Now that 2.1 is GA (thanks guys and gals), are we ready to branch it off and move trunk to 2.2? I was wanting to do some refactoring of how XWork configuration is loaded and parsed, but new classes and the like really isn't appropriate for a patch/micro release. Any objections to the branching? Don - 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
Google App Engine support?
Has anyone tried or, better yet, succeeded in getting Struts 2 to run on Google App Engine? While waiting for an account, I did get the showcase with 2.1.6 to run in the sdk. The only sticking point was the security manager that ognl uses. Since the security manager is used by GAE to lock down Java, the custom OGNL permissions are obviously not granted, so to disable OGNL's little checks, I created an servlet context listener that just sets OgnlRuntime.setSecurityManager(null), which seems to do the trick. From what I hear, deploying on the real thing is still different than the sdk, so I don't know if it runs for real. Don - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Google App Engine support?
Cool. I have an account too, but haven't received the Java upgrade approval yet. I put my code up on Github: http://github.com/mrdon/gae-sandbox/tree/master You will need to change the path to the sdk in build.xml. Don On Fri, Apr 10, 2009 at 12:32 AM, Al Sutton a...@funkyandroid.com wrote: If you want to send over what you've done I've got a live account I'd be willing to test it 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: Don Brown [mailto:mr...@twdata.org] Sent: 09 April 2009 15:31 To: Struts Developers List Subject: Google App Engine support? Has anyone tried or, better yet, succeeded in getting Struts 2 to run on Google App Engine? While waiting for an account, I did get the showcase with 2.1.6 to run in the sdk. The only sticking point was the security manager that ognl uses. Since the security manager is used by GAE to lock down Java, the custom OGNL permissions are obviously not granted, so to disable OGNL's little checks, I created an servlet context listener that just sets OgnlRuntime.setSecurityManager(null), which seems to do the trick. From what I hear, deploying on the real thing is still different than the sdk, so I don't know if it runs for real. Don - 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: Google App Engine support?
Hmm...bad sitemesh... java.lang.NoClassDefFoundError: Could not initialize class com.google.apphosting.runtime.security.shared.stub.javax.naming.InitialContext at com.opensymphony.module.sitemesh.Factory.getEnvEntry(Factory.java:88) at com.opensymphony.module.sitemesh.Factory.getInstance(Factory.java:42) at com.opensymphony.module.sitemesh.filter.PageFilter.init(PageFilter.java: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 you should get access to the Java loveliness error log that way ;). 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 15:39 To: Struts Developers List Subject: Re: Google App Engine support? Cool. I have an account too, but haven't received the Java upgrade approval yet. I put my code up on Github: http://github.com/mrdon/gae-sandbox/tree/master You will need to change the path to the sdk in build.xml. Don On Fri, Apr 10, 2009 at 12:32 AM, Al Sutton a...@funkyandroid.com wrote: If you want to send over what you've done I've got a live account I'd be willing to test it 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: Don Brown [mailto:mr...@twdata.org] Sent: 09 April 2009 15:31 To: Struts Developers List Subject: Google App Engine support? Has anyone tried or, better yet, succeeded in getting Struts 2 to run on Google App Engine? While waiting for an account, I did get the showcase with 2.1.6 to run in the sdk. The only sticking point was the security manager that ognl uses. Since the security manager is used by GAE to lock down Java, the custom OGNL permissions are obviously not granted, so to disable OGNL's little checks, I created an servlet context listener that just sets OgnlRuntime.setSecurityManager(null), which seems to do the trick. From what I hear, deploying on the real thing is still different than the sdk, so I don't know if it runs for real. Don - 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: 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.Initi a lConte xt at com.opensymphony.module.sitemesh.Factory.getEnvEntry(Factory.java:88) at com.opensymphony.module.sitemesh.Factory.getInstance(Factory.java:42) 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 you should get access to the Java loveliness error log that way ;). 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 15:39 To: Struts Developers List Subject: Re: Google App Engine support? Cool. I have an account too, but haven't received the Java upgrade approval yet. I put my code up on Github: http://github.com/mrdon/gae-sandbox/tree/master You will need to change the path to the sdk in build.xml. Don On Fri, Apr 10, 2009 at 12:32 AM, Al Sutton a...@funkyandroid.com wrote: If you want to send over what you've done I've got a live account I'd be willing to test it on. Al. --- * Written an Android App? - List it at http://andappstore.com
Re: INFRA-1811
+1 On Sat, Jan 31, 2009 at 2:31 PM, Wendy Smoak wsm...@gmail.com wrote: We currently have build status notifications going to commits@ -- I'd prefer to keep the automated messages going there (or to a new notifications@ list) and reserve dev@ for human conversations. :) -- 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: [VOTE] Struts Annotations 1.0.4
Doh, make that +1 GA ... is a quality vote really required for internal, compile-time libraries? We don't vote on the quality of POM files, and those are more public. Don On Tue, Dec 23, 2008 at 9:24 PM, Don Brown mr...@twdata.org wrote: +1 On Tue, Dec 23, 2008 at 3:30 PM, Musachy Barroso musa...@gmail.com wrote: The Struts Annotations 1.0.4 test build is now available as a Maven artifact. It is a dependency of Struts 2.1.3. If you have had a chance to review the test build, please respond with a vote on its quality: [ ] Leave at test build [ ] Alpha [ ] Beta [ ] General Availability (GA) Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and more +1s than -1s. The vote will remain open for at least 72 hours, longer upon request. 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: [VOTE] Struts Annotations 1.0.4
+1 On Tue, Dec 23, 2008 at 3:30 PM, Musachy Barroso musa...@gmail.com wrote: The Struts Annotations 1.0.4 test build is now available as a Maven artifact. It is a dependency of Struts 2.1.3. If you have had a chance to review the test build, please respond with a vote on its quality: [ ] Leave at test build [ ] Alpha [ ] Beta [ ] General Availability (GA) Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and more +1s than -1s. The vote will remain open for at least 72 hours, longer upon request. 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: java tags proposal
Neat, I'm glad to see work finally being done on the tags. What exactly would this mean for 2.1 and 2.2? Would this be the default template engine for the tags? Will the documentation need to be rewritten? How do we keep the engines in sync if we keep the freemarker and velocity engines around? Do we have any tests for that? Don On Sun, Dec 21, 2008 at 5:24 AM, Musachy Barroso musa...@gmail.com wrote: As mentioned on the other thread I's like to propose to move the java tags out of the sandbox into the core plugins bundled with the distribution, so they will be part of the 2.1 release. here is +1 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: java tags proposal
That's fine, I just think we should have an agreed-upon, documented strategy for Struts users and developers. Doing an 'svn move' is pretty easy - creating a migration strategy, documenting it, writing tests to ensure the transition goes smoothly, keeping on top of bugs, etc, there are the tricky bits. Of course, being open source, I'd be happy for 3 out of the 4 :) Don On Sun, Dec 21, 2008 at 11:35 PM, James Holmes ja...@jamesholmes.com wrote: In my opinion the Java-tags should ultimately become the default in say 2.2 or 2.3, but for now they should be a supported, experimental plugin packaged with core. I say that because I think it's a little early to have them replace the time-tested FreeMarker-based tags. If we can get them out in the wild in 2.1 and people start using them, we can work out the kinks and then make them the default. Perhaps the FreeMarker-based tags ultimately move to the Sandbox?? On Sun, Dec 21, 2008 at 7:29 AM, Don Brown mr...@twdata.org wrote: Neat, I'm glad to see work finally being done on the tags. What exactly would this mean for 2.1 and 2.2? Would this be the default template engine for the tags? Will the documentation need to be rewritten? How do we keep the engines in sync if we keep the freemarker and velocity engines around? Do we have any tests for that? Don On Sun, Dec 21, 2008 at 5:24 AM, Musachy Barroso musa...@gmail.com wrote: As mentioned on the other thread I's like to propose to move the java tags out of the sandbox into the core plugins bundled with the distribution, so they will be part of the 2.1 release. here is +1 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 - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Fixed the build
I fixed the builds running at http://opensource.bamboo.atlassian.com/browse/STRUTS The problem was a Maven 1 repository in there that was causing Maven to, for some reason, not try all the repositories when looking for a dependency. For now, I just commented out that repository and we'll see what other projects' builds that breaks :) Don - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: BAMBOO failing
That should have been fixed a while ago. Could someone who has moderate permissions give them to me as well so I can debug this issue? Don On Wed, Dec 3, 2008 at 5:39 PM, Martin Cooper [EMAIL PROTECTED] wrote: Yep. At least at some point, they were being sent with a bulk header, which tripped them straight into never-never land. -- Martin Cooper -Wes - 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] Struts 2.0.12 Quality
+1 GA On Thu, Oct 16, 2008 at 9:01 PM, Rene Gielen [EMAIL PROTECTED] wrote: The Struts 2.0.12 test build is now available. Release notes: * http://struts.apache.org/2.x/docs/release-notes-2012.html Distribution: * http://people.apache.org/builds/struts/2.0.12/ Maven 2 staging repository: * http://people.apache.org/builds/struts/2.0.12/m2-staging-repository/ Once you have had a chance to review the test build, please respond with a vote on its quality: [ ] Leave at test build [ ] Alpha [ ] Beta [ ] General Availability (GA) Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and more +1s than -1s. The vote will remain open for at least 72 hours, longer upon request. A vote can be amended at any time to upgrade or downgrade the quality of the release based on future experience. If an initial vote designates the build as Beta, the release will be submitted for mirroring and announced to the user list. Once released as a public beta, subsequent quality votes on a build may be held on the user list. As always, the act of voting carries certain obligations. A binding vote not only states an opinion, but means that the voter is agreeing to help do the work. - 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: OWASP Intrinsic Security Working Group workshop on Framework Security
Any struts devs on that side of the world? I'd love to go and could probably get Atlassian to sponsor me, but with the conference on November 7, it is way too late notice. Don On Sat, Oct 11, 2008 at 4:49 AM, Colin Watson [EMAIL PROTECTED] wrote: Dear Struts Dev list, The Open Web Application Security Project (OWASP, http://www.owasp.org) is holding an Intrinsic Security Working Group (ISWG) workshop on Framework Security. The point of the workshop is to gather security experts and framework developers/security teams together in order to facilitate introducing more and more usable security into the frameworks that we build our applications on. OWASP would be pleased to see as many of you as possible in the beautiful Algarve, Portugal where the workshops and conference are being held. More information on dates and logistics can be found on the conference website: http://www.owasp.org/index.php/OWASP_EU_Summit_2008 However, if one 'official' representative from the Struts framework, such as a leader or a senior person from the developer or security team, is available and OWASP is allowed to use the framework logo on the Working Session page at: http://www.owasp.org/index.php/OWASP_Working_Session_-_Web_Application_Framework_Security OWASP would then happily cover part of the expenses of attendance for the one official representative. To discuss this official representative offer, please contact Arshan Dabirsiaghi as soon as possible, since the offer may be withdrawn at any time. Sent on behalf of, Arshan Dabirsiaghi [EMAIL PROTECTED] Project Lead, ISWG OWASP by Colin Watson OWASP individual member, London - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 Plugin Repository Issue
Unfortunately, pages that aggregate content from other pages have to be generated manually. I updated it. Don On Thu, Sep 25, 2008 at 2:04 PM, Yohan Liyanage [EMAIL PROTECTED] wrote: Hi, I created a plugin for Struts 2 and posted a news in the Struts 2 Plugin Repository Confluence Wiki. However, I cannot see my plugin listed in the http://cwiki.apache.org/S2PLUGINS/home.html announcements list (which is the URL linked by the home page of Struts2 web site). But I can see it in http://cwiki.apache.org/confluence/display/S2PLUGINS/home. I noticed the .html extension in the first URL. Is this a static page and not updated when wiki is updated? Thanks. -- View this message in context: http://www.nabble.com/Struts-2-Plugin-Repository-Issue-tp19662735p19662735.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: [s2] Improved Velocity Integration
Ah, that does look a lot better. I still wish velocity supported
named parameters, but this is better than nothing. Could you file a
ticket for this improvement please, and if you have time to write a
patch, it would certainly be appreciated :)
Don
On Thu, Sep 18, 2008 at 7:12 AM, Christopher Schultz
[EMAIL PROTECTED] wrote:
All,
I'm an S1 user and a member of the Velocity team. I recently posted a
message to the velocity-dev list regarding the ugly syntax required by
the S2 tag Velocity implementation.
For reference:
http://www.nabble.com/Named-macro-parameters-td19459070.html
The gist of the question was: can Velocity support a better syntax so
that stringified name=value parameter pairs didn't have to be
re-parsed for every run-through of the template.
After a bit of back-and-forth Nathan Bubna showed that an on-the-fly Map
can be used to make the syntax look similar to the JSP/fm
implementations, but does not require the string parsing of each macro
parameter. Something like this:
#sform({'action' : 'updatePerson' })
#stextfield({'label' : 'First name', 'name' : 'firstName'})
#ssubmit({'value' = 'Update'})
#end
(Written to match the examples on this page:
http://struts.apache.org/2.0.11.2/docs/velocity-tags.html)
I wonder if there's any interest in supporting this type of Velocity
integration in order to avoid parsing the name/value strings that arise
from this syntax:
#sform (action=updatePerson)
#stextfield (label=First name name=firstName)
#ssubmit (value=Update)
#end
Just a thought.
Thanks,
-chris
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: more OSGI thoughts?
The latest status is I built a plugin system around OSGi for Atlassian and it is in the process of being rolled out. Basically, it utilizes a hybrid approach where the main webapp is a normal webapp, but plugins can be installed on it dynamically via OSGi. I have the OK to open source it, but I want to have something in mind to use it with first. Archiva, the Maven proxy, is looking to add a plugin system, and since James, a fellow Atlassian, is a committer, I might start there. They use WebWork 2 right now, so it may involve a migration to Struts 2, we'll see... Don On Fri, Sep 12, 2008 at 10:33 AM, Jeromy Evans [EMAIL PROTECTED] wrote: Has anyone given any more thought to an OSGI container embedded within Struts2? I ask because I growing to hate having to build and deploy entire war files and regularly restart Containers. It seems far behind alternative technologies. Is it conceivable that: - the container provides the infrastructure (and almost never restarts); - S2 provides a standard deployment/development environment (and is never undeployed) - the OSGI container within S2 provides the ability to deploy/undeploy bundles within that environment Then, as an S2 developer I package my application up as sensible bundles and deploy/update them as needed, so I'm working with tiny little jars instead of massive wars. Some complex discovery is required with each bundle deployment but achievable. I'd much prefer something like this rather than S2 apps themselves being deployed within an OSGI container. Is this along the lines with your latest thoughts Don or Musachy or have you moved on? - 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: more OSGI thoughts?
The Atlassian plugin system has been in Atlassian products for years, allowing developers to add new features to Atlassian applications dynamically in some cases (Confluence). However, the two main problems with it were: * No defined boundary between the application and plugins, causing plugins to break on application upgrades as well as buggy plugins using the internal application classes in ways they weren't meant to be used * Plugins cannot depend on other plugins reliably. The last one was particularly painful for projects I've been working in as we've been trying to basically build new applications on top of the existing applications using plugins, and not having a reliable way to have plugin dependencies has been a real blocker. The first issue hampers our plugin community and causes a significant support load. Therefore, I build Atlassian Plugins 2.0 to resolve these issues by building the framework on OSGi. OSGi allows our applications to say exactly what classes and services are available to plugins, and has built-in support for inter-bundle dependencies. At this point, we are positioning this to be a solution for user plugins as well as our internal bundled plugins, but there is movement for rewriting bits of the application architecture over to use plugins. Therefore, we are using OSGi in a hybrid sense, because the usual integration path is to build the whole application as OSGi bundles using a Servlet bridge or get rid of the app server altogether and use an OSGi container directly. This allows us to leave the main application alone and migrate to OSGi where it makes sense. Our medium term goal is to build a plugin market place, where administrators can browse plugins and install them from a remote repository with one click. This feature is available now on Confluence and soon on JIRA, but we want to support this in all our products consistently. Our first draft of plugin documentation can be found here: http://confluence.atlassian.com/display/PLUGINFRAMEWORK/Plugin+Framework+Documentation Don On Fri, Sep 12, 2008 at 11:25 AM, Jeromy Evans [EMAIL PROTECTED] wrote: Thanks for the update. Is the purpose of the plugin system to make it easier for administrators to bring plugins into their deployment at run-time, or more about minimising conflicts between plugin versions? And are you pulling plugins from a repository (eg. browse and select compatible versions much like, say, IntelliJ)? Interesting. In my use-case the plugins (bundles) would contain S2 actions/packages and Entities. Don Brown wrote: The latest status is I built a plugin system around OSGi for Atlassian and it is in the process of being rolled out. Basically, it utilizes a hybrid approach where the main webapp is a normal webapp, but plugins can be installed on it dynamically via OSGi. I have the OK to open source it, but I want to have something in mind to use it with first. Archiva, the Maven proxy, is looking to add a plugin system, and since James, a fellow Atlassian, is a committer, I might start there. They use WebWork 2 right now, so it may involve a migration to Struts 2, we'll see... Don On Fri, Sep 12, 2008 at 10:33 AM, Jeromy Evans [EMAIL PROTECTED] wrote: Has anyone given any more thought to an OSGI container embedded within Struts2? I ask because I growing to hate having to build and deploy entire war files and regularly restart Containers. It seems far behind alternative technologies. Is it conceivable that: - the container provides the infrastructure (and almost never restarts); - S2 provides a standard deployment/development environment (and is never undeployed) - the OSGI container within S2 provides the ability to deploy/undeploy bundles within that environment Then, as an S2 developer I package my application up as sensible bundles and deploy/update them as needed, so I'm working with tiny little jars instead of massive wars. Some complex discovery is required with each bundle deployment but achievable. I'd much prefer something like this rather than S2 apps themselves being deployed within an OSGI container. Is this along the lines with your latest thoughts Don or Musachy or have you moved on? - 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: more OSGI thoughts?
Written from scratch, although it did build on the plugin, conceptually. Don On Fri, Sep 12, 2008 at 12:36 PM, Musachy Barroso [EMAIL PROTECTED] wrote: Yeah that sounds cool. Is it based on the current OSGi plugin or is it written from scratch? musachy On Thu, Sep 11, 2008 at 9:59 PM, Jeromy Evans [EMAIL PROTECTED] wrote: Don Brown wrote: The Atlassian plugin system has been in Atlassian products for years, allowing developers to add new features to Atlassian applications dynamically in some cases (Confluence). However, the two main problems with it were: Cool. I'm impressed you guys are allowed to be open about what you're working on. - 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: [VOTE] Release Struts 2 Starter Maven Archetype v2.0.11.2
+1 On Tue, Sep 2, 2008 at 4:09 PM, Rainer Hermanns [EMAIL PROTECTED] wrote: +1 The Struts 2 Starter Maven Archetype v2.0.11.2 is available for review. Staging repository: http://people.apache.org/builds/struts/struts-archetypes/2.0.11.2/starter-m2-staging-repository Instructions for use: - http://struts.apache.org/2.x/docs/ready-set-go.html - http://struts.apache.org/2.x/docs/struts-maven-archetypes.html (...adjust version and remote repo as necessary.) Once you have had a chance to review this build, please vote: [ ] +1 Release it and update the docs! [ ] +/- 0 [ ] -1 This should not be released because... -- Wendy - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S2 as JSR for Action Framework
On Mon, Aug 25, 2008 at 12:54 PM, Martin Cooper [EMAIL PROTECTED] wrote: Another option is a client-side component-based framework like Ext or Flex running directly against web services, RESTful or otherwise. No server-side web framework required. Of course, you could use something server-side like DWR to facilitate working with web services, or Jersey for RESTful services, but that would be a choice rather than a requirement. This is a nice design, when you can do it. GWT is also a good way to build these types of apps. Unfortunately, they can easily break much of what makes the web what it is - the back button, unique, addressable URI's, accessibility, search engine crawling, etc. Therefore, I think some sort of server-side web framework will usually be necessary, however, I don't think it has to go so far as JSF, where they try to push all the state to the server. I was talking with a guy here at work who is looking to start using GWT more about how and where a plain HTML view of the application fits. He wants to do very dynamic, client-side heavy views, but still needs to support search engines and REST clients. What if you use Jersey for your REST API, GWT or straight JQuery for your client-side UI, then have Jersey + something generate HTML views of your REST API, which you could use for search engines and developers wanting to browse and interact with your application. If you can have the HTML representation of your REST API auto-generated, you wouldn't have to maintain two different interfaces, and you could go fully nuts with your client-side heavy app without having to worry about accessibility or search engine issues. Don -- Martin Cooper This idea of a JSR would be standardizing the third group, but I wonder if maybe the better direction to go is not a new API, but build extensions on JAX-RS [2]. To me, this group's niche is apps that need lightweight presentation engines a layer above servlets, but still very much web-y. JSR 311 aims to make restful resources easy to build, which isn't far from restful web applications. Especially as more and more applications are starting to rely on client-side AJAX interfaces, the need for a solid RESTful backend only gets stronger. The storage of server-side state of the component frameworks becomes less important, and if you don't want the bulk of Grails, this approach may be attractive. For my day job, we need to build REST interfaces to our web apps, so we are looking to standardize on JAX-RS. Well, we also need a lightweight web framework for our plugin system, and if we are already using something like Jersey [3], it would be nice to be able to write web apps using the same technology. This use case is obviously very specific to our situation, but it is the direction I'll likely be taking in the next few months. Don [1] http://www.source-code.biz/MiniTemplator/ [2] https://jsr311.dev.java.net/ [3] https://jersey.dev.java.net/ On Fri, Aug 22, 2008 at 4:31 PM, Frans Thamura [EMAIL PROTECTED] wrote: hi all is it possible that S2 become part of JCP? java server action framework right now only component framework there any idea? -- -- Frans Thamura Meruvian Foundation Mobile: +62 855 7888 699 Linkedin: http://www.linkedin.com/in/fthamura Training JENI, Medallion (Alfresco, Liferay dan Compiere).. buruan... URL: http://nagasakti.mervpolis.com/roller/mervnews/entry/jeni_training_compiere_dan_alfresco - 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 as JSR for Action Framework
Personally, I don't think Struts 2 has a strong enough API, ok, I _know_ Struts 2 doesn't have a strong enough API to be turned into a JSR, currently anyway. Bob did some work trying to define such an API, and is probably 80% of the way there, but I wonder if the technology has moved on a bit since then... For fun in a side project, I'm going back to pure Servlets and a simple template language [1] to better understand what a web framework really needs to provide. As I see the options now you have: * Rails/Merb/Grails - rapid development, scripting language base, solid best of breed stack (for Grails anyway) under the covers. On the other hand, using any of these to write a hello world war is something like 25 megabytes and a ton of dependencies. That is fine for shops that need to get something up quickly and are starting from scratch, but not for others. * JSF/Wicket/Tapestry - component development for swing/drag-and-drop folks, ability to wrap up complex bits into new components, usually nice tool support. On the other hand, their apps tend to not be RESTful and take you quite a ways from HTTP. Also, they usually involve a lot of server-side state management which can impact scalability and they sometimes rely on a Javascript to really work. Finally, each tends to really favor their one template language by design, limiting options down the road. * Struts/Stripes/Spring MVC - lightweight MVC frameworks with minimal dependencies, with a specific focus on the presentation tier. Easy access to HTTP features, not much to learn, can fit easily into most application stacks, and tend to be very RESTful. These frameworks tend to be fast, impose little requirements on the session, and work with most template engines. This idea of a JSR would be standardizing the third group, but I wonder if maybe the better direction to go is not a new API, but build extensions on JAX-RS [2]. To me, this group's niche is apps that need lightweight presentation engines a layer above servlets, but still very much web-y. JSR 311 aims to make restful resources easy to build, which isn't far from restful web applications. Especially as more and more applications are starting to rely on client-side AJAX interfaces, the need for a solid RESTful backend only gets stronger. The storage of server-side state of the component frameworks becomes less important, and if you don't want the bulk of Grails, this approach may be attractive. For my day job, we need to build REST interfaces to our web apps, so we are looking to standardize on JAX-RS. Well, we also need a lightweight web framework for our plugin system, and if we are already using something like Jersey [3], it would be nice to be able to write web apps using the same technology. This use case is obviously very specific to our situation, but it is the direction I'll likely be taking in the next few months. Don [1] http://www.source-code.biz/MiniTemplator/ [2] https://jsr311.dev.java.net/ [3] https://jersey.dev.java.net/ On Fri, Aug 22, 2008 at 4:31 PM, Frans Thamura [EMAIL PROTECTED] wrote: hi all is it possible that S2 become part of JCP? java server action framework right now only component framework there any idea? -- -- Frans Thamura Meruvian Foundation Mobile: +62 855 7888 699 Linkedin: http://www.linkedin.com/in/fthamura Training JENI, Medallion (Alfresco, Liferay dan Compiere).. buruan... URL: http://nagasakti.mervpolis.com/roller/mervnews/entry/jeni_training_compiere_dan_alfresco - 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: bamboo
Build is fixed. Turned out to be some weird problem with Maven where its metadata file for plugins was screwed up, for some reason. Don On Thu, Aug 21, 2008 at 10:37 AM, Musachy Barroso [EMAIL PROTECTED] wrote: Does any one understand what is broken here? http://opensource.bamboo.atlassian.com/browse/STRUTS-MAIN-906 //I get a cookie every time I break the build 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: [s2] Hurray, we have functional/integration tests
Sure, putting the integration tests into a profile is fine (or vice-versa). They actually take only a few seconds right now, but that could (and hopefully will) grow. Don On Mon, Aug 4, 2008 at 2:49 AM, Wendy Smoak [EMAIL PROTECTED] wrote: On Tue, Jul 29, 2008 at 7:40 AM, Don Brown [EMAIL PROTECTED] wrote: I've started adding functional tests to Struts 2 by adding a few to the REST showcase application, running against Tomcat 5.x, Jetty 6.x, JBoss 4.2.x, and Resin 3.x. The magic happens through a new Maven 2 plugin I developed called maven-itblast-plugin, which enables multiple integration test runs against multiple containers in one go. For more info, see http://github.com/mrdon/maven-itblast-plugin/wikis/home Great idea! It looks like these are running by default. Integration tests take a _long_ time to run. Or, in my case, to fail with some complaint about the tomcat 5.x container. So my defense is... to skip the tests. How do you feel about putting the integration test config in a profile? Actually I'd like to see the profiles in the s2 build reversed so that by default 'mvn install' builds all the code, then you can turn off the apps or plugins if you don't want them. -- Wendy - 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] Hurray, we have functional/integration tests
If you are wanting to know how to use the plugin in your own projects, see the project docs: http://github.com/mrdon/maven-itblast-plugin/wikis/home Don On Mon, Aug 4, 2008 at 2:55 AM, Frans Thamura [EMAIL PROTECTED] wrote: wow' share the step so we can try it here also F On Sun, Aug 3, 2008 at 11:49 PM, Wendy Smoak [EMAIL PROTECTED] wrote: On Tue, Jul 29, 2008 at 7:40 AM, Don Brown [EMAIL PROTECTED] wrote: I've started adding functional tests to Struts 2 by adding a few to the REST showcase application, running against Tomcat 5.x, Jetty 6.x, JBoss 4.2.x, and Resin 3.x. The magic happens through a new Maven 2 plugin I developed called maven-itblast-plugin, which enables multiple integration test runs against multiple containers in one go. For more info, see http://github.com/mrdon/maven-itblast-plugin/wikis/home Great idea! It looks like these are running by default. Integration tests take a _long_ time to run. Or, in my case, to fail with some complaint about the tomcat 5.x container. So my defense is... to skip the tests. How do you feel about putting the integration test config in a profile? Actually I'd like to see the profiles in the s2 build reversed so that by default 'mvn install' builds all the code, then you can turn off the apps or plugins if you don't want them. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Frans Thamura Meruvian Foundation Mobile: +62 855 7888 699 Linkedin: http://www.linkedin.com/in/fthamura Training JENI, Medallion (Alfresco, Liferay dan Compiere).. buruan... URL: http://nagasakti.mervpolis.com/roller/mervnews/entry/jeni_training_compiere_dan_alfresco - 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]
[s2] Broken build....
Musachy, you broke the build: http://opensource.bamboo.atlassian.com/browse/STRUTS-MAIN-900 Does anyone have moderator access to the Struts lists? I'd really like to get the Bamboo messages back on the commits@ list. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Google XML Pages (GXP) to replace Freemarker in tags?
I agree, however, the pain of the piss-poor Maven 2 integration in 7.0.3 is mostly gone in 7.0.4 EAP (Selena). I think just about everyone at Atlassian switched over to it, as you save hours in a day not having to wait while IDEA downloads the Maven world every. single. time. Don On Tue, Jul 29, 2008 at 8:58 PM, Rene Gielen [EMAIL PROTECTED] wrote: Yes, I know, but since I work with IDEA in my daytime job, EAP versions are not acceptable :) Am Mo, 28.07.2008, 18:58, schrieb Brian Pontarelli: 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] -- Rene Gielen | http://it-neering.net/ Aachen | PGP-ID: BECB785A Germany | gielen at it-neering.net - 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] IDEA 7.0.4 EAP sucks a lot less (was Google XML Pages (GXP) to replace Freemarker in tags?)
Yeah, I've found I don't need the idea plugin anymore with Selena. Opening even a complicated, multi-module Maven build only takes a few seconds, as it resolves dependencies and source jars in the background. You can open a project just by opening its pom.xml, which is quite handy for reducing steps to start coding. Glad to see IDEA adopting the Eclipse feature of being able to background stupidly modal processes. Don On Tue, Jul 29, 2008 at 9:48 PM, Rene Gielen [EMAIL PROTECTED] wrote: Yeah, the 7.0.3 maven integration is still not convincing, and in that case 7.0.x EAP is an option, should not be as risky as an 8.0 EAP. I'm still using the maven:idea plugin most of the time, accompanied with a build server it makes your small turnarounds often a lot faster, while keeping all your maven benefits... Am Di, 29.07.2008, 13:10, schrieb Don Brown: I agree, however, the pain of the piss-poor Maven 2 integration in 7.0.3 is mostly gone in 7.0.4 EAP (Selena). I think just about everyone at Atlassian switched over to it, as you save hours in a day not having to wait while IDEA downloads the Maven world every. single. time. Don On Tue, Jul 29, 2008 at 8:58 PM, Rene Gielen [EMAIL PROTECTED] wrote: Yes, I know, but since I work with IDEA in my daytime job, EAP versions are not acceptable :) Am Mo, 28.07.2008, 18:58, schrieb Brian Pontarelli: 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] -- Rene Gielen | http://it-neering.net/ Aachen | PGP-ID: BECB785A Germany | gielen at it-neering.net - 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] -- Rene Gielen | http://it-neering.net/ Aachen | PGP-ID: BECB785A Germany | gielen at it-neering.net - 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]
[s2] Hurray, we have functional/integration tests
I've started adding functional tests to Struts 2 by adding a few to the REST showcase application, running against Tomcat 5.x, Jetty 6.x, JBoss 4.2.x, and Resin 3.x. The magic happens through a new Maven 2 plugin I developed called maven-itblast-plugin, which enables multiple integration test runs against multiple containers in one go. For more info, see http://github.com/mrdon/maven-itblast-plugin/wikis/home Just in creating the integration tests, I found a bug in the REST mapper around the ;jsessionid value in the URI when ran in Jetty 6, and an invalid TLD problem that JBoss 4.2.x picked up, so it has already proven its worth. For the tests, I'm using JWebUnit and HtmlUnit, mainly because that is what we use at work, so I'm familiar with it. The new plugin came about because I was annoyed how much pom XML is required to run integration tests against multiple containers, and even then, you can only run one container at a time in a build, which means lots of Bamboo plans. Soo... next, I plan to add the integration tests to our showcase app, then we can start adding new tests for any new features and/or bug fixes. I know we have Selenium test tickets in JIRA, but from what we've found at Atlassian, Selenium is kind of a pain to setup and write proper tests for, and really, most of what we would want to test would be basic HTML anyways. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Google XML Pages (GXP) to replace Freemarker in tags?
Sure, this wouldn't go in till at least 2.2, but just wanted to see what others thought about it as solution to our tag problem. Don On Sat, Jul 26, 2008 at 4:37 PM, dusty [EMAIL PROTECTED] wrote: Sounds good to me, but is it just the latest and greatest? Should we wait a bit and get some of the other stuff ready and out in the wild? 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] -- View this message in context: http://www.nabble.com/-s2--Google-XML-Pages-%28GXP%29-to-replace-Freemarker-in-tags--tp18663215p18663916.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]
[s2] Google XML Pages (GXP) to replace Freemarker in tags?
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]
Re: hacking OGNL and parameter binding
Musachy, you need to mark the box that lets anyone join the review as
a reviewer. As it is now, no one can comment.
Don
On Sat, Jul 19, 2008 at 12:47 AM, Musachy Barroso [EMAIL PROTECTED] wrote:
I opened a code review here:
http://fisheye6.atlassian.com/cru/CR-9
I added a new interface ClearableValueStack, which if implemented will
make the OGNL parameter binding run in a clean context.
musachy
On Thu, Jul 17, 2008 at 5:46 PM, Musachy Barroso [EMAIL PROTECTED] wrote:
I think it would be the same, we would just need to add a method to
ValueStack, to clear the context.
musachy
On Thu, Jul 17, 2008 at 5:32 PM, Chris Pratt [EMAIL PROTECTED] wrote:
Will it be pluggable between the new-and-improved ValueStack and the
OGNL ValueStack so that we can make the transition as painless as
possible?
(*Chris*)
On Thu, Jul 17, 2008 at 2:28 PM, Musachy Barroso [EMAIL PROTECTED] wrote:
Yeah I am set to fix those security holes ;). Doing the change below,
all tests pass, with the exception of some tests in
ParameterInterceptorTest, that need to inject dependencies, and others
that check for the order of the values added to the stack (new context
is created here, so they fail)
+ValueStack emptyStack = valueStackFactory.createValueStack(stack);
+MapString, Object context = emptyStack.getContext();
+((OgnlContext)context).getValues().clear(); /// THIS IS BAD
+ReflectionContextState.setCreatingNullObjects(context, true);
+ReflectionContextState.setDenyMethodExecution(context, true);
+ReflectionContextState.setReportingConversionErrors(context,
true);
+
for (Map.EntryString, Object entry :
acceptableParameters.entrySet()) {
String name = entry.getKey();
Object value = entry.getValue();
@@ -233,7 +265,7 @@
String name = entry.getKey();
Object value = entry.getValue();
try {
-stack.setValue(name, value);
+emptyStack.setValue(name, value);
} catch (RuntimeException e) {
if (devMode) {
String developerNotification =
LocalizedTextUtil.findText(ParametersInterceptor.class,
devmode.notification, ActionContext.getContext().getLocale(),
Developer Notification:\n{0}, new Object[]{
@@ -246,6 +278,9 @@
}
}
}
+stack.getContext().putAll(acceptableParameters);
+
The 2 big things to be addressed are:
1. ((OgnlContext)context).getValues().clear();
I cannot just do context.clear(), because that method not only removes
the values from the stack, but it clears the root, type converter and
other stuff, so we will have to add another clear method to the
OgnlContext, that just clears the values.
2. throwPropertyExceptions which needs to be the same in the new value
stack, but I think it is getting cleared.
what do you guys think?
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
--
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: Bamboo - Broken build
Not sure where the xwork snapshot went, but I deployed it, ran the builds and they are now failing due to Musachy's last commit. Don On Sat, Jul 19, 2008 at 6:12 PM, Nils-Helge Garli Hegvik [EMAIL PROTECTED] wrote: The Struts 2 main builds are currently failing, complaining about a missing xwork 2.1.2-SNAPSHOT dependency. The change from build 883 to 884 when it started to fail was minor and I can't see how that should have caused the failure. I guess something has been removed from a repository somewhere...? Nils-H - 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] Struts 2 OSGi Plugin
On Mon, Jul 14, 2008 at 5:31 PM, Antonio Petrelli [EMAIL PROTECTED] wrote: 2008/7/14 Don Brown [EMAIL PROTECTED]: It all depends on the approach. Currently, JSP's aren't supported and in fact, I doubt they will ever be supported. If tiles can work with Freemarker or Velocity, then I don't see why we couldn't get it working. Currently Tiles can use only JSP and FreeMarker. Then, for the properties of intersection, only FreeMarker is supported with OSGi... Well probably not since the jars of Tiles are not OSGi-compatible. Actually, that bit isn't a problem - we could bundle the tiles jars in the struts 2 tiles plugin and generate the manifest for both automatically. In fact, to get Struts 2 working in an OSGi container, I've had to basically create a bundle containing Struts 2 jars and select dependencies, and I'm finding that the OSGi headers you want basically depends on the deployment strategy you want to take (what plugins are you using, are you bundling freemarker, etc). Don Antonio - 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]
[s2] 72% of the way to a GA 2.1 release...
The Great Struts 2 Bug Hunt is proceeding well, but we need some more volunteers to close out the remaining issues. In particular, we have a lot of Dojo/tag issues, so if anyone can help with those tickets, it would really be appreciated. Check out this reddening chart: https://issues.apache.org/struts/secure/Dashboard.jspa Keep it up! Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Struts 2 OSGi Plugin
The key problem is JSP files cannot be packaged in a JAR, which is the default format of a bundle. The way systems like Sling and Spring Application Platform get around it is by embedding a Tomcat or Jetty instance within the OSGi container, then adding OSGi headers to the war manifest and deploying it as an OSGi bundle. The hybrid approach taking by the OSGi plugin puts an OSGi container in an existing webapp, but doesn't try to run a second application server in OSGi space, therefore JSP's won't work without significantly modifying a JSP compiler, and besides, Sun has basically deprecated JSP's in favor of JSF and even replacing JSP with Facelets in JSP 2.0. Velocity or Freemarker templates are so much easier to develop, test, and debug, so I don't really see the loss. Don On Tue, Jul 15, 2008 at 1:12 PM, alvins [EMAIL PROTECTED] wrote: I would think JSP support would have to be mandatory for wide acceptance?? I know in the alpha plugin you are using is Apache Felix as the OSGi container but Equinox is building in JSP support (they also have a struts example) - http://www.eclipse.org/equinox/server/jsp_support.php. Don Brown-2 wrote: It all depends on the approach. Currently, JSP's aren't supported and in fact, I doubt they will ever be supported. If tiles can work with Freemarker or Velocity, then I don't see why we couldn't get it working. Don -- View this message in context: http://www.nabble.com/-s2--Struts-2-OSGi-Plugin-tp11851951p18457332.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: [s2] Struts 2 OSGi Plugin
It all depends on the approach. Currently, JSP's aren't supported and in fact, I doubt they will ever be supported. If tiles can work with Freemarker or Velocity, then I don't see why we couldn't get it working. Don On Mon, Jul 14, 2008 at 10:36 AM, alvins [EMAIL PROTECTED] wrote: Thanks for that Don - great to hear. I would also be interested to know if it will have Struts tiles support? Any idea when you think this might land? Don Brown wrote: I'm actually in the middle of a pretty large rollout of OSGi as the basis of the new Atlassian (JIRA, Confluence, etc) plugin framework, which uses an embedded Felix, Spring DM, and supporting code to enable the hybrid architecture. I want to get that into shipping versions of several of our products before coming back to this plugin, as I think code that has been extracted from production systems is generally better than that which was dreamed up from nothing. Speaking of dreamed up code, I've also become more aware of the shortcomings of the codebehind plugin, and am looking forward to transitioning to the convention plugin in 2.2. Speaking of 2.2, don't forget to close out 2.1 bugs so we can get that out the door! :) Don -- View this message in context: http://www.nabble.com/-s2--Struts-2-OSGi-Plugin-tp11851951p18435680.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: [s2] Struts 2 OSGi Plugin
I'm actually in the middle of a pretty large rollout of OSGi as the basis of the new Atlassian (JIRA, Confluence, etc) plugin framework, which uses an embedded Felix, Spring DM, and supporting code to enable the hybrid architecture. I want to get that into shipping versions of several of our products before coming back to this plugin, as I think code that has been extracted from production systems is generally better than that which was dreamed up from nothing. Speaking of dreamed up code, I've also become more aware of the shortcomings of the codebehind plugin, and am looking forward to transitioning to the convention plugin in 2.2. Speaking of 2.2, don't forget to close out 2.1 bugs so we can get that out the door! :) Don On Sat, Jul 12, 2008 at 2:44 PM, Musachy Barroso [EMAIL PROTECTED] wrote: There is a service(felix bundle) that polls a directory an install uninstalls bundles, but it is kind of buggy still, that's why it is commented out in the plugin. An interface to upload bundles and install them the would be nice, I was going to work on it but got distracted by the convention plugin :). The spring integration also needs some polishing, and then we need to make it work with the convention plugin, but that's another story. musachy On Fri, Jul 11, 2008 at 11:51 PM, alvins [EMAIL PROTECTED] wrote: Hi Don, I wanted to start working on this where you left off (excellent work btw!). Was thinking of starting with the GUI management to install, uninstall etc. Wanted to make sure there isn't someone already doing this so don't duplicate.. Or if you had any other plans? Alvin btw. sorry I pressed the wrong button so you may get an email Don Brown-2 wrote: At this point, the /bundles directory is only read on startup, however, it wouldn't be too hard to add a polling scanner. The better solution will be to write a GUI that will let you install, uninstall, and upgrade bundles at runtime. Don On 7/30/07, Frank W. Zammetti [EMAIL PROTECTED] wrote: Don, could you clarify something for me? You say Drop the jar into the /WEB-INF/classes/bundles directory and it will automatically be installed when the application starts up ... so if I have a running application, I have to restart it for the deploy to happen... is that restart always going to be necessary, or is that just a side-effect of this being an early release? Frank Don Brown wrote: Writing an OSGi plugin for Struts 2 has been something I've been playing with on and off since I put in place the Struts 2 plugin architecture, and I finally completed an end-to-end functional spike of such a beast. My motivation for a Struts 2 OSGi plugin is to easily allow Struts 2 developers to write their applications such that they can install, upgrade, and uninstall sections of it at a time without restarting or reloading the whole application or application server. Think how nice it would be to install a new admin tool in your public, heavily-used web application without affecting any users, or fixing a critical bug without, again, taking the application down even for a few seconds. The Struts 2 OSGi plugin allows you to separate your application into jars (called bundles), each containing a struts.xml file, Action classes, and Velocity (for now) files. Just by adding a few lines in the jar's manifest.mf: Bundle-Activator: org.apache.struts2.osgi.StrutsActivator Export-Package: com.mycompany.myapp.actions Bundle-Version: 1.0.0 Bundle-SymbolicName: foo.actions The jar is ready to be deployed. Drop the jar into the /WEB-INF/classes/bundles directory and it will automatically be installed when the application starts up. As this was a spike, there are a bunch of limitations and missing features such as: * Only Velocity templates are supported * Application classes, including third-party jars such as Spring, will probably not be available in bundles * No GUI to install, upgrade, and uninstall bundles at runtime * Bundles cannot contain beans or constants (will probably never be allowed) * Most likely improper OSGi usage Still, the code is functional and available in the Struts sandbox: http://svn.apache.org/repos/asf/struts/sandbox/trunk/struts2-osgi-plugin/ One of my side goals in this project is to hide as much of OSGi from the Struts 2 developer as possible, so that bundles will be easy to write and deploy. Therefore, there is probably a lot of OSGi that is hidden, which OSGi experts would lament, but the main goal is to allow Struts actions to be hot deployable, and I think this plugin could make it happen. Don -- copied from my blog post for those too lazy to click links: http://www.jroller.com/mrdon/entry/struts_2_osgi_plugin_spike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: CodeBehind and index action?
No, I don't believe it does. Conventions plugin does, I believe. Don On Sat, Jul 12, 2008 at 11:03 PM, Paul Benedict [EMAIL PROTECTED] wrote: Does the CodeBehind plugin allow me to specify a default action for a directory? So that way I can just do /dir instead of /dir/index.action? I want the directory to load up /index.jsp which is backed by /index.action Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CodeBehind and index action?
Try using a parent package that has a default action defined. Not sure if it'll be inherited, but worth a try. Don On Sat, Jul 12, 2008 at 11:21 PM, Paul Benedict [EMAIL PROTECTED] wrote: Anyway to accomplish this in 2.0? Have you ever did it? Just looking for a quick answer, even if that includes adding action mappings to the config. Paul On Sat, Jul 12, 2008 at 8:13 AM, Don Brown [EMAIL PROTECTED] wrote: No, I don't believe it does. Conventions plugin does, I believe. Don On Sat, Jul 12, 2008 at 11:03 PM, Paul Benedict [EMAIL PROTECTED] wrote: Does the CodeBehind plugin allow me to specify a default action for a directory? So that way I can just do /dir instead of /dir/index.action? I want the directory to load up /index.jsp which is backed by /index.action Paul - 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: Bamboo woes
Well, the maven 1 repository won't be searched by default, so it should be in the central maven 2 repo. I'll have one of the bamboo guys look into it. As for the notifications, I think the messages are getting lost in moderation, but I don't have access to the Struts list moderation to resolve it. Don On Thu, Jul 10, 2008 at 2:54 PM, Wes Wannemacher [EMAIL PROTECTED] wrote: I think it came up before, but isn't bamboo supposed to send us build results? It looks like the last build was failed like two days ago. I didn't notice until Musachy mentioned it on user@ Also, I tried to fix it, but it failed again now with maven trying to resolve the jfreechart artifact. I'm not particularly up with maven repository management, but it looks like the jfreechart jar are sitting on one of the specified repositories - https://maven.atlassian.com/maven1/jfreechart/jars/ If Don's the only one that can look into it, we'll just wait, but if anyone else at Atlassian is watching it'd be great if we can get this working again. -Wes - 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: Getting action extension from a class outside the container
The ActionMapping contains the original extension that request was submitted with. You can retrieve the ActionMapping either via the ServetActionContext or the portlet dispatcher. Don On Mon, Jun 23, 2008 at 7:44 PM, Nils-Helge Garli Hegvik [EMAIL PROTECTED] wrote: Hi! I'm looking at WW-2622 and I need to get the configured action extension for the application. Is there a way to obtain this from a class that is not instantiated by the core container? Nils-H - 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]
[s2] New filter strategy RFC
I've committed a new filter dispatcher strategy that aims to: * Make it crystal clear to users how to deploy Struts * Make it crystal clear to developers what filters are doing what processes * Better enable customizations and overrides by advanced users This first cut is more about tackling the first two issues, and I'd like to get some feedback on them. There are a number of tickets that are caused by buggy and confusing filter dispatchers and their deployments, as well as I have a need to have our dispatch process be more flexible to support things like native operation in OSGi or in a plugin system. You'll notice that there is certainly more code in this new design, however, I'm hoping it is self-documenting, brain-dead code that is easier to read and follow. I've outlined how it would be used in the package Javadocs: Simple Dispatcher filter filter-namestruts2/filter-name filter-classorg.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter/filter-class /filter filter-mapping filter-namestruts2/filter-name url-pattern/*/url-pattern /filter-mapping Deployment with Sitemesh filter filter-namestruts2-prepare/filter-name filter-classorg.apache.struts2.dispatcher.filter.StrutsPrepareFilter/filter-class /filter filter filter-namesitemesh/filter-name filter-classcom.opensymphony.module.sitemesh.filter.PageFilter/filter-class /filter filter filter-namestruts2-execute/filter-name filter-classorg.apache.struts2.dispatcher.filter.StrutsExecuteFilter/filter-class /filter filter-mapping filter-namestruts2-prepare/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namesitemesh/filter-name url-pattern/*/url-pattern /filter-mapping filter-mapping filter-namestruts2-execute/filter-name url-pattern/*/url-pattern /filter-mapping So basically, a one-to-one, filter to usecase mapping. Please take a look at the code as I'd like to get this finalized in the next few days: http://svn.apache.org/viewvc/struts/struts2/trunk/core/src/main/java/org/apache/struts2/dispatcher/filter/ Thanks, Don PS. We are 46% of the way to GA 2.1 release... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RESTful form tags
On Sun, Jun 22, 2008 at 1:46 PM, dusty [EMAIL PROTECTED] wrote: In my UI I have things like s:url/ and s:form/ and s:action/ that are going to need to address resources. The routing system should make it easy for me to both recognize incoming urls and to define rules for outbound url html. Is the answer to create a custom tag library for s:form/ that hides the url details? or use a s:url/ and reference that in s:form. I think making the action param evaluate is moving in the wrong direction, making it even more forced. A centralized REST routing system would be better so that we can just reference it when we need to talk to resources. What would this routing system look like? Ignore how Struts is designed today - how would you want such a system to work? How would you configure it? Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[s2] 2.1.3 is 34% complete...keep it up
The Great Struts Bug Hunt is progressing nicely, with 50 issues closed already. Don't be shy and join in the efforts to close out the remaining 95 issues. Any help, from attaching fixes, to creating repeatable test cases, to just adding in your 2 cents on the issue is appreciated. I put the release health status portlet on our default JIRA dashboard at http://issues.apache.org/struts or you can view it directly at: https://issues.apache.org/struts/secure/RunPortlet.jspa?portletKey=com.sourcelabs.jira.plugin.portlet.releases:releasesdefaultUserType=allprojectid=10030randomproject=falseversionid=21864versionlist=; The list of open issues is here: http://issues.apache.org/struts/secure/IssueNavigator.jspa?reset=truepid=10030fixfor=21864 Here is a nice FAQ on how to help: http://struts.apache.org/helping.html More updates to come... Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] 2.1.3 is 34% complete...keep it up
Cool, done. Don On Sat, Jun 21, 2008 at 2:05 AM, James Holmes [EMAIL PROTECTED] wrote: Don, we can close out WW-2132 once you have some time to up the Struts Annotations dependency. http://issues.apache.org/struts/browse/WW-2132 On Fri, Jun 20, 2008 at 10:36 AM, Don Brown [EMAIL PROTECTED] wrote: The Great Struts Bug Hunt is progressing nicely, with 50 issues closed already. Don't be shy and join in the efforts to close out the remaining 95 issues. Any help, from attaching fixes, to creating repeatable test cases, to just adding in your 2 cents on the issue is appreciated. I put the release health status portlet on our default JIRA dashboard at http://issues.apache.org/struts or you can view it directly at: https://issues.apache.org/struts/secure/RunPortlet.jspa?portletKey=com.sourcelabs.jira.plugin.portlet.releases:releasesdefaultUserType=allprojectid=10030randomproject=falseversionid=21864versionlist=; The list of open issues is here: http://issues.apache.org/struts/secure/IssueNavigator.jspa?reset=truepid=10030fixfor=21864 Here is a nice FAQ on how to help: http://struts.apache.org/helping.html More updates to come... 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]
Re: [S2] trunk build broken since last fix (again)
Fixed. Missing ?string in the template. Don On Sat, Jun 21, 2008 at 2:03 PM, Jeromy Evans [EMAIL PROTECTED] wrote: Anyone know how to work-around this? It's caused by the updated annotation processor: http://opensource.bamboo.atlassian.com/browse/STRUTS-MAIN-851 http://opensource.bamboo.atlassian.com/browse/STRUTS-MAIN-852 [INFO] [ERROR] BUILD ERROR [INFO] [INFO] : [EMAIL PROTECTED] Compilation error. Problem encountered during annotation processing; see stacktrace below for more information. java.lang.RuntimeException: freemarker.core.NonStringException: Error on line 23, column 88 in tag.ftl ... Expecting a string, date or number here, Expression tag.allowDynamicAttributes is instead a freemarker.template.TemplateBooleanModel$1 Rainer Hermanns wrote: Don, I have a workaround fix for the failing build, that I justed commited, but this needs to be reviewed again... o fixing build by commenting old constructor in StrutsSpringObjectFactory o adding missing param to struts-plugin.xml in portlet-plugin cheers, Rainer On Wed, Jun 18, 2008 at 6:44 AM, Rainer Hermanns [EMAIL PROTECTED] wrote: Don, your latest change broke the build as well: http://opensource.bamboo.atlassian.com/build/viewBuildResults.action?buildKey=STRUTS-MAINbuildNumber=846 Work on it now. Btw why are there no more notification mails to our lists with build failure notifications? Dunno, it still seems to be configured correctly. Maybe it is getting stuck in a spam filter or in the moderation queue? Does anyone have the appropriate access? Don cheers, Rainer Hi, the current build from trunk is broken. There are failing tests: http://opensource.bamboo.atlassian.com/browse/STRUTS-MAIN-843 @James Holmes: Since you commited the latest fixes, could you please have a look at the failing unit tests, thanks :) cheers, Rainer Rainer Hermanns aixcept Mariahilfstraße 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] No virus found in this incoming message. Checked by AVG. Version: 8.0.100 / Virus Database: 270.4.0/1506 - Release Date: 17/06/2008 4:30 PM - 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: RESTful form tags
Why not put them in the rest plugin? Don On Sat, Jun 21, 2008 at 12:19 PM, Jeromy Evans [EMAIL PROTECTED] wrote: Is there any interest in creating restful form tags? I've created variations of the s:form tag (create, destroy, index, update) that simply and/or enforce the restful conventions. Basically, the action attribute of s:form is removed and replaced with a resourceURI attribute that understands the convention and context. eg. a create tag knows that if the current uri ends with /pet/editNew then the target URI is /pet (and the resourceURI attribute doesn't need to be specified). I've found them a useful simplification. Eventually the s:action tag also needs to be substituted with one that knows which method to invoke based on the current context. I don't think these belong in the rest plugin as we eventually want to achieve independence of the tag implementation though. Any interest? If not I may just push them onto googlecode. 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]
Re: RESTful form tags
Well, my current thought is we should wait to move tags out until we have a decent replacement. Otherwise, it does users no good and just confuses things. However, you could split the rest plugin into two artifacts - struts2-rest-plugin and struts2-rest-tags We are doing something similar with the osgi plugin. Don On Sat, Jun 21, 2008 at 2:47 PM, Jeromy Evans [EMAIL PROTECTED] wrote: Don Brown wrote: Why not put them in the rest plugin? Well... I thought we planning on moving the S2 tag support out of core into a tags-plugin eventually. Including tags in the rest-plugin will complicate that issue further, won't it? UIBean does come with a lot of coupling baggage. - 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] ParentPackage annotation
The change to allow the annotation at the package level is only in trunk right now and not in the released versions of 2.0.11.1 or 2.1.2. I didn't see that other page, so I'll make a note to update it as well. The 2.x docs are from our very current documentation for the version that is currently in trunk. See http://struts.apache.org/2.0.11.1/docs/zero-configuration.html for the docs for that version (for the most part). Don 2008/6/19 Paweł Wielgus [EMAIL PROTECTED]: Hi all, i'm trying to make use of ParentPackage annotaion and here: http://struts.apache.org/2.x/docs/zero-configuration.html it is sad that i should use it at package-level in package-info.java, but here: http://struts.apache.org/2.x/docs/parentpackage-annotation.html is sad that ParentPackage is class-level I've been trying this out and it looks like ParentPackage is only working when declared at class level. I tried it on 2.0.11.1 and 2.1.2 Some kind of documentation error? Best greetings, Paweł Wielgus.
Re: [S2] trunk build broken since last fix (again)
On Wed, Jun 18, 2008 at 6:44 AM, Rainer Hermanns [EMAIL PROTECTED] wrote: Don, your latest change broke the build as well: http://opensource.bamboo.atlassian.com/build/viewBuildResults.action?buildKey=STRUTS-MAINbuildNumber=846 Work on it now. Btw why are there no more notification mails to our lists with build failure notifications? Dunno, it still seems to be configured correctly. Maybe it is getting stuck in a spam filter or in the moderation queue? Does anyone have the appropriate access? Don cheers, Rainer Hi, the current build from trunk is broken. There are failing tests: http://opensource.bamboo.atlassian.com/browse/STRUTS-MAIN-843 @James Holmes: Since you commited the latest fixes, could you please have a look at the failing unit tests, thanks :) cheers, Rainer Rainer Hermanns aixcept Mariahilfstraße 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] The Great Struts 2.1 Bug Hunt!
As I understand it, we can't up the Struts 1 version due to a backwards-incompatible change made in 1.3.6 or later. If Struts 1 releases a version that we can use without excluding other 1.3.x versions, I'd be happy to make the change. However, from experience, I know getting a GA release of Struts 1 is a rather long process :) Don On Fri, Jun 13, 2008 at 3:54 PM, Al Sutton [EMAIL PROTECTED] wrote: Don, I noticed you bounced the WW-2586 which updated the pom for the struts1 plugin to 1.3.8 from 1.3.5 to be fixed in 2.2.x. Does this mean the intention is not to fix the bug which means that compilation fails if you update the dependency? Al. Don Brown wrote: I officially declare the Struts 2.1 bug hunting season open! In order to ensure a high-quality 2.1 GA release, I've gone through the tickets and assigned most open bugs to the 2.1.3 version: https://issues.apache.org/struts/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=10030fixfor=21864 I'm going to talk to the marketing dept at Atlassian to see if I can't get some sort of prize for people that close more than 10 issues and maybe something for the person who closes the most. If you have any other ideas how to help drive volunteers to this hunt, please chime in. Bottom line: we have been too lax in dealing with incoming bugs, something you'd think we would have learned from Struts 1. Let's focus on fixing these issues so we can get back to the more interesting tasks like REST support, scoping/Web Beans, convention plugin, and OSGi support. 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]
[s2] The Great Struts 2.1 Bug Hunt!
I officially declare the Struts 2.1 bug hunting season open! In order to ensure a high-quality 2.1 GA release, I've gone through the tickets and assigned most open bugs to the 2.1.3 version: https://issues.apache.org/struts/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=10030fixfor=21864 I'm going to talk to the marketing dept at Atlassian to see if I can't get some sort of prize for people that close more than 10 issues and maybe something for the person who closes the most. If you have any other ideas how to help drive volunteers to this hunt, please chime in. Bottom line: we have been too lax in dealing with incoming bugs, something you'd think we would have learned from Struts 1. Let's focus on fixing these issues so we can get back to the more interesting tasks like REST support, scoping/Web Beans, convention plugin, and OSGi support. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.1.2 on Resin
Looks like it wants short-name and uri after display-name. Should be an easy fix. See if you can figure out all the changes needed and file a JIRA ticket. Thanks, Don On Fri, Jun 6, 2008 at 5:03 PM, Chris Pratt [EMAIL PROTECTED] wrote: It appears that the struts-tags.tld doesn't validate on Resin 3.1. When I tried to update my app I get: 500 Servlet Exception jar:file:/C:/Proj/LCARS/webapp/lcars/WEB-INF/lib/struts2-core-2.1.2.jar!/META-INF/struts-tags.tld:6: display-name is an unexpected tag (parent taglib starts at 2). 4: short-names/short-name 5: uri/struts-tags/uri 6: display-nameStruts Tags/display-name 7: description![CDATA[To make it easier to access dynamic data; 8: the Apache Struts framework includes a library of custom tags. Check for duplicate and out-of-order tags. taglib syntax: (@version, @xsi:schemaLocation?, description*, display-name?, icon?, tlib-version, short-name?, uri?, validator?, listener*, tag*, tag-file*, function*, taglib-extension*) Any ideas? (*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: Freemarker 2.3.13
Yeah, as long as nothing breaks, feel free to up dependencies at will. Don On Mon, Jun 2, 2008 at 8:30 PM, Al Sutton [EMAIL PROTECTED] wrote: Guys, I've rolled a patch and put it on https://issues.apache.org/struts/browse/WW-2664, given the FM guys say it gave a 20x speedup in one scenario I think it's probably worth putting it in for the next release :). Al. - 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]
[s2] Towards a stable 2.1.x release
With 2.1.2 beta out the door, I think it is time we consider the branch feature-complete, which means our focus should now be on working out the bugs so we can get a stable, GA-quality 2.1.x release ASAP. I'm going to start going through our tickets and push them around accordingly. At this point, I don't think we have enough active development to necessitate branching trunk, so hopefully the sandbox should be enough for those wanting to try out new features like the Conventions plugin. How does this sound? Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Bring Convention plugin into trunk and deprecate Zero Config
I agree it is important to present a solid convention and REST solution, and am glad you agree backwards-compatibility is important. For Struts developers, they probably don't care what happens, as long as they can drop the right combination of jars into their application and their application continues to work. How we decide to organize it on our end is irrelevant. Now, keep in mind that the earliest this would get into a release is Struts 2.2, and from this discussion, it is obvious that we are a long ways from production-ready, shippable code. With the Struts 2.1.2 beta release, it is implied that branch is feature complete, so I plan to now start the march towards a GA release, but please, do use the sandbox to try out some of these integration ideas. Don On Sun, Jun 1, 2008 at 1:53 AM, dusty [EMAIL PROTECTED] wrote: It is an interesting situation. I think its clear that majority of mind share an momentum on the configuration side is with the Convention plugin. REST is hot and so people are going to want to try an use the REST plugin for action invocation. Ideally, we would want the best of both worlds in a single package to minimize user confusion. Don's point is a valid one, but I also hope that he agrees that its a good thing to somehow combine REST and Convention. I am not so sure that changing how Struts fundamentally works so that we can include more and competing plugins at runtime is a good thing. It is that type of confusion that makes the framework hard for the masses to absorb. I think combining the REST and Convention as a new super config plugin. Keeping the REST plugin separate but dependant on other plugins seems wrong anyhow. The idea of a legacy jar to support existing plugins works I think. Forking REST is not so great but having two complete offerings is better than several incomplete ones. You could even take a look at the Restlet + XWork bridge posted earlier as the REST stack on top of Convention if you wanted. Although my initial thought on that work was cool, but not quite struts-native enough. I just feel like we have been stuck on this issue for a while and with current trends in web frameworks, REST and Convention over Configuration are the two hottest topics these days. Struts should try and present a clear and strong solution as soon as possible and then spread that message. Musachy Barroso wrote: The only conflict between codebehind and convention is on the UnknownHandler. If struts would support multiple UnknownHandler(s), like it supports multiple PackageProvider(s), we wouldn't have a problem at all, and they could be able to co-exist without knowing anything about each other. Given a request and multiple UnknownHandler, the first one that could return an action config would be used. musachy On Fri, May 30, 2008 at 9:39 PM, Don Brown [EMAIL PROTECTED] wrote: On Thu, May 29, 2008 at 7:21 AM, dusty [EMAIL PROTECTED] wrote: So lets do it and consolidate all of the configuration automation into Convention. We can get the new Convention and REST in 2.1.3-SNAPSHOT and then update the Codebehind page that its being absorbed into Convention. I say the new version of Convention doesn't have to support Codebehind if its going to hold back the Convention code base. I disagree, because if we just switched the rest plugin to use the Convention plugin, we'd be screwing existing apps that use either the Codebehind or REST plugin, of which I personally know several. At the very least, the Conventions plugin should support Codebehind applications via a separate conventions-legacy.jar project. We need to be much better about not making backwards-incompatible changes for our users, as one could argue that was Struts 1's greatest strength and secret to much of its success. Don - 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] -- View this message in context: http://www.nabble.com/-VOTE--Bring-Convention-plugin-into-trunk-and-deprecate-Zero-Config-tp17222798p17576647.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]
[s2] 2.1 to 2.5 Roadmap discussions
Struts 2 desperately needs a public roadmap, IMO, so here's a quick strawman to get the discussion started: Struts 2.1 * New plugins: REST, Dojo, DWR, Portlet, JUnit, and TestNG * Internal API cleanups Struts 2.2 * Finalize zero configuration strategy with new Conventions plugin o Move REST Plugin over to use Conventions plugin, if necessary o Ensure full legacy support * OSGi Plugin? * Public API Struts 2.5 * 2.5 and not 2.3 to reflect important changes in xwork o Guice 1.0 o Reworked localization * JSR 303 (Bean Validation) support * Built-in command line tool like Grails I'm mirroring the proposal on this wiki page: http://cwiki.apache.org/confluence/display/S2WIKI/2.1+to+2.5+Roadmap Also keep in mind, what we can do is very much constrained by who volunteers to do the work. Most of what is on the strawman are features that Rainer, Rene, or I have already indicated we plan on working on. Still, don't hesitate to throw out ideas that may inspire someone to take them up. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: classpath scanner
On Fri, May 30, 2008 at 7:09 PM, Adam Hardy [EMAIL PROTECTED] wrote: jarjar'ing the dependency? What does that mean? I hope I'm not the only one who isn't hip to the lingo! I guess if I knew the context better I could work it out. jarjar is a tool that repackages a dependency in a jar by renaming its packages so that it won't conflict with another version in the classpath. http://code.google.com/p/jarjar/ 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? Actually, this Maven era is more like shining the light on an ugly, moldy dark corner of the basement. It also highlights the need, IMO, for a module system in Java, because if you think about it, only XWork really needs to have access to ASM, so jarjar can make that happen. A user shouldn't have to worry about using a different version of ASM in their application. I believe a library should stay out of your way and impose as little of itself as possible. Libraries should be enablers, not constrictors. 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]
Re: [VOTE] Bring Convention plugin into trunk and deprecate Zero Config
On Thu, May 29, 2008 at 7:21 AM, dusty [EMAIL PROTECTED] wrote: So lets do it and consolidate all of the configuration automation into Convention. We can get the new Convention and REST in 2.1.3-SNAPSHOT and then update the Codebehind page that its being absorbed into Convention. I say the new version of Convention doesn't have to support Codebehind if its going to hold back the Convention code base. I disagree, because if we just switched the rest plugin to use the Convention plugin, we'd be screwing existing apps that use either the Codebehind or REST plugin, of which I personally know several. At the very least, the Conventions plugin should support Codebehind applications via a separate conventions-legacy.jar project. We need to be much better about not making backwards-incompatible changes for our users, as one could argue that was Struts 1's greatest strength and secret to much of its success. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: classpath scanner
xbean-finder is already split into a common library, just it is part of the xbean project rather than commons. From a technical level, there is no difference. The reason we want to copy the code over has less to do with the project's stability but the desire to have fewer dependencies. Don On Thu, May 29, 2008 at 4:03 PM, Al Sutton [EMAIL PROTECTED] wrote: How about talking to the author about splitting it into a commons library? This would give the usual benefits of propogating bug fixes and avoid duplicate work on divergent code bases. Al. 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 musachy - 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
Hmm...this should really be another thread, but there is a much better solution for classpath scanning - xbean-finder. It is a small library used by OpenEJB and Geronimo, three classes, that scans the classpath, but uses a technique that doesn't require the class to be loaded into memory. As a result, it uses less resources and is much faster. http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/ Don On Wed, May 28, 2008 at 12:18 AM, Musachy Barroso [EMAIL PROTECTED] wrote: You are right and I am confused with another problem, if your action is: action -actions.MyCoolAction (@ResultPath(/)) result - /my-cool.ftl what you get is a bunch of (with different jars) SEVERE: Unable to scan [C:\Program Files\apache-tomcat-6.0.16\lib\catalina.jar] for resources java.lang.IllegalArgumentException: Unable to make a URL . Caused by: java.net.MalformedURLException: no protocol: /catalina-ha.jar .. At some point I did get NoClassDefFoundError, like Dusty mentioned, but I can't replicate it, so I will this.shutUp() for now :) musachy On Tue, May 27, 2008 at 9:36 AM, Brian Pontarelli [EMAIL PROTECTED] wrote: Musachy Barroso wrote: The scanning doesn't have anything to do with the location of the JSP files. It is entirely based on the set of package locators and exclude packages. It uses the classpath scanning mechanism that simply opens all the JAR files and looks at them. It only loads a class into the JVM if it is in a correctly named package that is not excluded. No, what I meant is, if you have your templates under root, like in rest-showcase and you add: @ResultPath(/) then it will scan the whole classpath(unless like you said, the package locators are modified), which can cause some trouble. This still shouldn't matter. You shouldn't need to change the package locators to find templates. The ResultPath and all the template configuration is used elsewhere and separate. I keep my templates in WEB-INF/content and my actions are in *actions*, but this is completely arbitrary. Even if you place your templates in /, you can still have a locator like actions and exclude packages however you need. All that is necessary is that the namespace of the action and the result are matched. Therefore you could do this: action -com.example.actions.someNamespace.MyCoolAction result - /some-namespace/my-cool.ftl This works fine and the locator and exclude packages hasn't been modified. Unless I'm missing something, you case should be easy to fix. -bp - 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]
Re: [VOTE] Bring Convention plugin into trunk and deprecate Zero Config
My vote is we bring the classes into XWork to replace the existing classpath scanner. Don On Wed, May 28, 2008 at 10:04 AM, Musachy Barroso [EMAIL PROTECTED] wrote: I will check it out. Is this something that another plugin could use or core itself? musachy On Tue, May 27, 2008 at 7:24 PM, Don Brown [EMAIL PROTECTED] wrote: Hmm...this should really be another thread, but there is a much better solution for classpath scanning - xbean-finder. It is a small library used by OpenEJB and Geronimo, three classes, that scans the classpath, but uses a technique that doesn't require the class to be loaded into memory. As a result, it uses less resources and is much faster. http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/ Don On Wed, May 28, 2008 at 12:18 AM, Musachy Barroso [EMAIL PROTECTED] wrote: You are right and I am confused with another problem, if your action is: action -actions.MyCoolAction (@ResultPath(/)) result - /my-cool.ftl what you get is a bunch of (with different jars) SEVERE: Unable to scan [C:\Program Files\apache-tomcat-6.0.16\lib\catalina.jar] for resources java.lang.IllegalArgumentException: Unable to make a URL . Caused by: java.net.MalformedURLException: no protocol: /catalina-ha.jar .. At some point I did get NoClassDefFoundError, like Dusty mentioned, but I can't replicate it, so I will this.shutUp() for now :) musachy On Tue, May 27, 2008 at 9:36 AM, Brian Pontarelli [EMAIL PROTECTED] wrote: Musachy Barroso wrote: The scanning doesn't have anything to do with the location of the JSP files. It is entirely based on the set of package locators and exclude packages. It uses the classpath scanning mechanism that simply opens all the JAR files and looks at them. It only loads a class into the JVM if it is in a correctly named package that is not excluded. No, what I meant is, if you have your templates under root, like in rest-showcase and you add: @ResultPath(/) then it will scan the whole classpath(unless like you said, the package locators are modified), which can cause some trouble. This still shouldn't matter. You shouldn't need to change the package locators to find templates. The ResultPath and all the template configuration is used elsewhere and separate. I keep my templates in WEB-INF/content and my actions are in *actions*, but this is completely arbitrary. Even if you place your templates in /, you can still have a locator like actions and exclude packages however you need. All that is necessary is that the namespace of the action and the result are matched. Therefore you could do this: action -com.example.actions.someNamespace.MyCoolAction result - /some-namespace/my-cool.ftl This works fine and the locator and exclude packages hasn't been modified. Unless I'm missing something, you case should be easy to fix. -bp - 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] -- 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: [VOTE] Bring Convention plugin into trunk and deprecate Zero Config
That's not a problem, particularly if we jarjar the dependency in the xwork jar. Don On Wed, May 28, 2008 at 10:12 AM, Musachy Barroso [EMAIL PROTECTED] wrote: It depends on ASM musachy On Tue, May 27, 2008 at 8:07 PM, Don Brown [EMAIL PROTECTED] wrote: My vote is we bring the classes into XWork to replace the existing classpath scanner. Don On Wed, May 28, 2008 at 10:04 AM, Musachy Barroso [EMAIL PROTECTED] wrote: I will check it out. Is this something that another plugin could use or core itself? musachy On Tue, May 27, 2008 at 7:24 PM, Don Brown [EMAIL PROTECTED] wrote: Hmm...this should really be another thread, but there is a much better solution for classpath scanning - xbean-finder. It is a small library used by OpenEJB and Geronimo, three classes, that scans the classpath, but uses a technique that doesn't require the class to be loaded into memory. As a result, it uses less resources and is much faster. http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/ Don On Wed, May 28, 2008 at 12:18 AM, Musachy Barroso [EMAIL PROTECTED] wrote: You are right and I am confused with another problem, if your action is: action -actions.MyCoolAction (@ResultPath(/)) result - /my-cool.ftl what you get is a bunch of (with different jars) SEVERE: Unable to scan [C:\Program Files\apache-tomcat-6.0.16\lib\catalina.jar] for resources java.lang.IllegalArgumentException: Unable to make a URL . Caused by: java.net.MalformedURLException: no protocol: /catalina-ha.jar .. At some point I did get NoClassDefFoundError, like Dusty mentioned, but I can't replicate it, so I will this.shutUp() for now :) musachy On Tue, May 27, 2008 at 9:36 AM, Brian Pontarelli [EMAIL PROTECTED] wrote: Musachy Barroso wrote: The scanning doesn't have anything to do with the location of the JSP files. It is entirely based on the set of package locators and exclude packages. It uses the classpath scanning mechanism that simply opens all the JAR files and looks at them. It only loads a class into the JVM if it is in a correctly named package that is not excluded. No, what I meant is, if you have your templates under root, like in rest-showcase and you add: @ResultPath(/) then it will scan the whole classpath(unless like you said, the package locators are modified), which can cause some trouble. This still shouldn't matter. You shouldn't need to change the package locators to find templates. The ResultPath and all the template configuration is used elsewhere and separate. I keep my templates in WEB-INF/content and my actions are in *actions*, but this is completely arbitrary. Even if you place your templates in /, you can still have a locator like actions and exclude packages however you need. All that is necessary is that the namespace of the action and the result are matched. Therefore you could do this: action -com.example.actions.someNamespace.MyCoolAction result - /some-namespace/my-cool.ftl This works fine and the locator and exclude packages hasn't been modified. Unless I'm missing something, you case should be easy to fix. -bp - 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] -- 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]
[RESULT] Struts 2.1.2 test build
The Struts 2.1.2 vote has passed with the following results: +1 Beta: 5 binding, three non-binding +1 Beta: 1 binding I'm moving the release files over to the mirrors now and will announce the public release in 24 hours (or so). Don On Fri, May 2, 2008 at 3:12 PM, Don Brown [EMAIL PROTECTED] wrote: The Struts 2.1.2 test build is now available. Release notes: * http://struts.apache.org/2.x/docs/version-notes-212.html Distribution: * http://people.apache.org/builds/struts/2.1.2/ Maven 2 staging repository: * http://people.apache.org/builds/struts/2.1.2/m2-staging-repository/ Once you have had a chance to review the test build, please respond with a vote on its quality: [ ] Leave at test build [ ] Alpha [ ] Beta [ ] General Availability (GA) Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and more +1s than -1s. The vote will remain open for at least 72 hours, longer upon request. A vote can be amended at any time to upgrade or downgrade the quality of the release based on future experience. If an initial vote designates the build as Beta, the release will be submitted for mirroring and announced to the user list. Once released as a public beta, subsequent quality votes on a build may be held on the user list. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is documentation single sourcing really the holy grail?
On Mon, May 19, 2008 at 3:43 PM, Chase [EMAIL PROTECTED] wrote: From the point of view of someone functioning in the role of a documentation maintainer what would the benefit of the snippet macro be? If we actually had one or more active documentation maintainers, I'd be happy to hand over the keys and let them have their way with the docs. As it is now, the problem is not one of technology, but one of people. Most, if not all, of the documentation team are committers, so the snippet plugin lets them make the best use of their limited time. If we had another group of active, dedicated volunteers, they would be free to fix the docs as they deem best. As we say at apache, those who do the work make the rules ... or something like that :) Don -Matthieu Chase Heimer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Bring Convention plugin into trunk and deprecate Zero Config
Has any work been done to support existing zero config applications with this new plugin? If not, I'd kinda consider that a blocker (-1) because a sufficiently flexible configuration system should be able to support multiple conventions. Also, someone will have to sign up to convert the REST plugin, which currently depends on the codebehind plugin. If backwards-compatibility and REST plugin migration are resolved, I'd vote +0 Don On Wed, May 14, 2008 at 1:39 PM, Musachy Barroso [EMAIL PROTECTED] 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 -- 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: Convention Plugin Status
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]
Re: commercial: paying for work on features
I think this is a great idea, Jeromy. The only place I think you'd need to be careful is ensuring that you own the copyright for the code you produce, so it can be properly contributed to the ASF. Other than that, go nuts. Don On Tue, May 6, 2008 at 9:39 PM, Jeromy Evans [EMAIL PROTECTED] wrote: Each week I try to make some voluntary contribution to an open source project through support or coding. As I have my own business though I must resist the temptation to do more for Struts2 as when I do I directly neglect some other priority. Often the consequence is that I contribute code in areas that direct benefit me and issues of importance to the community are missed. Given that I'd like to do more but often can't justify it, I was wondering whether it's appropriate for an individual or business to attempt to raise funding for the direct improvement of struts2? For example, the Struts2 tags for Dojo 1.1 are one of the most frequently requested improvements. I have both the skills and the time required to create them, but as I don't need Dojo support myself I cannot justify the effort. If I could raise some funding for the work though I certainly would do it and I suspect there are some progressive businesses out there that would appreciate the cost/benefit. The crucial point here is that I'm not talking about donations to Apache; rather I'm talking about individuals or businesses soliciting funding to perform work on Struts2. Personally I'd hate to see emails in struts-users from Joe Everyman soliciting funding (I'll fix that bug it if you pay me $50 on paypal), but on the other hand there seems to be a missed opportunity to improve Struts2 here. How does the PMC feel about this and what are the implications? regards, 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]
[s2] Release feedback
Ok, so this time, it took probably two hours to generate the release all told. The guide is now pretty accurate, but the steps themselves can take quite a while. This time, I copied my keys, m2 config, etc. over to a server in the US and ran the release from there, and boy, what a difference that made. If anyone else wants to get involved in releases, I'm hoping to get them out every few weeks or so, so feel free to jump in. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.1.2 test build
On Fri, May 2, 2008 at 3:12 PM, Don Brown [EMAIL PROTECTED] wrote: [ ] Leave at test build [ ] Alpha [X] Beta [ ] General Availability (GA) I don't think it is stable enough for a GA (and there are apparent licensing issues I guess), but I think it is good enough to be BETA and to get into our user's hands for more testing. Unless there are huge legal issues or show-stopping stability problems, we need to be getting these releases out to our community or we will never get a GA build. Remember, beta means it is feature complete but there are known issues, and I think that is what we have here. Don o Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and more +1s than -1s. The vote will remain open for at least 72 hours, longer upon request. A vote can be amended at any time to upgrade or downgrade the quality of the release based on future experience. If an initial vote designates the build as Beta, the release will be submitted for mirroring and announced to the user list. Once released as a public beta, subsequent quality votes on a build may be held on the user list. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
