Re: [s2] Struts 2.0.7 Status
Sounds cool Ted, marked as "fix for fure". Cheers. Ted Husted <[EMAIL PROTECTED]> wrote: We could just change the "Fix For" to future, in case someone wants to try later. Ted. On 3/12/07, tm jee wrote: > Hi guys, > > > OK, we've now cleared out all the 2.0.7 patches from last week, save > > one that might still be sitting on Toby's hard drive :) > > The jira issue for this is at [1]. Would it be possible to not migrate this > to Struts2, cause I am not really sure how to make it a plugin (part of the > code could go into sitemesh plugin, but some code resides in the core of > Struts2). See jira issue for more details. > > If its ok not to port it to struts2, I could close this issue. > > Thx & Cheers. > > > [1] - > https://issues.apache.org/struts/browse/WW-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40518 > > > Ted Husted wrote: OK, we've now cleared out all the 2.0.7 patches from last > week, save > one that might still be sitting on Toby's hard drive :) > > Unfortunately, I won't be able to run through the release gauntlet > tonight, and the rest of the week is booked. If someone else is up for > rolling 2.0.7, please, feel free. Otherwise, I can put it down for the > 17th, and we can call it a St Paddy's day celebration :) > > I will try to lock down the release notes and such tonight, so that we > are otherwise ready to roll. > > -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider.
Re: [s2] Struts 2.0.7 Status
forgotten to mention that the code is already in WebWork svn together with documentation and a showcase example. Details could be found in the jira issue itself. cheers tm jee <[EMAIL PROTECTED]> wrote: Hi guys, > OK, we've now cleared out all the 2.0.7 patches from last week, save > one that might still be sitting on Toby's hard drive :) The jira issue for this is at [1]. Would it be possible to not migrate this to Struts2, cause I am not really sure how to make it a plugin (part of the code could go into sitemesh plugin, but some code resides in the core of Struts2). See jira issue for more details. If its ok not to port it to struts2, I could close this issue. Thx & Cheers. [1] - https://issues.apache.org/struts/browse/WW-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40518 Ted Husted wrote: OK, we've now cleared out all the 2.0.7 patches from last week, save one that might still be sitting on Toby's hard drive :) Unfortunately, I won't be able to run through the release gauntlet tonight, and the rest of the week is booked. If someone else is up for rolling 2.0.7, please, feel free. Otherwise, I can put it down for the 17th, and we can call it a St Paddy's day celebration :) I will try to lock down the release notes and such tonight, so that we are otherwise ready to roll. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Copy addresses and emails from any email account to Yahoo! Mail - quick, easy and free. Do it now... - The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider.
Re: [s2] Struts 2.0.7 Status
Hi guys, > OK, we've now cleared out all the 2.0.7 patches from last week, save > one that might still be sitting on Toby's hard drive :) The jira issue for this is at [1]. Would it be possible to not migrate this to Struts2, cause I am not really sure how to make it a plugin (part of the code could go into sitemesh plugin, but some code resides in the core of Struts2). See jira issue for more details. If its ok not to port it to struts2, I could close this issue. Thx & Cheers. [1] - https://issues.apache.org/struts/browse/WW-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40518 Ted Husted <[EMAIL PROTECTED]> wrote: OK, we've now cleared out all the 2.0.7 patches from last week, save one that might still be sitting on Toby's hard drive :) Unfortunately, I won't be able to run through the release gauntlet tonight, and the rest of the week is booked. If someone else is up for rolling 2.0.7, please, feel free. Otherwise, I can put it down for the 17th, and we can call it a St Paddy's day celebration :) I will try to lock down the release notes and such tonight, so that we are otherwise ready to roll. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Copy addresses and emails from any email account to Yahoo! Mail - quick, easy and free. Do it now...
Re: [S2] XWork Status Quo
Happy new year guys. :-) WebWork just like any other open-source project follows the open-source spirits. It is very much driven by the community itself. Features are often implemented when they are substantial enough, it doesn't matter if it originated from users, commiters or the project leads themself. Discussions are normally done until an agreement reach prior to having them implemented. I'd say opensymphony is very much like ASF minus the rigid rules. Just want to say that from my experience its been both fun and educational at the same time working under the lead of Pat/Jason/Rainer with the community. Jason might be at times a bit harsh at words but he is very much most of the time accurately true. Cheers guys. :-) Don Brown <[EMAIL PROTECTED]> wrote: To fight philosophy with philosophy ;), the goal of Struts 2 has been pretty much the same since we started: to simplify web development to create a more developer-friendly framework. We've been following the Struts Ti plan [1] roughly since late 2005. WebWork was brought on board as it was the perfect, solid and proven framework that these ideas could be built upon. The current driving goal of Struts 2 is to get a GA release out. Yes, we've implemented some pretty core changes and resolved a lot of the rough spots [2] in WebWork 2, and now it is time to get them out to the wider public. Following such progress can be difficult, particularly because of the organization structure of Struts and Apache projects in general. In WebWork, you had two project leads that directed efforts. In Struts, you have a group of committers on the Project Management Committee (PMC), each with an equal voice in determining where the project is going. As expected, each PMC member has their own idea of where the project should go, so direction and conflicts are more difficult to discern and resolve. That said, I'm very confident that we are all on board to get Struts 2 out and make it the best framework available. All I can tell you is to follow the dev mailing list and get involved in the discussions. That is the best way to keep abreast of the changes and directions, as well as move the project to where you want it to go. If you see a change you don't like, speak up! Your voice is just as important as anyone else's, and the more talented people we have behind the project, the better. Don [1] http://wiki.apache.org/struts/StrutsTi [2] http://wiki.apache.org/struts/RoughSpots Alexandru Popescu wrote: > First of all Happy New Year to everyone! and then a bit of a > philosophical email - something related to previous post by Rainer and > something that bothered me for the last couple of months. > > Before the merge, I was spending a lot of my spare time contributing > to WW and on the XWork side along with Rainer, Jason, and occasionally > a couple of more guys. The direction was clear for everybody and > everybody knew where we are heading to. During the merge and > afterwards, I got very confused... I've seen lots of emails in the > form: "hey I've thought about this incredible idea, how does it > sound?... oh by the way I have already implemented it... (and as a > side note it changes everything you knew about the underlying > pieces)". At this point I have stepped back a bit and I have started > to just watch because I HAD NO IDEA where we want to go - and not the > generic answers. There are lots of discussions about alphas, betas, > GAs, etc releases but I haven't seen a single one that would qualify > itself to be promoted to final users. > > Now I see Rainer asking for help and I tend to see the reasons why. > And as always I would be happy to help, but I frankly would like to > see what the intentions are. Because, once again, I would like to > understand why I would put my efforts behind it - and hopefully not > just to create a couple of alphas, betas, etc. > > BR, > > ./alex > -- > .w( the_mindstorm )p. > :: OSS Evangelist :: > > - > 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] Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: [s2] XWork2 release plan
Lmao ;-D Philip Luppens <[EMAIL PROTECTED]> wrote: > > Although the train stops in Aachen, I fear I will > not > > join you there, as Rainer and me will go together > by > > car . But I'm sure we find some time & place in > > Antwerp :) > > Well, you have not that far from aachen to Antwerp. > I personally > efer sipping tasty Weizen in Bordbistro while > watching jammed > A3 whooshing at 300 kph ;) We'll make a call to the train station telling them there's a bomb on the track somewhere - that should keep you stalled for a couple of hours while we enjoy some delicious beer in a pub in Antwerp - smartass ;-) - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=49702&messageID=103495#103495 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: [s2] 2.0.2 release this weekend
Hi Rainer, >Toby, are you still working on the docs? I think there's some changes needed to be done on the current xwork2 docs, there's the new DI introduced lately and I think the docs doesn't take that into account. I think (I am not sure) that the creation of ActionProxy etc. might be different. I could have a look at it again this weekend. :-) I think I will be working on WebWork and XWork-1_2 mostly. There's quite a few bugs report in WebWork lately. Cheers Rainer. Rainer Hermanns <[EMAIL PROTECTED]> wrote: Don and others, regarding the XWork 2.0 release, I only have time to do this either this thursday or later then monday. Haven't had a look at the docs lately, so there might be some things to do. I'll recheck all the other open tasks till tomorrow evening and report back, if thursday could be the xwork 2 release date. Toby, are you still working on the docs? regards, Rainer > Don, I agree with you that a release should be scheduled sometime very > soon. However, at this moment due to the latest changes I would > suggest the following process: > > 1/ tag all dependencies (XWork2, Tiles2, Guice, CodeBehind etc.) > 2/ make a release of the external dependencies (XWork2, Tiles2, Guice) > 3/ document the new things > 4/ make an alpha to be tested/played with at least the committers > 5/ only after these push a beta/ga > > How does this sound to you? > > ./alex > -- > .w( the_mindstorm )p. > > > On 11/21/06, Ted Husted wrote: >> My best vote right now would be Alpha. >> >> I'm trying to get up to speed with all the recent changes, but I >> wouldn't want to put something out there for other people to use until >> I"ve actually used it myself. >> >> -Ted. >> >> >> On 11/20/06, Don Brown wrote: >> > We really, really, really need to get a release out there, even if was >> > determined to be beta. The snapshot system is unpredictable and >> > confusing for potential users, and really, users shouldn't be using >> them >> > anyways as they aren't "official" struts releases. >> > >> > Any showstoppers to a likely beta release? >> > >> > Don >> > >> > PS. I just deployed the snapshots off trunk to maven >> >> - >> 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] Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: Value Stack Question
Hi Mark,
By doing
valueStack.getContext();
we get the valueStack's context (a Map) whose value with "someKey" as its key
is accessible through
<@s.property value="%{#someKey}" />
There's a root in the value stack as well,
valueStack.getRoot();
which is like a stack, I think that's where the action resides.
rgds
Mark Menard <[EMAIL PROTECTED]> wrote: Is there a means of examining the value
stack. I have a very strange
situation where OGNL in my JSP is returning a value from
com.opensymphony.xwork2.ActionContext.parameters on the stack, even though I
have a property with the name on my action class. It's almost like OGNL is
skipping over the property of my action and moving down the stack until it
find my property sitting in the "parameters" Map.
I'd like to be able to dump the stack from top to bottom, listing the names
of the object in the stack, and call toString() and getClass().getName() on
them.
I tried the following in an Interceptor using PreResultListener:
valueStackContext = context.getValueStack().getContext ();
for (Object o : valueStackContext.keySet () ) {
if (o == null) {
System.out.println ("o is null");
} else {
Object value = valueStackContext.get (o);
System.out.println (o.toString() + ": " +
(value == null ? "null" : value.toString () ) );
System.out.println (o.toString() + ": " +
(value == null ? "null" : value.getClass().getName () ) );
}
}
But, I don't see my action on the stack. Stripping out the toString() output
I see the following:
17:35:27,773 INFO [STDOUT] last.bean.accessed: null
17:35:27,773 INFO [STDOUT] struts.actionMapping:
org.apache.struts2.dispatcher.mapper.ActionMapping
17:35:27,773 INFO [STDOUT] com.opensymphony.xwork2.ActionContext.locale:
java.util.Locale
17:35:27,773 INFO [STDOUT] session:
org.apache.struts2.dispatcher.SessionMap
17:35:27,773 INFO [STDOUT] current.property.path: null
17:35:27,773 INFO [STDOUT] attr: org.apache.struts2.util.AttributeMap
17:35:27,773 INFO [STDOUT]
com.opensymphony.xwork2.ActionContext.application:
org.apache.struts2.dispatcher.ApplicationMap
17:35:27,773 INFO [STDOUT] report.conversion.errors: java.lang.Boolean
17:35:27,773 INFO [STDOUT]
com.opensymphony.xwork2.ActionContext.actionInvocation:
com.opensymphony.xwork2.DefaultActionInvocation
17:35:27,773 INFO [STDOUT] last.property.accessed: null
17:35:27,774 INFO [STDOUT] com.opensymphony.xwork2.ActionContext.session:
org.apache.struts2.dispatcher.SessionMap
17:35:27,774 INFO [STDOUT] application:
org.apache.struts2.dispatcher.ApplicationMap
17:35:27,774 INFO [STDOUT]
com.opensymphony.xwork2.ActionContext.parameters: java.util.HashMap
17:35:27,774 INFO [STDOUT] parameters: java.util.HashMap
17:35:27,774 INFO [STDOUT] com.opensymphony.xwork2.ActionContext.name:
java.lang.String
17:35:27,774 INFO [STDOUT] __link: [Ljava.lang.Object;
17:35:27,774 INFO [STDOUT]
com.opensymphony.xwork2.util.ValueStack.ValueStack:
com.opensymphony.xwork2.util.OgnlValueStack
17:35:27,774 INFO [STDOUT] xwork.MethodAccessor.denyMethodExecution:
java.lang.Boolean
17:35:27,774 INFO [STDOUT]
com.opensymphony.xwork2.dispatcher.HttpServletRequest:
org.apache.struts2.dispatcher.StrutsRequestWrapper
17:35:27,774 INFO [STDOUT] xwork.NullHandler.createNullObjects:
java.lang.Boolean
17:35:27,774 INFO [STDOUT]
com.opensymphony.xwork2.ActionContext.conversionErrors: java.util.HashMap
17:35:27,774 INFO [STDOUT]
com.opensymphony.xwork2.dispatcher.ServletContext:
org.apache.catalina.core.ApplicationContextFacade
17:35:27,774 INFO [STDOUT]
com.opensymphony.xwork2.dispatcher.HttpServletResponse:
com.opensymphony.module.sitemesh.filter.PageResponseWrapper
17:35:27,774 INFO [STDOUT] request:
org.apache.struts2.dispatcher.RequestMap
I don't see an instance of my action class, nor an ActionProxy. I do see the
com.opensymphony.xwork2.util.OgnlValueStack. Is that the actual stack that
is used by OGNL to display the view?
Thanks,
Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: [s2] struts-default
sorry for poping this again. Any thoughts on this? :) tm jee <[EMAIL PROTECTED]> wrote: forgotten some stuff in previous post. xwork-default.xml wouldn't be loaded is we are using Struts2, just that with this approach there's 2 files to maintain whenever we introduce new beans etc. (one in struts-default.xml and another in xwork.xml) Or we could use in struts-default.xml, but that would require us to refactor out commons stuff from struts-default.xml plus the disadvantage Don pointed out. I'd prefer the first approach, declare the xwork related beans in xwork-default.xml, since xwork-default.xml already have interceptors etc that are duplicated in struts-default.xml. Thoughts? rgds tm jee wrote: I see. What about duplicating those beans in xwork-default.xml, it is still going to be in struts-default.xml as well. Just such that those who use xwork standalone could do // the will load xwork-default.xml and all the beans required during injection configurationManager.addConfigurationProvider(new XmlConfigurationProvider(xwork-default.xml)); // this will load xwork.xml where custom beans, action, interceptor etc resides configurationManager.addConfigurationProvider(new XmlConfigurationProvider()); This is such that xwork standalone user does need to add those bean manually in their xwork.xml which would need understnading of xwork code base. Thoughts? rgds Don Brown wrote: I thought about that, however, there are two advantages to keeping everything in struts-default.xml: 1. Default implementations for extension points can be named "struts" universally. Otherwise, we'd have to allow two, xwork and struts, or choose a third option. 2. Easier for a new developer to see how struts configures itself. Since we publicize the struts-default, struts-plugin, struts.xml load order, it is less confusing to not have the additional hidden xwork-default.xml I'm open to changing this if there are other good options on the table. Don tm jee wrote: > Hi guys, > > Shouldn't we have the xwork stuff in xwork-default.xml? In struts-default.xml, > > There's some common beans like > > > > > > > ... > > > > > > .. > > > that might be better if moved to xwork-default.xml Am I missing somthing? > > rgds > > > > > > Send instant messages to your online friends http://uk.messenger.yahoo.com > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Send instant messages to your online friends http://uk.messenger.yahoo.com Send instant messages to your online friends http://uk.messenger.yahoo.com Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: [s2] BeanSelectionProvider
Ok. thx :)
Don Brown <[EMAIL PROTECTED]> wrote: Do an svn update...I just fixed that bug
30 minutes ago :)
Don
tm jee wrote:
> Hi guys,
>
> There's some part I don't understand, would be glad if anyone could help me
> understand it better.
>
> In Dispatcher, during init (in init() method),. BeanSelectionProvider is
> being added twice to ConfigurationManager, once during loading config from
> classloader (zero configuration) and another time later in the method. Is
> there a reason behind this?
>
> private void init() {
>
>// Load configuration from a scan of the classloader
> String packages = initParams.get("actionPackages");
> if (packages != null) {
>...
> configurationManager.addConfigurationProvider(new
> BeanSelectionProvider()); // --- (1)
>
> }
>
>configurationManager.addConfigurationProvider(new BeanSelectionProvider());
>.
> }
>
>
> I guess BeanSelectionProvider alias some standard injected beans with
> different key (type, name) through ContainerProperties which the same object
> used throughout registering configuration providers. It seems that (1) is
> redundant. Is this correct or am i missng the point again?
>
> tia
>
> rgds
>
>
>
>
> Send instant messages to your online friends http://uk.messenger.yahoo.com
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease
of use." - PC Magazine
[s2] BeanSelectionProvider
Hi guys,
There's some part I don't understand, would be glad if anyone could help me
understand it better.
In Dispatcher, during init (in init() method),. BeanSelectionProvider is being
added twice to ConfigurationManager, once during loading config from
classloader (zero configuration) and another time later in the method. Is there
a reason behind this?
private void init() {
// Load configuration from a scan of the classloader
String packages = initParams.get("actionPackages");
if (packages != null) {
...
configurationManager.addConfigurationProvider(new
BeanSelectionProvider()); // --- (1)
}
configurationManager.addConfigurationProvider(new BeanSelectionProvider());
.
}
I guess BeanSelectionProvider alias some standard injected beans with different
key (type, name) through ContainerProperties which the same object used
throughout registering configuration providers. It seems that (1) is redundant.
Is this correct or am i missng the point again?
tia
rgds
Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: [s2] struts-default
forgotten some stuff in previous post. xwork-default.xml wouldn't be loaded is we are using Struts2, just that with this approach there's 2 files to maintain whenever we introduce new beans etc. (one in struts-default.xml and another in xwork.xml) Or we could use in struts-default.xml, but that would require us to refactor out commons stuff from struts-default.xml plus the disadvantage Don pointed out. I'd prefer the first approach, declare the xwork related beans in xwork-default.xml, since xwork-default.xml already have interceptors etc that are duplicated in struts-default.xml. Thoughts? rgds tm jee <[EMAIL PROTECTED]> wrote: I see. What about duplicating those beans in xwork-default.xml, it is still going to be in struts-default.xml as well. Just such that those who use xwork standalone could do // the will load xwork-default.xml and all the beans required during injection configurationManager.addConfigurationProvider(new XmlConfigurationProvider(xwork-default.xml)); // this will load xwork.xml where custom beans, action, interceptor etc resides configurationManager.addConfigurationProvider(new XmlConfigurationProvider()); This is such that xwork standalone user does need to add those bean manually in their xwork.xml which would need understnading of xwork code base. Thoughts? rgds Don Brown wrote: I thought about that, however, there are two advantages to keeping everything in struts-default.xml: 1. Default implementations for extension points can be named "struts" universally. Otherwise, we'd have to allow two, xwork and struts, or choose a third option. 2. Easier for a new developer to see how struts configures itself. Since we publicize the struts-default, struts-plugin, struts.xml load order, it is less confusing to not have the additional hidden xwork-default.xml I'm open to changing this if there are other good options on the table. Don tm jee wrote: > Hi guys, > > Shouldn't we have the xwork stuff in xwork-default.xml? In struts-default.xml, > > There's some common beans like > > > > > > > ... > > > > > > .. > > > that might be better if moved to xwork-default.xml Am I missing somthing? > > rgds > > > > > > Send instant messages to your online friends http://uk.messenger.yahoo.com > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Send instant messages to your online friends http://uk.messenger.yahoo.com Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: [s2] struts-default
I see. What about duplicating those beans in xwork-default.xml, it is still going to be in struts-default.xml as well. Just such that those who use xwork standalone could do // the will load xwork-default.xml and all the beans required during injection configurationManager.addConfigurationProvider(new XmlConfigurationProvider(xwork-default.xml)); // this will load xwork.xml where custom beans, action, interceptor etc resides configurationManager.addConfigurationProvider(new XmlConfigurationProvider()); This is such that xwork standalone user does need to add those bean manually in their xwork.xml which would need understnading of xwork code base. Thoughts? rgds Don Brown <[EMAIL PROTECTED]> wrote: I thought about that, however, there are two advantages to keeping everything in struts-default.xml: 1. Default implementations for extension points can be named "struts" universally. Otherwise, we'd have to allow two, xwork and struts, or choose a third option. 2. Easier for a new developer to see how struts configures itself. Since we publicize the struts-default, struts-plugin, struts.xml load order, it is less confusing to not have the additional hidden xwork-default.xml I'm open to changing this if there are other good options on the table. Don tm jee wrote: > Hi guys, > > Shouldn't we have the xwork stuff in xwork-default.xml? In struts-default.xml, > > There's some common beans like > > > > > > > ... > > > > > > .. > > > that might be better if moved to xwork-default.xml Am I missing somthing? > > rgds > > > > > > Send instant messages to your online friends http://uk.messenger.yahoo.com > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Send instant messages to your online friends http://uk.messenger.yahoo.com
[s2] struts-default
Hi guys, Shouldn't we have the xwork stuff in xwork-default.xml? In struts-default.xml, There's some common beans like ... .. that might be better if moved to xwork-default.xml Am I missing somthing? rgds Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: [s2][OT] Guice rocks
Thx for the share of knowledge Konstantin. I'd need to read up about pico to be able to understand more. :) > I looked at javadocs ( there is no real docs besides > it ) and sources, and it looks that it is really new, > and there is not so much there. Yup. Its pretty new. I think the codes are clean and very well written. I like the way it uses the Factory interface as callbacks The uses of generics. Separation of internal and external apis (eg. ExternalContext and Context / InternalContext, Factory vs InternalFactory ). The callbacks are nicely used. Nice extension like FinalizableReferenceQueue that does clean up upon gc. Use of adapters pattern / transformer (hopefully i got this right) like Function. Resolving cyclic dependncy using Proxy etc. :) > I do not like idea of "scope" - it's kind looks > "springy" to me. Scope can be obtained easily by using > container hierarchy ( like nanocontainer does - > it registers 3 container hierarchy with managed > lifecycles, or possibly more like "one container per > directory / package " ) I see. I am more used to the "scope" because of Spring. Pico does have a interesting way of doing things. I guess its like a composite / chain kindof thing, but I'll need to read up about pico to understand more. ;) > There are a lot of such adapters also for remote > access ( just register it with interface and backend > url, and your action gets webservice bean injected > without knowing it ) etc. The same would work with > ejb / jndi lookup or whatever. I see, i guess its something like Spring's FactoryBean/ProxyFactoryBean. I guess in Guice, one could registor a custom factory using ContainerBuilder, but I might be totally wrong. :) Unfortunately I can't make it to JavaPolis. what a pitty. If you decided to have a blog, do let me know. I could be reached at (tm_jee at yahoo dot co do uk). Cheers. rgds Konstantin Priblouda <[EMAIL PROTECTED]> wrote: --- tm jee wrote: > Thx for the reply. If you have any finding, I'd be > glad to learn more about it. I am kindof interested > in this area as well. But i am still a beginner so I > might talk nonsense... :P Well, I'm pretty used to DI / IoC containers ( being pico commiter ;) ) I looked at javadocs ( there is no real docs besides it ) and sources, and it looks that it is really new, and there is not so much there. I do not like idea of "scope" - it's kind looks "springy" to me. Scope can be obtained easily by using container hierarchy ( like nanocontainer does - it registers 3 container hierarchy with managed lifecycles, or possibly more like "one container per directory / package " ) Though this code did not made it into S2 codebase yet pending issue with source headers ( and WW-1370 ), it is usable. Storage of wiring information in annotations is a nice idea, but not really flexible ( Is it posssible to manipulate annotations on a class, or are they bound at compile time? ) Pico uses "component adapters" instead, which can be ( and usually are ) chained to specify some really weird behaviour like: (constructor injection) -> (parameters via setter) -> ( aop) -> (cache/threadlocal) There are a lot of such adapters also for remote access ( just register it with interface and backend url, and your action gets webservice bean injected without knowing it ) etc. The same would work with ejb / jndi lookup or whatever. So, there is definitely no need to invent yet another DI container for xwork unless you have fun of it ;) > Have you got a blog? Maybe blog about your findings > would be nice. I'll definitely subscribe to it. not yet. being a hausmate I'm definitely enitled to one at blogs.codehaus.org, but I did not figured out how to activate it yet ;) If you go to javapolis, we can surely met at dinner ;) regards, [ Konstantin Pribluda http://www.pribluda.de ] Still using XDoclet 1.x? XDoclet 2 is released and of production quality. check it out: http://xdoclet.codehaus.org Sponsored Link Mortgage rates near 39yr lows. $420k for $1,399/mo. Calculate new payment! www.LowerMyBills.com/lre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail.
Re: [s2] WW-1506
Hi guys, I've undo the commit for WW-1506, so the problem will still exists in the latest svn head. Can't seems to figure out a way without doing changes (quite major) to the container /xwork2 api. See jira issue WW-1506 for more info. p/s i might be off for a few days. rgds tm jee <[EMAIL PROTECTED]> wrote: Hi Don, I've reverted the changes on my local box, and tried out with @Inject(required=false), when starting jetty using mvn jetty:run, it seems to be giving me the following stack Should I commit back the reverted changes. Can't figure out a way to fix this without doing changes to the DI Container. 2006-11-15 19:22:43,901 INFO [StrutsSpringObjectFactory.java:94] : ... initialized Struts-Spring integration successfully 2006-11-15 19:22:43.935::WARN: failed action2-cleanup 2006-11-15 19:22:43.935::WARN: failed [EMAIL PROTECTED]/myApp,file:/home/tmjee/development/temp/myApp/src/main/webapp/} 2006-11-15 19:22:43.935::WARN: failed [EMAIL PROTECTED] 2006-11-15 19:22:43.935::WARN: failed [EMAIL PROTECTED] 2006-11-15 19:22:44.162::INFO: Started SelectChannelConnector @ 0.0.0.0:8080 2006-11-15 19:22:44.163::WARN: failed [EMAIL PROTECTED] [INFO] Jetty server exiting. [INFO] [ERROR] FATAL ERROR [INFO] [INFO] org/apache/velocity/context/Context [INFO] [INFO] Trace java.lang.NoClassDefFoundError: org/apache/velocity/context/Context at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2328) at java.lang.Class.getDeclaredConstructors(Class.java:1808) at com.opensymphony.xwork2.inject.ContainerImpl$ConstructorInjector.findConstructorIn(ContainerImpl.java:313) at com.opensymphony.xwork2.inject.ContainerImpl$ConstructorInjector.(ContainerImpl.java:291) at com.opensymphony.xwork2.inject.ContainerImpl$5.create(ContainerImpl.java:277) at com.opensymphony.xwork2.inject.ContainerImpl$5.create(ContainerImpl.java:276) at com.opensymphony.xwork2.inject.util.ReferenceCache$CallableCreate.call(ReferenceCache.java:155) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269) at java.util.concurrent.FutureTask.run(FutureTask.java:123) at com.opensymphony.xwork2.inject.util.ReferenceCache.internalCreate(ReferenceCache.java:81) at com.opensymphony.xwork2.inject.util.ReferenceCache.get(ReferenceCache.java:121) at com.opensymphony.xwork2.inject.ContainerImpl.getConstructor(ContainerImpl.java:534) at com.opensymphony.xwork2.inject.ContainerBuilder$5.create(ContainerBuilder.java:207) at com.opensymphony.xwork2.inject.Scope$2$1.create(Scope.java:49) at com.opensymphony.xwork2.inject.ContainerImpl$ParameterInjector.inject(ContainerImpl.java:407) at com.opensymphony.xwork2.inject.ContainerImpl.getParameters(ContainerImpl.java:422) at com.opensymphony.xwork2.inject.ContainerImpl.access$000(ContainerImpl.java:42) at com.opensymphony.xwork2.inject.ContainerImpl$MethodInjector.inject(ContainerImpl.java:266) at com.opensymphony.xwork2.inject.ContainerImpl$2.call(ContainerImpl.java:95) at com.opensymphony.xwork2.inject.ContainerImpl$2.call(ContainerImpl.java:93) at com.opensymphony.xwork2.inject.ContainerImpl.callInContext(ContainerImpl.java:514) at com.opensymphony.xwork2.inject.ContainerImpl.injectStatics(ContainerImpl.java:92) at com.opensymphony.xwork2.inject.ContainerBuilder.create(ContainerBuilder.java:494) at com.opensymphony.xwork2.config.impl.DefaultConfiguration.reload(DefaultConfiguration.java:139) at com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:52) at org.apache.struts2.dispatcher.Dispatcher.init(Dispatcher.java:339) at org.apache.struts2.dispatcher.Dispatcher.(Dispatcher.java:198) at org.apache.struts2.dispatcher.AbstractFilter.createDispatcher(AbstractFilter.java:153) at org.apache.struts2.dispatcher.AbstractFilter.init(AbstractFilter.java:111) at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:95) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:38) at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:545) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1133) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:420) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:457) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:38) at org.mortbay.jetty.handler
Re: [s2] WW-1506
Hi Don, I've reverted the changes on my local box, and tried out with @Inject(required=false), when starting jetty using mvn jetty:run, it seems to be giving me the following stack Should I commit back the reverted changes. Can't figure out a way to fix this without doing changes to the DI Container. 2006-11-15 19:22:43,901 INFO [StrutsSpringObjectFactory.java:94] : ... initialized Struts-Spring integration successfully 2006-11-15 19:22:43.935::WARN: failed action2-cleanup 2006-11-15 19:22:43.935::WARN: failed [EMAIL PROTECTED]/myApp,file:/home/tmjee/development/temp/myApp/src/main/webapp/} 2006-11-15 19:22:43.935::WARN: failed [EMAIL PROTECTED] 2006-11-15 19:22:43.935::WARN: failed [EMAIL PROTECTED] 2006-11-15 19:22:44.162::INFO: Started SelectChannelConnector @ 0.0.0.0:8080 2006-11-15 19:22:44.163::WARN: failed [EMAIL PROTECTED] [INFO] Jetty server exiting. [INFO] [ERROR] FATAL ERROR [INFO] [INFO] org/apache/velocity/context/Context [INFO] [INFO] Trace java.lang.NoClassDefFoundError: org/apache/velocity/context/Context at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2328) at java.lang.Class.getDeclaredConstructors(Class.java:1808) at com.opensymphony.xwork2.inject.ContainerImpl$ConstructorInjector.findConstructorIn(ContainerImpl.java:313) at com.opensymphony.xwork2.inject.ContainerImpl$ConstructorInjector.(ContainerImpl.java:291) at com.opensymphony.xwork2.inject.ContainerImpl$5.create(ContainerImpl.java:277) at com.opensymphony.xwork2.inject.ContainerImpl$5.create(ContainerImpl.java:276) at com.opensymphony.xwork2.inject.util.ReferenceCache$CallableCreate.call(ReferenceCache.java:155) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269) at java.util.concurrent.FutureTask.run(FutureTask.java:123) at com.opensymphony.xwork2.inject.util.ReferenceCache.internalCreate(ReferenceCache.java:81) at com.opensymphony.xwork2.inject.util.ReferenceCache.get(ReferenceCache.java:121) at com.opensymphony.xwork2.inject.ContainerImpl.getConstructor(ContainerImpl.java:534) at com.opensymphony.xwork2.inject.ContainerBuilder$5.create(ContainerBuilder.java:207) at com.opensymphony.xwork2.inject.Scope$2$1.create(Scope.java:49) at com.opensymphony.xwork2.inject.ContainerImpl$ParameterInjector.inject(ContainerImpl.java:407) at com.opensymphony.xwork2.inject.ContainerImpl.getParameters(ContainerImpl.java:422) at com.opensymphony.xwork2.inject.ContainerImpl.access$000(ContainerImpl.java:42) at com.opensymphony.xwork2.inject.ContainerImpl$MethodInjector.inject(ContainerImpl.java:266) at com.opensymphony.xwork2.inject.ContainerImpl$2.call(ContainerImpl.java:95) at com.opensymphony.xwork2.inject.ContainerImpl$2.call(ContainerImpl.java:93) at com.opensymphony.xwork2.inject.ContainerImpl.callInContext(ContainerImpl.java:514) at com.opensymphony.xwork2.inject.ContainerImpl.injectStatics(ContainerImpl.java:92) at com.opensymphony.xwork2.inject.ContainerBuilder.create(ContainerBuilder.java:494) at com.opensymphony.xwork2.config.impl.DefaultConfiguration.reload(DefaultConfiguration.java:139) at com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:52) at org.apache.struts2.dispatcher.Dispatcher.init(Dispatcher.java:339) at org.apache.struts2.dispatcher.Dispatcher.(Dispatcher.java:198) at org.apache.struts2.dispatcher.AbstractFilter.createDispatcher(AbstractFilter.java:153) at org.apache.struts2.dispatcher.AbstractFilter.init(AbstractFilter.java:111) at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:95) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:38) at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:545) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1133) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:420) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:457) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:38) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:156) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:120) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:38) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:156) at org.
Re: [s2] WW-1506
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:38) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:119) at org.mortbay.jetty.Server.doStart(Server.java:210) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:38) at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:134) at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:327) at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:272) at org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:177) at org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:183) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] [INFO] Total time: 11 seconds [INFO] Finished at: Wed Nov 15 19:22:44 EST 2006 [INFO] Final Memory: 6M/12M [INFO] 2006-11-15 19:22:44.590::INFO: Shutdown hook executing 2006-11-15 19:22:44.590::INFO: Shutdown hook complete [EMAIL PROTECTED]:~/development/temp/myApp$ Cheers Don Brown <[EMAIL PROTECTED]> wrote: I'm glad you found this problem. However, I think it could be easier solved by marking the injections in the freemarker and velocity page filters as "required=false", and then complain very loudly if the filters are used by not initialized. Then, we wouldn't need all the changes to xwork and guice. In particular, I'd like to avoid changing the Guice source code if all possible to facilitate easier synchronization with the original project. Could you back out the changes and try the required="false" approach? Thanks, Don tm jee wrote: > Hi guys, > > Found a possible bug with Struts2 DI feature. Opened up a jira issue for it > (WW-1508). Leaving the issue open for reviews. Don if you got the time to > have a look, it would be great. > > cheers > > Send instant messages to your online friends http://uk.messenger.yahoo.com > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Send instant messages to your online friends http://uk.messenger.yahoo.com Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: [s2] WW-1506
Hi Don,
Do you mean
@Inject(required=false)
public static void setFreemarkerManager(FreemarkerManager mgr) {
...
}
I'll give it a go and report back.
cheers.
Don Brown <[EMAIL PROTECTED]> wrote: I'm glad you found this problem. However,
I think it could be easier
solved by marking the injections in the freemarker and velocity page
filters as "required=false", and then complain very loudly if the
filters are used by not initialized. Then, we wouldn't need all the
changes to xwork and guice. In particular, I'd like to avoid changing
the Guice source code if all possible to facilitate easier
synchronization with the original project.
Could you back out the changes and try the required="false" approach?
Thanks,
Don
tm jee wrote:
> Hi guys,
>
> Found a possible bug with Struts2 DI feature. Opened up a jira issue for it
> (WW-1508). Leaving the issue open for reviews. Don if you got the time to
> have a look, it would be great.
>
> cheers
>
> Send instant messages to your online friends http://uk.messenger.yahoo.com
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Send instant messages to your online friends http://uk.messenger.yahoo.com
[s2] WW-1506
Hi guys, Found a possible bug with Struts2 DI feature. Opened up a jira issue for it (WW-1508). Leaving the issue open for reviews. Don if you got the time to have a look, it would be great. cheers Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: Alternate Update Example
Hi Mark, Thank you for your interest and efford. I think we could add it into the example section. :-) As the article is about Struts2, I think it would be more appropriate if we have it in Struts2 confluence, what do you think? Unfortunately to access the struts2 confluence, one needs CLA. (http://cwiki.apache.org/confluence/display/WW) But there's another community based one at http://cwiki.apache.org/confluence/display/S2WIKI which I think allows everyone to participate. If you want access to the official struts2 confluence, one the CLA is received, I think Ted or Don will be able to wire you up ( I don't have access to that). If you want access to webwork confluence, just drop me a line, I could forward it to Rainer / Pat who could grant you access instantly. Cheers. Mark Menard <[EMAIL PROTECTED]> wrote: I'm pretty new to Struts2/WW and figuring out how to update a List of domain objects stumped me. I've written up a short explanation of how I do it and was wondering if it would make sense to work this up into a fuller article and add it to the Struts2 Documentation. http://www.vitarara.org/cms/node/81 Thanks, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: [s2] XWork2 release plan
Sounds ok to me, I'll be able to update the docs by then and maybe do more bugfixing by then hopefully. But Rainer, Pat or Jason will have to make the decision. They are the tech. lead of XWork. :-) Cheers. Ted Husted <[EMAIL PROTECTED]> wrote: I'd say that we could still get the bits out there. I think we anticipate that both the XWork 2 and Struts 2 distributions will be stuck at beta again this cycle. But, we can't have another Struts 2 beta without another XWork 2 beta. On 11/15/06, tm jee wrote: > I think we might need to push back XWork2 release plan a bit. With the new > IoC feature in XWork2, the docs gets outdated, might need some time to make > it up-todate again. Thoughts? > > Cheers. > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Try the all-new Yahoo! Mail . "The New Version is radically easier to use" The Wall Street Journal
Re: [s2][OT] Guice rocks
Hi Konstantin, Thx for the reply. If you have any finding, I'd be glad to learn more about it. I am kindof interested in this area as well. But i am still a beginner so I might talk nonsense... :P Have you got a blog? Maybe blog about your findings would be nice. I'll definitely subscribe to it. Cheers. Konstantin Priblouda <[EMAIL PROTECTED]> wrote: --- tm jee wrote: > Hi Konstantin, > > Its at http://code.google.com/p/google-guice/ > > Enjoy Guice. Its Guice time :-) Not sure whether I will be enjoying it, but I will try to understand why it is better thank pico/nano or spring. regards, [ Konstantin Pribluda http://www.pribluda.de ] Still using XDoclet 1.x? XDoclet 2 is released and of production quality. check it out: http://xdoclet.codehaus.org Sponsored Link Compare mortgage rates for today. Get up to 5 free quotes. Www2.nextag.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Try the all-new Yahoo! Mail . "The New Version is radically easier to use" The Wall Street Journal
Re: [s2][OT] Guice rocks
Good idea Alex. ;) I manage to find his email at carzybob.org Alexandru Popescu <[EMAIL PROTECTED]> wrote: On 11/15/06, tm jee wrote: > Hi guys, > > Guice doesn't seem to have a mailing list or forum. Does anyone know how to > follow up with development / news of Guice? > > It doesn't seem to have a documentation page as well, too bad for such a > superb project. :P Anyone knows about the plans of Guice? > Just ping Bob Lee, till he will answer :-). ./alex -- .w( the_mindstorm )p. > tia. > > rgds > > Don Brown wrote: Guice is the love child of our very own Bob Lee of Google. > He wrote it > for his applications at work that needed a DI library, but needed it to > be small and very fast (he quotes some strange stat like 150x the speed > of Spring). In bug tickets and personal conversions, he hinted that he > wanted to use it, once it went Open Source, in his new API, so I decided > to take it a step further and put it at the core of XWork and Struts 2 > now. > > And I agree, it is a very impressive piece of code :) I'm looking > forward to finding new ways to use it better as we learn its capabilities. > > Don > > tm jee wrote: > > Hi guys, > > > > Sorry, this might be off topic a bit. > > > > Just want to say I really like Guice. Its simple, fast (amazing !!!), well > > written ... > > > > I like the code, its so clean and elegant (to me at least). For newbies > > like me who are still trying to pick up the new features offered by Tiger, > > Guice is really a nice tutorial (educative) to start off with. Just reading > > the code teaches me a great deal. Oh.. and the Apis are well thought out, > > nicely separate between internal and external where only external stuff are > > expose as public. Its also makes good uses of Tiger's Threading > > capabilities :-) > > > > Simply amazing. Kudos guys. Got to love Guice. > > > > p/s Btw, Don would you mind sharing with us where did you manage to find > > goodies like Guice? I haven't heard about it until your post, maybe I am > > just too out-dated missing all the fun > > > > rgds > > > > > > Send instant messages to your online friends http://uk.messenger.yahoo.com > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > Send instant messages to your online friends http://uk.messenger.yahoo.com > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Copy addresses and emails from any email account to Yahoo! Mail - quick, easy and free. Do it now...
Re: [s2][OT] Guice rocks
Hi Konstantin, Its at http://code.google.com/p/google-guice/ Enjoy Guice. Its Guice time :-) Cheers. Konstantin Priblouda <[EMAIL PROTECTED]> wrote: --- tm jee wrote: > Hi guys, > > Guice doesn't seem to have a mailing list or forum. > Does anyone know how to follow up with development / > news of Guice? > > It doesn't seem to have a documentation page as > well, too bad for such a superb project. :P Anyone > knows about the plans of Guice? what's the URL? ;) ( google does not find it ;) ) regards, [ Konstantin Pribluda http://www.pribluda.de ] Still using XDoclet 1.x? XDoclet 2 is released and of production quality. check it out: http://xdoclet.codehaus.org Sponsored Link Compare mortgage rates for today. Get up to 5 free quotes. Www2.nextag.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: [s2][OT] Guice rocks
Hi guys, Guice doesn't seem to have a mailing list or forum. Does anyone know how to follow up with development / news of Guice? It doesn't seem to have a documentation page as well, too bad for such a superb project. :P Anyone knows about the plans of Guice? tia. rgds Don Brown <[EMAIL PROTECTED]> wrote: Guice is the love child of our very own Bob Lee of Google. He wrote it for his applications at work that needed a DI library, but needed it to be small and very fast (he quotes some strange stat like 150x the speed of Spring). In bug tickets and personal conversions, he hinted that he wanted to use it, once it went Open Source, in his new API, so I decided to take it a step further and put it at the core of XWork and Struts 2 now. And I agree, it is a very impressive piece of code :) I'm looking forward to finding new ways to use it better as we learn its capabilities. Don tm jee wrote: > Hi guys, > > Sorry, this might be off topic a bit. > > Just want to say I really like Guice. Its simple, fast (amazing !!!), well > written ... > > I like the code, its so clean and elegant (to me at least). For newbies like > me who are still trying to pick up the new features offered by Tiger, Guice > is really a nice tutorial (educative) to start off with. Just reading the > code teaches me a great deal. Oh.. and the Apis are well thought out, nicely > separate between internal and external where only external stuff are expose > as public. Its also makes good uses of Tiger's Threading capabilities :-) > > Simply amazing. Kudos guys. Got to love Guice. > > p/s Btw, Don would you mind sharing with us where did you manage to find > goodies like Guice? I haven't heard about it until your post, maybe I am just > too out-dated missing all the fun > > rgds > > > Send instant messages to your online friends http://uk.messenger.yahoo.com > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: [s2] XWork2 release plan
Hi guys, I think we might need to push back XWork2 release plan a bit. With the new IoC feature in XWork2, the docs gets outdated, might need some time to make it up-todate again. Thoughts? Cheers. Don Brown <[EMAIL PROTECTED]> wrote: James Mitchell wrote: > I'd be happy to take a stab at adding the retro plugin to xwork. The > only issue I had was after the jar was converted, getting the new bits > into the repo or part of a distribution, but we can cross that bridge > later. > > I don't want to do duplicate work, so shall I work on it, or someone > else doing it? Do it. :) Don > > > > -- > James Mitchell > 678.910.8017 > > > > > On Nov 14, 2006, at 2:35 PM, Don Brown wrote: > >> James has successfully integrated retrotranslator into the Maven 2 >> process for Shale, so it should be pretty easy to translate that work >> for XWork. As for closing out XWork, I would like to do another beta >> release of it and Struts 2, perhaps this weekend. The Guice and Dojo >> 0.4 changes are pretty big and I think they should be tested by the >> public for a few weeks before shooting for GA. >> >> Also, I've started the merging of the tiger subproject with XWork >> core, and IIRC, only the unit tests need to be brought over still. >> >> Don >> >> Rainer Hermanns wrote: >>> Ted, >>> I need some more time (the coming weekend) to finish up the open >>> tasks for >>> xwork2. >>> We have some "deadline problems" in my daytime customer project so >>> that I >>> can not work on the open xwork issues before the weekend. >>> Since we are waiting for the ajax stuff to be fixed as well for >>> Struts2, I >>> think this shouldn't be a big thing. >>> I hope this is okay with the current release schedule. >>> >>> Regarding the retroweaver build: Is this part of the common maven2 >>> build >>> process or do I need to apply the filter after the release process is >>> finished? >>> >>> -Rainer >>> >>> Thanks, Rainer. Applying Retroweaver is trivial. It's just a filter that that you run over the J5 JAR. It only takes a few seconds. We are already bundling a XW2/J4 JAR with Struts 2. People have been using it, and I understand it works just fine. * http://www.apache.org/dist/struts/library/struts-2.0.1-j4.zip -Ted. > Ted, > >> I think the biggest problem for xwork2 is still the >> > fact, > that there is no retroweaver enabled build for Java > 1.4. > Also the build with maven is not working as required. > I hope to get the maven build done till the mid of > next week. > > Toby promised to help out with the other open issues > in xwork's Jira, so > that the doc and refactoring tasks should be done as > well till then. > > As soon as these issues are fixed, we can remove the > beta qualifier > and I'll release xwork 2.0 next week. > > regards, > Rainer > > >>> There are some open issues left, mostly regarding >>> > the > >>> build and release process with maven. >>> >> That being the case, are we removing the "beta" >> > qualifier from this XWork > >> 2 release? >> >> -Ted. >> >> > -- > --- > >> Posted via Jive Forums >> >> > http://forums.opensymphony.com/thread.jspa?threadID=49 > 702&messageID=100017#100017 > - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=49702&messageID=100892#100892 - 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] Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: svn commit: r475123 - /struts/struts2/trunk/core/src/main/resources/org/apache/struts2/default.properties
I see. thx for the info Don. Just removed the comments in default.properties, added / updated javadoc in CompositeActionMapper to reflect this. cheers. Don Brown <[EMAIL PROTECTED]> wrote: Actually, that wasn't an accident. The composite mapper now uses a different, simpler mechanism to gather subordinate mappers. See CompositeActionMapper.setActionMappers(List) Don [EMAIL PROTECTED] wrote: > Author: tmjee > Date: Tue Nov 14 21:08:29 2006 > New Revision: 475123 > > URL: http://svn.apache.org/viewvc?view=rev&rev=475123 > Log: > WW-1490 > - Have a composite ActionMapper that decides which ActionMapper it contains > should be used > - re-adding this cause, the comments was accidently deleted during last > commit > > > Modified: > > struts/struts2/trunk/core/src/main/resources/org/apache/struts2/default.properties > > Modified: > struts/struts2/trunk/core/src/main/resources/org/apache/struts2/default.properties > URL: > http://svn.apache.org/viewvc/struts/struts2/trunk/core/src/main/resources/org/apache/struts2/default.properties?view=diff&rev=475123&r1=475122&r2=475123 > == > --- > struts/struts2/trunk/core/src/main/resources/org/apache/struts2/default.properties > (original) > +++ > struts/struts2/trunk/core/src/main/resources/org/apache/struts2/default.properties > Tue Nov 14 21:08:29 2006 > @@ -49,6 +49,15 @@ > > ### How request URLs are mapped to and from actions > #struts.mapper.class=org.apache.struts2.dispatcher.mapper.DefaultActionMapper > +### The above line is to be commented and following are to be uncommented to > +### enable CompositeActionMapper > +### - With CompositeActionMapper one could specified many ActionMapper > instance, where > +### each of them will be chosen according to the order. Lower order number > has > +### higher precedence > +#struts.mapper.class=org.apache.struts2.dispatcher.mapper.CompositeActionMapper > +#struts.mapper.composite.1=org.apache.struts2.dispatcher.mapper.DefaultActionMapper > +#struts.mapper.composite.2=foo.bar.MyActionMapper > +#struts.mapper.composite.3=foo.bar.MyAnotherActionMapper > > ### Used by the DefaultActionMapper > ### You may provide a comma separated list, e.g. > struts.action.extension=action,jnlp,do > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: New Struts configuration design
I've go ahead and re-added the fix and update WW-1489 as well. Do have a go through if you got the time, thx. Cheers. Don Brown <[EMAIL PROTECTED]> wrote: Hmm...ok. The reason I took it out was it was initializing the framework twice, but I can see how we would need it. If you have a chance, please readd your fix, but try to find more explicit names for the dispatchers and very clearly document the logic so it is easier to grasp. If you don't have time, I may be able to get to it next week. Thanks, Don tm jee wrote: >> Could you go into detail why the cleanup filter needs to initialize the >> dispatcher? >> > > Yup sure. :) > > ActionContextCleanUp and FilterDispatcher both keeps a copy of Dispatcher, > and put them in thread local only if one doesn't exists yet. The order of > filters when using sitemesh would be > > 1] ActionContextCleanUp > 2] Sitemesh Filter > 3] Dispatcher Filter > > This is such that ActionContextCleanUp when present, would have the > Dispatcher setup so Sitemesh will have access to Struts2 / WebWork internals. > > Previously, the logics of setting up the dispatcher (the encoding stuff etc.) > are in both FilterDispatcher and ActionContextCleanUp, the AbstractFilter > moves those commons logics to itsef such that they are not repeated in both > FilterDispatcher and ActionContextCleanUp. > > p/s hopefully i get the logics correct. ;) > > rgds > > > > > Don Brown wrote: Yeah, I did have to put the filters back to their original > state. I > found the _dispatcher and dispatcher variables really confusing and I'm > not sure I understand the original usecase why the cleanup filter needs > to have a dispatcher instance at all. Could you go into detail why the > cleanup filter needs to initialize the dispatcher? > > Don > > tm jee wrote: > >> Hi guys, >> >> There might be a fix releated to this >> (https://issues.apache.org/struts/browse/WW-1489) that seems to be broken. >> WW-1489 abstracted the common logic from both DispatcherFilter and >> ActionContextCleanUp to an Abstract filter. With the latest commit, >> FilterDispatcher is put back to its old state (plus the new DI code) and >> AbstractFilter was deleted. >> >> I guess its ok to revert back to the old state but ActionContextCleanUp is >> not reverted totally to its old state, such that it doesn't initialize >> Dispatcher etc. The consequence i guess would be that sitemesh will not have >> access to struts2 value stack etc. Is this the itended behaviour or am i >> missing something? >> >> Tia >> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > Send instant messages to your online friends http://uk.messenger.yahoo.com > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: New Struts configuration design
> Could you go into detail why the cleanup filter needs to initialize the > dispatcher? Yup sure. :) ActionContextCleanUp and FilterDispatcher both keeps a copy of Dispatcher, and put them in thread local only if one doesn't exists yet. The order of filters when using sitemesh would be 1] ActionContextCleanUp 2] Sitemesh Filter 3] Dispatcher Filter This is such that ActionContextCleanUp when present, would have the Dispatcher setup so Sitemesh will have access to Struts2 / WebWork internals. Previously, the logics of setting up the dispatcher (the encoding stuff etc.) are in both FilterDispatcher and ActionContextCleanUp, the AbstractFilter moves those commons logics to itsef such that they are not repeated in both FilterDispatcher and ActionContextCleanUp. p/s hopefully i get the logics correct. ;) rgds Don Brown <[EMAIL PROTECTED]> wrote: Yeah, I did have to put the filters back to their original state. I found the _dispatcher and dispatcher variables really confusing and I'm not sure I understand the original usecase why the cleanup filter needs to have a dispatcher instance at all. Could you go into detail why the cleanup filter needs to initialize the dispatcher? Don tm jee wrote: > Hi guys, > > There might be a fix releated to this > (https://issues.apache.org/struts/browse/WW-1489) that seems to be broken. > WW-1489 abstracted the common logic from both DispatcherFilter and > ActionContextCleanUp to an Abstract filter. With the latest commit, > FilterDispatcher is put back to its old state (plus the new DI code) and > AbstractFilter was deleted. > > I guess its ok to revert back to the old state but ActionContextCleanUp is > not reverted totally to its old state, such that it doesn't initialize > Dispatcher etc. The consequence i guess would be that sitemesh will not have > access to struts2 value stack etc. Is this the itended behaviour or am i > missing something? > > Tia > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: [s2] Move Ognl code base into Struts2
I see. At first I was thinking that if we have the source in struts2 code base, we could do a release of ognl with fixes whenever we release webwork. Ognl development seems to be inactive for a long time. I think Pat have commit access to Ognl code, but are we allow to do a release of Ognl when felt appropriate? But as Martin pointed out, there's going to be quite a massive responsibility in maintaining ognl docs, patches, user requests etc. So i guess its not really a feasible option right now. Cheers. Martin Cooper <[EMAIL PROTECTED]> wrote: On 11/13/06, tm jee wrote: > > Hey guys, > > What do you guys think about moving Ognl code base into Struts2, just like > what was did with Guice? I would not be in favour of that. As Don implies, that means that we would effectively be forking OGNL and taking on the responsibility to maintain it (code, documentation, etc.) ourselves, including updating to any newer releases of the "original" OGNL that came along. I'd have to see convincing reasons to take that on, which I don't see right now. -- Martin Cooper rgds > > > - > All new Yahoo! Mail "The new Interface is stunning in its simplicity and > ease of use." - PC Magazine > Send instant messages to your online friends http://uk.messenger.yahoo.com
[s2] Move Ognl code base into Struts2
Hey guys, What do you guys think about moving Ognl code base into Struts2, just like what was did with Guice? rgds - All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine
Re: New Struts configuration design
Hi guys, There might be a fix releated to this (https://issues.apache.org/struts/browse/WW-1489) that seems to be broken. WW-1489 abstracted the common logic from both DispatcherFilter and ActionContextCleanUp to an Abstract filter. With the latest commit, FilterDispatcher is put back to its old state (plus the new DI code) and AbstractFilter was deleted. I guess its ok to revert back to the old state but ActionContextCleanUp is not reverted totally to its old state, such that it doesn't initialize Dispatcher etc. The consequence i guess would be that sitemesh will not have access to struts2 value stack etc. Is this the itended behaviour or am i missing something? Tia Don Brown <[EMAIL PROTECTED]> wrote: I've redesigned the Struts configuration scheme to better structure XWork and Struts internals, allow self-configuring plugins, and reduce the amount of configuration necessary to write a Struts application - none, in fact. The core changes are: - A new dependency injection engine in XWork (Guice [1]) - XWork and Struts use this DI engine to wire together framework pieces - Ability to configure settings (previously struts.properties) and Guice beans in XML - struts.xml and struts.properties are now completely optional - Plugins can override any injected Struts bean and provide their own settings/properties The primary purpose of these changes was to minimize the amount of configuration an end user needs to provide in order to create a Struts application. The secondary goal was to better structure Struts/XWork internals to make plugins more powerful and, one day, get rid of statics to allow different configurations of the framework per filter instance, per package, etc. My favorite part of the changes is the ability to have a fully functional Struts app with no additional XML or properties files. Just set the "actionPackages" property in web.xml, and Struts will scan those packages and their subpackages for any Actions automatically. The new plugin features allow you simply drop in a jar like the Plexus plugin and have its, say, ObjectFactory, automatically used as the default without you having to provide any extra configuration (plan to move Spring to its own plugin next). You might be wondering why Guice, why not Spring, or why a dependency injection container at all. First, the dependency injection engine is solely for XWork, Struts, and its plugins. It is not meant, nor would it be a good fit, for the end user application. Guice has a very minimal feature set that is perfect for the Struts framework, but wouldn't be sufficient for a Struts application. Second, an internal DI container is important as it doesn't force a Struts application to use a certain DI container for their application. If we used Spring, the framework would not only require all Struts applications to have Spring, but also require a certain version. Guice is not only a very small, fast, DI container, but it also has been imported into the XWork source repository and package structure, so that if a Struts application wanted to use a different version of Guice down the road, it wouldn't be a problem. Finally, having an internal DI container gives us a standard way of defining extension points and allowing plugins and users to easily choose implements of these extension points. Also, a DI container allows us to get rid of most of our uses of 'static', meaning an application could use two implementations simultaneously in different areas. This means getting rid of singletons and unextendable static classes. An added benefit is the ability to inject things like constants, the ServletContext, or the current Configuration into any bean just by declaring an annotation. Finally, testing is easier since dependencies can be injected via set calls, minimizing setup costs. The code has been committed, all unit tests are passing, and the Showcase app seems to be working correctly. Please give it a try so we can iron out the inevitable bugs as soon as possible. I think this DI foundation will allow for some very interesting plugins, turning Struts 2 into a deeply customizable, yet turnkey, framework. http://jira.opensymphony.com/browse/XW-433 http://jira.opensymphony.com/browse/XW-434 http://jira.opensymphony.com/browse/XW-435 https://issues.apache.org/struts/browse/WW-1421 https://issues.apache.org/struts/browse/WW-1402 https://issues.apache.org/struts/browse/WW-1498 Don [1] http://code.google.com/p/google-guice/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: [s2] XWork2 release plan
Sounds interesing. I guess after this, to use XWork, we could just say, grab a copy ActionProxyFactory from Container, and everything is wired in by Guice. Is there any place where those interested could follow up with this? Maybe a jira issue describing the details about it. Guice is cool, should definitely check it out more. Cheers. Don Brown <[EMAIL PROTECTED]> wrote: Actually, I'd like to make one more semi-major change while we have the opportunity. I've been working on revamping the configuration to combine struts.properties into struts.xml, and use an internal dependency injection container (Bob's Guice project [1]) to wire internal XWork and Struts components. This change shouldn't affect most webwork applications and will lay the groundwork for a very powerful restructuring of XWork and Struts to allow plugins and end user applications to easily replace any major or minor piece of Xwork/Xstruts. I have the initial XWork integration and plan to tackle the Struts integration this weekend. As I said before, it should be 100% backwards compatible with struts.properties, but allow you to define them in struts.xml as well. Also, this will allow us to move the Spring code into a plugin, and make it easier for plugins to extend Struts. I'd like to do this now because this does have significant implications for internal XWork API's and a major release is the proper time to make those types of changes. Don [1] http://code.google.com/p/google-guice/ Rainer Hermanns wrote: > Ted, > > I think the biggest problem for xwork2 is still the fact, > that there is no retroweaver enabled build for Java 1.4. > Also the build with maven is not working as required. > I hope to get the maven build done till the mid of next week. > > Toby promised to help out with the other open issues in xwork's Jira, so > that the doc and refactoring tasks should be done as well till then. > > As soon as these issues are fixed, we can remove the beta qualifier > and I'll release xwork 2.0 next week. > > regards, > Rainer > > >>> There are some open issues left, mostly regarding the >>> build and release process with maven. >>> >> That being the case, are we removing the "beta" qualifier from this XWork >> 2 release? >> >> -Ted. >> - >> Posted via Jive Forums >> http://forums.opensymphony.com/thread.jspa?threadID=49702&messageID=100017#100017 >> >> >> - >> 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] - The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider.
Re: Is it possible to configure a request scoped bean of Spring2?
You are welcomed. :) Ruimo Uno <[EMAIL PROTECTED]> wrote: Thanks! It works fine! 2006/11/12, tm jee : > > Hi Ruimo, > > If not mistaken i think we might need this > > > ... > > ... > > > rgds > > > Ruimo Uno wrote: Hi, > > I'm trying Spring2 with Struts2 but cannot configure request scoped bean. > I've changed web.xml along with the folowing guide: > > http://www.opensymphony.com/webwork/wikidocs/Spring%20Session%20Components%20Workarounds.html > > > requestContextFilter > org.springframework.web.filter.RequestContextFilter > > > > requestContextFilter > /* > > > Then added a request scoped bean in the applicationContext.xml. > > > init-method="init" destroy-method="terminate" scope="request"> > > > However, the application fails throwing the following exception. > > org.springframework.beans.factory.BeanCreationException: Error creat > ing bean with name 'userAction' defined in ServletContext resource > [/WEB-INF/app > licationContext.xml]: Cannot resolve reference to bean 'userDao' while > setting b > ean property 'userDao'; nested exception is > org.springframework.beans.factory.Be > anCreationException: Error creating bean with name 'userDao': Scope 'request' > is > not active; nested exception is java.lang.IllegalStateException: No > thread-boun > d request: use RequestContextFilter > > Any idea? > > -- > Ruimo Uno > (Shisei Hanai) > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - > Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail. > -- Ruimo Uno (Shisei Hanai) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine
Re: Is it possible to configure a request scoped bean of Spring2?
Hi Ruimo, If not mistaken i think we might need this ... ... rgds Ruimo Uno <[EMAIL PROTECTED]> wrote: Hi, I'm trying Spring2 with Struts2 but cannot configure request scoped bean. I've changed web.xml along with the folowing guide: http://www.opensymphony.com/webwork/wikidocs/Spring%20Session%20Components%20Workarounds.html requestContextFilter org.springframework.web.filter.RequestContextFilter requestContextFilter /* Then added a request scoped bean in the applicationContext.xml. init-method="init" destroy-method="terminate" scope="request"> However, the application fails throwing the following exception. org.springframework.beans.factory.BeanCreationException: Error creat ing bean with name 'userAction' defined in ServletContext resource [/WEB-INF/app licationContext.xml]: Cannot resolve reference to bean 'userDao' while setting b ean property 'userDao'; nested exception is org.springframework.beans.factory.Be anCreationException: Error creating bean with name 'userDao': Scope 'request' is not active; nested exception is java.lang.IllegalStateException: No thread-boun d request: use RequestContextFilter Any idea? -- Ruimo Uno (Shisei Hanai) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail.
Re: [s2] struts2-archetype-starter 's struts-master parent
> What's happening and when? (Is there a problem when building the > archetype, during mvn archetype:create or when using the generated > project?) If there's no /org/apache/struts/struts-master/4-SNAPSHOT directory in my local repository, mvn install gives me error saying that struts-master 4-SNAPSHOT cannot be found from any repository. With the following added to struts2-archetype-starter pom.xml it seems to be working ok. apache.snapshots Apache Maven Repository (Snapshots and Test Builds) http://people.apache.org/repo/m2-snapshot-repository true true Maybe we should have this in struts2-archetype-starter's pom.xml as well. rgds Wendy Smoak <[EMAIL PROTECTED]> wrote: On 11/11/06, tm jee wrote: > struts2-archetype-starter seems to depends on struts-master version > 4-snapshot which doesn't exists at the moment in maven repository > (http://repo1.maven.org/maven2/). Struts2's core, etc seems to still be using > struts-master version 3. It's a snapshot, so it won't be in the central repository. It is in the snapshot repo: http://people.apache.org/repo/m2-snapshot-repository/org/apache/struts/struts-master/4-SNAPSHOT/ What's happening and when? (Is there a problem when building the archetype, during mvn archetype:create or when using the generated project?) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Try the all-new Yahoo! Mail . "The New Version is radically easier to use" The Wall Street Journal
[s2] XWork2 documentation
Hi guys, Got XWork2 documentation filled up. Please do have a look at it if you've got some time to free. Its at http://wiki.opensymphony.com/display/XW/XWork2 As usual any feedbacks are welcomed. Cheers rgds Send instant messages to your online friends http://uk.messenger.yahoo.com
[s2] struts2-archetype-starter 's struts-master parent
Hi guys, struts2-archetype-starter seems to depends on struts-master version 4-snapshot which doesn't exists at the moment in maven repository (http://repo1.maven.org/maven2/). Struts2's core, etc seems to still be using struts-master version 3. Are we suppose to use struts-master version 3 or have i missed the point? Thx in advance. rgds - Try the all-new Yahoo! Mail . "The New Version is radically easier to use" The Wall Street Journal
Re: [s2] XWork2 release plan
Hi guys, I think there's an issue that might be related to retrotranslator. Its at https://issues.apache.org/struts/browse/WW-1493 Could this be related? Thoughs Have anyone used the weaved jar file with BEA JRockit? Thx. Ted Husted <[EMAIL PROTECTED]> wrote: Thanks, Rainer. Applying Retroweaver is trivial. It's just a filter that that you run over the J5 JAR. It only takes a few seconds. We are already bundling a XW2/J4 JAR with Struts 2. People have been using it, and I understand it works just fine. * http://www.apache.org/dist/struts/library/struts-2.0.1-j4.zip -Ted. > Ted, > > I think the biggest problem for xwork2 is still the > fact, > that there is no retroweaver enabled build for Java > 1.4. > Also the build with maven is not working as required. > I hope to get the maven build done till the mid of > next week. > > Toby promised to help out with the other open issues > in xwork's Jira, so > that the doc and refactoring tasks should be done as > well till then. > > As soon as these issues are fixed, we can remove the > beta qualifier > and I'll release xwork 2.0 next week. > > regards, > Rainer > > >> There are some open issues left, mostly regarding > the > >> build and release process with maven. > > > > That being the case, are we removing the "beta" > qualifier from this XWork > > 2 release? > > > > -Ted. > > > -- > --- > > Posted via Jive Forums > > > http://forums.opensymphony.com/thread.jspa?threadID=49 > 702&messageID=100017#100017 - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=49702&messageID=100892#100892 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: svn commit: r472338 - in /struts/maven/trunk/struts2-archetype-starter/src/main/resources: META-INF/archetype.xml archetype-resources/src/main/webapp/WEB-INF/decorators/main.ftl archetype-resource
Thx for the clarification Craig. :-) Craig McClanahan <[EMAIL PROTECTED]> wrote: On 11/8/06, tm jee wrote: > > > Does this need a servlet mapping? > > I don't think so. It just expose the servlet instance itself such > that ServletConfig etc. could be obtained . This I think is needed > when using a jsp taglib in freemarker You're correct ... a servlet mapping is not required, if all you are after is the "load on startup" behavior of the container calling init() at startup time, but you do not want this servlet to process any requests. With the current generation servlet APIs, you'd more likely do this sort of thing in a ServletContextListener, but I imagine this design predates that. rgds. Craig Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: svn commit: r472338 - in /struts/maven/trunk/struts2-archetype-starter/src/main/resources: META-INF/archetype.xml archetype-resources/src/main/webapp/WEB-INF/decorators/main.ftl archetype-resource
> Does this need a servlet mapping? I don't think so. It just expose the servlet instance itself such that ServletConfig etc. could be obtained . This I think is needed when using a jsp taglib in freemarker rgds. Wendy Smoak <[EMAIL PROTECTED]> wrote: On 11/7/06, [EMAIL PROTECTED] wrote: > Author: tmjee > Date: Tue Nov 7 15:55:48 2006 > New Revision: 472338 > > URL: http://svn.apache.org/viewvc?view=rev&rev=472338 ... > + > + jspSupportServlet > + org.apache.struts2.views.JspSupportServlet > + 5 > + Does this need a servlet mapping? http://svn.apache.org/repos/asf/struts/maven/trunk/struts2-archetype-starter/src/main/resources/archetype-resources/src/main/webapp/WEB-INF/web.xml Thanks, Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: Struts2 radio UI tag issue.
No problem Shisei. :-) Its being applied to both webwork and struts2 WW-1494 (struts2) WW-1369 (webwork) Thx again for the feedback. Cheers. Shisei Hanai <[EMAIL PROTECTED]> wrote: Thanks, now I realize that ww-1369 is the same issue that I've stated. Is this patch going to be applied to Struts2 too? 2006/11/8, tm jee : > Yup. That's the reason I think its ok to compare they key, just like the > patch (ww-1369) and you suggested. :-) > > > Ruimo Uno wrote: > 2006/11/8, tm jee : > > There's a related jira issue for this as well reported on WebWork. > > > > http://jira.opensymphony.com/browse/WW-1369 > > > > I don't think there's an issue comparing the key. What do others think > about it? But for rendering the page, we should use the string cause > freemarker will added locale specific information to numbers for example > such that 1234567 might gets rendered as 1,234,567 etc. I think that's the > reason the string representation is used. > > Well, this fix does NOT affect rendering at all. It changes the > following three lines: > > <#if tag.contains(parameters.nameValue, itemKey)> > checked="checked"<#rt/> > > > This code is only for determining if the radio tag is checked or not. > It will never > interfere othere features such as value rendering or i18n. > > Thanks, > > -- > Shisei Hanai > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > Try the all-new Yahoo! Mail . "The New Version is radically easier to use" > The Wall Street Journal -- --- Shisei Hanai (Ruimo Uno) http://www.ruimo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: [s2] Servlet 2.4 for the starter archetype?
Hi guys,
I've go ahead make the following changes on struts2-archetype-starter :-
- make web.xml 2.4 compatible instead of 2.3 (removed the taglib portion and
add the appripriate 2.4 web-app tag)
- corrected the unused 'home.html' link
> The next question is, where are Sitemesh tags used at
> all in that archetype?
Sitemesh tag isn't really being used. Sitemesh decorator in
main./WEB-INF/decorators/main.ftl decorates the page using ${title}, ${head}
and ${body} etc which is put into freemarker's model by FreeMarkerPageFilter.
> I think the elements and the tlds can be removed from the
> archetype.
Yup, i guess so as well. :-)
Thx for the info.
cheers.
Wendy Smoak <[EMAIL PROTECTED]> wrote: On 11/7/06, Matt Raible wrote:
> Yes, they are. I haven't used a in my web.xml in years. ;-)
> It is needed by some 2.3 containers, but shouldn't be needed according
> to the spec.
Me, neither. :) The next question is, where are Sitemesh tags used at
all in that archetype?
The only occurrences of 'sitemesh-decorator' and 'sitemesh-page' are
in web.xml and the tlds themselves. I have no idea how Freemarker and
Sitmesh work together, but there are no JSP tags that I can see. I
think the elements and the tlds can be removed from the
archetype.
(And while we're here, the 'Home' link on the menu goes to home.html,
which doesn't exist in the webapp generated from the archetype.)
--
Wendy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: Struts2 radio UI tag issue.
Yup, but sometimes the key might be an object or a string, I guess that's the reason toString() was used. I think it should be fixed as Ruimo Uno suggested. rgds Musachy Barroso <[EMAIL PROTECTED]> wrote: You can force freemarker to render it as a number with "?c" I think. musachy tm jee wrote: > There's a related jira issue for this as well reported on WebWork. > > http://jira.opensymphony.com/browse/WW-1369 > > I don't think there's an issue comparing the key. What do others think about > it? But for rendering the page, we should use the string cause freemarker > will added locale specific information to numbers for example such that > 1234567 might gets rendered as 1,234,567 etc. I think that's the reason the > string representation is used. > > rgds > > Ruimo Uno wrote: Hi, > > Current radiomap.ftl file uses the string representation of map key to > determine if > the radio button should be checked: > > <#if tag.contains(parameters.nameValue, itemKeyStr)> > > As a result, only String type of property can be used for the radio tag. > > In select.ftl file, it uses the map key itself instead of the string > representation of it: > > <#if tag.contains(parameters.nameValue, itemKey) == true> > > This makes much sence becuase you can use other types than the String such as > type-safe enums for the property type. > > Is there any problems to use the itemKey instead of the itemKeyStr in > radiomap.ftl too? > > <#if tag.contains(parameters.nameValue, itemKey)> > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: Struts2 radio UI tag issue.
Yup. That's the reason I think its ok to compare they key, just like the patch (ww-1369) and you suggested. :-) Ruimo Uno <[EMAIL PROTECTED]> wrote: 2006/11/8, tm jee : > There's a related jira issue for this as well reported on WebWork. > > http://jira.opensymphony.com/browse/WW-1369 > > I don't think there's an issue comparing the key. What do others think about > it? But for rendering the page, we should use the string cause freemarker > will added locale specific information to numbers for example such that > 1234567 might gets rendered as 1,234,567 etc. I think that's the reason the > string representation is used. Well, this fix does NOT affect rendering at all. It changes the following three lines: <#if tag.contains(parameters.nameValue, itemKey)> checked="checked"<#rt/> This code is only for determining if the radio tag is checked or not. It will never interfere othere features such as value rendering or i18n. Thanks, -- Shisei Hanai - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Try the all-new Yahoo! Mail . "The New Version is radically easier to use" The Wall Street Journal
Re: Struts2 radio UI tag issue.
There's a related jira issue for this as well reported on WebWork. http://jira.opensymphony.com/browse/WW-1369 I don't think there's an issue comparing the key. What do others think about it? But for rendering the page, we should use the string cause freemarker will added locale specific information to numbers for example such that 1234567 might gets rendered as 1,234,567 etc. I think that's the reason the string representation is used. rgds Ruimo Uno <[EMAIL PROTECTED]> wrote: Hi, Current radiomap.ftl file uses the string representation of map key to determine if the radio button should be checked: <#if tag.contains(parameters.nameValue, itemKeyStr)> As a result, only String type of property can be used for the radio tag. In select.ftl file, it uses the map key itself instead of the string representation of it: <#if tag.contains(parameters.nameValue, itemKey) == true> This makes much sence becuase you can use other types than the String such as type-safe enums for the property type. Is there any problems to use the itemKey instead of the itemKeyStr in radiomap.ftl too? <#if tag.contains(parameters.nameValue, itemKey)> -- Shisei Hanai - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Try the all-new Yahoo! Mail . "The New Version is radically easier to use" The Wall Street Journal
Re: [s2] XWork2 release plan
Okie dokie Rainer. I'll have a go at it, this weekend and comming weekends as well. rgds Rainer Hermanns <[EMAIL PROTECTED]> wrote: Toby, have a look at OS Jira for XWork2... There are some open issues left, mostly regarding the build and release process with maven. I plan to work on these over the coming weekend, but this depends on current project schedules. hth, Rainer > Hi guys, > > What the release plan for xwork2. I think the last time it was discussed, > the main issue holding back the release of xwork2 is the old and outdated > docs. I am working on it for a bit but totally forgotten about it until > Pete ask about the xwork2 release plan in the forum. I could finish it off > this weekend, I think there's just a few more pages to be written. :-) > > Are there any more stuff we need to get done before getting xwork2 out? > > cheers > - > Posted via Jive Forums > http://forums.opensymphony.com/thread.jspa?threadID=49702&messageID=99943#99943 > > > - > 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] Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: Will Struts2 use OGNL as WW did?
> Well, since we have full access to OGNL, why can't we just make the > changes we need? Patrick should be able to hook us up :) Sounds cool. For those who are interested, more info about OGNL could be found at http://www.opensymphony.com/ognl/ rgds Don Brown <[EMAIL PROTECTED]> wrote: tm jee wrote: > Hi guys, > > I think this option is mentioned before in Struts2 maling list (by Ted if not > mistaken). What do you guys think about us forking Ognl? Ognl is just too > important to WebWork/Struts2. > > Thoughts? Good? Bad > Well, since we have full access to OGNL, why can't we just make the changes we need? Patrick should be able to hook us up :) Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Try the all-new Yahoo! Mail . "The New Version is radically easier to use" The Wall Street Journal
Re: Will Struts2 use OGNL as WW did?
sounds ok to me. But are we going to take it out in 2.1.x ? I'd prefer not to. rgds Matt Raible <[EMAIL PROTECTED]> wrote: +1 for restoring "do*". Matt On 11/6/06, Don Brown wrote: > tm jee wrote: > > Hi Vitor, > > > > I think the do fallback was removed from webwork. Have a look at > > http://cwiki.apache.org/confluence/display/WW/Key+Changes+From+WebWork+2 > > for more of the changes from webwork to struts2. > > > Yeah, I'm thinking we should put this back. Struts 2.0.x is about > compatibility, so I think we should be compatible where ever we can. > Perhaps we could throw a warning if it is used, but I think it should be > in there. The do* pattern is too common. > > Don > > > >> Or maybe I did something wrong and I'm totally embarassing myself right > >> now. > >> > > No you are not. :-) > > > > rgds > > > > > > Vitor Souza wrote: > Vitor Souza wrote: > > > >>> However, if you'd like I could create a JIRA (Bugzilla?) issue [...] > >>> > >>> > >> Yes, please create the ticket. Unfortunately, I don't believe there is > >> anyone left who _does_ have enough knowledge of OGNL > >> to truely vet it :( > >> > > > > Ok. I will work on that. I will build a quick example of how it fails to > > attach to the issue and create it ASAP. > > > > Is https://issues.apache.org/struts/browse/WW the right place for this > > issue? Version 2.0.2? > > > > > > > >>> In this thread I mentioned I ran into a new issue, > >>> one that my OGNL hack wasn't enough to fix. It turns > >>> out that it is not true. In fact, the problem was > >>> that I misconfigured Struts2. [...] > >>> > >>> > >> What exactly was the problem with the xwork.xml? I'd > >> like to keep as > >> much backwards compatibility as possible. > >> > > > > In WW2, myaction!input.action called doInput() in the class mapped for the > > action named myaction. In Struts2, it calls input(). Or maybe I did > > something wrong and I'm totally embarassing myself right now. :) > > > > Vitor Souza > > - > > Posted via Jive Forums > > http://forums.opensymphony.com/thread.jspa?threadID=48752&messageID=99725#99725 > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > - > > All new Yahoo! Mail "The new Interface is stunning in its simplicity and > > ease of use." - PC Magazine > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- http://raibledesigns.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: Will Struts2 use OGNL as WW did?
Hi guys, I think this option is mentioned before in Struts2 maling list (by Ted if not mistaken). What do you guys think about us forking Ognl? Ognl is just too important to WebWork/Struts2. Thoughts? Good? Bad? rgds Alexandru Popescu <[EMAIL PROTECTED]> wrote: On 11/6/06, Don Brown wrote: > Vitor Souza wrote: > >> I'd love to have proper generics support in OGNL. If > >> you create an OGNL > >> patch, be sure to let the Struts dev list know so we > >> can ensure it gets in. > >> Don > >> > > > > Don, > > > > I hacked OnglRuntime until it worked, but I don't think I have enough > > knowledge of OGNL and Generics to say that it would work in all cases and > > that it won't break other parts of it. That's the reason I haven't > > submitted it as a patch. > > > > However, if you'd like I could create a JIRA (Bugzilla?) issue and attach > > the changes (which are described here: > > http://forums.opensymphony.com/thread.jspa?threadID=34624&tstart=0) and > > also a small example application that demonstrates the problem. > > > Yes, please create the ticket. Unfortunately, I don't believe there is > anyone left who _does_ have enough knowledge of OGNL to truely vet it :( At some point I was enough familiar with OGNL, but this happened a while ago. And I must confess I am not 100% generics familiar :-S. ./alex -- .w( the_mindstorm )p. > > In this thread I mentioned I ran into a new issue, one that my OGNL hack > > wasn't enough to fix. It turns out that it is not true. In fact, the > > problem was that I misconfigured Struts2. Apparently, the ActionMapper is > > not the same as WebWork's and using my old xwork.xml configuration wouldn't > > work. After I fixed it, the CRUD operations worked fine on Struts2 (thanks > > to the OGNL hack). > > > What exactly was the problem with the xwork.xml? I'd like to keep as > much backwards compatibility as possible. > > Don > > I have deleted the old files (from previous post) and made available new > > ones, with the application working properly. If anyone would like to see > > it, download http://labes.inf.ufes.br/~vitor/ww_ognl_issue/Cookbook.war and > > run it. You will need a HSQLDB server running with a database called > > "cookbook". The source code is also availabe at > > http://labes.inf.ufes.br/~vitor/ww_ognl_issue/Cookbook.tar.gz (the whole > > Eclipse project). To see the error, delete the folder WEB-INF/classes/ognl > > from the WAR and try the CRUD operations. Last, but not least, I forgot to > > delete struts.locale=pt_BR from WEB-INF/classes/struts.properties. Delete > > it (or change it) so the WebSite won't appear in Portuguese. > > > > Sorry I can't help further, but if any Struts developer would take this > > issue to him(her)self, I'd be glad to assist him(her). I think this is a > > big issue, considering that Struts 2.0 will use OGNL and backwards > > compatibility is taken very seriously, as has been said. > > > > Vitor Souza > > - > > Posted via Jive Forums > > http://forums.opensymphony.com/thread.jspa?threadID=48752&messageID=99628#99628 > > > > > > - > > 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] Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: Will Struts2 use OGNL as WW did?
Hi Vitor, I think the do fallback was removed from webwork. Have a look at http://cwiki.apache.org/confluence/display/WW/Key+Changes+From+WebWork+2 for more of the changes from webwork to struts2. > Or maybe I did something wrong and I'm totally embarassing myself right > now. No you are not. :-) rgds Vitor Souza <[EMAIL PROTECTED]> wrote: > Vitor Souza wrote: > > However, if you'd like I could create a JIRA (Bugzilla?) issue [...] > > > Yes, please create the ticket. Unfortunately, I don't believe there is > anyone left who _does_ have enough knowledge of OGNL > to truely vet it :( Ok. I will work on that. I will build a quick example of how it fails to attach to the issue and create it ASAP. Is https://issues.apache.org/struts/browse/WW the right place for this issue? Version 2.0.2? > > In this thread I mentioned I ran into a new issue, > > one that my OGNL hack wasn't enough to fix. It turns > > out that it is not true. In fact, the problem was > > that I misconfigured Struts2. [...] > > > What exactly was the problem with the xwork.xml? I'd > like to keep as > much backwards compatibility as possible. In WW2, myaction!input.action called doInput() in the class mapped for the action named myaction. In Struts2, it calls input(). Or maybe I did something wrong and I'm totally embarassing myself right now. :) Vitor Souza - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=48752&messageID=99725#99725 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine
Re: ajax tags
Sorry for the delay guys. I see. Thx for the heads up. :-) Haven't tried it on eclipse yet. Rainer have started playing with dojo 0.4 on his local box, will get it and the patches into svn within these few days. Thx Rainer. Cheers. Musachy Barroso <[EMAIL PROTECTED]> wrote: I tried also with similar results(using patch), I tried with eclipse and it worked like a charm. Shame on me :) tm jee wrote: > Hi guys, > > I've tried to apply Musachy's patch on my local machine and the following is > the output. There seems to be some part that failed. Am I patching it wrongly? > > [EMAIL PROTECTED]:~/development/struts2_temp> svn update ./ > At revision 471138. > [EMAIL PROTECTED]:~/development/struts2_temp> patch -p0 < WW-1484.patch > (Stripping trailing CRs from patch.) > patching file apps/showcase/src/main/webapp/ajax/AjaxResult.jsp > (Stripping trailing CRs from patch.) > > patching file > core/src/main/java/org/apache/struts2/components/TabbedPanel.java > (Stripping trailing CRs from patch.) > patching file core/src/main/java/org/apache/struts2/components/TimePicker.java > Hunk #1 FAILED at 25. > 1 out of 1 hunk FAILED -- saving rejects to file > core/src/main/java/org/apache/struts2/components/TimePicker.java.rej > (Stripping trailing CRs from patch.) > patching file > core/src/main/java/org/apache/struts2/views/freemarker/tags/DropdownDateTimePickerModel.java > (Stripping trailing CRs from patch.) > patching file > core/src/main/java/org/apache/struts2/views/freemarker/tags/PanelModel.java > Reversed (or previously applied) patch detected! Assume -R? [n] > Apply anyway? [n] > Skipping patch. > 1 out of 1 hunk ignored -- saving rejects to file > core/src/main/java/org/apache/struts2/views/freemarker/tags/PanelModel.java.rej > (Stripping trailing CRs from patch.) > > > rgds > > > > tm jee wrote: Okie dokie. Thx Musachy. :-) > > Musachy Barroso wrote: I have attached the patch to WW-1484, please note > that it doesn't > include some of the things mentioned in the bug (javadoc-like > documentation for the widgets). This includes > BindDiv, BindAnchor, BindButton, TabbedPannel, DatePicker, TimePicker, > DropDownDateTimePicker(kind of a verbose name right? :)) > > musachy > > tm jee wrote: > >> Done, 2 jira ticket created >> >> http://issues.apache.org/struts/browse/WW-1484 >> - upgrading Struts2 dojo widget that might failed due to upgrading dojo to >> 0.4 >> >> http://issues.apache.org/struts/browse/WW-1485 >> - upgrading Struts2 dojo to 0.4 >> >> Musachy Barroso wrote: yes, I overwrote those bindXs with defineWidget. We >> are going to need >> another bug for the actual upgrade from dojo 0.3 to 0.4(0.4 was released >> today I think). >> >> musachy >> >> tm jee wrote: >> >> >>>> I'm using defineWidget, and it is cool. >>>> >>>> >>>> >>> Yup. Is it that the bind, binddiv, bindanchor etc have been written with >>> dojo.widget.defineWidget? If so, this would be great. :-) I've converter >>> the bind component using defineWidget... but looks like it could be deleted >>> now :-) >>> >>> >>> >>> >>>> I will be looking into hostedqa >>>> >>>> >>>> >>> You could get a free account from Pat at [ plightbo at friendly gmail dot >>> com ] >>> >>> Cheers. >>> >>> >>> Musachy Barroso wrote: I'm using defineWidget, and it is cool. I will be >>> looking into hostedqa >>> given that it is being used in struts already, as per Don's comment >>> somewhere on this thread. >>> >>> musachy >>> >>> tm jee wrote: >>> >>> >>> >>>> Hi guys, >>>> >>>> sorry for jumping into this late. I think we should do the followings for >>>> struts2 dojo widgets. >>>> >>>> - use dojo.widget.defineWidget instead of the old-way of using >>>> dojo.provide, dojo.extends etc. Dojo got most of its widget rewritten >>>> using this way. >>>> >>>> - have struts2 widgets/utils as a separate module and add them in using >>>> dojo.setModulePrefix(...) (0.3) I think the method is renamed in 0.4 and >>>> the concept of module is namespace in 0.4 >>>> >>>> - have javadoc comments in our widget, hopefully it would be eas
Re: ajax tags
Hi guys, I've tried to apply Musachy's patch on my local machine and the following is the output. There seems to be some part that failed. Am I patching it wrongly? [EMAIL PROTECTED]:~/development/struts2_temp> svn update ./ At revision 471138. [EMAIL PROTECTED]:~/development/struts2_temp> patch -p0 < WW-1484.patch (Stripping trailing CRs from patch.) patching file apps/showcase/src/main/webapp/ajax/AjaxResult.jsp (Stripping trailing CRs from patch.) patching file core/src/main/java/org/apache/struts2/components/TabbedPanel.java (Stripping trailing CRs from patch.) patching file core/src/main/java/org/apache/struts2/components/TimePicker.java Hunk #1 FAILED at 25. 1 out of 1 hunk FAILED -- saving rejects to file core/src/main/java/org/apache/struts2/components/TimePicker.java.rej (Stripping trailing CRs from patch.) patching file core/src/main/java/org/apache/struts2/views/freemarker/tags/DropdownDateTimePickerModel.java (Stripping trailing CRs from patch.) patching file core/src/main/java/org/apache/struts2/views/freemarker/tags/PanelModel.java Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file core/src/main/java/org/apache/struts2/views/freemarker/tags/PanelModel.java.rej (Stripping trailing CRs from patch.) .... rgds tm jee <[EMAIL PROTECTED]> wrote: Okie dokie. Thx Musachy. :-) Musachy Barroso wrote: I have attached the patch to WW-1484, please note that it doesn't include some of the things mentioned in the bug (javadoc-like documentation for the widgets). This includes BindDiv, BindAnchor, BindButton, TabbedPannel, DatePicker, TimePicker, DropDownDateTimePicker(kind of a verbose name right? :)) musachy tm jee wrote: > Done, 2 jira ticket created > > http://issues.apache.org/struts/browse/WW-1484 > - upgrading Struts2 dojo widget that might failed due to upgrading dojo to > 0.4 > > http://issues.apache.org/struts/browse/WW-1485 > - upgrading Struts2 dojo to 0.4 > > Musachy Barroso wrote: yes, I overwrote those bindXs with defineWidget. We > are going to need > another bug for the actual upgrade from dojo 0.3 to 0.4(0.4 was released > today I think). > > musachy > > tm jee wrote: > >>> I'm using defineWidget, and it is cool. >>> >>> >> Yup. Is it that the bind, binddiv, bindanchor etc have been written with >> dojo.widget.defineWidget? If so, this would be great. :-) I've converter >> the bind component using defineWidget... but looks like it could be deleted >> now :-) >> >> >> >>> I will be looking into hostedqa >>> >>> >> You could get a free account from Pat at [ plightbo at friendly gmail dot >> com ] >> >> Cheers. >> >> >> Musachy Barroso wrote: I'm using defineWidget, and it is cool. I will be >> looking into hostedqa >> given that it is being used in struts already, as per Don's comment >> somewhere on this thread. >> >> musachy >> >> tm jee wrote: >> >> >>> Hi guys, >>> >>> sorry for jumping into this late. I think we should do the followings for >>> struts2 dojo widgets. >>> >>> - use dojo.widget.defineWidget instead of the old-way of using >>> dojo.provide, dojo.extends etc. Dojo got most of its widget rewritten using >>> this way. >>> >>> - have struts2 widgets/utils as a separate module and add them in using >>> dojo.setModulePrefix(...) (0.3) I think the method is renamed in 0.4 and >>> the concept of module is namespace in 0.4 >>> >>> - have javadoc comments in our widget, hopefully it would be easier to >>> follow and maybe if possible able to generate docs like >>> http://dojotoolkit.org/api But I am not sure about how to do this yet. >>> Definitely interested in finding out more. >>> >>> - have a test folder, like dojo's where we could have pages that test the >>> widget, we could use Pat's product to do test the pages (something like >>> HostedQA or Selenium) >>> >>> What you guys think? :-) >>> >>> Rainer Hermanns wrote: I'll wait for your patch against 0.4 then. >>> As soon as I get it, I'll update Dojo first and commit your patches for >>> the tags separately. >>> >>> just let me know, when you are done :) >>> tia, >>> Rainer >>> >>> >>> >>> >>>> :) I know. What I meant is that it shouldn't be applied yet 'cause I >>
Re: ajax tags
Okie dokie. Thx Musachy. :-) Musachy Barroso <[EMAIL PROTECTED]> wrote: I have attached the patch to WW-1484, please note that it doesn't include some of the things mentioned in the bug (javadoc-like documentation for the widgets). This includes BindDiv, BindAnchor, BindButton, TabbedPannel, DatePicker, TimePicker, DropDownDateTimePicker(kind of a verbose name right? :)) musachy tm jee wrote: > Done, 2 jira ticket created > > http://issues.apache.org/struts/browse/WW-1484 > - upgrading Struts2 dojo widget that might failed due to upgrading dojo to > 0.4 > > http://issues.apache.org/struts/browse/WW-1485 > - upgrading Struts2 dojo to 0.4 > > Musachy Barroso wrote: yes, I overwrote those bindXs with defineWidget. We > are going to need > another bug for the actual upgrade from dojo 0.3 to 0.4(0.4 was released > today I think). > > musachy > > tm jee wrote: > >>> I'm using defineWidget, and it is cool. >>> >>> >> Yup. Is it that the bind, binddiv, bindanchor etc have been written with >> dojo.widget.defineWidget? If so, this would be great. :-) I've converter >> the bind component using defineWidget... but looks like it could be deleted >> now :-) >> >> >> >>> I will be looking into hostedqa >>> >>> >> You could get a free account from Pat at [ plightbo at friendly gmail dot >> com ] >> >> Cheers. >> >> >> Musachy Barroso wrote: I'm using defineWidget, and it is cool. I will be >> looking into hostedqa >> given that it is being used in struts already, as per Don's comment >> somewhere on this thread. >> >> musachy >> >> tm jee wrote: >> >> >>> Hi guys, >>> >>> sorry for jumping into this late. I think we should do the followings for >>> struts2 dojo widgets. >>> >>> - use dojo.widget.defineWidget instead of the old-way of using >>> dojo.provide, dojo.extends etc. Dojo got most of its widget rewritten using >>> this way. >>> >>> - have struts2 widgets/utils as a separate module and add them in using >>> dojo.setModulePrefix(...) (0.3) I think the method is renamed in 0.4 and >>> the concept of module is namespace in 0.4 >>> >>> - have javadoc comments in our widget, hopefully it would be easier to >>> follow and maybe if possible able to generate docs like >>> http://dojotoolkit.org/api But I am not sure about how to do this yet. >>> Definitely interested in finding out more. >>> >>> - have a test folder, like dojo's where we could have pages that test the >>> widget, we could use Pat's product to do test the pages (something like >>> HostedQA or Selenium) >>> >>> What you guys think? :-) >>> >>> Rainer Hermanns wrote: I'll wait for your patch against 0.4 then. >>> As soon as I get it, I'll update Dojo first and commit your patches for >>> the tags separately. >>> >>> just let me know, when you are done :) >>> tia, >>> Rainer >>> >>> >>> >>> >>>> :) I know. What I meant is that it shouldn't be applied yet 'cause I >>>> made it using 0.3 and I haven't tried it on 0.4 yet. >>>> >>>> musachy >>>> >>>> Martin Cooper wrote: >>>> >>>> >>>> >>>>> On 10/30/06, Musachy Barroso wrote: >>>>> >>>>> >>>>> >>>>>> Oh, ok. Then just don't apply the patch. >>>>>> >>>>>> >>>>>> >>>>> No, no - I'm not saying that it shouldn't be applied, only that it >>>>> should be >>>>> a separate commit. >>>>> >>>>> By the way, do we have a Jira >>>>> >>>>> >>>>> >>>>>> issue for the dojo upgrade? >>>>>> >>>>>> >>>>>> >>>>> Not that I can see. Feel free to add one, and one with your patch, if >>>>> there >>>>> isn't one already. >>>>> >>>>> -- >>>>> Martin. >>>>> >>>>> >>>>> musachy >>>>>
Re: Our continuum instance is back up
and keep careless developer like me to make sure the test case passed and things run smoothly before commiting James Mitchell <[EMAIL PROTECTED]> wrote: and do the nightly distribution -- James Mitchell 678.910.8017 On Nov 1, 2006, at 5:10 AM, James Mitchell wrote: > http://struts.zones.apache.org:8080/continuum/ > > I had to fix all of the s1 pom scm references, which, I hope, > doesn't break anything else.(Wendy???) :D > > Now we just need to have Continuum nag us on build failures. > > > -- > James Mitchell > 678.910.8017 > > > > > > - > 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] Send instant messages to your online friends http://uk.messenger.yahoo.com
[s2][Improvement] ActionContextCleanUp and FilterDispatcher
Hi, Both filter, ActionContextCleanUp and FilterDispatcher contains some similar logic which I think would be more appropriate if we move them to an abstract superclass, maybe called AbstractFilterDispatcher. Some of the logics are - creation of a Dispatcher - populating the created Dispatcher to Dispatcher's ThreadLocal - using Dispatcher prepare method. rgds Send instant messages to your online friends http://uk.messenger.yahoo.com
[s2] [Idea] CompositeActionMapper
Hi guys, What do you guys think about having a CompositeActionMapper that allows one of the many ActionMapper it has to being used. 1 +-+ +| ActionMapper | |+-+ |^ || | +-- || | | +--+-+ +---+-+ | CompositeActionMapper | |DefaultActionMapper | M +-+ +--+ The configuration could be done in struts.properties eg. struts.mapper.class=foo.bar.CompositeActionMapper struts.mapper.composite.1=foo.bar.MyActionMapper struts.mapper.composite.2=foo.bar.DefaultActionMapper With this we got 2 action mapper which get called in turns to see if they are able to produce an ActionMappings. Thoughts? good, bad, feasible? rgds - All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine
Re: ajax tags
I think ToggleBindDiv.js and DynArchCalendar.js are not used. We could update them if we wish later once we got the main ones in (eg. BindDiv which ToggleBindDiv extends from) Musachy Barroso <[EMAIL PROTECTED]> wrote: I just finished with DatePicker and DropdownDatePicker. The ones missing are ToggleBindDiv.js, DynArchCalendar.js, and TimePicker, I think only TimerPicker is important(I need to add DropDownTimePicker), which I could get done by Wednesday or Thursday. musachy On 10/31/06, tm jee wrote: > > Hi Ian, > > > Have we cut the 2.0.1 beta yet? > I think we have the 2.0.1 release, its now open for quality voting. If we > do another release it would be 2.0.2. So i guess the answer would be > "yes". Do correct me if I am wrong, Ted, Don :-) > > > My preference would also be to have the dojo 0.4 > > update, together with all the existing tags working with 0.4 available, > > but to commit them separately. This way we only need to fix bugs, > > rather than convert failing UI widgets that the user community may be > > relying on. > > I think Musachy have converted all of them, just that they are not > commited yet. If we are to do it this way, i guess we'll need Musachy to > have all the patches ready. Then we could upgrade dojo to 0.4 in one > commit, and one commit for each widget/component etc. > > Thoughts? > > > > > Ian Roughley wrote: Sorry for the late reply - vacation. > > Have we cut the 2.0.1 beta yet? If not, we should wait until then > before this update. My preference would also be to have the dojo 0.4 > update, together with all the existing tags working with 0.4 available, > but to commit them separately. This way we only need to fix bugs, > rather than convert failing UI widgets that the user community may be > relying on. > > /Ian > > -- > From Down & Around, Inc. > Innovative IT Solutions > Software Architecture * Design * Development > ~~~~~~~~~ > web: www.fdar.com > email [EMAIL PROTECTED] > phone:617.821.5430 > ~ > > > > tm jee wrote: > > Hi guys, > > > > If its ok with everyone, I'd like to upgrade Struts2 dojo js to 0.4, > sometime today or tomorrow. (WW-1845). This will most likely breaks some > existing struts2 components. We will patch them up individually (WW-1844) > > > > Cheers > > > > > > tm jee wrote: Done, 2 jira ticket created > > > > http://issues.apache.org/struts/browse/WW-1484 > > - upgrading Struts2 dojo widget that might failed due to upgrading dojo > to 0.4 > > > > http://issues.apache.org/struts/browse/WW-1485 > > - upgrading Struts2 dojo to 0.4 > > > > Musachy Barroso wrote: yes, I overwrote those bindXs with > defineWidget. We are going to need > > another bug for the actual upgrade from dojo 0.3 to 0.4(0.4 was released > > today I think). > > > > musachy > > > > tm jee wrote: > > > >>> I'm using defineWidget, and it is cool. > >>> > >>> > >> Yup. Is it that the bind, binddiv, bindanchor etc have been written > with dojo.widget.defineWidget? If so, this would be great. :-) I've > converter the bind component using defineWidget... but looks like it could > be deleted now :-) > >> > >> > >> > >>> I will be looking into hostedqa > >>> > >>> > >> You could get a free account from Pat at [ plightbo at friendly gmail > dot com ] > >> > >> Cheers. > >> > >> > >> Musachy Barroso wrote: I'm using defineWidget, and it is cool. I will > be looking into hostedqa > >> given that it is being used in struts already, as per Don's comment > >> somewhere on this thread. > >> > >> musachy > >> > >> tm jee wrote: > >> > >> > >>> Hi guys, > >>> > >>> sorry for jumping into this late. I think we should do the followings > for struts2 dojo widgets. > >>> > >>> - use dojo.widget.defineWidget instead of the old-way of using > dojo.provide, dojo.extends etc. Dojo got most of its widget rewritten > using this way. > >>> > >>> - have struts2 widgets/utils as a separate module and add them in > using dojo.setModulePrefix(...) (0.3) I think the method is renamed in 0.4and > the concept of module is namespace in > 0.4 > >>> > >>> - have javadoc comments in our widget, hopefully it would be easier to > follow and maybe if possible able to generate
Re: ajax tags
Hi Ian, > Have we cut the 2.0.1 beta yet? I think we have the 2.0.1 release, its now open for quality voting. If we do another release it would be 2.0.2. So i guess the answer would be "yes". Do correct me if I am wrong, Ted, Don :-) > My preference would also be to have the dojo 0.4 > update, together with all the existing tags working with 0.4 available, > but to commit them separately. This way we only need to fix bugs, > rather than convert failing UI widgets that the user community may be > relying on. I think Musachy have converted all of them, just that they are not commited yet. If we are to do it this way, i guess we'll need Musachy to have all the patches ready. Then we could upgrade dojo to 0.4 in one commit, and one commit for each widget/component etc. Thoughts? Ian Roughley <[EMAIL PROTECTED]> wrote: Sorry for the late reply - vacation. Have we cut the 2.0.1 beta yet? If not, we should wait until then before this update. My preference would also be to have the dojo 0.4 update, together with all the existing tags working with 0.4 available, but to commit them separately. This way we only need to fix bugs, rather than convert failing UI widgets that the user community may be relying on. /Ian -- >From Down & Around, Inc. Innovative IT Solutions Software Architecture * Design * Development ~ web: www.fdar.com email [EMAIL PROTECTED] phone:617.821.5430 ~~~~~~~~~ tm jee wrote: > Hi guys, > > If its ok with everyone, I'd like to upgrade Struts2 dojo js to 0.4, sometime > today or tomorrow. (WW-1845). This will most likely breaks some existing > struts2 components. We will patch them up individually (WW-1844) > > Cheers > > > tm jee wrote: Done, 2 jira ticket created > > http://issues.apache.org/struts/browse/WW-1484 > - upgrading Struts2 dojo widget that might failed due to upgrading dojo to > 0.4 > > http://issues.apache.org/struts/browse/WW-1485 > - upgrading Struts2 dojo to 0.4 > > Musachy Barroso wrote: yes, I overwrote those bindXs with defineWidget. We > are going to need > another bug for the actual upgrade from dojo 0.3 to 0.4(0.4 was released > today I think). > > musachy > > tm jee wrote: > >>> I'm using defineWidget, and it is cool. >>> >>> >> Yup. Is it that the bind, binddiv, bindanchor etc have been written with >> dojo.widget.defineWidget? If so, this would be great. :-) I've converter >> the bind component using defineWidget... but looks like it could be deleted >> now :-) >> >> >> >>> I will be looking into hostedqa >>> >>> >> You could get a free account from Pat at [ plightbo at friendly gmail dot >> com ] >> >> Cheers. >> >> >> Musachy Barroso wrote: I'm using defineWidget, and it is cool. I will be >> looking into hostedqa >> given that it is being used in struts already, as per Don's comment >> somewhere on this thread. >> >> musachy >> >> tm jee wrote: >> >> >>> Hi guys, >>> >>> sorry for jumping into this late. I think we should do the followings for >>> struts2 dojo widgets. >>> >>> - use dojo.widget.defineWidget instead of the old-way of using >>> dojo.provide, dojo.extends etc. Dojo got most of its widget rewritten using >>> this way. >>> >>> - have struts2 widgets/utils as a separate module and add them in using >>> dojo.setModulePrefix(...) (0.3) I think the method is renamed in 0.4 and >>> the concept of module is namespace in 0.4 >>> >>> - have javadoc comments in our widget, hopefully it would be easier to >>> follow and maybe if possible able to generate docs like >>> http://dojotoolkit.org/api But I am not sure about how to do this yet. >>> Definitely interested in finding out more. >>> >>> - have a test folder, like dojo's where we could have pages that test the >>> widget, we could use Pat's product to do test the pages (something like >>> HostedQA or Selenium) >>> >>> What you guys think? :-) >>> >>> Rainer Hermanns wrote: I'll wait for your patch against 0.4 then. >>> As soon as I get it, I'll update Dojo first and commit your patches for >>> the tags separately. >>> >>> just let me know, when you are done :) >>> tia, >>> Rainer >>> >>>
Re: ajax tags
Hi guys, If its ok with everyone, I'd like to upgrade Struts2 dojo js to 0.4, sometime today or tomorrow. (WW-1845). This will most likely breaks some existing struts2 components. We will patch them up individually (WW-1844) Cheers tm jee <[EMAIL PROTECTED]> wrote: Done, 2 jira ticket created http://issues.apache.org/struts/browse/WW-1484 - upgrading Struts2 dojo widget that might failed due to upgrading dojo to 0.4 http://issues.apache.org/struts/browse/WW-1485 - upgrading Struts2 dojo to 0.4 Musachy Barroso wrote: yes, I overwrote those bindXs with defineWidget. We are going to need another bug for the actual upgrade from dojo 0.3 to 0.4(0.4 was released today I think). musachy tm jee wrote: >> I'm using defineWidget, and it is cool. >> > Yup. Is it that the bind, binddiv, bindanchor etc have been written with > dojo.widget.defineWidget? If so, this would be great. :-) I've converter the > bind component using defineWidget... but looks like it could be deleted > now :-) > > >> I will be looking into hostedqa >> > You could get a free account from Pat at [ plightbo at friendly gmail dot com > ] > > Cheers. > > > Musachy Barroso wrote: I'm using defineWidget, and it is cool. I will be > looking into hostedqa > given that it is being used in struts already, as per Don's comment > somewhere on this thread. > > musachy > > tm jee wrote: > >> Hi guys, >> >> sorry for jumping into this late. I think we should do the followings for >> struts2 dojo widgets. >> >> - use dojo.widget.defineWidget instead of the old-way of using dojo.provide, >> dojo.extends etc. Dojo got most of its widget rewritten using this way. >> >> - have struts2 widgets/utils as a separate module and add them in using >> dojo.setModulePrefix(...) (0.3) I think the method is renamed in 0.4 and the >> concept of module is namespace in 0.4 >> >> - have javadoc comments in our widget, hopefully it would be easier to >> follow and maybe if possible able to generate docs like >> http://dojotoolkit.org/api But I am not sure about how to do this yet. >> Definitely interested in finding out more. >> >> - have a test folder, like dojo's where we could have pages that test the >> widget, we could use Pat's product to do test the pages (something like >> HostedQA or Selenium) >> >> What you guys think? :-) >> >> Rainer Hermanns wrote: I'll wait for your patch against 0.4 then. >> As soon as I get it, I'll update Dojo first and commit your patches for >> the tags separately. >> >> just let me know, when you are done :) >> tia, >> Rainer >> >> >> >>> :) I know. What I meant is that it shouldn't be applied yet 'cause I >>> made it using 0.3 and I haven't tried it on 0.4 yet. >>> >>> musachy >>> >>> Martin Cooper wrote: >>> >>> >>>> On 10/30/06, Musachy Barroso wrote: >>>> >>>> >>>>> Oh, ok. Then just don't apply the patch. >>>>> >>>>> >>>> No, no - I'm not saying that it shouldn't be applied, only that it >>>> should be >>>> a separate commit. >>>> >>>> By the way, do we have a Jira >>>> >>>> >>>>> issue for the dojo upgrade? >>>>> >>>>> >>>> Not that I can see. Feel free to add one, and one with your patch, if >>>> there >>>> isn't one already. >>>> >>>> -- >>>> Martin. >>>> >>>> >>>> musachy >>>> >>>> >>>>> Martin Cooper wrote: >>>>> >>>>> >>>>>> On 10/30/06, Musachy Barroso wrote: >>>>>> >>>>>> >>>>>>> Hi Rainer >>>>>>> >>>>>>> Give me a couple of days so I can test it against 0.4 (I made the >>>>>>> >>>>>>> >>>>> patch >>>>> >>>>> >>>>>>> using 0.3) and finish some changes(for BindButton) that I have for a >>>>>>> >>>>>>> >>>>> new &
Re: ajax tags
Done, 2 jira ticket created http://issues.apache.org/struts/browse/WW-1484 - upgrading Struts2 dojo widget that might failed due to upgrading dojo to 0.4 http://issues.apache.org/struts/browse/WW-1485 - upgrading Struts2 dojo to 0.4 Musachy Barroso <[EMAIL PROTECTED]> wrote: yes, I overwrote those bindXs with defineWidget. We are going to need another bug for the actual upgrade from dojo 0.3 to 0.4(0.4 was released today I think). musachy tm jee wrote: >> I'm using defineWidget, and it is cool. >> > Yup. Is it that the bind, binddiv, bindanchor etc have been written with > dojo.widget.defineWidget? If so, this would be great. :-) I've converter the > bind component using defineWidget... but looks like it could be deleted > now :-) > > >> I will be looking into hostedqa >> > You could get a free account from Pat at [ plightbo at friendly gmail dot com > ] > > Cheers. > > > Musachy Barroso wrote: I'm using defineWidget, and it is cool. I will be > looking into hostedqa > given that it is being used in struts already, as per Don's comment > somewhere on this thread. > > musachy > > tm jee wrote: > >> Hi guys, >> >> sorry for jumping into this late. I think we should do the followings for >> struts2 dojo widgets. >> >> - use dojo.widget.defineWidget instead of the old-way of using dojo.provide, >> dojo.extends etc. Dojo got most of its widget rewritten using this way. >> >> - have struts2 widgets/utils as a separate module and add them in using >> dojo.setModulePrefix(...) (0.3) I think the method is renamed in 0.4 and the >> concept of module is namespace in 0.4 >> >> - have javadoc comments in our widget, hopefully it would be easier to >> follow and maybe if possible able to generate docs like >> http://dojotoolkit.org/api But I am not sure about how to do this yet. >> Definitely interested in finding out more. >> >> - have a test folder, like dojo's where we could have pages that test the >> widget, we could use Pat's product to do test the pages (something like >> HostedQA or Selenium) >> >> What you guys think? :-) >> >> Rainer Hermanns wrote: I'll wait for your patch against 0.4 then. >> As soon as I get it, I'll update Dojo first and commit your patches for >> the tags separately. >> >> just let me know, when you are done :) >> tia, >> Rainer >> >> >> >>> :) I know. What I meant is that it shouldn't be applied yet 'cause I >>> made it using 0.3 and I haven't tried it on 0.4 yet. >>> >>> musachy >>> >>> Martin Cooper wrote: >>> >>> >>>> On 10/30/06, Musachy Barroso wrote: >>>> >>>> >>>>> Oh, ok. Then just don't apply the patch. >>>>> >>>>> >>>> No, no - I'm not saying that it shouldn't be applied, only that it >>>> should be >>>> a separate commit. >>>> >>>> By the way, do we have a Jira >>>> >>>> >>>>> issue for the dojo upgrade? >>>>> >>>>> >>>> Not that I can see. Feel free to add one, and one with your patch, if >>>> there >>>> isn't one already. >>>> >>>> -- >>>> Martin. >>>> >>>> >>>> musachy >>>> >>>> >>>>> Martin Cooper wrote: >>>>> >>>>> >>>>>> On 10/30/06, Musachy Barroso wrote: >>>>>> >>>>>> >>>>>>> Hi Rainer >>>>>>> >>>>>>> Give me a couple of days so I can test it against 0.4 (I made the >>>>>>> >>>>>>> >>>>> patch >>>>> >>>>> >>>>>>> using 0.3) and finish some changes(for BindButton) that I have for a >>>>>>> >>>>>>> >>>>> new >>>>> >>>>> >>>>>>> patch. I will give you a new patch soon with the changes for Bind, >>>>>>> BindDiv, BindAnchor, BindButton and TabbedPane
Re: ajax tags
Hi guys, I've go ahead and added a jira issue for struts2 dojo migration, Its at http://issues.apache.org/struts/browse/WW-1484 rgds Musachy Barroso <[EMAIL PROTECTED]> wrote: I'm using defineWidget, and it is cool. I will be looking into hostedqa given that it is being used in struts already, as per Don's comment somewhere on this thread. musachy tm jee wrote: > Hi guys, > > sorry for jumping into this late. I think we should do the followings for > struts2 dojo widgets. > > - use dojo.widget.defineWidget instead of the old-way of using dojo.provide, > dojo.extends etc. Dojo got most of its widget rewritten using this way. > > - have struts2 widgets/utils as a separate module and add them in using > dojo.setModulePrefix(...) (0.3) I think the method is renamed in 0.4 and the > concept of module is namespace in 0.4 > > - have javadoc comments in our widget, hopefully it would be easier to follow > and maybe if possible able to generate docs like http://dojotoolkit.org/api > But I am not sure about how to do this yet. Definitely interested in finding > out more. > > - have a test folder, like dojo's where we could have pages that test the > widget, we could use Pat's product to do test the pages (something like > HostedQA or Selenium) > > What you guys think? :-) > > Rainer Hermanns wrote: I'll wait for your patch against 0.4 then. > As soon as I get it, I'll update Dojo first and commit your patches for > the tags separately. > > just let me know, when you are done :) > tia, > Rainer > > >> :) I know. What I meant is that it shouldn't be applied yet 'cause I >> made it using 0.3 and I haven't tried it on 0.4 yet. >> >> musachy >> >> Martin Cooper wrote: >> >>> On 10/30/06, Musachy Barroso wrote: >>> >>>> Oh, ok. Then just don't apply the patch. >>>> >>> No, no - I'm not saying that it shouldn't be applied, only that it >>> should be >>> a separate commit. >>> >>> By the way, do we have a Jira >>> >>>> issue for the dojo upgrade? >>>> >>> Not that I can see. Feel free to add one, and one with your patch, if >>> there >>> isn't one already. >>> >>> -- >>> Martin. >>> >>> >>> musachy >>> >>>> Martin Cooper wrote: >>>> >>>>> On 10/30/06, Musachy Barroso wrote: >>>>> >>>>>> Hi Rainer >>>>>> >>>>>> Give me a couple of days so I can test it against 0.4 (I made the >>>>>> >>>> patch >>>> >>>>>> using 0.3) and finish some changes(for BindButton) that I have for a >>>>>> >>>> new >>>> >>>>>> patch. I will give you a new patch soon with the changes for Bind, >>>>>> BindDiv, BindAnchor, BindButton and TabbedPanel tested on dojo >>>>>> >>>> 0.4. If >>>> >>>>>> you want to go ahead and upgrade to 0.4 and apply the patch later, >>>>>> that's fine. (I will just be bothering with another patch soon :) ) >>>>>> >>>>> Well, the upgrade and the patch should certainly be separate >>>>> >>>> commits, so >>>> >>>>> that we can track the changes separately, and so that we can revert >>>>> one or >>>>> the other if that ever becomes necessary. Beyond that, it's up to the >>>>> prospective committer to determine timing. ;-) >>>>> >>>>> -- >>>>> Martin Cooper >>>>> >>>>> >>>>> musachy >>>>> >>>>>> Rainer Hermanns wrote: >>>>>> >>>>>>> Musachy, >>>>>>> >>>>>>> I could upgrade the embedded Dojo files to the 0.4 release >>>>>>> >>>> during the >>>> >>>>>> week. >>>>>> >>>>>>> If your patches for the s2 ajax tags already are against the >>>>>>> >>>>>> 0.4release, >>>>>> >>>>>>> I could apply those as well. >&
Re: ajax tags
> I'm using defineWidget, and it is cool. Yup. Is it that the bind, binddiv, bindanchor etc have been written with dojo.widget.defineWidget? If so, this would be great. :-) I've converter the bind component using defineWidget... but looks like it could be deleted now :-) > I will be looking into hostedqa You could get a free account from Pat at [ plightbo at friendly gmail dot com ] Cheers. Musachy Barroso <[EMAIL PROTECTED]> wrote: I'm using defineWidget, and it is cool. I will be looking into hostedqa given that it is being used in struts already, as per Don's comment somewhere on this thread. musachy tm jee wrote: > Hi guys, > > sorry for jumping into this late. I think we should do the followings for > struts2 dojo widgets. > > - use dojo.widget.defineWidget instead of the old-way of using dojo.provide, > dojo.extends etc. Dojo got most of its widget rewritten using this way. > > - have struts2 widgets/utils as a separate module and add them in using > dojo.setModulePrefix(...) (0.3) I think the method is renamed in 0.4 and the > concept of module is namespace in 0.4 > > - have javadoc comments in our widget, hopefully it would be easier to follow > and maybe if possible able to generate docs like http://dojotoolkit.org/api > But I am not sure about how to do this yet. Definitely interested in finding > out more. > > - have a test folder, like dojo's where we could have pages that test the > widget, we could use Pat's product to do test the pages (something like > HostedQA or Selenium) > > What you guys think? :-) > > Rainer Hermanns wrote: I'll wait for your patch against 0.4 then. > As soon as I get it, I'll update Dojo first and commit your patches for > the tags separately. > > just let me know, when you are done :) > tia, > Rainer > > >> :) I know. What I meant is that it shouldn't be applied yet 'cause I >> made it using 0.3 and I haven't tried it on 0.4 yet. >> >> musachy >> >> Martin Cooper wrote: >> >>> On 10/30/06, Musachy Barroso wrote: >>> >>>> Oh, ok. Then just don't apply the patch. >>>> >>> No, no - I'm not saying that it shouldn't be applied, only that it >>> should be >>> a separate commit. >>> >>> By the way, do we have a Jira >>> >>>> issue for the dojo upgrade? >>>> >>> Not that I can see. Feel free to add one, and one with your patch, if >>> there >>> isn't one already. >>> >>> -- >>> Martin. >>> >>> >>> musachy >>> >>>> Martin Cooper wrote: >>>> >>>>> On 10/30/06, Musachy Barroso wrote: >>>>> >>>>>> Hi Rainer >>>>>> >>>>>> Give me a couple of days so I can test it against 0.4 (I made the >>>>>> >>>> patch >>>> >>>>>> using 0.3) and finish some changes(for BindButton) that I have for a >>>>>> >>>> new >>>> >>>>>> patch. I will give you a new patch soon with the changes for Bind, >>>>>> BindDiv, BindAnchor, BindButton and TabbedPanel tested on dojo >>>>>> >>>> 0.4. If >>>> >>>>>> you want to go ahead and upgrade to 0.4 and apply the patch later, >>>>>> that's fine. (I will just be bothering with another patch soon :) ) >>>>>> >>>>> Well, the upgrade and the patch should certainly be separate >>>>> >>>> commits, so >>>> >>>>> that we can track the changes separately, and so that we can revert >>>>> one or >>>>> the other if that ever becomes necessary. Beyond that, it's up to the >>>>> prospective committer to determine timing. ;-) >>>>> >>>>> -- >>>>> Martin Cooper >>>>> >>>>> >>>>> musachy >>>>> >>>>>> Rainer Hermanns wrote: >>>>>> >>>>>>> Musachy, >>>>>>> >>>>>>> I could upgrade the embedded Dojo files to the 0.4 release >>>>>>> >>>> during the >>>> >>>>>> week. >>>>>>
Re: ajax tags
Hi guys, I've go ahead and added a jira issue for struts2 dojo migration, Its at http://issues.apache.org/struts/browse/WW-1484 rgds Musachy Barroso <[EMAIL PROTECTED]> wrote: I'm using defineWidget, and it is cool. I will be looking into hostedqa given that it is being used in struts already, as per Don's comment somewhere on this thread. musachy tm jee wrote: > Hi guys, > > sorry for jumping into this late. I think we should do the followings for > struts2 dojo widgets. > > - use dojo.widget.defineWidget instead of the old-way of using dojo.provide, > dojo.extends etc. Dojo got most of its widget rewritten using this way. > > - have struts2 widgets/utils as a separate module and add them in using > dojo.setModulePrefix(...) (0.3) I think the method is renamed in 0.4 and the > concept of module is namespace in 0.4 > > - have javadoc comments in our widget, hopefully it would be easier to follow > and maybe if possible able to generate docs like http://dojotoolkit.org/api > But I am not sure about how to do this yet. Definitely interested in finding > out more. > > - have a test folder, like dojo's where we could have pages that test the > widget, we could use Pat's product to do test the pages (something like > HostedQA or Selenium) > > What you guys think? :-) > > Rainer Hermanns wrote: I'll wait for your patch against 0.4 then. > As soon as I get it, I'll update Dojo first and commit your patches for > the tags separately. > > just let me know, when you are done :) > tia, > Rainer > > >> :) I know. What I meant is that it shouldn't be applied yet 'cause I >> made it using 0.3 and I haven't tried it on 0.4 yet. >> >> musachy >> >> Martin Cooper wrote: >> >>> On 10/30/06, Musachy Barroso wrote: >>> >>>> Oh, ok. Then just don't apply the patch. >>>> >>> No, no - I'm not saying that it shouldn't be applied, only that it >>> should be >>> a separate commit. >>> >>> By the way, do we have a Jira >>> >>>> issue for the dojo upgrade? >>>> >>> Not that I can see. Feel free to add one, and one with your patch, if >>> there >>> isn't one already. >>> >>> -- >>> Martin. >>> >>> >>> musachy >>> >>>> Martin Cooper wrote: >>>> >>>>> On 10/30/06, Musachy Barroso wrote: >>>>> >>>>>> Hi Rainer >>>>>> >>>>>> Give me a couple of days so I can test it against 0.4 (I made the >>>>>> >>>> patch >>>> >>>>>> using 0.3) and finish some changes(for BindButton) that I have for a >>>>>> >>>> new >>>> >>>>>> patch. I will give you a new patch soon with the changes for Bind, >>>>>> BindDiv, BindAnchor, BindButton and TabbedPanel tested on dojo >>>>>> >>>> 0.4. If >>>> >>>>>> you want to go ahead and upgrade to 0.4 and apply the patch later, >>>>>> that's fine. (I will just be bothering with another patch soon :) ) >>>>>> >>>>> Well, the upgrade and the patch should certainly be separate >>>>> >>>> commits, so >>>> >>>>> that we can track the changes separately, and so that we can revert >>>>> one or >>>>> the other if that ever becomes necessary. Beyond that, it's up to the >>>>> prospective committer to determine timing. ;-) >>>>> >>>>> -- >>>>> Martin Cooper >>>>> >>>>> >>>>> musachy >>>>> >>>>>> Rainer Hermanns wrote: >>>>>> >>>>>>> Musachy, >>>>>>> >>>>>>> I could upgrade the embedded Dojo files to the 0.4 release >>>>>>> >>>> during the >>>> >>>>>> week. >>>>>> >>>>>>> If your patches for the s2 ajax tags already are against the >>>>>>> >>>>>> 0.4release, >>>>>> >>>>>>> I could apply those as well. >&
Re: ajax tags
> I'm using defineWidget, and it is cool. Yup. Is it that the bind, binddiv, bindanchor etc have been written with dojo.widget.defineWidget? If so, this would be great. :-) I've converter the bind component using defineWidget... but looks like it could be deleted now :-) > I will be looking into hostedqa You could get a free account from Pat at [ plightbo at friendly gmail dot com ] Cheers. Musachy Barroso <[EMAIL PROTECTED]> wrote: I'm using defineWidget, and it is cool. I will be looking into hostedqa given that it is being used in struts already, as per Don's comment somewhere on this thread. musachy tm jee wrote: > Hi guys, > > sorry for jumping into this late. I think we should do the followings for > struts2 dojo widgets. > > - use dojo.widget.defineWidget instead of the old-way of using dojo.provide, > dojo.extends etc. Dojo got most of its widget rewritten using this way. > > - have struts2 widgets/utils as a separate module and add them in using > dojo.setModulePrefix(...) (0.3) I think the method is renamed in 0.4 and the > concept of module is namespace in 0.4 > > - have javadoc comments in our widget, hopefully it would be easier to follow > and maybe if possible able to generate docs like http://dojotoolkit.org/api > But I am not sure about how to do this yet. Definitely interested in finding > out more. > > - have a test folder, like dojo's where we could have pages that test the > widget, we could use Pat's product to do test the pages (something like > HostedQA or Selenium) > > What you guys think? :-) > > Rainer Hermanns wrote: I'll wait for your patch against 0.4 then. > As soon as I get it, I'll update Dojo first and commit your patches for > the tags separately. > > just let me know, when you are done :) > tia, > Rainer > > >> :) I know. What I meant is that it shouldn't be applied yet 'cause I >> made it using 0.3 and I haven't tried it on 0.4 yet. >> >> musachy >> >> Martin Cooper wrote: >> >>> On 10/30/06, Musachy Barroso wrote: >>> >>>> Oh, ok. Then just don't apply the patch. >>>> >>> No, no - I'm not saying that it shouldn't be applied, only that it >>> should be >>> a separate commit. >>> >>> By the way, do we have a Jira >>> >>>> issue for the dojo upgrade? >>>> >>> Not that I can see. Feel free to add one, and one with your patch, if >>> there >>> isn't one already. >>> >>> -- >>> Martin. >>> >>> >>> musachy >>> >>>> Martin Cooper wrote: >>>> >>>>> On 10/30/06, Musachy Barroso wrote: >>>>> >>>>>> Hi Rainer >>>>>> >>>>>> Give me a couple of days so I can test it against 0.4 (I made the >>>>>> >>>> patch >>>> >>>>>> using 0.3) and finish some changes(for BindButton) that I have for a >>>>>> >>>> new >>>> >>>>>> patch. I will give you a new patch soon with the changes for Bind, >>>>>> BindDiv, BindAnchor, BindButton and TabbedPanel tested on dojo >>>>>> >>>> 0.4. If >>>> >>>>>> you want to go ahead and upgrade to 0.4 and apply the patch later, >>>>>> that's fine. (I will just be bothering with another patch soon :) ) >>>>>> >>>>> Well, the upgrade and the patch should certainly be separate >>>>> >>>> commits, so >>>> >>>>> that we can track the changes separately, and so that we can revert >>>>> one or >>>>> the other if that ever becomes necessary. Beyond that, it's up to the >>>>> prospective committer to determine timing. ;-) >>>>> >>>>> -- >>>>> Martin Cooper >>>>> >>>>> >>>>> musachy >>>>> >>>>>> Rainer Hermanns wrote: >>>>>> >>>>>>> Musachy, >>>>>>> >>>>>>> I could upgrade the embedded Dojo files to the 0.4 release >>>>>>> >>>> during the >>>> >>>>>> week. >>>>>>
Re: [Proposal] Struts 2 Result Selectors
Hi guys,
Is it possible to have something like
o.a.s.d.RoleMatcher
o.a.s.d.AgentMatchero.a.s.d.ServletDispatcherResult
so that we don't need to introduce another class attribute to the param tag.
Thoughts? :-)
"David H. DeWolf" <[EMAIL PROTECTED]> wrote: YES! I like that. This seems to
reduce the extra complexity from the
config but still provides the flexibility we're looking for.
David
Ted Husted wrote:
> On 10/26/06, Don Brown wrote:
>> Then, each result selector is given a chance to select a single String.
>> If a result has when="modern-browser,partial-html",
>> the each selector will be given a chance to return its "when" token, and
>> xwork will match them together as AND.
>
> Or, with wildcards ...
>
>
>
>
>
>
>/{1}{result-code}{role}{agent}.jsp
>
>/{1}-error.jsp
>
>
>
> Each "matcher" could add a named token into the context, like
> "-manager". The selector result could then resolve the wildcard path
> and delegate to another Result, like the default ServletDispatcher
> Result. The matchers might not inject a token, if it was the default
> or didn't apply for some reason.
>
> So, an application using this strategy might have pages named like.
>
> * ViewFoo.jsp
> * ViewFoo-netscape4.jsp
> * ViewFoo-manager.jsp
> * ViewFoo-manager-netscape4.jsp
> * ViewFoo-failure.jsp
>
> Of course, this strategy presupposes using something like SiteMesh or
> Tiles to provide the standard layout, so that each "page" can just
> focus on it's own content.
>
> -T.
>
> -
> 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]
Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: ajax tags
Hi guys, sorry for jumping into this late. I think we should do the followings for struts2 dojo widgets. - use dojo.widget.defineWidget instead of the old-way of using dojo.provide, dojo.extends etc. Dojo got most of its widget rewritten using this way. - have struts2 widgets/utils as a separate module and add them in using dojo.setModulePrefix(...) (0.3) I think the method is renamed in 0.4 and the concept of module is namespace in 0.4 - have javadoc comments in our widget, hopefully it would be easier to follow and maybe if possible able to generate docs like http://dojotoolkit.org/api But I am not sure about how to do this yet. Definitely interested in finding out more. - have a test folder, like dojo's where we could have pages that test the widget, we could use Pat's product to do test the pages (something like HostedQA or Selenium) What you guys think? :-) Rainer Hermanns <[EMAIL PROTECTED]> wrote: I'll wait for your patch against 0.4 then. As soon as I get it, I'll update Dojo first and commit your patches for the tags separately. just let me know, when you are done :) tia, Rainer > :) I know. What I meant is that it shouldn't be applied yet 'cause I > made it using 0.3 and I haven't tried it on 0.4 yet. > > musachy > > Martin Cooper wrote: >> On 10/30/06, Musachy Barroso wrote: >>> >>> Oh, ok. Then just don't apply the patch. >> >> >> No, no - I'm not saying that it shouldn't be applied, only that it >> should be >> a separate commit. >> >> By the way, do we have a Jira >>> issue for the dojo upgrade? >> >> >> Not that I can see. Feel free to add one, and one with your patch, if >> there >> isn't one already. >> >> -- >> Martin. >> >> >> musachy >>> >>> Martin Cooper wrote: >>> > On 10/30/06, Musachy Barroso wrote: >>> >> >>> >> Hi Rainer >>> >> >>> >> Give me a couple of days so I can test it against 0.4 (I made the >>> patch >>> >> using 0.3) and finish some changes(for BindButton) that I have for a >>> new >>> >> patch. I will give you a new patch soon with the changes for Bind, >>> >> BindDiv, BindAnchor, BindButton and TabbedPanel tested on dojo >>> 0.4. If >>> >> you want to go ahead and upgrade to 0.4 and apply the patch later, >>> >> that's fine. (I will just be bothering with another patch soon :) ) >>> > >>> > >>> > Well, the upgrade and the patch should certainly be separate >>> commits, so >>> > that we can track the changes separately, and so that we can revert >>> > one or >>> > the other if that ever becomes necessary. Beyond that, it's up to the >>> > prospective committer to determine timing. ;-) >>> > >>> > -- >>> > Martin Cooper >>> > >>> > >>> > musachy >>> >> >>> >> Rainer Hermanns wrote: >>> >> > Musachy, >>> >> > >>> >> > I could upgrade the embedded Dojo files to the 0.4 release >>> during the >>> >> week. >>> >> > If your patches for the s2 ajax tags already are against the >>> >> 0.4release, >>> >> > I could apply those as well. >>> >> > >>> >> > What do you (and others of course) think? >>> >> > >>> >> > regards, >>> >> > Rainer >>> >> > >>> >> > >>> >> >> Any idea on when is Dojo going to be bumped up to 0.4? >>> >> >> >>> >> >> musachy >>> >> >> >>> >> >> Don Brown wrote: >>> >> >> >>> >> >>> Yes, let's start with bumping up Dojo to 0.4, then apply >>> patches to >>> >> >>> update the tags. How much work do you think it'll be to upgrade >>> >> Dojo? >>> >> >>> >>> >> >>> Don >>> >> >>> >>> >> >>> Musachy Barroso wrote: >>> >> >>> >>> >> I attached a new patch to WW-205, this one includes the new >>> >> TabbedPanel, BindDiv and BindAnchor. It needs Dojo 0.3.1.Do >>> you >>> >> want >>> >> me to create a patch to update to Dojo 0.3.1?(We just need to >>> >> replace >>> >> dojo distribution under static/dojo.) >>> >> >>> >> I modified the examples in showcase and the test cases. Let me >>> know >>> >> if something is missing or wrong (bear with me on my first >>> patch >>> :) >>> >> ). >>> >> >>> >> musachy >>> >> >>> >> Don Brown wrote: >>> >> >>> >> > Ok, then put those two under one ticket. You know best :) >>> >> > >>> >> > Don >>> >> > >>> >> > Musachy Barroso wrote: >>> >> > >>> >> >> That's ok, the only problem is that this one by itself would >>> >> break >>> >> >> anchor and tabbed panel. >>> >> >> >>> >> >> musachy >>> >> >> >>> >> >> Don Brown wrote: >>> >> >> >>> >> >>> I'd prefer separate issues, with attached patches. As for >>> >> >>> testing, we started to use Patrick's hostedqa stuff, but we >>> need >>> >> >>> to use it more. >>> >> >>> >>> >> >>> Don >>> >> >>> >>> >> >>> Musachy Barroso wrote: >>> >> >>> >>> >> I have everything (I think :)) for the ajax Div Tag, do you >>> >> want >>> >> me to create a patch for it, or wait and create a big one >>> when >>> >> I'm done with the other widgets (anchor, tree...dojo 0.2 -> >>> >> 0.3)? >>> >> >>> >> >
Re: ajax tags
Hi Musachy, Thank you for your interest. I think this mailing list would be fine as it is going to be related to Struts2. Please feel free to share any of your thoughs. Actually, there's no real ownership to Struts2 code, its by the Struts2 community for the Struts2 community as well. If we have the discussion here, everyone could be free to jump in at any part they feel relevant. :-) rgds --- Musachy Barroso <[EMAIL PROTECTED]> wrote: > Hi all, > > I was checking out struts 2 yesterday (I'm a 1.2.7 > user) and I found > that some of the UI tags(tree, tab panel...) overlap > with a project that > I'm currently maintaining (ajaxtags at > http://ajaxtags.sourceforge.net/). I'd like to > contribute to the UI ajax > tags, so some pointers on where to start or whom to > talk to would be > appreciated. Ajaxtags is distributed under an apache > 2.0 license so we > could lift some code if needed. > > thanks > > musachy > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > Send instant messages to your online friends http://uk.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Action Injection and ExecuteResult=true
Hi Ted, Shouldn't it be [EMAIL PROTECTED] name="actions.StoryTypeIdList" executeResult="true"/] or did i miss something. rgds Ted Husted <[EMAIL PROTECTED]> wrote: If we are injecting Action classes via Spring, singleton="false"/> should that work when we call an Action from an action tag using executeResult=true. [EMAIL PROTECTED] name="StoryTypeIdList" executeResult="true"/] I'm getting the (wildcard) result, but the Action class isn't firing. The "conventional" Actions we're injecting work just fine. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: JXP Template support?
Hi guys, I've go ahead and created an issue in Struts2 jira. https://issues.apache.org/struts/browse/WW-1473 rgds Philip Luppens <[EMAIL PROTECTED]> wrote: > On 10/16/06, Philip Luppens > wrote: > > b) if we can't fix the caching problem in > Freemarker. > > Are we talking about this caching problem: > > * > http://article.gmane.org/gmane.comp.web.freemarker.use > r/2555/match=freemarker+performance+ww Yes, that's the one. There were a couple of other reports on the WW forum as well [1]. > > Do we have a JIRA ticket open for the problem? Afaik, no. Not in Struts 2 nor in WW 2. Want me to make one ? > > -Ted. Phil [1] http://forums.opensymphony.com/thread.jspa?messageID=85432; - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=46468&messageID=93904#93904 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider.
Re: [s2] xwork docs
Hi James, I think you'll need 'xwork-developers' to edit the pages. I don't have the access to add user as 'xwork-developer', but I could see if Pat or Phil could give you that role. What's your id? rgds James Mitchell <[EMAIL PROTECTED]> wrote: I don't remember if I have a login on that wiki, can someone check? -- James Mitchell 678.910.8017 On Oct 14, 2006, at 6:40 AM, tm jee wrote: > Hi Guys, > > I've got the xwork2 docs mostly filled up i guess, except for a few > more pages. I'll need extra pairs of eyes to help going through > them to make sure they are valid. Else i think its ready > > Give it a go and post back or make direct changes to them. If > anyone need access to cofluence, just drop me a mail, i'd be able > to arrange that with Phil or mybe Pat. > > Cheers. > > > tm jee wrote: Thx Don. > >> Thanks again for picking this up! > Well, its a challengin task, someone has to pick it up fast before > its being occupied ;-) > > rgds > > > > Don Brown wrote: Toby, that looks great. If you had to pick, try > to align the docs with > Struts 2 rather than XWork 1 since that will what the majority of the > new users will be familiar with. And honestly, it is pretty hard > to go > wrong when adding new docs, so feel free to just run with it. > > Thanks again for picking this up! > > Don > > tm jee wrote: >> Hi guys, >> >> Got the outline of xwork2 documentation out at http:// >> wiki.opensymphony.com/display/XW/XWork2 >> >> Its based on how the WebWork documentation currently looks like, >> so users familiar with WebWork docs should be familiar with xwork2 >> docs hopefully. >> >> Any feedbacks are very much welcomed. >> >> Cheers >> >> >> Send instant messages to your online friends http:// >> uk.messenger.yahoo.com > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > Send instant messages to your online friends http:// > uk.messenger.yahoo.com > > Send instant messages to your online friends http:// > uk.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine
Re: [S2] Spring 2 for Struts 2?
> Hey I am not so selfish; I was thinking about all those big > companies for which an upgrade is taking a lot of time. Yup. I know, I'm just joking :-) Alexandru Popescu <[EMAIL PROTECTED]> wrote: On 10/14/06, tm jee wrote: > > I guess everybody knows the reasons ;-). > > Hmm... let me guess, infoq uses Spring 1.2.x ;-) Me too :-) > Hey I am not so selfish; I was thinking about all those big companies for which an upgrade is taking a lot of time. ./alex -- .w( the_mindstorm )p. > > Alexandru Popescu wrote: On 10/14/06, Mark Menard wrote: > > On 10/13/06 5:36 PM, "Ted Husted" wrote: > > > > > Since the reports are that Spring 2 works just fine with Struts 2, why > > > don't we bite the bullet and update our dependencies? > > > > Not that I'm a s2 developer, and my vote doesn't matter, but I've been using > > it for a few weeks now with no issues. > > > > +1 > > > > I agree with this upgrade as long as the Spring 1.2 users will still > be able to use Struts2 just by drop-in replacement of the Spring jar > (and I think this is possible). If not, then we must figure out a way > to have Struts2 working with both versions. I guess everybody knows > the reasons ;-). > > ./alex > -- > .w( the_mindstorm )p. > > > Mark > > -- > > Mark Menard > > Business: http://www.vitarara.net/ > > Personal: http://www.vitarara.org/ > > > > - > > 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] > > > > Send instant messages to your online friends http://uk.messenger.yahoo.com > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: [s2] xwork docs
Hi Guys, I've got the xwork2 docs mostly filled up i guess, except for a few more pages. I'll need extra pairs of eyes to help going through them to make sure they are valid. Else i think its ready Give it a go and post back or make direct changes to them. If anyone need access to cofluence, just drop me a mail, i'd be able to arrange that with Phil or mybe Pat. Cheers. tm jee <[EMAIL PROTECTED]> wrote: Thx Don. >Thanks again for picking this up! Well, its a challengin task, someone has to pick it up fast before its being occupied ;-) rgds Don Brown wrote: Toby, that looks great. If you had to pick, try to align the docs with Struts 2 rather than XWork 1 since that will what the majority of the new users will be familiar with. And honestly, it is pretty hard to go wrong when adding new docs, so feel free to just run with it. Thanks again for picking this up! Don tm jee wrote: > Hi guys, > > Got the outline of xwork2 documentation out at > http://wiki.opensymphony.com/display/XW/XWork2 > > Its based on how the WebWork documentation currently looks like, so users > familiar with WebWork docs should be familiar with xwork2 docs hopefully. > > Any feedbacks are very much welcomed. > > Cheers > > > Send instant messages to your online friends http://uk.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Send instant messages to your online friends http://uk.messenger.yahoo.com Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: [S2] Spring 2 for Struts 2?
> I guess everybody knows the reasons ;-). Hmm... let me guess, infoq uses Spring 1.2.x ;-) Me too :-) Alexandru Popescu <[EMAIL PROTECTED]> wrote: On 10/14/06, Mark Menard wrote: > On 10/13/06 5:36 PM, "Ted Husted" wrote: > > > Since the reports are that Spring 2 works just fine with Struts 2, why > > don't we bite the bullet and update our dependencies? > > Not that I'm a s2 developer, and my vote doesn't matter, but I've been using > it for a few weeks now with no issues. > > +1 > I agree with this upgrade as long as the Spring 1.2 users will still be able to use Struts2 just by drop-in replacement of the Spring jar (and I think this is possible). If not, then we must figure out a way to have Struts2 working with both versions. I guess everybody knows the reasons ;-). ./alex -- .w( the_mindstorm )p. > Mark > -- > Mark Menard > Business: http://www.vitarara.net/ > Personal: http://www.vitarara.org/ > > - > 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] Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: [s2] xwork docs
Thx Don. >Thanks again for picking this up! Well, its a challengin task, someone has to pick it up fast before its being occupied ;-) rgds Don Brown <[EMAIL PROTECTED]> wrote: Toby, that looks great. If you had to pick, try to align the docs with Struts 2 rather than XWork 1 since that will what the majority of the new users will be familiar with. And honestly, it is pretty hard to go wrong when adding new docs, so feel free to just run with it. Thanks again for picking this up! Don tm jee wrote: > Hi guys, > > Got the outline of xwork2 documentation out at > http://wiki.opensymphony.com/display/XW/XWork2 > > Its based on how the WebWork documentation currently looks like, so users > familiar with WebWork docs should be familiar with xwork2 docs hopefully. > > Any feedbacks are very much welcomed. > > Cheers > > > Send instant messages to your online friends http://uk.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: [S2] Confluence clear cache & snippet plugins code access
I see. thx for the info Pat. Ted, are you busy lately? If so i guess the snippet stuff could wait. rgds Patrick Lightbody <[EMAIL PROTECTED]> wrote: Toby, I believe Ted can provide insight here. I gave him access to the plugin source, but I don't know what happened to it since or in what form it was installed. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=45766&messageID=92846#92846 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Try the all-new Yahoo! Mail . "The New Version is radically easier to use" The Wall Street Journal
[s2] xwork docs
Hi guys, Got the outline of xwork2 documentation out at http://wiki.opensymphony.com/display/XW/XWork2 Its based on how the WebWork documentation currently looks like, so users familiar with WebWork docs should be familiar with xwork2 docs hopefully. Any feedbacks are very much welcomed. Cheers Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: Struts 2.0.1 release
> Has anyone volunteered to work on the XWork docs? I could work on XWork2 docs. I think its better if I don't alter the confluence content for xwork directly but prepare the word doc i have in mind maybe in a doc format and maybe commit a copy into xwork2 svn such that others could have a look at it. I guess we'll work on the word doc for a bit, untill its mostly ok, then I could start altering the confluence content. What do you guys think? rgds - Original Message From: Ted Husted <[EMAIL PROTECTED]> To: Struts Developers List Sent: Friday, 6 October, 2006 4:26:53 PM Subject: Re: Struts 2.0.1 release Has anyone volunteered to work on the XWork docs? The XW2 docs aren't any better or worse than the XW 1.1 docs, and I believe that release series was getting the "ready for prime time" stamp. Is anyone besides Struts 2.0.x trying to use XWork in production? Is there even an XWork forum any more? Aside from the Tiles plugin, which we could sidestep, there might not be anything else that would keep Struts 2.0.1 from going GA. There's other stuff we want to do, but what we've done is solid, useful, and complete. (Which given the starting point, shouldn't be suprising!) I mean, if we find issues as more people use Struts 2.0.1, then sure we reflect that status in the quality grade. But why make a beta status a foregone conclusion? -Ted. On 10/6/06, Don Brown <[EMAIL PROTECTED]> wrote: > XWork does use the alpha, beta, stable tagging of releases, however, the > release process is lightweight and many people have commit access. I > do, and you just need to ask Patrick to get access yourself. To be > honest, this XWork release shouldn't go 2.0.0 final, because the > documentation for XWork is woefully out of date and needs work. Also, > I'd like to test all the new changes we made for a beta release or two > before we slap that label on it. > > Don > > Ted Husted wrote: > > Yes. > > > > Though, does XWork the release process allow for updating the bits > > from beta to stable or GA? > > > > The reason I ask is that our 2.0.1 release will be tied to whatever > > version moniker that XWork uses. If tomorrow's XWork release is tagged > > as "beta", and that cannot change for that set of bits, then the 2.0.1 > > release will also be forever beta. > > > > OTOH, if XWork were tagged as a 2.0.0 release, and it were upgradable > > from beta to stable/GA at a later date, then we would be able to do > > the same with Struts 2.0.1 (should it merit the quality upgrade). > > > > Otherwise, we will always be playing hand-over-hand with XWork. After > > XWork generates a GA/Stable release, we will have to rebuild and > > redistribute a Struts build all over again. Avoiding "cascading > > release triggers" is a key benefit of the build-then-grade-and-upgrade > > approach. If a build has dependencies that are upgraded, we don't have > > to redistribute the bits, just upgrade our quality assessment. > > > > -Ted. > > > > On 10/6/06, Rainer Hermanns <[EMAIL PROTECTED]> wrote: > >> Ted, > >> I am planning a beta-1 release of xwork 2.0 for tomorrow. > >> This will be tagged and build with a fixed version number. > >> > >> Would this fit into your timeframe? > >> > >> Rainer > >> > >> > I don't have karma to XWork, so it's not something I could tag myself. > >> > > >> > -Ted. > >> > > >> > On 10/6/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: > >> >> On 10/6/06, Ted Husted <[EMAIL PROTECTED]> wrote: > >> >> > >> >> > I'm wondering if maybe we should roll this tomorrow afternoon > >> instead. > >> >> > They might be working on the Internet connection on Monday, and my > >> >> > tutorial is Monday afternoon. It would be nice to have it before I > >> >> > leave, so that I can put it on the tutorial CDs, and cover the > >> new S1 > >> >> > compatability bridge classes. > >> >> > >> >> This may be on your list already, but XWork needs to be tagged and > >> >> built at a fixed version number in advance of a Struts 2 build. > >> >> > >> >> (The snapshot dependency in the Struts 2.0.0 pom caused problems for > >> >> Maven users once new XWork snapshots were published.) > >> >> > >> >> Thanks, > >> >> 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] > >> > >> > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- HTH, Ted. * http://www.husted.com/struts/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___
[S2] Confluence clear cache & snippet plugins code access
Hi guys, The "clear cache" feature of cwiki seems to be missing. Does anyone notice this? I've made some changes to the javadoc snippet and wanted to clear the cache such that confluence re-pickup the changes from svn, it seems that the clearCache.action is not being mapped. Recently we reorganized stuff into plugins, I think the source code in plugins is not configured to be reconizable by confluence snippet plugin cuase the places where snippet are to be pulled out from the plugin folder in svn seems to be giving error Eg. http://cwiki.apache.org/confluence/display/WW/SiteMesh can't seems to pull snippet from FreeMarkerPageFilter Cheers. rgds ___ NEW Yahoo! Cars - sell your car and browse thousands of new and used cars online! http://uk.cars.yahoo.com/
Re: Abstracting Ognl from XWork and Struts 2?
> AFAIR, considering that the expressions are already cached (which
> represents an improvement on the performance), the next problem is the
> value manipulation which is not so performant (though I haven't looked
> so deep to suggest some optimizations)
I see. Do you mean stuff like
%{'someString'+#someContextKey+someContextRootKey}
Or is it something else?
rgds
- Original Message
From: Alexandru Popescu <[EMAIL PROTECTED]>
To: Struts Developers List
Sent: Friday, 29 September, 2006 3:38:57 AM
Subject: Re: Abstracting Ognl from XWork and Struts 2?
On 9/29/06, tm jee <[EMAIL PROTECTED]> wrote:
> Its doable I guess.
>
> If we have an Expression parser / converter like Alex pointed out, we could
> have a standard syntax, but it would be more complicated to implement.
>
> Without an Expression parser / converter, it'd likely to get users confused
> as it depends on what implementation is being used.
>
This would be indeed a possible drawback, not to mention the confusion
that will arise from the forum posts:
[future-quote]
Q: I have the following in my JSP and it is not working:
A: Oh no, you need to write it ${tralala}
A: No, that's not true: you need to write it %{tralala}
A: by the way what expression language are you using?
[/future-quote]
> Either case, I think we should stick with a standard supported
> implementation i guess. Personally, I think that Ognl is still the most
> powerfull expression language. :-)
>
> Btw, is Ognl so slow? I think there's some caching done to the expression
> evaluation, is that not sufficient to make the performance acceptable as well?
>
AFAIR, considering that the expressions are already cached (which
represents an improvement on the performance), the next problem is the
value manipulation which is not so performant (though I haven't looked
so deep to suggest some optimizations)
./alex
--
.w( the_mindstorm )p.
> rgds
>
>
> - Original Message
> From: Alexandru Popescu <[EMAIL PROTECTED]>
> To: Struts Developers List
> Sent: Friday, 29 September, 2006 3:38:45 PM
> Subject: Re: Abstracting Ognl from XWork and Struts 2?
>
> On 9/29/06, Don Brown <[EMAIL PROTECTED]> wrote:
> > I've been toying with this idea of severing XWork and Struts 2's strict
> > dependency to OGNL. The goal is not necessary to remove OGNL outright,
> > but to make it possible to replace it with another expression language.
> > I'm happy with OGNL right now, however a couple things - its slow,
> > mostly unsupported, doesn't have tool support, and did I mention slow? -
> > inspire me to want to start to wean Struts off of it.
> >
> > How would we do it?
> > 1. Pull out a ValueStack interface from OgnlValueStack
> > 2. Create an abstract factory, ValueStackFactory, to create the ValueStack
> > 3. Pull out an interface from OgnlUtils and create a factory for it
> > 4. Replace/abstract the custom type conversion stuff
> >
> > I've done 1 and 2, compiling and tests passing. #3 seems pretty easy,
> > but the big question mark is #4. Also, I'd imagine things like our tags
> > are tied to the OGNL grammer, which might be interesting.
> >
> > Again, my goal isn't to remove it completely, but just to make it
> > possible to swap it out sometime in the future with JEXL, JSP EL, custom
> > OGNL (like Wicket and Stripes have done), WW 1 EL, or BeanUtils EL. The
> > last two might be interesting to assist in migration situations.
> >
> > What does some of the Webwork veterans think? Is this doable?
> >
>
> IMO, this is doable. But I think it may require yet another
> abstraction: an expression converter, as the engines you are
> mentioning are using different types of syntax. Or, if this is
> something that comes in the XValueStack implementation than I guess it
> may work too.
>
> ./alex
> --
> .w( the_mindstorm )p.
>
> > Don
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts plugins
> Now if this is the case, may I read this is another configuration XML > file needed? IMO we should try to allow an application to work with > less and less configuration needed, and not the other way around. Or I > am looking at this from the wrong perspective? I think (if not mistaken) is that the struts-plugin.xml would have the same definition as struts_x_x.dtd (the same definition as the current struts.xml uses). The aim is such that when a jar is added to the classpath, if it has such a struts-plugin.xml, will get its interceptor, packages etc registered just like a normal struts.xml would. The benifit is that we don't need a being defined in struts.xml. I guess thats the main motivation behind this idea. What do you think Alex? rgds - Original Message From: Alexandru Popescu <[EMAIL PROTECTED]> To: Struts Developers List Sent: Friday, 29 September, 2006 3:13:19 AM Subject: Re: Struts plugins On 9/29/06, Don Brown <[EMAIL PROTECTED]> wrote: > While I appreciate the idea, I don't particularly think that plugins > should be deterministic. Perhaps plugin is the wrong word as it brings > to mind descriptors, versioning, dependencies, etc. for some people. In > this case, I see it as simply a way to organize code and provide default > configuration for that code. Anything that is common to multiple > plugins should be pushed into the core. > Now if this is the case, may I read this is another configuration XML file needed? IMO we should try to allow an application to work with less and less configuration needed, and not the other way around. Or I am looking at this from the wrong perspective? ./alex -- .w( the_mindstorm )p. > Now, since the names of what configuration files are configurable, you > could change it to load "struts-default.xml, struts-plugin.xml, > struts-plugin-ext.xml, struts.xml" or whatever other files you'd like. > From a core framework POV, I think simply loading struts-plugin.xml in > a non-deterministic order is fine for our needs. > > Don > > tm jee wrote: > > Hi guys, > > > > Just some thoughts, maybe we could have an order parameter introduced eg > > > > struts-plugin.xml > > > > 10 > > > > > > > > > > > > So we could have control of which plugin gets the priority when loading > > and we could defined order 1-100 is for struts, custom plugin starts from > > 101 etc. Ordering for plugins with same ordering would be undefined. The > > ordering could maybe applied only to plugin (struts-plugin.xml) as we have > > just one bootstrap configuration (struts.xml) > > > > Thoughts? > > > > rgds > > > > > > - Original Message > > From: David H. DeWolf <[EMAIL PROTECTED]> > > To: Struts Developers List > > Sent: Thursday, 28 September, 2006 12:15:12 AM > > Subject: Re: Struts plugins > > > > Not sure if this is exactly what you're looking for, but the patch to > > upgrade from 0.2 to 2.0 exists: > > > > https://issues.apache.org/struts/browse/WW-1418 > > > > > > > > Also, while you're looking at this, here's another patch related to > > tiles that I'd be interested in: > > > > https://issues.apache.org/struts/browse/WW-1450 > > > > > > David > > > > > > Don Brown wrote: > > > >> Is there any Tiles 2 migration code I can put into a block or does it > >> need to be written yet? I do agree it would be a great candidate. > >> > >> Don > >> > >> Antonio Petrelli wrote: > >> > >>> Don Brown ha scritto: > >>> > >>>> The first batch of plugins: > >>>> 1. Configuration Browser > >>>> 2. Jasper Reports > >>>> 3. JFreeChart > >>>> 4. JSF > >>>> 5. Pell Multipart handler > >>>> 6. Sitemesh > >>>> 7. Struts 1 > >>>> > >>> You forgot Tiles 2 :-) > >>> > >>> Ciao > >>> 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] > >> > >> > >> > > > > - > > 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: Abstracting Ognl from XWork and Struts 2?
Its doable I guess. If we have an Expression parser / converter like Alex pointed out, we could have a standard syntax, but it would be more complicated to implement. Without an Expression parser / converter, it'd likely to get users confused as it depends on what implementation is being used. Either case, I think we should stick with a standard supported implementation i guess. Personally, I think that Ognl is still the most powerfull expression language. :-) Btw, is Ognl so slow? I think there's some caching done to the expression evaluation, is that not sufficient to make the performance acceptable as well? rgds - Original Message From: Alexandru Popescu <[EMAIL PROTECTED]> To: Struts Developers List Sent: Friday, 29 September, 2006 3:38:45 PM Subject: Re: Abstracting Ognl from XWork and Struts 2? On 9/29/06, Don Brown <[EMAIL PROTECTED]> wrote: > I've been toying with this idea of severing XWork and Struts 2's strict > dependency to OGNL. The goal is not necessary to remove OGNL outright, > but to make it possible to replace it with another expression language. > I'm happy with OGNL right now, however a couple things - its slow, > mostly unsupported, doesn't have tool support, and did I mention slow? - > inspire me to want to start to wean Struts off of it. > > How would we do it? > 1. Pull out a ValueStack interface from OgnlValueStack > 2. Create an abstract factory, ValueStackFactory, to create the ValueStack > 3. Pull out an interface from OgnlUtils and create a factory for it > 4. Replace/abstract the custom type conversion stuff > > I've done 1 and 2, compiling and tests passing. #3 seems pretty easy, > but the big question mark is #4. Also, I'd imagine things like our tags > are tied to the OGNL grammer, which might be interesting. > > Again, my goal isn't to remove it completely, but just to make it > possible to swap it out sometime in the future with JEXL, JSP EL, custom > OGNL (like Wicket and Stripes have done), WW 1 EL, or BeanUtils EL. The > last two might be interesting to assist in migration situations. > > What does some of the Webwork veterans think? Is this doable? > IMO, this is doable. But I think it may require yet another abstraction: an expression converter, as the engines you are mentioning are using different types of syntax. Or, if this is something that comes in the XValueStack implementation than I guess it may work too. ./alex -- .w( the_mindstorm )p. > 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: Struts plugins
I see. > Now, since the names of what configuration files are configurable, you > could change it to load "struts-default.xml, struts-plugin.xml, > struts-plugin-ext.xml, struts.xml" or whatever other files you'd like. I guess the overall effect is that, struts.xml will be the first to be loaded and then struts-plugin.xml will be loaded in an non-deterministic manner, but we could change the name from "struts-plugin.xml" to something else through an entry in struts.properties. Is this correct? I guess without the ordering is fine, just that I think we should make it clear in the docs that its not really a "plugin" but a convenient way for Struts2 to organize its features. rgds - Original Message From: Don Brown <[EMAIL PROTECTED]> To: Struts Developers List Sent: Friday, 29 September, 2006 1:30:11 PM Subject: Re: Struts plugins While I appreciate the idea, I don't particularly think that plugins should be deterministic. Perhaps plugin is the wrong word as it brings to mind descriptors, versioning, dependencies, etc. for some people. In this case, I see it as simply a way to organize code and provide default configuration for that code. Anything that is common to multiple plugins should be pushed into the core. Now, since the names of what configuration files are configurable, you could change it to load "struts-default.xml, struts-plugin.xml, struts-plugin-ext.xml, struts.xml" or whatever other files you'd like. From a core framework POV, I think simply loading struts-plugin.xml in a non-deterministic order is fine for our needs. Don tm jee wrote: > Hi guys, > > Just some thoughts, maybe we could have an order parameter introduced eg > > struts-plugin.xml > > 10 > > > > > > So we could have control of which plugin gets the priority when loading and > we could defined order 1-100 is for struts, custom plugin starts from 101 > etc. Ordering for plugins with same ordering would be undefined. The ordering > could maybe applied only to plugin (struts-plugin.xml) as we have just one > bootstrap configuration (struts.xml) > > Thoughts? > > rgds > > > - Original Message > From: David H. DeWolf <[EMAIL PROTECTED]> > To: Struts Developers List > Sent: Thursday, 28 September, 2006 12:15:12 AM > Subject: Re: Struts plugins > > Not sure if this is exactly what you're looking for, but the patch to > upgrade from 0.2 to 2.0 exists: > > https://issues.apache.org/struts/browse/WW-1418 > > > > Also, while you're looking at this, here's another patch related to > tiles that I'd be interested in: > > https://issues.apache.org/struts/browse/WW-1450 > > > David > > > Don Brown wrote: > >> Is there any Tiles 2 migration code I can put into a block or does it >> need to be written yet? I do agree it would be a great candidate. >> >> Don >> >> Antonio Petrelli wrote: >> >>> Don Brown ha scritto: >>> >>>> The first batch of plugins: >>>> 1. Configuration Browser >>>> 2. Jasper Reports >>>> 3. JFreeChart >>>> 4. JSF >>>> 5. Pell Multipart handler >>>> 6. Sitemesh >>>> 7. Struts 1 >>>> >>> You forgot Tiles 2 :-) >>> >>> Ciao >>> 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] >> >> >> > > - > 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: Struts plugins
Hi guys, Just some thoughts, maybe we could have an order parameter introduced eg struts-plugin.xml 10 So we could have control of which plugin gets the priority when loading and we could defined order 1-100 is for struts, custom plugin starts from 101 etc. Ordering for plugins with same ordering would be undefined. The ordering could maybe applied only to plugin (struts-plugin.xml) as we have just one bootstrap configuration (struts.xml) Thoughts? rgds - Original Message From: David H. DeWolf <[EMAIL PROTECTED]> To: Struts Developers List Sent: Thursday, 28 September, 2006 12:15:12 AM Subject: Re: Struts plugins Not sure if this is exactly what you're looking for, but the patch to upgrade from 0.2 to 2.0 exists: https://issues.apache.org/struts/browse/WW-1418 Also, while you're looking at this, here's another patch related to tiles that I'd be interested in: https://issues.apache.org/struts/browse/WW-1450 David Don Brown wrote: > Is there any Tiles 2 migration code I can put into a block or does it > need to be written yet? I do agree it would be a great candidate. > > Don > > Antonio Petrelli wrote: >> Don Brown ha scritto: >>> The first batch of plugins: >>> 1. Configuration Browser >>> 2. Jasper Reports >>> 3. JFreeChart >>> 4. JSF >>> 5. Pell Multipart handler >>> 6. Sitemesh >>> 7. Struts 1 >> >> You forgot Tiles 2 :-) >> >> Ciao >> 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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Extras build seems to be failing
The compilation is failing as well due to a missing Junit dependency. Fixed
that in svn head.
I think the warning about pell should be ignorable, i guess. "mvn clean test"
seems to be working ok for me, so does "mvn install" after adding junit
dependency.
rgds
- Original Message
From: Ted Husted <[EMAIL PROTECTED]>
To: Struts Developers List
Sent: Sunday, 17 September, 2006 9:44:35 AM
Subject: [s2] Extras build seems to be failing
The Extras build seems to failing, apparently because of something to
with the pell-multipart POM. I'm using a current checkout of XWork
(r1136).
-T.
C:\projects\Apache\current\struts2\extras>mvn install -e
+ Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO] -
---
[INFO] Building Struts Extras
[INFO]task-segment: [install]
[INFO] -
---
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] snapshot opensymphony:xwork:2.0-SNAPSHOT: checking for updates from snaps
hots-maven-codehaus
[INFO] snapshot opensymphony:xwork:2.0-SNAPSHOT: checking for updates from opens
ymphony
[WARNING]
Artifact commons-logging:commons-logging:jar:1.0.4:provided retains loca
l scope 'provided' overriding broader scope 'compile'
given by a dependency. If this is not intended, modify or remove the loc
al scope.
[WARNING] POM for 'opensymphony:pell-multipart:pom:2.1.5:provided' is invalid. I
t will be ignored for artifact resolution. Reason: Not a v4.0.0 POM.
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[WARNING] POM for 'opensymphony:pell-multipart:pom:2.1.5:provided' is invalid. I
t will be ignored for artifact resolution. Reason: Not a v4.0.0 POM.
[INFO] [compiler:testCompile]
Compiling 1 source file to C:\projects\Apache\current\struts2\extras\target\test
-classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
C:\projects\Apache\current\struts2\extras\src\test\java\org\apache\struts2\dispa
tcher\ChartResultTest.java:[24,23] package junit.framework does not exist
C:\projects\Apache\current\struts2\extras\src\test\java\org\apache\struts2\dispa
tcher\ChartResultTest.java:[37,37] cannot find symbol
symbol: class TestCase
public class ChartResultTest extends TestCase {
C:\projects\Apache\current\struts2\extras\src\test\java\org\apache\struts2\dispa
tcher\ChartResultTest.java:[57,8] cannot find symbol
symbol : method assertTrue(boolean)
location: class org.apache.struts2.dispatcher.ChartResultTest
C:\projects\Apache\current\struts2\extras\src\test\java\org\apache\struts2\dispa
tcher\ChartResultTest.java:[68,12] cannot find symbol
symbol : method fail()
location: class org.apache.struts2.dispatcher.ChartResultTest
C:\projects\Apache\current\struts2\extras\src\test\java\org\apache\struts2\dispa
tcher\ChartResultTest.java:[73,8] cannot find symbol
symbol : method assertFalse(boolean)
location: class org.apache.struts2.dispatcher.ChartResultTest
[INFO]
[INFO] Trace
org.apache.maven.BuildFailureException: Compilation failure
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:555)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
fecycle(DefaultLifecycleExecutor.java:475)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
ltLifecycleExecutor.java:454)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFailures(DefaultLifecycleExecutor.java:306)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:273)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
fecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(
Re: [Proposal] Framework plugin architecture (was Re: [s2] Logging levels)
Ah... i got it now. I am having aggregate=true, that's why its having duplicates. With aggregate=false, its working ok. - Original Message From: Don Brown <[EMAIL PROTECTED]> To: Struts Developers List Sent: Tuesday, 12 September, 2006 10:58:19 AM Subject: Re: [Proposal] Framework plugin architecture (was Re: [s2] Logging levels) Why would we get duplicates? ATM, we are only loading the resource from the first successful classloader, so we shouldn't get the same file multiple times. The FileManager keeps a list of loaded files to ensure we don't load one twice. Don tm jee wrote: > I see, I think I might have misunderstood. Please correct me if I am wrong. > With, > > one.jar >pac/test.xml > two.jar >pac/test.xml > three.jar >pac/test.xml > > We would get something like (if we iterate over each iteration) > jar:file:/.../one.jar!/META-INF/test.xml > jar:file:/.../two.jar!/META-INF/test.xml > jar:file:/.../three.jar!/META-INF/test.xml > jar:file:/.../one.jar!/META-INF/test.xml > jar:file:/.../two.jar!/META-INF/test.xml > jar:file:/.../three.jar!/META-INF/test.xml > jar:file:/.../one.jar!/META-INF/test.xml > jar:file:/.../two.jar!/META-INF/test.xml > jar:file:/.../three.jar!/META-INF/test.xml > > It should be sufficient I think if we could just get > jar:file:/.../one.jar!/META-INF/test.xml > jar:file:/.../two.jar!/META-INF/test.xml > jar:file:/.../three.jar!/META-INF/test.xml > > instead of some extra duplicates. What do you think? Should we fix this, or > is it a feature? > > Thx in advance. > > > > > - Original Message > From: Don Brown <[EMAIL PROTECTED]> > To: Struts Developers List > Sent: Tuesday, 12 September, 2006 10:35:18 AM > Subject: Re: [Proposal] Framework plugin architecture (was Re: [s2] Logging > levels) > > > > tm jee wrote: > >> Sounds cool. >> >> Just some thoughts. Maybe we could make the bootstrap struts xml >> "struts-default.xml" and the plugins xml "struts-plugin.xml" while those in >> the webapp "struts.xml". The bootstraping sequence would be >> >> 1] struts-default.xml >> 2] struts-plugins.xml >> 3] struts.xml >> >> This way its easier for us to control which config we are dealing with. If >> we have the plugins config and the base bootsraping config all called >> "struts-default.xml", depending on which gets loaded first in the >> classpath, we might get the plugin's "struts-default.xml" called first >> before the struts-core's "struts-default.xml" which will cause some problem >> (with current xwork code) cuase some of the required interceptor, results >> etc used by the plugin might not be loaded yet. I hope i got the concept >> correct, if not please correct me. :-) >> >> > Good point, let's do this. > > >> Another thing we might want to considered is the dependency of plugins. If >> say plugin A needs some stuff declared in plugin B, it might not work, >> depending on which gets loaded first in the classpath. Or would this make >> thing unnecessarily complicated? >> >> > Well, the most robust solution for plugins would be to use OSGI like > Eclipse does, however, I'm not sure we need that power yet. I'd like to > keep it simple for now, sticking with a system that is already in > place. It doubles as an example to users on how to plug in > functionality easily. > >> About the new ClassLoaderUtil under xwork2 code, the method >> "getResources(String, Class, boolean)". I think its better if we could make >> the Iterator returned not to contains duplicates. Eg. if I jave >> >> one.jar >> pac/test.xml >> two.jar >> pac/test.xml >> three.jar >> pac/test.xml >> >> trying to get "pac/test.xml" will return more than 3 copies. What do you >> guys think? >> Attached below is a patch attemt to fix this. I could create a jira issue if >> its agreed that its something to be fix. >> >> > Actually, that's the whole point :) In our case, we are using it to get > all the struts-plugin.xml files in all jars. This allows us to > dynamically discover new plugins without the need to "register" them > somewhere. It also makes it nice for users to deploy new modules by > simply including a struts.xml file in their jar and the module is > automatically discovered and installed. > > Don > >> Tia. >> >> Inde
Re: [Proposal] Framework plugin architecture (was Re: [s2] Logging levels)
Thx for the tips Antonio. Looks interesting. :-) I guess we might want to keep it simple for the time being as Don mentioned in the replying email. - Original Message From: Antonio Petrelli <[EMAIL PROTECTED]> To: Struts Developers List Sent: Tuesday, 12 September, 2006 10:29:23 AM Subject: Re: [Proposal] Framework plugin architecture (was Re: [s2] Logging levels) tm jee ha scritto: > Another thing we might want to considered is the dependency of plugins. If > say plugin A needs some stuff declared in plugin B, it might not work, > depending on which gets loaded first in the classpath. Or would this make > thing unnecessarily complicated? > It seems that this problem has been addressed by Eclipse team, and one day I found this blog entry: http://www.eclipsezone.com/eclipse/forums/t64085.html And it uses Struts as an example. I don't know if it could help, but it's worth a look. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Framework plugin architecture (was Re: [s2] Logging levels)
Thx for the reply Don. > Good point, let's do this. Cool. > Actually, that's the whole point :) In our case, we are using it to get > all the struts-plugin.xml files in all jars. This allows us to > dynamically discover new plugins without the need to "register" them > somewhere. It also makes it nice for users to deploy new modules by > simply including a struts.xml file in their jar and the module is > automatically discovered and installed. I see, I think I might have misunderstood. Please correct me if I am wrong. With, one.jar pac/test.xml two.jar pac/test.xml three.jar pac/test.xml We would get something like (if we iterate over each iteration) jar:file:/.../one.jar!/META-INF/test.xml jar:file:/.../two.jar!/META-INF/test.xml jar:file:/.../three.jar!/META-INF/test.xml jar:file:/.../one.jar!/META-INF/test.xml jar:file:/.../two.jar!/META-INF/test.xml jar:file:/.../three.jar!/META-INF/test.xml jar:file:/.../one.jar!/META-INF/test.xml jar:file:/.../two.jar!/META-INF/test.xml jar:file:/.../three.jar!/META-INF/test.xml It should be sufficient I think if we could just get jar:file:/.../one.jar!/META-INF/test.xml jar:file:/.../two.jar!/META-INF/test.xml jar:file:/.../three.jar!/META-INF/test.xml instead of some extra duplicates. What do you think? Should we fix this, or is it a feature? Thx in advance. - Original Message From: Don Brown <[EMAIL PROTECTED]> To: Struts Developers List Sent: Tuesday, 12 September, 2006 10:35:18 AM Subject: Re: [Proposal] Framework plugin architecture (was Re: [s2] Logging levels) tm jee wrote: > Sounds cool. > > Just some thoughts. Maybe we could make the bootstrap struts xml > "struts-default.xml" and the plugins xml "struts-plugin.xml" while those in > the webapp "struts.xml". The bootstraping sequence would be > > 1] struts-default.xml > 2] struts-plugins.xml > 3] struts.xml > > This way its easier for us to control which config we are dealing with. If > we have the plugins config and the base bootsraping config all called > "struts-default.xml", depending on which gets loaded first in the classpath, > we might get the plugin's "struts-default.xml" called first before the > struts-core's "struts-default.xml" which will cause some problem (with > current xwork code) cuase some of the required interceptor, results etc used > by the plugin might not be loaded yet. I hope i got the concept correct, if > not please correct me. :-) > Good point, let's do this. > Another thing we might want to considered is the dependency of plugins. If > say plugin A needs some stuff declared in plugin B, it might not work, > depending on which gets loaded first in the classpath. Or would this make > thing unnecessarily complicated? > Well, the most robust solution for plugins would be to use OSGI like Eclipse does, however, I'm not sure we need that power yet. I'd like to keep it simple for now, sticking with a system that is already in place. It doubles as an example to users on how to plug in functionality easily. > About the new ClassLoaderUtil under xwork2 code, the method > "getResources(String, Class, boolean)". I think its better if we could make > the Iterator returned not to contains duplicates. Eg. if I jave > > one.jar > pac/test.xml > two.jar > pac/test.xml > three.jar > pac/test.xml > > trying to get "pac/test.xml" will return more than 3 copies. What do you guys > think? > Attached below is a patch attemt to fix this. I could create a jira issue if > its agreed that its something to be fix. > Actually, that's the whole point :) In our case, we are using it to get all the struts-plugin.xml files in all jars. This allows us to dynamically discover new plugins without the need to "register" them somewhere. It also makes it nice for users to deploy new modules by simply including a struts.xml file in their jar and the module is automatically discovered and installed. Don > Tia. > > Index: src/java/com/opensymphony/xwork2/util/ClassLoaderUtil.java > === > --- src/java/com/opensymphony/xwork2/util/ClassLoaderUtil.java (revision > 1129) > +++ src/java/com/opensymphony/xwork2/util/ClassLoaderUtil.java (working copy) > @@ -13,6 +13,7 @@ > import java.util.Collections; > import java.util.Enumeration; > import java.util.Iterator; > +import java.util.LinkedHashSet; > import java.util.LinkedList; > import java.util.List; > import java.util.NoSuchElementException; > @@ -160,7 +161,8 @@ > /** Aggregates Enumeration instances into
Re: [Proposal] Framework plugin architecture (was Re: [s2] Logging levels)
Sounds cool.
Just some thoughts. Maybe we could make the bootstrap struts xml
"struts-default.xml" and the plugins xml "struts-plugin.xml" while those in
the webapp "struts.xml". The bootstraping sequence would be
1] struts-default.xml
2] struts-plugins.xml
3] struts.xml
This way its easier for us to control which config we are dealing with. If we
have the plugins config and the base bootsraping config all called
"struts-default.xml", depending on which gets loaded first in the classpath,
we might get the plugin's "struts-default.xml" called first before the
struts-core's "struts-default.xml" which will cause some problem (with current
xwork code) cuase some of the required interceptor, results etc used by the
plugin might not be loaded yet. I hope i got the concept correct, if not please
correct me. :-)
Another thing we might want to considered is the dependency of plugins. If say
plugin A needs some stuff declared in plugin B, it might not work, depending on
which gets loaded first in the classpath. Or would this make thing
unnecessarily complicated?
About the new ClassLoaderUtil under xwork2 code, the method
"getResources(String, Class, boolean)". I think its better if we could make the
Iterator returned not to contains duplicates. Eg. if I jave
one.jar
pac/test.xml
two.jar
pac/test.xml
three.jar
pac/test.xml
trying to get "pac/test.xml" will return more than 3 copies. What do you guys
think?
Attached below is a patch attemt to fix this. I could create a jira issue if
its agreed that its something to be fix.
Tia.
Index: src/java/com/opensymphony/xwork2/util/ClassLoaderUtil.java
===
--- src/java/com/opensymphony/xwork2/util/ClassLoaderUtil.java (revision 1129)
+++ src/java/com/opensymphony/xwork2/util/ClassLoaderUtil.java (working copy)
@@ -13,6 +13,7 @@
import java.util.Collections;
import java.util.Enumeration;
import java.util.Iterator;
+import java.util.LinkedHashSet;
import java.util.LinkedList;
import java.util.List;
import java.util.NoSuchElementException;
@@ -160,7 +161,8 @@
/** Aggregates Enumeration instances into one iterator */
protected static class AggregateIterator implements Iterator {
-LinkedList> enums = new LinkedList>();
+//LinkedList> enums = new LinkedList>();
+ LinkedHashSet> enums = new
LinkedHashSet>();
Enumeration cur = null;
public AggregateIterator addEnumeration(Enumeration e) {
@@ -191,7 +193,9 @@
private Enumeration determineCurrentEnumeration() {
if (cur != null && !cur.hasMoreElements()) {
if (enums.size() > 0) {
-cur = enums.removeLast();
+ Enumeration[] e = enums.toArray(new Enumeration[0]);
+ enums.remove(e[enums.size() - 1]);
+//cur = enums.removeLast();
} else {
cur = null;
}
- Original Message
From: Ted Husted <[EMAIL PROTECTED]>
To: Struts Developers List
Sent: Tuesday, 12 September, 2006 6:23:06 AM
Subject: Re: [Proposal] Framework plugin architecture (was Re: [s2] Logging
levels)
On 9/11/06, Don Brown <[EMAIL PROTECTED]> wrote:
> The way I propose to solve this problem is to implement "Framework
> Plugins". A framework plugin is a jar that contains framework extension
> classes and configuration, which only need to be dropped into the
> classpath to be activated.
+1
-Ted.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r439914 - /struts/maven/trunk/struts2-archetype-starter/README.txt
Ahh... ok, noted. Changed the email address to direct to struts-dev malling list (in svn head). rgds - Original Message From: Ted Husted <[EMAIL PROTECTED]> To: dev@struts.apache.org Sent: Tuesday, 5 September, 2006 9:37:09 AM Subject: Re: svn commit: r439914 - /struts/maven/trunk/struts2-archetype-starter/README.txt As a general practice, it's better to encourage people to direct comments like this to dev@ or to file a comment against an open JIRA issue, rather than email an individual (who may be busy with a day job at the moment). -T. On 9/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > This is due to the fact that I can't find a way to change maven archetype > resource > path dynamically. If anyone knows how kindly let me know > (tm_jee(at)yahoo.co.uk). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] maven archetype
Ooopsss... or I should have check my mail again before creating a jira issue... :-) - Original Message From: Wendy Smoak <[EMAIL PROTECTED]> To: Struts Developers List Sent: Monday, 4 September, 2006 2:00:49 PM Subject: Re: [s2] maven archetype On 9/3/06, tm jee <[EMAIL PROTECTED]> wrote: > Thx for the tips Wendy. Created a jira issue under archetype module. Its at > http://jira.codehaus.org/browse/ARCHETYPE-54 ... and I closed ARCHETYPE-53 as a duplicate of yours. I should have waited a few more minutes. ;) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] maven archetype
Thx for the tips Wendy. Created a jira issue under archetype module. Its at http://jira.codehaus.org/browse/ARCHETYPE-54 rgds - Original Message From: Wendy Smoak <[EMAIL PROTECTED]> To: Struts Developers List Sent: Monday, 4 September, 2006 11:28:16 AM Subject: Re: [s2] maven archetype On 9/3/06, tm jee <[EMAIL PROTECTED]> wrote: > Is there a way allow resource generated by maven archetype to change > dynamically. ... > The files under the generated resources directory seems to be static. It > doesn't seems to change accordingly with the -DgroupId argument passed in. Is > there a way to configured it to change according to the groupId? Apparently not. In a prior version of Maven Archetype, you could put non-Java files in the section, and it would put them in the proper package structure. There are some notes in the Shale Blank archetype.xml file [1]. It probably needs to be raised in Maven's JIRA. I haven't filed it, let me know the issue number if you do. src/main/resources/Bundle.properties (And it's actually packageName, though that will default to groupId if you don't specify it.) [1] http://svn.apache.org/repos/asf/shale/maven/trunk/archetypes/shale-archetype-blank/src/main/resources/META-INF/archetype.xml -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r439910 - in /struts/maven/trunk/struts2-archetype-starter/src/main/resources/archetype-resources/src: main/java/ main/java/com/ test/java/ test/java/com/
Thx for the info. Fixed in svn head.
- Original Message
From: Wendy Smoak <[EMAIL PROTECTED]>
To: dev@struts.apache.org
Sent: Monday, 4 September, 2006 12:20:33 PM
Subject: Re: svn commit: r439910 - in
/struts/maven/trunk/struts2-archetype-starter/src/main/resources/archetype-resources/src:
main/java/ main/java/com/ test/java/ test/java/com/
On 9/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Author: tmjee
> Date: Sun Sep 3 19:58:55 2006
> New Revision: 439910
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=439910
struts/maven/trunk/struts2-archetype-starter/src/main/resources/archetype-resources/src/main/java/IndexAction.java
Sun Sep 3 19:58:55 2006
> @@ -15,7 +15,7 @@
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
> -package com.myComp.myApp;
> +package ${groupId};
This should be: package ${package} , else it won't work with:
mvn archetype:create -DgroupId=org.example -DpackageName=org.example.myproject
--
Wendy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ognl a new dependency?
> I did things similar to this, as well as removing xwork2 from my > (locally built) .m2/repository. Thanks for the tip, seems to be > working now. Glad its working now. I occationally get myself stuck in such situation as well. :-) - Original Message From: Matt Raible <[EMAIL PROTECTED]> To: Struts Developers List ; tm jee <[EMAIL PROTECTED]> Sent: Sunday, 3 September, 2006 2:51:19 PM Subject: Re: Ognl a new dependency? On 9/3/06, tm jee <[EMAIL PROTECTED]> wrote: > Could it be that the ognl jar in your local maven repository is being > corrupted? > > Does a clean compile work eg. I did things similar to this, as well as removing xwork2 from my (locally built) .m2/repository. Thanks for the tip, seems to be working now. Matt > > mvn clean compile ? > > - Original Message > From: Matt Raible <[EMAIL PROTECTED]> > To: Struts Developers List > Sent: Saturday, 2 September, 2006 10:36:53 PM > Subject: Ognl a new dependency? > > For some reason, my builds against 2.0.0 were fine - until I svn > updated this evening. Now I get: > > java.lang.NoClassDefFoundError: ognl/ClassResolver > at > com.opensymphony.xwork2.ActionContext$ActionContextThreadLocal.initialValue(ActionContext.java:328) > at > java.lang.ThreadLocal$ThreadLocalMap.getAfterMiss(ThreadLocal.java:374) > > After adding the following to my pom.xml: > > > ognl > ognl > 2.6.9 > > > I get: > > << ERROR! > java.lang.NoClassDefFoundError > at > com.opensymphony.xwork2.ActionContext$ActionContextThreadLocal.initialValue(ActionContext.java:328) > at > java.lang.ThreadLocal$ThreadLocalMap.getAfterMiss(ThreadLocal.java:374) > > Is something up with struts2 and xwork2 being out of synch? > > Thanks, > > Matt > > - > 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] maven archetype
Hi guys, Is there a way allow resource generated by maven archetype to change dynamically. For example, with mvn archetype:create -DgroupId=com.mycomp -DartifactId=myapp -DarchetypeGroupId=org.apache.struts -DarchetypeArtifactId=struts2-archetype-starter the structure created should be :- myapp + src + main + java + com + mycomp + java files (eg. SomeAction.java) + resources + ( this part seems to be static) .. The files under the generated resources directory seems to be static. It doesn't seems to change accordingly with the -DgroupId argument passed in. Is there a way to configured it to change according to the groupId? Tia.
Re: Ognl a new dependency?
Could it be that the ognl jar in your local maven repository is being corrupted? Does a clean compile work eg. mvn clean compile ? - Original Message From: Matt Raible <[EMAIL PROTECTED]> To: Struts Developers List Sent: Saturday, 2 September, 2006 10:36:53 PM Subject: Ognl a new dependency? For some reason, my builds against 2.0.0 were fine - until I svn updated this evening. Now I get: java.lang.NoClassDefFoundError: ognl/ClassResolver at com.opensymphony.xwork2.ActionContext$ActionContextThreadLocal.initialValue(ActionContext.java:328) at java.lang.ThreadLocal$ThreadLocalMap.getAfterMiss(ThreadLocal.java:374) After adding the following to my pom.xml: ognl ognl 2.6.9 I get: << ERROR! java.lang.NoClassDefFoundError at com.opensymphony.xwork2.ActionContext$ActionContextThreadLocal.initialValue(ActionContext.java:328) at java.lang.ThreadLocal$ThreadLocalMap.getAfterMiss(ThreadLocal.java:374) Is something up with struts2 and xwork2 being out of synch? Thanks, Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Retain the "!" idiom but disable it by default
I'd prefer it to be turn off by default. I normally use an extra action alias instead of "foo!bar". As for cancel action, I'd normally use and have an action alias "purchaseCancel" which could be using the same action class but with a different method defined in the struts xml file. instead of So, i guess the overall impact isn't significant to me. The overall sturts config file could get more verbose, but i guess we could separate them out using . regards - Original Message From: Ted Husted <[EMAIL PROTECTED]> To: Struts Developers List Sent: Saturday, 26 August, 2006 8:35:31 AM Subject: Re: [VOTE] Retain the "!" idiom but disable it by default On 8/25/06, Don Brown <[EMAIL PROTECTED]> wrote: > What were you meaning by removing the deprecation? Deprecation means that we may remove the behavior in favor of a preferred alternative. That's very different from making the behavior switchable. Right now, we don't have a preferred alternative, so it was wrong to ever refer to the behavior as "deprecated" in the first place. The original notion was that wildcards could be a dropin replacement for hardwiring the "!" syntax, and in my experience, we are already 98% there, but it's hard to test wilcard replacements with the hardwired code switched on, since the special-casde code hijacks the processing of any action name with an embedded "!". The builtin, hardwired, non-configurable behavior It is also arguably a security flaw, and since we already have code that can switch it off, there is no reason not to provide the switch, even if the default is to enable the behavior. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Freemarker transform name
>I updated that, and the velocity prefix, yesterday. Ah... Ok.. cheers Ted. Looks like I am a bit out dated. :-) > For the validator framework, is the "Classname-alias-validation.xml" > syntax working? Yes, i believe it is. > The next biggest task is following up with the taglib proposal. > (Starting with refreshing the TLD file from the WW head.) Ok, have we decided on this yet? that is to maintain only the tld (by hand) and have all the examples in the tld as well. If so, I think we'll have to remove all the xdoclet tags as well to avoid confusion. > But, since it's optional for 2.0, that could also wait for 2.0.1 or so. Ok then. > We should also update the Showcase example so that they do not use the > ! alias syntax. Agree. I think we have a jira issue for this already. rgds. - Original Message From: Ted Husted <[EMAIL PROTECTED]> To: Struts Developers List ; tm jee <[EMAIL PROTECTED]> Sent: Monday, 21 August, 2006 7:33:35 AM Subject: Re: [s2] Freemarker transform name I updated that, and the velocity prefix, yesterday. (Check out your Hangman example!) The next biggest task is following up with the taglib proposal. (Starting with refreshing the TLD file from the WW head.) We should also update the Showcase example so that they do not use the ! alias syntax. (For the validator framework, is the "Classname-alias-validation.xml" syntax working? Without that, we have to flex the stack or create stub subclasses.) With those two things, and a final pass on the documentation, we should be good to go for 2.0.0. The third remaining task is completing the remaining 10% of the new API, utilizing it for our own examples, and updating the relevant documentation. But, since it's optional for 2.0, that could also wait for 2.0.1 or so. -Ted. On 8/21/06, tm jee <[EMAIL PROTECTED]> wrote: > Hi guys, > > If not mistaken i think we came to the conclusion to rename Struts2 > Freemarker transform from saf to s such that instead of doing > > <@saf.property value="" /> > > we would do > > <@s.property value="" /> > > Just want to confirm this, cause I've notice the its not changed to "s" yet. > I could make the changes within these few days, if the above is correct. > > Tia. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[s2] Freemarker transform name
Hi guys, If not mistaken i think we came to the conclusion to rename Struts2 Freemarker transform from saf to s such that instead of doing <@saf.property value="" /> we would do <@s.property value="" /> Just want to confirm this, cause I've notice the its not changed to "s" yet. I could make the changes within these few days, if the above is correct. Tia.
Re: [s2] Snippet Macro
The xwork2 snippet can't seems to be referenced. I was trying to change this
http://cwiki.apache.org/confluence/display/WW/Model+Driven+Interceptor
from refering to the old xwork to the new xwork2.
Looks like it is still refering to cvs instead of the new svn.
Just notice this in the diff
- if (urlParam.startsWith("com.opensymphony.")) {
+ if (urlParam.startsWith("org.opensymphony.")) {
shouldn't it be "com.opensymphony..." instead?
Thx in advance.
- Original Message
From: tm jee <[EMAIL PROTECTED]>
To: Struts Developers List
Sent: Saturday, 19 August, 2006 12:51:16 AM
Subject: Re: [s2] Snippet Macro
Cheers. Ted.
- Original Message
From: Ted Husted <[EMAIL PROTECTED]>
To: Struts Developers List
Sent: Friday, 18 August, 2006 11:09:14 PM
Subject: Re: [s2] Snippet Macro
OK, the snippet macro is up and running on the ASF Struts 2 wiki,
complete with shortcuts.
h2. Description
{snippet:id=javadoc|javadoc=true|url=org.apache.struts2.components.If}
h2. Parameters
{snippet:id=tagattributes|javadoc=false|url=struts2/docs/tags/If.html}
h2. Examples
{snippet:id=example|lang=xml|javadoc=true|url=struts2/core/src/main/java/org/apache/struts2/components/If.java}
I'll start a final pass on the wiki to update the snippets and catch
other stragglers.
(Note that when updating the references pages, we should rachet the
headings down a knotch, so that the largest is h2. (h1 being reserved
for the top-level page title.))
I didn't have the karma to check the snippet macro back in, but here's
the patch.
Index: snippet/src/java/atlassian-plugin.xml
===
--- snippet/src/java/atlassian-plugin.xml(revision 279)
+++ snippet/src/java/atlassian-plugin.xml(working copy)
@@ -2,8 +2,8 @@
Macro that gets a snippet of the content from a
URL
-http://www.codehaus.com"/>
-0.5
+https://opensymphony.dev.java.net/source/browse/opensymphony/wiki/snippet/"/>
+r280
Index: snippet/src/java/snippet/SnippetMacro.java
===
--- snippet/src/java/snippet/SnippetMacro.java(revision 279)
+++ snippet/src/java/snippet/SnippetMacro.java(working copy)
@@ -106,7 +106,7 @@
String urlParam = (String) parameters.get("url");
required(urlParam, "url");
- if (urlParam.startsWith("com.opensymphony.")) {
+ if (urlParam.startsWith("org.opensymphony.")) {
// ok, this is a direct class reference, we can fix this
// first, figure out which module we're talking about
int nextDot = urlParam.indexOf('.', "com.opensymphony.".length());
@@ -121,18 +121,18 @@
} else {
urlParam = module + "/src/java/" +
urlParam.replaceAll("\\.", "/") + ".java";
}
-} else if (urlParam.startsWith("org.apache.struts.action2.")) {
-// ex:
https://svn.apache.org/repos/asf/struts/action2/trunk/core/src/main/java/org/apache/struts/action2/
-// support for SAF 2.0
-String url =
"https://svn.apache.org/repos/asf/struts/action2/trunk/core/src/main/java/"
+} else if (urlParam.startsWith("org.apache.struts2.")) {
+// ex:
https://svn.apache.org/repos/asf/struts/strut2/trunk/core/src/main/java/org/apache/struts/action2/
+// support for Struts 2.0
+String url =
"https://svn.apache.org/repos/asf/struts/struts2/trunk/core/src/main/java/"
urlParam = url + urlParam.replaceAll("\\.", "/") + ".java";
}
if (!urlParam.startsWith("http")) {
-if (urlParam.startsWith("action2")) {
-// cut out the action2 part
-urlParam = urlParam.substring("action2".length());
-urlParam =
"https://svn.apache.org/repos/asf/struts/action2/trunk/" + urlParam;
+if (urlParam.startsWith("struts2")) {
+// cut out the struts2 part
+urlParam = urlParam.substring("struts2".length());
+urlParam =
"https://svn.apache.org/repos/asf/struts/struts2/trunk/" + urlParam;
} else {
urlParam =
"https://opensymphony.dev.java.net/source/browse/*checkout*/" +
urlParam;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
