On Fri, May 30, 2008 at 7:56 AM, Musachy Barroso <[EMAIL PROTECTED]> wrote:
> Sounds like a plan but we don't have the votes yet :) I think this is where I chime in (again) and claim that consensus is preferable to a vote in any case. ;-) -- Martin Cooper > > musachy > > On Wed, May 28, 2008 at 5:21 PM, dusty <[EMAIL PROTECTED]> wrote: > > > > So lets do it and consolidate all of the configuration automation into > > Convention. We can get the new Convention and REST in 2.1.3-SNAPSHOT and > > then update the Codebehind page that its being absorbed into Convention. > > > > I say the new version of Convention doesn't have to support Codebehind if > > its going to hold back the Convention code base. 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] > > > > > > > > -- > "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] > >
