So lets do it and consolidate all of the configuration automation into Convention. We can get the new Convention and REST in 2.1.3-SNAPSHOT and then update the Codebehind page that its being absorbed into Convention.
I say the new version of Convention doesn't have to support Codebehind if its going to hold back the Convention code base. We are at a sensitive and early spot where we want to pick a winner and run with it. If people don't want to "upgrade" they can run their apps with Codebehind or make the changes needed for Convention. The only feature I think really needs to be in Convention is that it looks for default results in [base path config]/action-name/result-name.jsp. At least we can make the "separator" (- or /) configurable between the action name and result. -D Don Brown-2 wrote: > > That's not a problem, particularly if we jarjar the dependency in the > xwork jar. > > Don > > On Wed, May 28, 2008 at 10:12 AM, Musachy Barroso <[EMAIL PROTECTED]> > wrote: >> It depends on ASM >> >> musachy >> >> On Tue, May 27, 2008 at 8:07 PM, Don Brown <[EMAIL PROTECTED]> wrote: >>> My vote is we bring the classes into XWork to replace the existing >>> classpath scanner. >>> >>> Don >>> >>> On Wed, May 28, 2008 at 10:04 AM, Musachy Barroso <[EMAIL PROTECTED]> >>> wrote: >>>> I will check it out. Is this something that another plugin could use >>>> or core itself? >>>> >>>> musachy >>>> >>>> On Tue, May 27, 2008 at 7:24 PM, Don Brown <[EMAIL PROTECTED]> wrote: >>>>> Hmm...this should really be another thread, but there is a much better >>>>> solution for classpath scanning - xbean-finder. It is a small library >>>>> used by OpenEJB and Geronimo, three classes, that scans the classpath, >>>>> but uses a technique that doesn't require the class to be loaded into >>>>> memory. As a result, it uses less resources and is much faster. >>>>> >>>>> http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/ >>>>> >>>>> Don >>>>> >>>>> On Wed, May 28, 2008 at 12:18 AM, Musachy Barroso <[EMAIL PROTECTED]> >>>>> wrote: >>>>>> You are right and I am confused with another problem, if your action >>>>>> is: >>>>>> >>>>>> action -> actions.MyCoolAction (@ResultPath("/")) >>>>>> result -> /my-cool.ftl >>>>>> >>>>>> what you get is a bunch of (with different jars) >>>>>> >>>>>> SEVERE: Unable to scan [C:\Program >>>>>> Files\apache-tomcat-6.0.16\lib\catalina.jar] for resources >>>>>> java.lang.IllegalArgumentException: Unable to make a URL >>>>>> ..... >>>>>> Caused by: java.net.MalformedURLException: no protocol: >>>>>> /catalina-ha.jar >>>>>> ...... >>>>>> >>>>>> >>>>>> At some point I did get NoClassDefFoundError, like Dusty mentioned, >>>>>> but I can't replicate it, so I will this.shutUp() for now :) >>>>>> >>>>>> musachy >>>>>> >>>>>> On Tue, May 27, 2008 at 9:36 AM, Brian Pontarelli >>>>>> <[EMAIL PROTECTED]> wrote: >>>>>>> Musachy Barroso wrote: >>>>>>>>> >>>>>>>>> The scanning doesn't have anything to do with the location of the >>>>>>>>> JSP >>>>>>>>> files. >>>>>>>>> It is entirely based on the set of package locators and exclude >>>>>>>>> packages. >>>>>>>>> It >>>>>>>>> uses the classpath scanning mechanism that simply opens all the >>>>>>>>> JAR files >>>>>>>>> and looks at them. It only loads a class into the JVM if it is in >>>>>>>>> a >>>>>>>>> correctly named package that is not excluded. >>>>>>>>> >>>>>>>> >>>>>>>> No, what I meant is, if you have your templates under root, like in >>>>>>>> rest-showcase and you add: >>>>>>>> >>>>>>>> @ResultPath("/") >>>>>>>> >>>>>>>> then it will scan the whole classpath(unless like you said, the >>>>>>>> package locators are modified), which can cause some trouble. >>>>>>>> >>>>>>> >>>>>>> This still shouldn't matter. You shouldn't need to change the >>>>>>> package >>>>>>> locators to find templates. The ResultPath and all the template >>>>>>> configuration is used elsewhere and separate. I keep my templates in >>>>>>> WEB-INF/content and my actions are in *actions*, but this is >>>>>>> completely >>>>>>> arbitrary. Even if you place your templates in /, you can still have >>>>>>> a >>>>>>> locator like "actions" and exclude packages however you need. >>>>>>> >>>>>>> All that is necessary is that the namespace of the action and the >>>>>>> result are >>>>>>> matched. Therefore you could do this: >>>>>>> >>>>>>> action -> com.example.actions.someNamespace.MyCoolAction >>>>>>> result -> /some-namespace/my-cool.ftl >>>>>>> >>>>>>> This works fine and the locator and exclude packages hasn't been >>>>>>> modified. >>>>>>> Unless I'm missing something, you case should be easy to fix. >>>>>>> >>>>>>> -bp >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> "Hey you! Would you help me to carry the stone?" Pink Floyd >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> "Hey you! Would you help me to carry the stone?" Pink Floyd >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> >> >> -- >> "Hey you! Would you help me to carry the stone?" Pink Floyd >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/-VOTE--Bring-Convention-plugin-into-trunk-and-deprecate-Zero-Config-tp17222798p17522443.html Sent from the Struts - Dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
