RE: [proposal] Tag reorganization
We are using 2.0.1 and we are using form/div with ajax based theme. Is it going to be major problem for us to migrate to new tags. If so what are you recommendations, we are in process of building and only half way through. I don't want to create 250 screens with tags that are going to be outdated by the time we release the app. - Shekhar -Original Message- From: Ian Roughley [mailto:[EMAIL PROTECTED] Sent: Thursday, December 28, 2006 7:36 AM To: Struts Developers List Subject: Re: [proposal] Tag reorganization I'm torn - I like the fact that we are getting the ajax code out of the base, but especially for webwork-s2 upgrades there is going to be more work. The other thing is that 2.0.2 is still beta, and frankly I don't think there is that many people using the tags at the moment, so this would be a good time to make the change. /Ian David H. DeWolf wrote: That's what I'm imagining too. . .and we're agreeing that this incompatibility is a pill we have to swallow. Ian Roughley wrote: I think I am missing something here - how will the tags be invoked? It will need to be a new tld with a new name space, right? Something like dojo:select ... / rather than s:select theme=ajax ... / - so there will be a compatibility issue, but all the functionality will be moved forward. /Ian David H. DeWolf wrote: Ted Husted wrote: Don mentioned a separate tag library, so that would indicate another prefix, but there'd be no reason why the internal tag syntax would change. To keep the codebase manageable, I believe we do need to make this change, and I'd rather make it now while we are in our first beta series than after the first Struts 2 GA. The plugin model might also open the door to other AJAX implementations of the same tags. I agree. I like it, but just wanted to make sure we think through the compatibility changes before we make a decision. In essence we're saying that this change is more important than backwards compat of this one tag and we're willing to live with those repercussions. I'm on board with that. -T. On 12/27/06, David H. DeWolf [EMAIL PROTECTED] wrote: Ok, as long as we keep the tag prefixes and tag names once they are abstracted from the plugin. At one point we talked about having a simple version which is extended by the dojo version and added additional (dojo-specific) featuers. It seems like the current names would be more likely be used for the core tags - not the dojo-enhanced ones. Ted Husted wrote: A struts-dojo plugin shouldn't change the tag syntax. It should just be a matter of adding the JAR, as we do for Spring, and JasperReports, and Tiles, so forth. On 12/27/06, David H. DeWolf [EMAIL PROTECTED] wrote: Nope, that's the one I'm talking about. I got the impression we were going to keep it as is and thus break backwards compatibility in 2.0.2 -- and then mess with it again it when we create the plugin. . . David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: OGNL performance detrimental to Struts 2
We are also seeing very bad performance and I can not say for sure if it is OGNL or something else. Is there an easy way for us to say it is not OGNL. Because if it is OGNL then I would be very interested in seeing some solution for it... because we are planning to go production on this system and by hook or crook we have to solve the performance issue.. -Original Message- From: David H. DeWolf [mailto:[EMAIL PROTECTED] On Behalf Of David H. DeWolf Sent: Monday, December 18, 2006 6:32 PM To: Struts Developers List Subject: Re: OGNL performance detrimental to Struts 2 I double dare you :) Don Brown wrote: Well, I dare you then: http://issues.apache.org/struts/browse/WW-1566 :) Don Chris Brock wrote: Don't dare me. I'm pretty ambitious. I wrote MVEL 1.0 in three days. Don Brown-2 wrote: I'd like it to be possible for a Struts developer to swap in a new EL, perhaps MVEL, if they didn't like OGNL for some reason. If you can create a patch to make that happen, I would consider it my early Christmas present :) Don Chris Brock wrote: Why do you think it would be so terribly difficult? What does MVEL not support that is currently supported by OGNL that would not be fixable by a few tweaks to MVEL's syntax? Generally, MVEL's API architecture follows the same pattern as OGNL, supports type coercion, conversion, projections, etc. Not to mention that MVEL is now an active project and OGNL is not, and of course the performance advantage in MVEL which is only getting better by the day. Don Brown-2 wrote: If you can find a way to completely replace OGNL by MVEL, I'd be very interested to see it. :) Don Chris Brock wrote: I think the problem is that the Tapestry solution is simply a property accessor package, which doesn't really meet the needs of the established WebWork community which relies on expressions in addition to properties to accomplish tasks. That being said, my project (MVEL) stands willing to step in and assist. I think it's performance and flexibility speak for itself: http://wiki.mvflex.org/index.php?title=MVFLEX_Expression_Language Jessek wrote: I'm still not getting all of the hand wringing that is going on in this thread about ognl. There is what I think a perfectly reasonable solution that will help finish up those last remaining bits that ognl needs to really be production ready. Despite whatever we want to call it you could theoretically view it as just another interpreter. I may be from an enemy project but I'm still willing/able to make the changes necessary for this to work. I've tried on a few occasions to engage whoever I can in the ognl world to make this possible but haven't gotten any good responses yet. This isn't a hard problem to solve, so it's frustrating watching everyone implement new property path interpreters /debate ognl when the answer is right there... ;/ Don Brown wrote: I wrote a simple Struts 2 TemplateEngine that renders tags in pure Java, as opposed to the Freemarker that is used currently. I'm seeing performance improvements between 3 and 4 times faster than the old tags. This engine is based on the design I layed out previously [1]. It is better suited to simple tag rendering where the Freemarker version is better suited for HTML-heavy tag output and customization. The Java engine: - Allows the tag generator and interceptors to deal with tag objects, not pure text - Tag interceptors or handlers have full control over the output - Serialization of tag objects into text can be customized - Is fast - 3 to 4 times faster than the Freemarker engine Anyways, if nothing else, it shows there are things we can do to drastically speed up the tags w/o throwing out OGNL. If you only use the simple theme, this might be an attractive option that gives you more customization and speed. I'm kinda up in the air as to where to put this. I'm leaning toward committing it to the sandbox as then it would be clear it is experimental, especially since not all tags and themes are implemented. Don [1] - http://www.mail-archive.com/dev@struts.apache.org/msg25065.html On 12/13/06, Don Brown [EMAIL PROTECTED] wrote: Very interesting... I wonder how much of the performance hit was due to Freemarker and how much OGNL. Could you package this application in a war and attach it to a JIRA ticket? I'd love to have it for future comparisons. Don dice wrote: They are my stats Ted. The stats are posted below along with my sample JSP code. I only tried the textfield tag but looking at the ftl and vm files for the other tags I
Re: [proposal] Tag reorganization
If we go the dojo:select ... / from s:select theme=ajax ... / route, then it should be a simple global find and replace. I am surprised at such a large use of the tags though. I've asked more than a couple of times if anyone was using them, and there was never a response. /Ian Shekhar Yadav wrote: We are using 2.0.1 and we are using form/div with ajax based theme. Is it going to be major problem for us to migrate to new tags. If so what are you recommendations, we are in process of building and only half way through. I don't want to create 250 screens with tags that are going to be outdated by the time we release the app. - Shekhar -Original Message- From: Ian Roughley [mailto:[EMAIL PROTECTED] Sent: Thursday, December 28, 2006 7:36 AM To: Struts Developers List Subject: Re: [proposal] Tag reorganization I'm torn - I like the fact that we are getting the ajax code out of the base, but especially for webwork-s2 upgrades there is going to be more work. The other thing is that 2.0.2 is still beta, and frankly I don't think there is that many people using the tags at the moment, so this would be a good time to make the change. /Ian David H. DeWolf wrote: That's what I'm imagining too. . .and we're agreeing that this incompatibility is a pill we have to swallow. Ian Roughley wrote: I think I am missing something here - how will the tags be invoked? It will need to be a new tld with a new name space, right? Something like dojo:select ... / rather than s:select theme=ajax ... / - so there will be a compatibility issue, but all the functionality will be moved forward. /Ian David H. DeWolf wrote: Ted Husted wrote: Don mentioned a separate tag library, so that would indicate another prefix, but there'd be no reason why the internal tag syntax would change. To keep the codebase manageable, I believe we do need to make this change, and I'd rather make it now while we are in our first beta series than after the first Struts 2 GA. The plugin model might also open the door to other AJAX implementations of the same tags. I agree. I like it, but just wanted to make sure we think through the compatibility changes before we make a decision. In essence we're saying that this change is more important than backwards compat of this one tag and we're willing to live with those repercussions. I'm on board with that. -T. On 12/27/06, David H. DeWolf [EMAIL PROTECTED] wrote: Ok, as long as we keep the tag prefixes and tag names once they are abstracted from the plugin. At one point we talked about having a simple version which is extended by the dojo version and added additional (dojo-specific) featuers. It seems like the current names would be more likely be used for the core tags - not the dojo-enhanced ones. Ted Husted wrote: A struts-dojo plugin shouldn't change the tag syntax. It should just be a matter of adding the JAR, as we do for Spring, and JasperReports, and Tiles, so forth. On 12/27/06, David H. DeWolf [EMAIL PROTECTED] wrote: Nope, that's the one I'm talking about. I got the impression we were going to keep it as is and thus break backwards compatibility in 2.0.2 -- and then mess with it again it when we create the plugin. . . David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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]
How to do this with latest Tiles 2 API?
Using the API from Sep 2006 I was able to access externally an attribute from a tiles definition as follows: String sTilesDefName = (String) request.getAttribute(tile_name); TilesContext tilesContext = new ServletTilesContext(session.getServletContext(), request, response); ComponentDefinition componentDefinition = TilesUtil.getDefinition(sTilesDefName, tilesContext); String sMyAtribute = (String) componentDefinition.getAttribute(myAttribute); I can't quite figure out how to do this using the current Tiles 2 API. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Tag reorganization
On top of that, the div, tabbedPanel, anchor and submit tags will have almost no changes (except the redundant beforeLoading and afterLoading which I think we are going to drop). Only the DatePicker and TimePicker will be different. musachy Ian Roughley wrote: If we go the dojo:select ... / from s:select theme=ajax ... / route, then it should be a simple global find and replace. I am surprised at such a large use of the tags though. I've asked more than a couple of times if anyone was using them, and there was never a response. /Ian Shekhar Yadav wrote: We are using 2.0.1 and we are using form/div with ajax based theme. Is it going to be major problem for us to migrate to new tags. If so what are you recommendations, we are in process of building and only half way through. I don't want to create 250 screens with tags that are going to be outdated by the time we release the app. - Shekhar -Original Message- From: Ian Roughley [mailto:[EMAIL PROTECTED] Sent: Thursday, December 28, 2006 7:36 AM To: Struts Developers List Subject: Re: [proposal] Tag reorganization I'm torn - I like the fact that we are getting the ajax code out of the base, but especially for webwork-s2 upgrades there is going to be more work. The other thing is that 2.0.2 is still beta, and frankly I don't think there is that many people using the tags at the moment, so this would be a good time to make the change. /Ian David H. DeWolf wrote: That's what I'm imagining too. . .and we're agreeing that this incompatibility is a pill we have to swallow. Ian Roughley wrote: I think I am missing something here - how will the tags be invoked? It will need to be a new tld with a new name space, right? Something like dojo:select ... / rather than s:select theme=ajax ... / - so there will be a compatibility issue, but all the functionality will be moved forward. /Ian David H. DeWolf wrote: Ted Husted wrote: Don mentioned a separate tag library, so that would indicate another prefix, but there'd be no reason why the internal tag syntax would change. To keep the codebase manageable, I believe we do need to make this change, and I'd rather make it now while we are in our first beta series than after the first Struts 2 GA. The plugin model might also open the door to other AJAX implementations of the same tags. I agree. I like it, but just wanted to make sure we think through the compatibility changes before we make a decision. In essence we're saying that this change is more important than backwards compat of this one tag and we're willing to live with those repercussions. I'm on board with that. -T. On 12/27/06, David H. DeWolf [EMAIL PROTECTED] wrote: Ok, as long as we keep the tag prefixes and tag names once they are abstracted from the plugin. At one point we talked about having a simple version which is extended by the dojo version and added additional (dojo-specific) featuers. It seems like the current names would be more likely be used for the core tags - not the dojo-enhanced ones. Ted Husted wrote: A struts-dojo plugin shouldn't change the tag syntax. It should just be a matter of adding the JAR, as we do for Spring, and JasperReports, and Tiles, so forth. On 12/27/06, David H. DeWolf [EMAIL PROTECTED] wrote: Nope, that's the one I'm talking about. I got the impression we were going to keep it as is and thus break backwards compatibility in 2.0.2 -- and then mess with it again it when we create the plugin. . . David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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
s2 Struts2 maven2 archetype woes
Hello All, Tried out the Struts 2 maven 2 archetype using the directions from: http://cwiki.apache.org/confluence/display/WW/Struts+Maven+Archetype It builds fine , runs tests fine but when I try deploying it I get errors on both Resin 3.0.21 and tomcat 5.5.17 (bundled in netbeans 5.5) : Resin , shows this on webapp startup : 11:59:45.024] java.lang.NullPointerException [11:59:45.024] at org.springframework.core.io.support.PathMatchingResourcePatternResolver.doFindPathMatchingJarResources(PathMatchingResourcePatternResolver.java:339) [11:59:45.024] at org.springframework.core.io.support.PathMatchingResourcePatternResolver.findPathMatchingResources(PathMatchingResourcePatternResolver.java:265) [11:59:45.024] at org.springframework.core.io.support.PathMatchingResourcePatternResolver.getResources(PathMatchingResourcePatternResolver.java:205) [11:59:45.024] at org.springframework.context.support.AbstractApplicationContext.getResources(AbstractApplicationContext.java:667) [11:59:45.024] at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:144) [11:59:45.024] at org.springframework.web.context.support.XmlWebApplicationContext.loadBeanDefinitions(XmlWebApplicationContext.java:126) [11:59:45.024] at org.springframework.web.context.support.XmlWebApplicationContext.loadBeanDefinitions(XmlWebApplicationContext.java:94) [11:59:45.024] at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:89) [11:59:45.024] at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:262) [11:59:45.024] at org.springframework.web.context.support.AbstractRefreshableWebApplicationContext.refresh(AbstractRefreshableWebApplicationContext.java:139) [11:59:45.024] at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:252) [11:59:45.024] at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:190) [11:59:45.024] at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:49) [11:59:45.024] at com.caucho.server.webapp.Application.start(Application.java:1647) changed devmode to equal true in the struts properties and restarted webapp and I get this Struts error report: Main Content Struts Problem Report Struts has detected an unhandled exception: Messages: Element type bean must be declared. File: jar:file:/usr/local/resinData/webapps/mavenprojectclean/WEB-INF/lib/struts2-spring-plugin-2.0.2-SNAPSHOT.jar!/struts-plugin.xml Line number: 8 Column number: 132 struts bean type=com.opensymphony.xwork2.ObjectFactory name=spring class=org.apache.struts2.spring.StrutsSpringObjectFactory / !-- Make the Spring object factory the automatic default -- Stacktraces jar:file:/usr/local/resinData/webapps/mavenprojectclean/WEB-INF/lib/struts2-spring-plugin-2.0.2-SNAPSHOT.jar!/struts-plugin.xml:8:132 com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.loadConfigurationFiles(XmlConfigurationProvider.java:695) com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.init(XmlConfigurationProvider.java:121) com.opensymphony.xwork2.config.impl.DefaultConfiguration.reload(DefaultConfiguration.java:97) com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:46) org.apache.struts2.dispatcher.mapper.DefaultActionMapper.getMapping(DefaultActionMapper.java:238) org.apache.struts2.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:227) com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:70) com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:118) com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52) com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:70) org.apache.struts2.dispatcher.ActionContextCleanUp.doFilter(ActionContextCleanUp.java:118) com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:70) com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:173) com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229) com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:274) com.caucho.server.port.TcpConnection.run(TcpConnection.java:511) com.caucho.util.ThreadPool.runTasks(ThreadPool.java:516) com.caucho.util.ThreadPool.run(ThreadPool.java:442) java.lang.Thread.run(Thread.java:613) Element type bean must be declared. -
Re: OGNL performance detrimental to Struts 2
On 12/29/06, Shekhar Yadav [EMAIL PROTECTED] wrote: We are also seeing very bad performance and I can not say for sure if it is OGNL or something else. Is there an easy way for us to say it is not OGNL. Because if it is OGNL then I would be very interested in seeing some solution for it... because we are planning to go production on this system and by hook or crook we have to solve the performance issue.. Your profiler should tell you pretty quickly how much impact OGNL is having on overall performance in your particular scenario. -- Martin Cooper -Original Message- From: David H. DeWolf [mailto:[EMAIL PROTECTED] On Behalf Of David H. DeWolf Sent: Monday, December 18, 2006 6:32 PM To: Struts Developers List Subject: Re: OGNL performance detrimental to Struts 2 I double dare you :) Don Brown wrote: Well, I dare you then: http://issues.apache.org/struts/browse/WW-1566 :) Don Chris Brock wrote: Don't dare me. I'm pretty ambitious. I wrote MVEL 1.0 in three days. Don Brown-2 wrote: I'd like it to be possible for a Struts developer to swap in a new EL, perhaps MVEL, if they didn't like OGNL for some reason. If you can create a patch to make that happen, I would consider it my early Christmas present :) Don Chris Brock wrote: Why do you think it would be so terribly difficult? What does MVEL not support that is currently supported by OGNL that would not be fixable by a few tweaks to MVEL's syntax? Generally, MVEL's API architecture follows the same pattern as OGNL, supports type coercion, conversion, projections, etc. Not to mention that MVEL is now an active project and OGNL is not, and of course the performance advantage in MVEL which is only getting better by the day. Don Brown-2 wrote: If you can find a way to completely replace OGNL by MVEL, I'd be very interested to see it. :) Don Chris Brock wrote: I think the problem is that the Tapestry solution is simply a property accessor package, which doesn't really meet the needs of the established WebWork community which relies on expressions in addition to properties to accomplish tasks. That being said, my project (MVEL) stands willing to step in and assist. I think it's performance and flexibility speak for itself: http://wiki.mvflex.org/index.php?title=MVFLEX_Expression_Language Jessek wrote: I'm still not getting all of the hand wringing that is going on in this thread about ognl. There is what I think a perfectly reasonable solution that will help finish up those last remaining bits that ognl needs to really be production ready. Despite whatever we want to call it you could theoretically view it as just another interpreter. I may be from an enemy project but I'm still willing/able to make the changes necessary for this to work. I've tried on a few occasions to engage whoever I can in the ognl world to make this possible but haven't gotten any good responses yet. This isn't a hard problem to solve, so it's frustrating watching everyone implement new property path interpreters /debate ognl when the answer is right there... ;/ Don Brown wrote: I wrote a simple Struts 2 TemplateEngine that renders tags in pure Java, as opposed to the Freemarker that is used currently. I'm seeing performance improvements between 3 and 4 times faster than the old tags. This engine is based on the design I layed out previously [1]. It is better suited to simple tag rendering where the Freemarker version is better suited for HTML-heavy tag output and customization. The Java engine: - Allows the tag generator and interceptors to deal with tag objects, not pure text - Tag interceptors or handlers have full control over the output - Serialization of tag objects into text can be customized - Is fast - 3 to 4 times faster than the Freemarker engine Anyways, if nothing else, it shows there are things we can do to drastically speed up the tags w/o throwing out OGNL. If you only use the simple theme, this might be an attractive option that gives you more customization and speed. I'm kinda up in the air as to where to put this. I'm leaning toward committing it to the sandbox as then it would be clear it is experimental, especially since not all tags and themes are implemented. Don [1] - http://www.mail-archive.com/dev@struts.apache.org/msg25065.html On 12/13/06, Don Brown [EMAIL PROTECTED] wrote: Very interesting... I wonder how much of the performance hit was due to Freemarker and how much OGNL. Could you package this application in a war and attach it to a JIRA ticket? I'd love to have it for future comparisons. Don dice wrote: They are my stats Ted. The stats are posted below along with my sample JSP code. I only tried the textfield tag but looking at the ftl and vm files for the other tags I can't see how the results would be any different. Perhaps an interim solution could be to remove the use of
Re: [S2] Parameters Interceptor and Dojo
I attached a patch to WW-1551 that adds a property excludeParams to the params interceptor, taking a comma-delimited list of regular expressions. regards musachy Musachy Barroso wrote: It would be nice to have a filter taking regular expressions. I logged it: WW-1551 musachy Don Brown wrote: Well, we wouldn't want to simply hard-code the removal of that parameter...Isn't there a filter that you can configure it to pull out certain parameters? If not, we should either create one, or add a parameter to the ParametersInterceptor that takes a list of request parameters to automatically filter out. Either way, worth a JIRA ticket :) Don Martin Cooper wrote: On 12/7/06, Musachy Barroso [EMAIL PROTECTED] wrote: To prevent browser caching, Dojo adds a parameter dojo.preventCache with a random value to the request, this results in an exception like: 2006-12-07 09:54:07,916 ERROR (com.opensymphony.xwork2.interceptor.ParametersInterceptor:191) - ParametersInterceptor - [setParameters]: Unexpected Exception catched: Error setting expression 'dojo.preventCache' with value '[Ljava.lang.String;@2130c2' Somebody already mentioned it on the users list, and I saw it today. Given that Dojo is distributed with S2, can we ignore this parameter in the ParametersInterceptor to avoid the exception? I think we have to, at least for now. The parameter name is not currently customisable (although that would make a fine enhancement request for Dojo :). -- Martin Cooper regards 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Is this the appropriate mailing list for questions about the Tiles 2 sandbox project?
Is this the appropriate mailing list for questions about the Tiles 2 sandbox project? I've got some questions about using the most recent snapshot and want to make sure I pose them to the correct group. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is this the appropriate mailing list for questions about the Tiles 2 sandbox project?
On 12/29/06, Stone, Sam [EMAIL PROTECTED] wrote: Is this the appropriate mailing list for questions about the Tiles 2 sandbox project? For now yes. Tiles will soon have its own top-level project and when that happens you can ask questions there. But it will likely be a few weeks before all that is set up. Greg
Re: [proposal] Tag reorganization
I am sorry if I did not see previous notices.
These are typical tags that we are using:-
1. s:a href=${updateListStateURL} theme=ajax
afterLoading=javascript: refreshWidgetContent('listDetails',
'${listDetailsURL}');
s:property value=name/
/s:a
2. !-- form submit --
s:submit id=submit_next cssClass=submit_next
cssStyle=display:none name=submit_next theme=ajax
resultDivId=pageContent/
3. And I am trying to still find stable use for s:div ../ where it
gets updated from onChange event of some other widget say select.
4. s:select.. we want to use ajax but right now we are having issues
with it messing our layout.. so until we fix that we are not using it.
5. We will need tabbedPanel but we have not got there yet, so I don't
know of particular issues the changes might have for us.
So if you are saying that it is going to be simple replace of
s:select.. to dojo:select.. and likewise for all other use cases I
think we will be Ok.
- Shekhar
Musachy Barroso wrote:
On top of that, the div, tabbedPanel, anchor and submit tags will have
almost no changes (except the redundant beforeLoading and
afterLoading which I think we are going to drop). Only the
DatePicker and TimePicker will be different.
musachy
Ian Roughley wrote:
If we go the dojo:select ... / from s:select theme=ajax ... /
route, then it should be a simple global find and replace.
I am surprised at such a large use of the tags though. I've asked
more than a couple of times if anyone was using them, and there was
never a response.
/Ian
Shekhar Yadav wrote:
We are using 2.0.1 and we are using form/div with ajax based theme. Is
it going to be major problem for us to migrate to new tags. If so what
are you recommendations, we are in process of building and only half
way
through. I don't want to create 250 screens with tags that are going to
be outdated by the time we release the app.
- Shekhar
-Original Message-
From: Ian Roughley [mailto:[EMAIL PROTECTED] Sent: Thursday, December
28, 2006 7:36 AM
To: Struts Developers List
Subject: Re: [proposal] Tag reorganization
I'm torn - I like the fact that we are getting the ajax code out of
the base, but especially for webwork-s2 upgrades there is going to
be more work. The other thing is that 2.0.2 is still beta, and
frankly I don't think there is that many people using the tags at
the moment, so this would be a good time to make the change.
/Ian
David H. DeWolf wrote:
That's what I'm imagining too. . .and we're agreeing that this
incompatibility is a pill we have to swallow.
Ian Roughley wrote:
I think I am missing something here - how will the tags be
invoked? It will need to be a new tld with a new name space,
right? Something
like dojo:select ... / rather than s:select theme=ajax ... /
- so there will be a compatibility issue, but all the
functionality will be moved forward.
/Ian
David H. DeWolf wrote:
Ted Husted wrote:
Don mentioned a separate tag library, so that would indicate
another
prefix, but there'd be no reason why the internal tag syntax would
change.
To keep the codebase manageable, I believe we do need to make this
change, and I'd rather make it now while we are in our first beta
series than after the first Struts 2 GA. The plugin model might
also
open the door to other AJAX implementations of the same tags.
I agree. I like it, but just wanted to make sure we think
through the compatibility changes before we make a decision.
In essence we're saying that this change is more important than
backwards compat of this one tag and we're willing to live with
those repercussions. I'm on board with that.
-T.
On 12/27/06, David H. DeWolf [EMAIL PROTECTED] wrote:
Ok, as long as we keep the tag prefixes and tag names once they
are
abstracted from the plugin.
At one point we talked about having a simple version which is
extended
by the dojo version and added additional (dojo-specific)
featuers. It
seems like the current names would be more likely be used for
the core
tags - not the dojo-enhanced ones.
Ted Husted wrote:
A struts-dojo plugin shouldn't change the tag syntax. It
should
just
be a matter of adding the JAR, as we do for Spring, and
JasperReports,
and Tiles, so forth.
On 12/27/06, David H. DeWolf [EMAIL PROTECTED] wrote:
Nope, that's the one I'm talking about. I got the impression
we were
going to keep it as is and thus break backwards compatibility
in 2.0.2
-- and then mess with it again it when we create the plugin. .
.
David
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Re: [tiles2] Tiles TLP next steps
Here's the Infra ticket for Tiles: https://issues.apache.org/jira/browse/INFRA-1083 Greg On Dec 23, 2006, at 3:38 PM, Wendy Smoak wrote: The board meeting minutes take a while to be approved and posted, but Henri mentioned on the incubator list that the Tiles resolution was approved: http://mail-archives.apache.org/mod_mbox/incubator-general/ 200612.mbox/% [EMAIL PROTECTED] I think the next thing to do is open an issue in the infrastructure JIRA project to ask for mailing lists, svn space, etc., etc. Here's the one for Shale: http://issues.apache.org/jira/browse/ INFRA-866 Do we want anything done differently for Tiles? -- 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]
[Struts2] Use a list/array of objects in JSP
For instance if I have an array of objects in my action class: private MyObject[] objects; How can I handle it with JSP? The example below throws an exception s:property value=objects[0].prop1/ s:property value=objects[0].prop2/ s:property value=objects[1].prop1/ s:property value=objects[1].prop2/ Can I manage it with indexed properties? - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=55942messageID=30#30 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
New Struts 2 Plugin Registry
Before Struts 2 goes GA, I think it needs a proper plugin registry that lists not only bundled plugins, but any third-party plugins. Third-party extensions were such an important part of the success of Struts 1, so I think we need to do more to make it easy to publish and find such extensions. Introducing the new Struts 2 Plugin Repository: http://cwiki.apache.org/confluence/display/S2PLUGINS In addition to putting all the plugin docs under one place, this site features a page template [1] to somewhat standardize what to expect when looking for a plugin, and a announcements section to allow plugins hosted elsewhere a place to publish updates. As a registry, its goal is to aggregate plugin docs and announcements in one place, assuming they will be developed and hosted elsewhere. The registry allows any registered users to create pages, post news items, or comment, but only CLA submitters will have more permissions, and Struts committers have full rights. Don [1] http://cwiki.apache.org/confluence/pages/templates/viewpagetemplate.action?pageTemplateId=35key=S2PLUGINS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Is there a documented release process for Struts 2?
Is there a documented release process for Struts 2? How do you create the JARs, sources, javadocs and upload them to a Maven repo? We're using Maven 2 in AppFuse, so I figured we could probably follow a pre-existing solution rather than coming up with our own. Thanks, Matt -- View this message in context: http://www.nabble.com/Is-there-a-documented-release-process-for-Struts-2--tf2897387.html#a8094974 Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is there a documented release process for Struts 2?
On 12/29/06, mraible [EMAIL PROTECTED] wrote: Is there a documented release process for Struts 2? How do you create the JARs, sources, javadocs and upload them to a Maven repo? We're using Maven 2 in AppFuse, so I figured we could probably follow a pre-existing solution rather than coming up with our own. It's a work in progress... http://cwiki.apache.org/WW/creating-and-signing-a-distribution.html The 'mvn deploy' step puts everything in a staging repository. After the vote, we copy it over to another repo (internal to Apache) that gets automatically synced to the central Maven repository. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is there a documented release process for Struts 2?
I'm assuming you use the assembly plugin to create sources and javadocs? What about documentation? It looks like you're using the AutoExport Plugin for Confluence. How are you handling the export documentation process when it comes to releases? Thanks, Matt Wendy Smoak-3 wrote: On 12/29/06, mraible [EMAIL PROTECTED] wrote: Is there a documented release process for Struts 2? How do you create the JARs, sources, javadocs and upload them to a Maven repo? We're using Maven 2 in AppFuse, so I figured we could probably follow a pre-existing solution rather than coming up with our own. It's a work in progress... http://cwiki.apache.org/WW/creating-and-signing-a-distribution.html The 'mvn deploy' step puts everything in a staging repository. After the vote, we copy it over to another repo (internal to Apache) that gets automatically synced to the central Maven repository. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Is-there-a-documented-release-process-for-Struts-2--tf2897387.html#a8095387 Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is there a documented release process for Struts 2?
On 12/29/06, mraible [EMAIL PROTECTED] wrote: I'm assuming you use the assembly plugin to create sources and javadocs? No... that would be done with the source and javadoc plugins. It should be happening when the pre-assembly profile is enabled, but I don't actually see that defined anywhere in the Struts 2 build. It looks like this (from the Struts 1 core module): http://svn.apache.org/repos/asf/struts/struts1/trunk/core/pom.xml (That profile is mis-named. Originally we were just including the -sources and -javadoc jars in the assembly rather than the entire website and full source code with build files.) Unless I'm missing something, the Struts 2 build doesn't produce -sources and -javadoc jars right now. What about documentation? It looks like you're using the AutoExport Plugin for Confluence. How are you handling the export documentation process when it comes to releases? Did you see the notes at the bottom of the wiki page? Ted will have to comment if you have more questions, as far as I know there's the autoexport plugin, then a cron job that zips up the exported site. (Or else he just runs it manually to pick up last minute changes.) That's the docs.zip that the wiki page says to download and include in the distribution. All in all, I'm not so sure the Struts 2 build is a good example. :) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is there a documented release process for Struts 2?
Wendy Smoak-3 wrote: On 12/29/06, mraible [EMAIL PROTECTED] wrote: I'm assuming you use the assembly plugin to create sources and javadocs? No... that would be done with the source and javadoc plugins. It should be happening when the pre-assembly profile is enabled, but I don't actually see that defined anywhere in the Struts 2 build. It looks like this (from the Struts 1 core module): http://svn.apache.org/repos/asf/struts/struts1/trunk/core/pom.xml (That profile is mis-named. Originally we were just including the -sources and -javadoc jars in the assembly rather than the entire website and full source code with build files.) Unless I'm missing something, the Struts 2 build doesn't produce -sources and -javadoc jars right now. What about documentation? It looks like you're using the AutoExport Plugin for Confluence. How are you handling the export documentation process when it comes to releases? Did you see the notes at the bottom of the wiki page? Ted will have to comment if you have more questions, as far as I know there's the autoexport plugin, then a cron job that zips up the exported site. (Or else he just runs it manually to pick up last minute changes.) That's the docs.zip that the wiki page says to download and include in the distribution. All in all, I'm not so sure the Struts 2 build is a good example. :) Do you know know of a better example that uses Confluence for its documentation? Thanks, Matt -- View this message in context: http://www.nabble.com/Is-there-a-documented-release-process-for-Struts-2--tf2897387.html#a8095524 Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
