Re: convention and actions with annotations

I think most people would say, sure! But I think we are getting into the too many options phase again. I think if you are using Struts2 then its totally acceptable that it only scans the packages you declare and then only finds actions that end in Controller. Maybe not going that far, but it wo

Re: classpath scanner

That sounds like a good idea. I sent you a ClassFinder that does that. If you want to wait for a real patch I could create one over the weekend. thanks musachy On Thu, May 29, 2008 at 3:47 PM, David Blevins <[EMAIL PROTECTED]> wrote: > We could probably hook that up. The ClassLoader is a require

Re: classpath scanner

We could probably hook that up. The ClassLoader is a required argument for byte code scrapping, so we could pretty easily do a classLoader.findResource() to get the parent class, then process recursively. We'd just leave that deeper resolution off by default and allow it to be turned on w

convention and actions with annotations

Right now convention will find actions on named packages("com.my.classes.") or in package that match a package locator("actions", will match *.actions.*). Shouldn't it also find any action with an @Action annotation, disregarding the package? (there would be a flag to turn this off). musachy --

Re: classpath scanner

We would have to load the class at that point. I don't think we could make ClassFinder do this for us, because some of the classes in the hierarchy could be in the excluded jars. musachy On Thu, May 29, 2008 at 1:17 PM, Brian Pontarelli <[EMAIL PROTECTED]> wrote: > But does that include all of th

parameter vagaries...

In Struts2.1.X there are now multiple interceptors for setting parameters from different sources on the action, but these don't also add those parameters into the map stored in ActionContext so that they are included in the map set when implementing ParameterAware... I can try to work up some

Re: classpath scanner

No, you are right it doesn't include interfaces from parent classes/interfaces. It was working because of a bug somewhere else. musachy On Thu, May 29, 2008 at 1:17 PM, Brian Pontarelli <[EMAIL PROTECTED]> wrote: > But does that include all of the interfaces including those implemented by > super

Re: classpath scanner

But does that include all of the interfaces including those implemented by super-classes and those which interfaces the class directly implements extend? Musachy Barroso wrote: ClassFinder.ClassInfo has a list of implemented interfaces, so I am checking if "com.opensymphony.xwork2.Action" is

Re: classpath scanner

--- Musachy Barroso <[EMAIL PROTECTED]> wrote: > > is there any other way of doing this? property file? > This list for Struts development only. Pleas ask your question on the > users list. But here is the answer: It's so hard to keep the riff-raff out, especially when it's us. Dave ---

Re: classpath scanner

> is there any other way of doing this? property file? > This list for Struts development only. Pleas ask your question on the users list. But here is the answer: http://struts.apache.org/2.x/docs/constant-configuration.html musachy --

Re: classpath scanner

Hardcoding the jars to be excluded is not really cool, but requires a value, it would be nice if I could do: super regex list here... is there any other way of doing this? property file? musachy On Thu, May 29, 2008 at 11:58 AM, Musachy Barroso <[EMAIL PROTECTED]> wrote: > ClassFinde

Re: classpath scanner

ClassFinder.ClassInfo has a list of implemented interfaces, so I am checking if "com.opensymphony.xwork2.Action" is one of them musachy On Thu, May 29, 2008 at 11:47 AM, Brian Pontarelli <[EMAIL PROTECTED]> wrote: > > Just a quick question. How did you modify ClasFinder to check for > implementat

Re: classpath scanner

Just a quick question. How did you modify ClasFinder to check for implementation of the XWork Action interface? Doesn't this need to parse up the inheritance chain as well as the implementation chain? It didn't look like ClassFinder currently did that, unless I missed it. -bp Musachy Barro

Re: classpath scanner

Thanks for the tips, I wasn't using UrlSet at yet, but that looks great . I am using ASM 3 with it, I don't know about new features you could take advantage of, but it is easy to get it running. I think this method is wrong on ClassInfo: public String getPackageName(){ return name.substring(

Re: classpath scanner

xbean-finder is already split into a common library, just it is part of the xbean project rather than commons. From a technical level, there is no difference. The reason we want to copy the code over has less to do with the project's stability but the desire to have fewer dependencies. Don On T