You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Musachy Barroso <mu...@gmail.com> on 2008/05/28 21:07:47 UTC
classpath scanner
Stating new thread for this topic. Don suggested to use this classpath scanner:
http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/
in xwork and plugins. It uses ASM to extract class information and
annotations,so loading classes can be avoided until the last minute
(when you actually need it). I modified convention to use it(not
committed), and it is pretty good. Comment away here.
musachy
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: classpath scanner
Posted by Brian Pontarelli <br...@pontarelli.com>.
it's all Apache license and only 3 classes so we could just pull it into
XWork and manage it there.
On Wed, May 28, 2008 at 3:24 PM, dusty <du...@yahoo.com> wrote:
>
> If you already have it working, then great! I don't know anything about
> it,
> so my question is only how likely are the authors to update/nurse this
> library?
>
> -D
>
>
>
> Musachy Barroso wrote:
> >
> > Stating new thread for this topic. Don suggested to use this classpath
> > scanner:
> >
> > http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/
> >
> > in xwork and plugins. It uses ASM to extract class information and
> > annotations,so loading classes can be avoided until the last minute
> > (when you actually need it). I modified convention to use it(not
> > committed), and it is pretty good. Comment away here.
> >
> > musachy
> > --
> > "Hey you! Would you help me to carry the stone?" Pink Floyd
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/classpath-scanner-tp17519827p17522489.html
> Sent from the Struts - Dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: classpath scanner
Posted by Musachy Barroso <mu...@gmail.com>.
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 <da...@visi.com> wrote:
> 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 with a constructor flag.
>
> -David
>
> On May 29, 2008, at 10:43 AM, Musachy Barroso wrote:
>
>> 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 <br...@pontarelli.com>
>> wrote:
>>>
>>> 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 one of them
>>>>
>>>> musachy
>>>>
>>>> On Thu, May 29, 2008 at 11:47 AM, Brian Pontarelli
>>>> <br...@pontarelli.com>
>>>> wrote:
>>>>
>>>>>
>>>>> 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 Barroso wrote:
>>>>>
>>>>>>
>>>>>> 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(name.lastIndexOf(".")+1, name.length());
>>>>>> }
>>>>>>
>>>>>> musachy
>>>>>>
>>>>>> On Wed, May 28, 2008 at 9:04 PM, David Blevins
>>>>>> <da...@visi.com>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On May 28, 2008, at 4:54 PM, Musachy Barroso wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>> It is a standalone library, used heavily by the OpenEJB and
>>>>>>>>> Geronimo
>>>>>>>>> guys.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> oops.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Personally, I favor copying the code over and jarjar'ing the asm
>>>>>>>>> dependency.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> +1
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> +1 :)
>>>>>>>
>>>>>>> Just wanted to throw my support in for fun.
>>>>>>>
>>>>>>> I'd pull in the ClassFinder and UrlSet. ClassFinder.java is a
>>>>>>> standalone
>>>>>>> class (aside from ASM), but the UrlSet is really useful for narrowing
>>>>>>> down
>>>>>>> the scope of jars that you search which of course makes things even
>>>>>>> faster.
>>>>>>>
>>>>>>> If you know the exact jar(s) you want to search, you're set. But if
>>>>>>> you
>>>>>>> simply have a classloader and want to search everything "in" it, you
>>>>>>> might
>>>>>>> want to rip out some standard vm jars and other jars you know you do
>>>>>>> not
>>>>>>> care about. Here's an example usage:
>>>>>>>
>>>>>>> // Just this line right here is good as is will diff the classpath of
>>>>>>> the
>>>>>>> // parent classloader against the classpath of the supplied
>>>>>>> classloader
>>>>>>> and
>>>>>>> // give you the difference.
>>>>>>> UrlSet urlSet = new UrlSet(classLoader);
>>>>>>>
>>>>>>> // If you happen to need to search the system classloader, the
>>>>>>> difference
>>>>>>> // still leaves a lot of useless garbage
>>>>>>> urlSet =
>>>>>>> urlSet.exclude(ClassLoader.getSystemClassLoader().getParent());
>>>>>>> urlSet = urlSet.excludeJavaExtDirs();
>>>>>>> urlSet = urlSet.excludeJavaEndorsedDirs();
>>>>>>> urlSet = urlSet.excludeJavaHome();
>>>>>>> urlSet =
>>>>>>> urlSet.excludePaths(System.getProperty("sun.boot.class.path",
>>>>>>> ""));
>>>>>>> urlSet = urlSet.exclude(".*/JavaVM.framework/.*");
>>>>>>>
>>>>>>> // If the remainder contains a lot of third party libraries required
>>>>>>> by
>>>>>>> you
>>>>>>> // that you know don't contain annotations you're interested in, then
>>>>>>> it
>>>>>>> can
>>>>>>> // be good to aggressively cut those out.
>>>>>>> urlSet = urlSet.exclude(".*/activemq-(core|ra)-[\\d.]+.jar(!/)?");
>>>>>>> urlSet = urlSet.exclude(".*/catalina-[\\d.]+.jar(!/)?");
>>>>>>> urlSet =
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> urlSet.exclude(".*/commons-(logging|cli|pool|lang|collections|dbcp)-[\\d.]+.jar(!/)?");
>>>>>>> urlSet = urlSet.exclude(".*/derby-[\\d.]+.jar(!/)?");
>>>>>>> urlSet =
>>>>>>>
>>>>>>> urlSet.exclude(".*/geronimo-(connector|transaction)-[\\d.]+.jar(!/)?");
>>>>>>> urlSet = urlSet.exclude(".*/geronimo-[^/]+_spec-[\\d.]+.jar(!/)?");
>>>>>>> urlSet =
>>>>>>>
>>>>>>> urlSet.exclude(".*/geronimo-javamail_([\\d.]+)_mail-[\\d.]+.jar(!/)?");
>>>>>>> urlSet = urlSet.exclude(".*/hsqldb-[\\d.]+.jar(!/)?");
>>>>>>> urlSet = urlSet.exclude(".*/idb-[\\d.]+.jar(!/)?");
>>>>>>> urlSet = urlSet.exclude(".*/jaxb-(impl|api)-[\\d.]+.jar(!/)?");
>>>>>>> urlSet = urlSet.exclude(".*/junit-[\\d.]+.jar(!/)?");
>>>>>>> urlSet = urlSet.exclude(".*/log4j-[\\d.]+.jar(!/)?");
>>>>>>> urlSet =
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> urlSet.exclude(".*/openjpa-(jdbc|kernel|lib|persistence|persistence-jdbc)(-5)?-[\\d.]+.jar(!/)?");
>>>>>>>
>>>>>>> // then eventually
>>>>>>> List<URL> urls = urlSet.getUrls();
>>>>>>> ClassFinder classFinder = new ClassFinder(classloader, urls);
>>>>>>>
>>>>>>>
>>>>>>> As far as the stability of the API, it hasn't changed in months and
>>>>>>> months.
>>>>>>> I do have one planned change involving the use of ASM 3 and new flag
>>>>>>> that
>>>>>>> will speed up the scanning by allowing ASM to skip by large chunks of
>>>>>>> the
>>>>>>> byte code.
>>>>>>>
>>>>>>> Let me see if I can't get that in there real quick.
>>>>>>>
>>>>>>> -David
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>>
>>
>> --
>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: classpath scanner
Posted by David Blevins <da...@visi.com>.
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 with a constructor flag.
-David
On May 29, 2008, at 10:43 AM, Musachy Barroso wrote:
> 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 <brian@pontarelli.com
> > wrote:
>> 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 one of them
>>>
>>> musachy
>>>
>>> On Thu, May 29, 2008 at 11:47 AM, Brian Pontarelli <brian@pontarelli.com
>>> >
>>> wrote:
>>>
>>>>
>>>> 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 Barroso wrote:
>>>>
>>>>>
>>>>> 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(name.lastIndexOf(".")+1, name.length());
>>>>> }
>>>>>
>>>>> musachy
>>>>>
>>>>> On Wed, May 28, 2008 at 9:04 PM, David Blevins <david.blevins@visi.com
>>>>> >
>>>>> wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> On May 28, 2008, at 4:54 PM, Musachy Barroso wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>> It is a standalone library, used heavily by the OpenEJB and
>>>>>>>> Geronimo
>>>>>>>> guys.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> oops.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Personally, I favor copying the code over and jarjar'ing the
>>>>>>>> asm
>>>>>>>> dependency.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> +1 :)
>>>>>>
>>>>>> Just wanted to throw my support in for fun.
>>>>>>
>>>>>> I'd pull in the ClassFinder and UrlSet. ClassFinder.java is a
>>>>>> standalone
>>>>>> class (aside from ASM), but the UrlSet is really useful for
>>>>>> narrowing
>>>>>> down
>>>>>> the scope of jars that you search which of course makes things
>>>>>> even
>>>>>> faster.
>>>>>>
>>>>>> If you know the exact jar(s) you want to search, you're set.
>>>>>> But if
>>>>>> you
>>>>>> simply have a classloader and want to search everything "in"
>>>>>> it, you
>>>>>> might
>>>>>> want to rip out some standard vm jars and other jars you know
>>>>>> you do
>>>>>> not
>>>>>> care about. Here's an example usage:
>>>>>>
>>>>>> // Just this line right here is good as is will diff the
>>>>>> classpath of
>>>>>> the
>>>>>> // parent classloader against the classpath of the supplied
>>>>>> classloader
>>>>>> and
>>>>>> // give you the difference.
>>>>>> UrlSet urlSet = new UrlSet(classLoader);
>>>>>>
>>>>>> // If you happen to need to search the system classloader, the
>>>>>> difference
>>>>>> // still leaves a lot of useless garbage
>>>>>> urlSet =
>>>>>> urlSet.exclude(ClassLoader.getSystemClassLoader().getParent());
>>>>>> urlSet = urlSet.excludeJavaExtDirs();
>>>>>> urlSet = urlSet.excludeJavaEndorsedDirs();
>>>>>> urlSet = urlSet.excludeJavaHome();
>>>>>> urlSet =
>>>>>> urlSet.excludePaths(System.getProperty("sun.boot.class.path",
>>>>>> ""));
>>>>>> urlSet = urlSet.exclude(".*/JavaVM.framework/.*");
>>>>>>
>>>>>> // If the remainder contains a lot of third party libraries
>>>>>> required
>>>>>> by
>>>>>> you
>>>>>> // that you know don't contain annotations you're interested
>>>>>> in, then
>>>>>> it
>>>>>> can
>>>>>> // be good to aggressively cut those out.
>>>>>> urlSet = urlSet.exclude(".*/activemq-(core|ra)-[\\d.]
>>>>>> +.jar(!/)?");
>>>>>> urlSet = urlSet.exclude(".*/catalina-[\\d.]+.jar(!/)?");
>>>>>> urlSet =
>>>>>>
>>>>>>
>>>>>> urlSet.exclude(".*/commons-(logging|cli|pool|lang|collections|
>>>>>> dbcp)-[\\d.]+.jar(!/)?");
>>>>>> urlSet = urlSet.exclude(".*/derby-[\\d.]+.jar(!/)?");
>>>>>> urlSet =
>>>>>> urlSet.exclude(".*/geronimo-(connector|transaction)-[\\d.]
>>>>>> +.jar(!/)?");
>>>>>> urlSet = urlSet.exclude(".*/geronimo-[^/]+_spec-[\\d.]
>>>>>> +.jar(!/)?");
>>>>>> urlSet =
>>>>>> urlSet.exclude(".*/geronimo-javamail_([\\d.]+)_mail-[\\d.]
>>>>>> +.jar(!/)?");
>>>>>> urlSet = urlSet.exclude(".*/hsqldb-[\\d.]+.jar(!/)?");
>>>>>> urlSet = urlSet.exclude(".*/idb-[\\d.]+.jar(!/)?");
>>>>>> urlSet = urlSet.exclude(".*/jaxb-(impl|api)-[\\d.]+.jar(!/)?");
>>>>>> urlSet = urlSet.exclude(".*/junit-[\\d.]+.jar(!/)?");
>>>>>> urlSet = urlSet.exclude(".*/log4j-[\\d.]+.jar(!/)?");
>>>>>> urlSet =
>>>>>>
>>>>>>
>>>>>> urlSet.exclude(".*/openjpa-(jdbc|kernel|lib|persistence|
>>>>>> persistence-jdbc)(-5)?-[\\d.]+.jar(!/)?");
>>>>>>
>>>>>> // then eventually
>>>>>> List<URL> urls = urlSet.getUrls();
>>>>>> ClassFinder classFinder = new ClassFinder(classloader, urls);
>>>>>>
>>>>>>
>>>>>> As far as the stability of the API, it hasn't changed in months
>>>>>> and
>>>>>> months.
>>>>>> I do have one planned change involving the use of ASM 3 and new
>>>>>> flag
>>>>>> that
>>>>>> will speed up the scanning by allowing ASM to skip by large
>>>>>> chunks of
>>>>>> the
>>>>>> byte code.
>>>>>>
>>>>>> Let me see if I can't get that in there real quick.
>>>>>>
>>>>>> -David
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: classpath scanner
Posted by Musachy Barroso <mu...@gmail.com>.
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 <br...@pontarelli.com> wrote:
> 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 one of them
>>
>> musachy
>>
>> On Thu, May 29, 2008 at 11:47 AM, Brian Pontarelli <br...@pontarelli.com>
>> wrote:
>>
>>>
>>> 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 Barroso wrote:
>>>
>>>>
>>>> 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(name.lastIndexOf(".")+1, name.length());
>>>> }
>>>>
>>>> musachy
>>>>
>>>> On Wed, May 28, 2008 at 9:04 PM, David Blevins <da...@visi.com>
>>>> wrote:
>>>>
>>>>
>>>>>
>>>>> On May 28, 2008, at 4:54 PM, Musachy Barroso wrote:
>>>>>
>>>>>
>>>>>
>>>>>>>
>>>>>>> It is a standalone library, used heavily by the OpenEJB and Geronimo
>>>>>>> guys.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> oops.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Personally, I favor copying the code over and jarjar'ing the asm
>>>>>>> dependency.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> +1
>>>>>>
>>>>>>
>>>>>
>>>>> +1 :)
>>>>>
>>>>> Just wanted to throw my support in for fun.
>>>>>
>>>>> I'd pull in the ClassFinder and UrlSet. ClassFinder.java is a
>>>>> standalone
>>>>> class (aside from ASM), but the UrlSet is really useful for narrowing
>>>>> down
>>>>> the scope of jars that you search which of course makes things even
>>>>> faster.
>>>>>
>>>>> If you know the exact jar(s) you want to search, you're set. But if
>>>>> you
>>>>> simply have a classloader and want to search everything "in" it, you
>>>>> might
>>>>> want to rip out some standard vm jars and other jars you know you do
>>>>> not
>>>>> care about. Here's an example usage:
>>>>>
>>>>> // Just this line right here is good as is will diff the classpath of
>>>>> the
>>>>> // parent classloader against the classpath of the supplied
>>>>> classloader
>>>>> and
>>>>> // give you the difference.
>>>>> UrlSet urlSet = new UrlSet(classLoader);
>>>>>
>>>>> // If you happen to need to search the system classloader, the
>>>>> difference
>>>>> // still leaves a lot of useless garbage
>>>>> urlSet =
>>>>> urlSet.exclude(ClassLoader.getSystemClassLoader().getParent());
>>>>> urlSet = urlSet.excludeJavaExtDirs();
>>>>> urlSet = urlSet.excludeJavaEndorsedDirs();
>>>>> urlSet = urlSet.excludeJavaHome();
>>>>> urlSet = urlSet.excludePaths(System.getProperty("sun.boot.class.path",
>>>>> ""));
>>>>> urlSet = urlSet.exclude(".*/JavaVM.framework/.*");
>>>>>
>>>>> // If the remainder contains a lot of third party libraries required
>>>>> by
>>>>> you
>>>>> // that you know don't contain annotations you're interested in, then
>>>>> it
>>>>> can
>>>>> // be good to aggressively cut those out.
>>>>> urlSet = urlSet.exclude(".*/activemq-(core|ra)-[\\d.]+.jar(!/)?");
>>>>> urlSet = urlSet.exclude(".*/catalina-[\\d.]+.jar(!/)?");
>>>>> urlSet =
>>>>>
>>>>>
>>>>> urlSet.exclude(".*/commons-(logging|cli|pool|lang|collections|dbcp)-[\\d.]+.jar(!/)?");
>>>>> urlSet = urlSet.exclude(".*/derby-[\\d.]+.jar(!/)?");
>>>>> urlSet =
>>>>> urlSet.exclude(".*/geronimo-(connector|transaction)-[\\d.]+.jar(!/)?");
>>>>> urlSet = urlSet.exclude(".*/geronimo-[^/]+_spec-[\\d.]+.jar(!/)?");
>>>>> urlSet =
>>>>> urlSet.exclude(".*/geronimo-javamail_([\\d.]+)_mail-[\\d.]+.jar(!/)?");
>>>>> urlSet = urlSet.exclude(".*/hsqldb-[\\d.]+.jar(!/)?");
>>>>> urlSet = urlSet.exclude(".*/idb-[\\d.]+.jar(!/)?");
>>>>> urlSet = urlSet.exclude(".*/jaxb-(impl|api)-[\\d.]+.jar(!/)?");
>>>>> urlSet = urlSet.exclude(".*/junit-[\\d.]+.jar(!/)?");
>>>>> urlSet = urlSet.exclude(".*/log4j-[\\d.]+.jar(!/)?");
>>>>> urlSet =
>>>>>
>>>>>
>>>>> urlSet.exclude(".*/openjpa-(jdbc|kernel|lib|persistence|persistence-jdbc)(-5)?-[\\d.]+.jar(!/)?");
>>>>>
>>>>> // then eventually
>>>>> List<URL> urls = urlSet.getUrls();
>>>>> ClassFinder classFinder = new ClassFinder(classloader, urls);
>>>>>
>>>>>
>>>>> As far as the stability of the API, it hasn't changed in months and
>>>>> months.
>>>>> I do have one planned change involving the use of ASM 3 and new flag
>>>>> that
>>>>> will speed up the scanning by allowing ASM to skip by large chunks of
>>>>> the
>>>>> byte code.
>>>>>
>>>>> Let me see if I can't get that in there real quick.
>>>>>
>>>>> -David
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>>
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: classpath scanner
Posted by Musachy Barroso <mu...@gmail.com>.
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 <br...@pontarelli.com> wrote:
> 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 one of them
>>
>> musachy
>>
>> On Thu, May 29, 2008 at 11:47 AM, Brian Pontarelli <br...@pontarelli.com>
>> wrote:
>>
>>>
>>> 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 Barroso wrote:
>>>
>>>>
>>>> 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(name.lastIndexOf(".")+1, name.length());
>>>> }
>>>>
>>>> musachy
>>>>
>>>> On Wed, May 28, 2008 at 9:04 PM, David Blevins <da...@visi.com>
>>>> wrote:
>>>>
>>>>
>>>>>
>>>>> On May 28, 2008, at 4:54 PM, Musachy Barroso wrote:
>>>>>
>>>>>
>>>>>
>>>>>>>
>>>>>>> It is a standalone library, used heavily by the OpenEJB and Geronimo
>>>>>>> guys.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> oops.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Personally, I favor copying the code over and jarjar'ing the asm
>>>>>>> dependency.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> +1
>>>>>>
>>>>>>
>>>>>
>>>>> +1 :)
>>>>>
>>>>> Just wanted to throw my support in for fun.
>>>>>
>>>>> I'd pull in the ClassFinder and UrlSet. ClassFinder.java is a
>>>>> standalone
>>>>> class (aside from ASM), but the UrlSet is really useful for narrowing
>>>>> down
>>>>> the scope of jars that you search which of course makes things even
>>>>> faster.
>>>>>
>>>>> If you know the exact jar(s) you want to search, you're set. But if
>>>>> you
>>>>> simply have a classloader and want to search everything "in" it, you
>>>>> might
>>>>> want to rip out some standard vm jars and other jars you know you do
>>>>> not
>>>>> care about. Here's an example usage:
>>>>>
>>>>> // Just this line right here is good as is will diff the classpath of
>>>>> the
>>>>> // parent classloader against the classpath of the supplied
>>>>> classloader
>>>>> and
>>>>> // give you the difference.
>>>>> UrlSet urlSet = new UrlSet(classLoader);
>>>>>
>>>>> // If you happen to need to search the system classloader, the
>>>>> difference
>>>>> // still leaves a lot of useless garbage
>>>>> urlSet =
>>>>> urlSet.exclude(ClassLoader.getSystemClassLoader().getParent());
>>>>> urlSet = urlSet.excludeJavaExtDirs();
>>>>> urlSet = urlSet.excludeJavaEndorsedDirs();
>>>>> urlSet = urlSet.excludeJavaHome();
>>>>> urlSet = urlSet.excludePaths(System.getProperty("sun.boot.class.path",
>>>>> ""));
>>>>> urlSet = urlSet.exclude(".*/JavaVM.framework/.*");
>>>>>
>>>>> // If the remainder contains a lot of third party libraries required
>>>>> by
>>>>> you
>>>>> // that you know don't contain annotations you're interested in, then
>>>>> it
>>>>> can
>>>>> // be good to aggressively cut those out.
>>>>> urlSet = urlSet.exclude(".*/activemq-(core|ra)-[\\d.]+.jar(!/)?");
>>>>> urlSet = urlSet.exclude(".*/catalina-[\\d.]+.jar(!/)?");
>>>>> urlSet =
>>>>>
>>>>>
>>>>> urlSet.exclude(".*/commons-(logging|cli|pool|lang|collections|dbcp)-[\\d.]+.jar(!/)?");
>>>>> urlSet = urlSet.exclude(".*/derby-[\\d.]+.jar(!/)?");
>>>>> urlSet =
>>>>> urlSet.exclude(".*/geronimo-(connector|transaction)-[\\d.]+.jar(!/)?");
>>>>> urlSet = urlSet.exclude(".*/geronimo-[^/]+_spec-[\\d.]+.jar(!/)?");
>>>>> urlSet =
>>>>> urlSet.exclude(".*/geronimo-javamail_([\\d.]+)_mail-[\\d.]+.jar(!/)?");
>>>>> urlSet = urlSet.exclude(".*/hsqldb-[\\d.]+.jar(!/)?");
>>>>> urlSet = urlSet.exclude(".*/idb-[\\d.]+.jar(!/)?");
>>>>> urlSet = urlSet.exclude(".*/jaxb-(impl|api)-[\\d.]+.jar(!/)?");
>>>>> urlSet = urlSet.exclude(".*/junit-[\\d.]+.jar(!/)?");
>>>>> urlSet = urlSet.exclude(".*/log4j-[\\d.]+.jar(!/)?");
>>>>> urlSet =
>>>>>
>>>>>
>>>>> urlSet.exclude(".*/openjpa-(jdbc|kernel|lib|persistence|persistence-jdbc)(-5)?-[\\d.]+.jar(!/)?");
>>>>>
>>>>> // then eventually
>>>>> List<URL> urls = urlSet.getUrls();
>>>>> ClassFinder classFinder = new ClassFinder(classloader, urls);
>>>>>
>>>>>
>>>>> As far as the stability of the API, it hasn't changed in months and
>>>>> months.
>>>>> I do have one planned change involving the use of ASM 3 and new flag
>>>>> that
>>>>> will speed up the scanning by allowing ASM to skip by large chunks of
>>>>> the
>>>>> byte code.
>>>>>
>>>>> Let me see if I can't get that in there real quick.
>>>>>
>>>>> -David
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>>
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: classpath scanner
Posted by Brian Pontarelli <br...@pontarelli.com>.
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 one of them
>
> musachy
>
> On Thu, May 29, 2008 at 11:47 AM, Brian Pontarelli <br...@pontarelli.com> wrote:
>
>> 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 Barroso wrote:
>>
>>> 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(name.lastIndexOf(".")+1, name.length());
>>> }
>>>
>>> musachy
>>>
>>> On Wed, May 28, 2008 at 9:04 PM, David Blevins <da...@visi.com>
>>> wrote:
>>>
>>>
>>>> On May 28, 2008, at 4:54 PM, Musachy Barroso wrote:
>>>>
>>>>
>>>>
>>>>>> It is a standalone library, used heavily by the OpenEJB and Geronimo
>>>>>> guys.
>>>>>>
>>>>>>
>>>>> oops.
>>>>>
>>>>>
>>>>>
>>>>>> Personally, I favor copying the code over and jarjar'ing the asm
>>>>>> dependency.
>>>>>>
>>>>>>
>>>>> +1
>>>>>
>>>>>
>>>> +1 :)
>>>>
>>>> Just wanted to throw my support in for fun.
>>>>
>>>> I'd pull in the ClassFinder and UrlSet. ClassFinder.java is a standalone
>>>> class (aside from ASM), but the UrlSet is really useful for narrowing
>>>> down
>>>> the scope of jars that you search which of course makes things even
>>>> faster.
>>>>
>>>> If you know the exact jar(s) you want to search, you're set. But if you
>>>> simply have a classloader and want to search everything "in" it, you
>>>> might
>>>> want to rip out some standard vm jars and other jars you know you do not
>>>> care about. Here's an example usage:
>>>>
>>>> // Just this line right here is good as is will diff the classpath of
>>>> the
>>>> // parent classloader against the classpath of the supplied classloader
>>>> and
>>>> // give you the difference.
>>>> UrlSet urlSet = new UrlSet(classLoader);
>>>>
>>>> // If you happen to need to search the system classloader, the
>>>> difference
>>>> // still leaves a lot of useless garbage
>>>> urlSet = urlSet.exclude(ClassLoader.getSystemClassLoader().getParent());
>>>> urlSet = urlSet.excludeJavaExtDirs();
>>>> urlSet = urlSet.excludeJavaEndorsedDirs();
>>>> urlSet = urlSet.excludeJavaHome();
>>>> urlSet = urlSet.excludePaths(System.getProperty("sun.boot.class.path",
>>>> ""));
>>>> urlSet = urlSet.exclude(".*/JavaVM.framework/.*");
>>>>
>>>> // If the remainder contains a lot of third party libraries required by
>>>> you
>>>> // that you know don't contain annotations you're interested in, then it
>>>> can
>>>> // be good to aggressively cut those out.
>>>> urlSet = urlSet.exclude(".*/activemq-(core|ra)-[\\d.]+.jar(!/)?");
>>>> urlSet = urlSet.exclude(".*/catalina-[\\d.]+.jar(!/)?");
>>>> urlSet =
>>>>
>>>> urlSet.exclude(".*/commons-(logging|cli|pool|lang|collections|dbcp)-[\\d.]+.jar(!/)?");
>>>> urlSet = urlSet.exclude(".*/derby-[\\d.]+.jar(!/)?");
>>>> urlSet =
>>>> urlSet.exclude(".*/geronimo-(connector|transaction)-[\\d.]+.jar(!/)?");
>>>> urlSet = urlSet.exclude(".*/geronimo-[^/]+_spec-[\\d.]+.jar(!/)?");
>>>> urlSet =
>>>> urlSet.exclude(".*/geronimo-javamail_([\\d.]+)_mail-[\\d.]+.jar(!/)?");
>>>> urlSet = urlSet.exclude(".*/hsqldb-[\\d.]+.jar(!/)?");
>>>> urlSet = urlSet.exclude(".*/idb-[\\d.]+.jar(!/)?");
>>>> urlSet = urlSet.exclude(".*/jaxb-(impl|api)-[\\d.]+.jar(!/)?");
>>>> urlSet = urlSet.exclude(".*/junit-[\\d.]+.jar(!/)?");
>>>> urlSet = urlSet.exclude(".*/log4j-[\\d.]+.jar(!/)?");
>>>> urlSet =
>>>>
>>>> urlSet.exclude(".*/openjpa-(jdbc|kernel|lib|persistence|persistence-jdbc)(-5)?-[\\d.]+.jar(!/)?");
>>>>
>>>> // then eventually
>>>> List<URL> urls = urlSet.getUrls();
>>>> ClassFinder classFinder = new ClassFinder(classloader, urls);
>>>>
>>>>
>>>> As far as the stability of the API, it hasn't changed in months and
>>>> months.
>>>> I do have one planned change involving the use of ASM 3 and new flag
>>>> that
>>>> will speed up the scanning by allowing ASM to skip by large chunks of the
>>>> byte code.
>>>>
>>>> Let me see if I can't get that in there real quick.
>>>>
>>>> -David
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: classpath scanner
Posted by Dave Newton <ne...@yahoo.com>.
--- Musachy Barroso <mu...@gmail.com> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: classpath scanner
Posted by Musachy Barroso <mu...@gmail.com>.
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: classpath scanner
Posted by Musachy Barroso <mu...@gmail.com>.
Hardcoding the jars to be excluded is not really cool, but <constant>
requires a value, it would be nice if I could do:
<constant name="excludeJars">
....super regex list here...
</constant>
is there any other way of doing this? property file?
musachy
On Thu, May 29, 2008 at 11:58 AM, Musachy Barroso <mu...@gmail.com> wrote:
> 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 <br...@pontarelli.com> wrote:
>>
>> 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 Barroso wrote:
>>>
>>> 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(name.lastIndexOf(".")+1, name.length());
>>> }
>>>
>>> musachy
>>>
>>> On Wed, May 28, 2008 at 9:04 PM, David Blevins <da...@visi.com>
>>> wrote:
>>>
>>>>
>>>> On May 28, 2008, at 4:54 PM, Musachy Barroso wrote:
>>>>
>>>>
>>>>>>
>>>>>> It is a standalone library, used heavily by the OpenEJB and Geronimo
>>>>>> guys.
>>>>>>
>>>>>
>>>>> oops.
>>>>>
>>>>>
>>>>>>
>>>>>> Personally, I favor copying the code over and jarjar'ing the asm
>>>>>> dependency.
>>>>>>
>>>>>
>>>>> +1
>>>>>
>>>>
>>>> +1 :)
>>>>
>>>> Just wanted to throw my support in for fun.
>>>>
>>>> I'd pull in the ClassFinder and UrlSet. ClassFinder.java is a standalone
>>>> class (aside from ASM), but the UrlSet is really useful for narrowing
>>>> down
>>>> the scope of jars that you search which of course makes things even
>>>> faster.
>>>>
>>>> If you know the exact jar(s) you want to search, you're set. But if you
>>>> simply have a classloader and want to search everything "in" it, you
>>>> might
>>>> want to rip out some standard vm jars and other jars you know you do not
>>>> care about. Here's an example usage:
>>>>
>>>> // Just this line right here is good as is will diff the classpath of
>>>> the
>>>> // parent classloader against the classpath of the supplied classloader
>>>> and
>>>> // give you the difference.
>>>> UrlSet urlSet = new UrlSet(classLoader);
>>>>
>>>> // If you happen to need to search the system classloader, the
>>>> difference
>>>> // still leaves a lot of useless garbage
>>>> urlSet = urlSet.exclude(ClassLoader.getSystemClassLoader().getParent());
>>>> urlSet = urlSet.excludeJavaExtDirs();
>>>> urlSet = urlSet.excludeJavaEndorsedDirs();
>>>> urlSet = urlSet.excludeJavaHome();
>>>> urlSet = urlSet.excludePaths(System.getProperty("sun.boot.class.path",
>>>> ""));
>>>> urlSet = urlSet.exclude(".*/JavaVM.framework/.*");
>>>>
>>>> // If the remainder contains a lot of third party libraries required by
>>>> you
>>>> // that you know don't contain annotations you're interested in, then it
>>>> can
>>>> // be good to aggressively cut those out.
>>>> urlSet = urlSet.exclude(".*/activemq-(core|ra)-[\\d.]+.jar(!/)?");
>>>> urlSet = urlSet.exclude(".*/catalina-[\\d.]+.jar(!/)?");
>>>> urlSet =
>>>>
>>>> urlSet.exclude(".*/commons-(logging|cli|pool|lang|collections|dbcp)-[\\d.]+.jar(!/)?");
>>>> urlSet = urlSet.exclude(".*/derby-[\\d.]+.jar(!/)?");
>>>> urlSet =
>>>> urlSet.exclude(".*/geronimo-(connector|transaction)-[\\d.]+.jar(!/)?");
>>>> urlSet = urlSet.exclude(".*/geronimo-[^/]+_spec-[\\d.]+.jar(!/)?");
>>>> urlSet =
>>>> urlSet.exclude(".*/geronimo-javamail_([\\d.]+)_mail-[\\d.]+.jar(!/)?");
>>>> urlSet = urlSet.exclude(".*/hsqldb-[\\d.]+.jar(!/)?");
>>>> urlSet = urlSet.exclude(".*/idb-[\\d.]+.jar(!/)?");
>>>> urlSet = urlSet.exclude(".*/jaxb-(impl|api)-[\\d.]+.jar(!/)?");
>>>> urlSet = urlSet.exclude(".*/junit-[\\d.]+.jar(!/)?");
>>>> urlSet = urlSet.exclude(".*/log4j-[\\d.]+.jar(!/)?");
>>>> urlSet =
>>>>
>>>> urlSet.exclude(".*/openjpa-(jdbc|kernel|lib|persistence|persistence-jdbc)(-5)?-[\\d.]+.jar(!/)?");
>>>>
>>>> // then eventually
>>>> List<URL> urls = urlSet.getUrls();
>>>> ClassFinder classFinder = new ClassFinder(classloader, urls);
>>>>
>>>>
>>>> As far as the stability of the API, it hasn't changed in months and
>>>> months.
>>>> I do have one planned change involving the use of ASM 3 and new flag
>>>> that
>>>> will speed up the scanning by allowing ASM to skip by large chunks of the
>>>> byte code.
>>>>
>>>> Let me see if I can't get that in there real quick.
>>>>
>>>> -David
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: classpath scanner
Posted by Musachy Barroso <mu...@gmail.com>.
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 <br...@pontarelli.com> wrote:
>
> 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 Barroso wrote:
>>
>> 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(name.lastIndexOf(".")+1, name.length());
>> }
>>
>> musachy
>>
>> On Wed, May 28, 2008 at 9:04 PM, David Blevins <da...@visi.com>
>> wrote:
>>
>>>
>>> On May 28, 2008, at 4:54 PM, Musachy Barroso wrote:
>>>
>>>
>>>>>
>>>>> It is a standalone library, used heavily by the OpenEJB and Geronimo
>>>>> guys.
>>>>>
>>>>
>>>> oops.
>>>>
>>>>
>>>>>
>>>>> Personally, I favor copying the code over and jarjar'ing the asm
>>>>> dependency.
>>>>>
>>>>
>>>> +1
>>>>
>>>
>>> +1 :)
>>>
>>> Just wanted to throw my support in for fun.
>>>
>>> I'd pull in the ClassFinder and UrlSet. ClassFinder.java is a standalone
>>> class (aside from ASM), but the UrlSet is really useful for narrowing
>>> down
>>> the scope of jars that you search which of course makes things even
>>> faster.
>>>
>>> If you know the exact jar(s) you want to search, you're set. But if you
>>> simply have a classloader and want to search everything "in" it, you
>>> might
>>> want to rip out some standard vm jars and other jars you know you do not
>>> care about. Here's an example usage:
>>>
>>> // Just this line right here is good as is will diff the classpath of
>>> the
>>> // parent classloader against the classpath of the supplied classloader
>>> and
>>> // give you the difference.
>>> UrlSet urlSet = new UrlSet(classLoader);
>>>
>>> // If you happen to need to search the system classloader, the
>>> difference
>>> // still leaves a lot of useless garbage
>>> urlSet = urlSet.exclude(ClassLoader.getSystemClassLoader().getParent());
>>> urlSet = urlSet.excludeJavaExtDirs();
>>> urlSet = urlSet.excludeJavaEndorsedDirs();
>>> urlSet = urlSet.excludeJavaHome();
>>> urlSet = urlSet.excludePaths(System.getProperty("sun.boot.class.path",
>>> ""));
>>> urlSet = urlSet.exclude(".*/JavaVM.framework/.*");
>>>
>>> // If the remainder contains a lot of third party libraries required by
>>> you
>>> // that you know don't contain annotations you're interested in, then it
>>> can
>>> // be good to aggressively cut those out.
>>> urlSet = urlSet.exclude(".*/activemq-(core|ra)-[\\d.]+.jar(!/)?");
>>> urlSet = urlSet.exclude(".*/catalina-[\\d.]+.jar(!/)?");
>>> urlSet =
>>>
>>> urlSet.exclude(".*/commons-(logging|cli|pool|lang|collections|dbcp)-[\\d.]+.jar(!/)?");
>>> urlSet = urlSet.exclude(".*/derby-[\\d.]+.jar(!/)?");
>>> urlSet =
>>> urlSet.exclude(".*/geronimo-(connector|transaction)-[\\d.]+.jar(!/)?");
>>> urlSet = urlSet.exclude(".*/geronimo-[^/]+_spec-[\\d.]+.jar(!/)?");
>>> urlSet =
>>> urlSet.exclude(".*/geronimo-javamail_([\\d.]+)_mail-[\\d.]+.jar(!/)?");
>>> urlSet = urlSet.exclude(".*/hsqldb-[\\d.]+.jar(!/)?");
>>> urlSet = urlSet.exclude(".*/idb-[\\d.]+.jar(!/)?");
>>> urlSet = urlSet.exclude(".*/jaxb-(impl|api)-[\\d.]+.jar(!/)?");
>>> urlSet = urlSet.exclude(".*/junit-[\\d.]+.jar(!/)?");
>>> urlSet = urlSet.exclude(".*/log4j-[\\d.]+.jar(!/)?");
>>> urlSet =
>>>
>>> urlSet.exclude(".*/openjpa-(jdbc|kernel|lib|persistence|persistence-jdbc)(-5)?-[\\d.]+.jar(!/)?");
>>>
>>> // then eventually
>>> List<URL> urls = urlSet.getUrls();
>>> ClassFinder classFinder = new ClassFinder(classloader, urls);
>>>
>>>
>>> As far as the stability of the API, it hasn't changed in months and
>>> months.
>>> I do have one planned change involving the use of ASM 3 and new flag
>>> that
>>> will speed up the scanning by allowing ASM to skip by large chunks of the
>>> byte code.
>>>
>>> Let me see if I can't get that in there real quick.
>>>
>>> -David
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>>
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: classpath scanner
Posted by Brian Pontarelli <br...@pontarelli.com>.
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 Barroso wrote:
> 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(name.lastIndexOf(".")+1, name.length());
> }
>
> musachy
>
> On Wed, May 28, 2008 at 9:04 PM, David Blevins <da...@visi.com> wrote:
>
>> On May 28, 2008, at 4:54 PM, Musachy Barroso wrote:
>>
>>
>>>> It is a standalone library, used heavily by the OpenEJB and Geronimo
>>>> guys.
>>>>
>>> oops.
>>>
>>>
>>>> Personally, I favor copying the code over and jarjar'ing the asm
>>>> dependency.
>>>>
>>> +1
>>>
>> +1 :)
>>
>> Just wanted to throw my support in for fun.
>>
>> I'd pull in the ClassFinder and UrlSet. ClassFinder.java is a standalone
>> class (aside from ASM), but the UrlSet is really useful for narrowing down
>> the scope of jars that you search which of course makes things even faster.
>>
>> If you know the exact jar(s) you want to search, you're set. But if you
>> simply have a classloader and want to search everything "in" it, you might
>> want to rip out some standard vm jars and other jars you know you do not
>> care about. Here's an example usage:
>>
>> // Just this line right here is good as is will diff the classpath of the
>> // parent classloader against the classpath of the supplied classloader and
>> // give you the difference.
>> UrlSet urlSet = new UrlSet(classLoader);
>>
>> // If you happen to need to search the system classloader, the difference
>> // still leaves a lot of useless garbage
>> urlSet = urlSet.exclude(ClassLoader.getSystemClassLoader().getParent());
>> urlSet = urlSet.excludeJavaExtDirs();
>> urlSet = urlSet.excludeJavaEndorsedDirs();
>> urlSet = urlSet.excludeJavaHome();
>> urlSet = urlSet.excludePaths(System.getProperty("sun.boot.class.path",
>> ""));
>> urlSet = urlSet.exclude(".*/JavaVM.framework/.*");
>>
>> // If the remainder contains a lot of third party libraries required by you
>> // that you know don't contain annotations you're interested in, then it
>> can
>> // be good to aggressively cut those out.
>> urlSet = urlSet.exclude(".*/activemq-(core|ra)-[\\d.]+.jar(!/)?");
>> urlSet = urlSet.exclude(".*/catalina-[\\d.]+.jar(!/)?");
>> urlSet =
>> urlSet.exclude(".*/commons-(logging|cli|pool|lang|collections|dbcp)-[\\d.]+.jar(!/)?");
>> urlSet = urlSet.exclude(".*/derby-[\\d.]+.jar(!/)?");
>> urlSet =
>> urlSet.exclude(".*/geronimo-(connector|transaction)-[\\d.]+.jar(!/)?");
>> urlSet = urlSet.exclude(".*/geronimo-[^/]+_spec-[\\d.]+.jar(!/)?");
>> urlSet =
>> urlSet.exclude(".*/geronimo-javamail_([\\d.]+)_mail-[\\d.]+.jar(!/)?");
>> urlSet = urlSet.exclude(".*/hsqldb-[\\d.]+.jar(!/)?");
>> urlSet = urlSet.exclude(".*/idb-[\\d.]+.jar(!/)?");
>> urlSet = urlSet.exclude(".*/jaxb-(impl|api)-[\\d.]+.jar(!/)?");
>> urlSet = urlSet.exclude(".*/junit-[\\d.]+.jar(!/)?");
>> urlSet = urlSet.exclude(".*/log4j-[\\d.]+.jar(!/)?");
>> urlSet =
>> urlSet.exclude(".*/openjpa-(jdbc|kernel|lib|persistence|persistence-jdbc)(-5)?-[\\d.]+.jar(!/)?");
>>
>> // then eventually
>> List<URL> urls = urlSet.getUrls();
>> ClassFinder classFinder = new ClassFinder(classloader, urls);
>>
>>
>> As far as the stability of the API, it hasn't changed in months and months.
>> I do have one planned change involving the use of ASM 3 and new flag that
>> will speed up the scanning by allowing ASM to skip by large chunks of the
>> byte code.
>>
>> Let me see if I can't get that in there real quick.
>>
>> -David
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: classpath scanner
Posted by Musachy Barroso <mu...@gmail.com>.
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(name.lastIndexOf(".")+1, name.length());
}
musachy
On Wed, May 28, 2008 at 9:04 PM, David Blevins <da...@visi.com> wrote:
>
> On May 28, 2008, at 4:54 PM, Musachy Barroso wrote:
>
>>> It is a standalone library, used heavily by the OpenEJB and Geronimo
>>> guys.
>>
>> oops.
>>
>>>
>>> Personally, I favor copying the code over and jarjar'ing the asm
>>> dependency.
>>
>> +1
>
> +1 :)
>
> Just wanted to throw my support in for fun.
>
> I'd pull in the ClassFinder and UrlSet. ClassFinder.java is a standalone
> class (aside from ASM), but the UrlSet is really useful for narrowing down
> the scope of jars that you search which of course makes things even faster.
>
> If you know the exact jar(s) you want to search, you're set. But if you
> simply have a classloader and want to search everything "in" it, you might
> want to rip out some standard vm jars and other jars you know you do not
> care about. Here's an example usage:
>
> // Just this line right here is good as is will diff the classpath of the
> // parent classloader against the classpath of the supplied classloader and
> // give you the difference.
> UrlSet urlSet = new UrlSet(classLoader);
>
> // If you happen to need to search the system classloader, the difference
> // still leaves a lot of useless garbage
> urlSet = urlSet.exclude(ClassLoader.getSystemClassLoader().getParent());
> urlSet = urlSet.excludeJavaExtDirs();
> urlSet = urlSet.excludeJavaEndorsedDirs();
> urlSet = urlSet.excludeJavaHome();
> urlSet = urlSet.excludePaths(System.getProperty("sun.boot.class.path",
> ""));
> urlSet = urlSet.exclude(".*/JavaVM.framework/.*");
>
> // If the remainder contains a lot of third party libraries required by you
> // that you know don't contain annotations you're interested in, then it
> can
> // be good to aggressively cut those out.
> urlSet = urlSet.exclude(".*/activemq-(core|ra)-[\\d.]+.jar(!/)?");
> urlSet = urlSet.exclude(".*/catalina-[\\d.]+.jar(!/)?");
> urlSet =
> urlSet.exclude(".*/commons-(logging|cli|pool|lang|collections|dbcp)-[\\d.]+.jar(!/)?");
> urlSet = urlSet.exclude(".*/derby-[\\d.]+.jar(!/)?");
> urlSet =
> urlSet.exclude(".*/geronimo-(connector|transaction)-[\\d.]+.jar(!/)?");
> urlSet = urlSet.exclude(".*/geronimo-[^/]+_spec-[\\d.]+.jar(!/)?");
> urlSet =
> urlSet.exclude(".*/geronimo-javamail_([\\d.]+)_mail-[\\d.]+.jar(!/)?");
> urlSet = urlSet.exclude(".*/hsqldb-[\\d.]+.jar(!/)?");
> urlSet = urlSet.exclude(".*/idb-[\\d.]+.jar(!/)?");
> urlSet = urlSet.exclude(".*/jaxb-(impl|api)-[\\d.]+.jar(!/)?");
> urlSet = urlSet.exclude(".*/junit-[\\d.]+.jar(!/)?");
> urlSet = urlSet.exclude(".*/log4j-[\\d.]+.jar(!/)?");
> urlSet =
> urlSet.exclude(".*/openjpa-(jdbc|kernel|lib|persistence|persistence-jdbc)(-5)?-[\\d.]+.jar(!/)?");
>
> // then eventually
> List<URL> urls = urlSet.getUrls();
> ClassFinder classFinder = new ClassFinder(classloader, urls);
>
>
> As far as the stability of the API, it hasn't changed in months and months.
> I do have one planned change involving the use of ASM 3 and new flag that
> will speed up the scanning by allowing ASM to skip by large chunks of the
> byte code.
>
> Let me see if I can't get that in there real quick.
>
> -David
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: classpath scanner
Posted by David Blevins <da...@visi.com>.
On May 28, 2008, at 4:54 PM, Musachy Barroso wrote:
>> It is a standalone library, used heavily by the OpenEJB and Geronimo
>> guys.
>
> oops.
>
>>
>> Personally, I favor copying the code over and jarjar'ing the asm
>> dependency.
>
> +1
+1 :)
Just wanted to throw my support in for fun.
I'd pull in the ClassFinder and UrlSet. ClassFinder.java is a
standalone class (aside from ASM), but the UrlSet is really useful for
narrowing down the scope of jars that you search which of course makes
things even faster.
If you know the exact jar(s) you want to search, you're set. But if
you simply have a classloader and want to search everything "in" it,
you might want to rip out some standard vm jars and other jars you
know you do not care about. Here's an example usage:
// Just this line right here is good as is will diff the classpath
of the
// parent classloader against the classpath of the supplied
classloader and
// give you the difference.
UrlSet urlSet = new UrlSet(classLoader);
// If you happen to need to search the system classloader, the
difference
// still leaves a lot of useless garbage
urlSet =
urlSet.exclude(ClassLoader.getSystemClassLoader().getParent());
urlSet = urlSet.excludeJavaExtDirs();
urlSet = urlSet.excludeJavaEndorsedDirs();
urlSet = urlSet.excludeJavaHome();
urlSet =
urlSet.excludePaths(System.getProperty("sun.boot.class.path", ""));
urlSet = urlSet.exclude(".*/JavaVM.framework/.*");
// If the remainder contains a lot of third party libraries
required by you
// that you know don't contain annotations you're interested in,
then it can
// be good to aggressively cut those out.
urlSet = urlSet.exclude(".*/activemq-(core|ra)-[\\d.]+.jar(!/)?");
urlSet = urlSet.exclude(".*/catalina-[\\d.]+.jar(!/)?");
urlSet = urlSet.exclude(".*/commons-(logging|cli|pool|lang|
collections|dbcp)-[\\d.]+.jar(!/)?");
urlSet = urlSet.exclude(".*/derby-[\\d.]+.jar(!/)?");
urlSet = urlSet.exclude(".*/geronimo-(connector|transaction)-[\\d.]
+.jar(!/)?");
urlSet = urlSet.exclude(".*/geronimo-[^/]+_spec-[\\d.]+.jar(!/)?");
urlSet = urlSet.exclude(".*/geronimo-javamail_([\\d.]+)_mail-[\\d.]
+.jar(!/)?");
urlSet = urlSet.exclude(".*/hsqldb-[\\d.]+.jar(!/)?");
urlSet = urlSet.exclude(".*/idb-[\\d.]+.jar(!/)?");
urlSet = urlSet.exclude(".*/jaxb-(impl|api)-[\\d.]+.jar(!/)?");
urlSet = urlSet.exclude(".*/junit-[\\d.]+.jar(!/)?");
urlSet = urlSet.exclude(".*/log4j-[\\d.]+.jar(!/)?");
urlSet = urlSet.exclude(".*/openjpa-(jdbc|kernel|lib|persistence|
persistence-jdbc)(-5)?-[\\d.]+.jar(!/)?");
// then eventually
List<URL> urls = urlSet.getUrls();
ClassFinder classFinder = new ClassFinder(classloader, urls);
As far as the stability of the API, it hasn't changed in months and
months. I do have one planned change involving the use of ASM 3 and
new flag that will speed up the scanning by allowing ASM to skip by
large chunks of the byte code.
Let me see if I can't get that in there real quick.
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: classpath scanner
Posted by Brian Pontarelli <br...@pontarelli.com>.
>
> Secondly, I was wondering about the advantages of having fewer
> dependencies, especially in this maven era. If something's really
> great, it's fine to depend on it, surely?
And there is still a large number of folks using Ant, Ivy and Savant.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: classpath scanner
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
David Blevins on 30/05/08 19:53, wrote:
>>>>>> Personally, I favor copying the code over and jarjar'ing the asm
>>>>>> dependency.
>>
>> Two quick questions:
>>
>> "jarjar'ing" the dependency? What does that mean? I hope I'm not the
>> only one who isn't hip to the lingo! I guess if I knew the context
>> better I could work it out.
>>
>> Secondly, I was wondering about the advantages of having fewer
>> dependencies, especially in this maven era. If something's really
>> great, it's fine to depend on it, surely?
>
> The term comes from a tool that essentially read in the byte code and
> repackaged it. For example changing the java package from
> org.objectweb.asm to org.apache.fooproject.asm. There are other tools
> that can do it now, like the maven-shade-plugin, but it was the first
> that I'm aware of.
>
> The ASM guys themselves recommend repackaging their code due to the
> number of people using different versions of ASM and that some of those
> versions of incompatible. Hibernate is a good example of this as they
> use a really old version of ASM. As this particular library is only 40K
> or so you can solve a lot of potential headaches for users by getting it
> out of their way.
Thanks for the info. IIRC I experienced the problems that stemmed from that when
I upgraded an app from Spring 2 to Spring 2.1 (or close to those version
numbers) due to Hibernate 3.1 - I think I ended up downgrading Hibernate to make
it work for a period.
I strikes me that somehow it should have worked better if the developers putting
out those new versions had just talked to each other, but they didn't and a lot
of people wasted whole days on the problem. So I guess you're right.
What isn't ideal is that the user experiences and knowledge becomes fragmented.
Perhaps that's the lesser of two evils.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: classpath scanner
Posted by Lukasz Lenart <lu...@googlemail.com>.
>
> What configuration options?
>
Sorry, not @Action but @Result and location attribute, but I think I
understand now what it means ;-)
Regards
--
Lukasz
http://www.lenart.org.pl/
Re: classpath scanner
Posted by Musachy Barroso <mu...@gmail.com>.
> Yes, at least it's working! It was somehow hard to configure it. Why you
> choose to use not standard configuration options for @Action (they are not
> related to struts.xml action's config)?
>
What configuration options?
musachy
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: classpath scanner
Posted by Lukasz Lenart <lu...@googlemail.com>.
Hi,
Yes, at least it's working! It was somehow hard to configure it. Why you
choose to use not standard configuration options for @Action (they are not
related to struts.xml action's config)?
Any why it's working with my project ;-)
Regards
--
Lukasz
http://www.lenart.org.pl/
Re: classpath scanner
Posted by Lukasz Lenart <lu...@googlemail.com>.
Hi,
They are not on any repo, just on the trunk of their projects:
>
> http://svn.opensymphony.com/svn/xwork/trunk
>
> http://svn.apache.org/repos/asf/struts/sandbox/trunk/struts2-convention-plugin
>
Thank you, I had in mean SVN repo ;-) I will try to use it in my projects.
Regards
--
Lukasz
http://www.lenart.org.pl/
Re: classpath scanner
Posted by Musachy Barroso <mu...@gmail.com>.
They are not on any repo, just on the trunk of their projects:
http://svn.opensymphony.com/svn/xwork/trunk
http://svn.apache.org/repos/asf/struts/sandbox/trunk/struts2-convention-plugin
musachy
On Mon, Jun 2, 2008 at 10:07 AM, Lukasz Lenart
<lu...@googlemail.com> wrote:
> Hi,
>
>
>> The xbean classes are under: com.opensymphony.xwork2.util.finder
>>
>> and ASM 3.1 will be jar-jared into: org.objectweb.asm.xwork
>>
>> Convention in sandbox was updated to use the xbean classes.
>>
>
> Is it possible to checkout such version from repo?
>
>
> Regards
> --
> Lukasz
> http://www.lenart.org.pl/
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: classpath scanner
Posted by Lukasz Lenart <lu...@googlemail.com>.
Hi,
> The xbean classes are under: com.opensymphony.xwork2.util.finder
>
> and ASM 3.1 will be jar-jared into: org.objectweb.asm.xwork
>
> Convention in sandbox was updated to use the xbean classes.
>
Is it possible to checkout such version from repo?
Regards
--
Lukasz
http://www.lenart.org.pl/
Re: classpath scanner
Posted by Musachy Barroso <mu...@gmail.com>.
The xbean classes are under: com.opensymphony.xwork2.util.finder
and ASM 3.1 will be jar-jared into: org.objectweb.asm.xwork
Convention in sandbox was updated to use the xbean classes.
musachy
On Fri, May 30, 2008 at 5:48 PM, Musachy Barroso <mu...@gmail.com> wrote:
> maven-shade-plugin works fine. It took me while to get it to work due
> to my maven noobness. If none object I will check in the xbean code
> into xwork, with the pom modifications .
>
> musachy
>
> On Fri, May 30, 2008 at 2:53 PM, David Blevins <da...@visi.com> wrote:
>>
>> On May 30, 2008, at 2:09 AM, Adam Hardy wrote:
>>
>>> Don Brown on 29/05/08 08:08, wrote:
>>>>
>>>> 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 Thu, May 29, 2008 at 4:03 PM, Al Sutton <al...@alsutton.com>
>>>> wrote:
>>>>>
>>>>> How about talking to the author about splitting it into a commons
>>>>> library?
>>>>> This would give the usual benefits of propogating bug fixes and avoid
>>>>> duplicate work on divergent code bases.
>>>>>
>>>>> Al.
>>>>>
>>>>> Musachy Barroso wrote:
>>>>>>>
>>>>>>> It is a standalone library, used heavily by the OpenEJB and Geronimo
>>>>>>> guys.
>>>>>>>
>>>>>> oops.
>>>>>>
>>>>>>
>>>>>>> Personally, I favor copying the code over and jarjar'ing the asm
>>>>>>> dependency.
>>>
>>> Two quick questions:
>>>
>>> "jarjar'ing" the dependency? What does that mean? I hope I'm not the only
>>> one who isn't hip to the lingo! I guess if I knew the context better I could
>>> work it out.
>>>
>>> Secondly, I was wondering about the advantages of having fewer
>>> dependencies, especially in this maven era. If something's really great,
>>> it's fine to depend on it, surely?
>>
>> The term comes from a tool that essentially read in the byte code and
>> repackaged it. For example changing the java package from org.objectweb.asm
>> to org.apache.fooproject.asm. There are other tools that can do it now,
>> like the maven-shade-plugin, but it was the first that I'm aware of.
>>
>> The ASM guys themselves recommend repackaging their code due to the number
>> of people using different versions of ASM and that some of those versions of
>> incompatible. Hibernate is a good example of this as they use a really old
>> version of ASM. As this particular library is only 40K or so you can solve
>> a lot of potential headaches for users by getting it out of their way.
>>
>> -David
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: classpath scanner
Posted by Musachy Barroso <mu...@gmail.com>.
maven-shade-plugin works fine. It took me while to get it to work due
to my maven noobness. If none object I will check in the xbean code
into xwork, with the pom modifications .
musachy
On Fri, May 30, 2008 at 2:53 PM, David Blevins <da...@visi.com> wrote:
>
> On May 30, 2008, at 2:09 AM, Adam Hardy wrote:
>
>> Don Brown on 29/05/08 08:08, wrote:
>>>
>>> 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 Thu, May 29, 2008 at 4:03 PM, Al Sutton <al...@alsutton.com>
>>> wrote:
>>>>
>>>> How about talking to the author about splitting it into a commons
>>>> library?
>>>> This would give the usual benefits of propogating bug fixes and avoid
>>>> duplicate work on divergent code bases.
>>>>
>>>> Al.
>>>>
>>>> Musachy Barroso wrote:
>>>>>>
>>>>>> It is a standalone library, used heavily by the OpenEJB and Geronimo
>>>>>> guys.
>>>>>>
>>>>> oops.
>>>>>
>>>>>
>>>>>> Personally, I favor copying the code over and jarjar'ing the asm
>>>>>> dependency.
>>
>> Two quick questions:
>>
>> "jarjar'ing" the dependency? What does that mean? I hope I'm not the only
>> one who isn't hip to the lingo! I guess if I knew the context better I could
>> work it out.
>>
>> Secondly, I was wondering about the advantages of having fewer
>> dependencies, especially in this maven era. If something's really great,
>> it's fine to depend on it, surely?
>
> The term comes from a tool that essentially read in the byte code and
> repackaged it. For example changing the java package from org.objectweb.asm
> to org.apache.fooproject.asm. There are other tools that can do it now,
> like the maven-shade-plugin, but it was the first that I'm aware of.
>
> The ASM guys themselves recommend repackaging their code due to the number
> of people using different versions of ASM and that some of those versions of
> incompatible. Hibernate is a good example of this as they use a really old
> version of ASM. As this particular library is only 40K or so you can solve
> a lot of potential headaches for users by getting it out of their way.
>
> -David
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: classpath scanner
Posted by David Blevins <da...@visi.com>.
On May 30, 2008, at 2:09 AM, Adam Hardy wrote:
> Don Brown on 29/05/08 08:08, wrote:
>> 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 Thu, May 29, 2008 at 4:03 PM, Al Sutton <al...@alsutton.com>
>> wrote:
>>> How about talking to the author about splitting it into a commons
>>> library?
>>> This would give the usual benefits of propogating bug fixes and
>>> avoid
>>> duplicate work on divergent code bases.
>>>
>>> Al.
>>>
>>> Musachy Barroso wrote:
>>>>> It is a standalone library, used heavily by the OpenEJB and
>>>>> Geronimo
>>>>> guys.
>>>>>
>>>> oops.
>>>>
>>>>
>>>>> Personally, I favor copying the code over and jarjar'ing the asm
>>>>> dependency.
>
> Two quick questions:
>
> "jarjar'ing" the dependency? What does that mean? I hope I'm not the
> only one who isn't hip to the lingo! I guess if I knew the context
> better I could work it out.
>
> Secondly, I was wondering about the advantages of having fewer
> dependencies, especially in this maven era. If something's really
> great, it's fine to depend on it, surely?
The term comes from a tool that essentially read in the byte code and
repackaged it. For example changing the java package from
org.objectweb.asm to org.apache.fooproject.asm. There are other tools
that can do it now, like the maven-shade-plugin, but it was the first
that I'm aware of.
The ASM guys themselves recommend repackaging their code due to the
number of people using different versions of ASM and that some of
those versions of incompatible. Hibernate is a good example of this
as they use a really old version of ASM. As this particular library
is only 40K or so you can solve a lot of potential headaches for users
by getting it out of their way.
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: classpath scanner
Posted by Don Brown <mr...@twdata.org>.
On Fri, May 30, 2008 at 7:09 PM, Adam Hardy
<ah...@cyberspaceroad.com> wrote:
> "jarjar'ing" the dependency? What does that mean? I hope I'm not the only
> one who isn't hip to the lingo! I guess if I knew the context better I could
> work it out.
jarjar is a tool that repackages a dependency in a jar by renaming its
packages so that it won't conflict with another version in the
classpath.
http://code.google.com/p/jarjar/
> Secondly, I was wondering about the advantages of having fewer dependencies,
> especially in this maven era. If something's really great, it's fine to
> depend on it, surely?
Actually, this Maven era is more like shining the light on an ugly,
moldy dark corner of the basement. It also highlights the need, IMO,
for a module system in Java, because if you think about it, only XWork
really needs to have access to ASM, so jarjar can make that happen. A
user shouldn't have to worry about using a different version of ASM in
their application. I believe a library should stay out of your way
and impose as little of itself as possible. Libraries should be
enablers, not constrictors.
Don
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: classpath scanner
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
Don Brown on 29/05/08 08:08, wrote:
> 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 Thu, May 29, 2008 at 4:03 PM, Al Sutton <al...@alsutton.com> wrote:
>> How about talking to the author about splitting it into a commons library?
>> This would give the usual benefits of propogating bug fixes and avoid
>> duplicate work on divergent code bases.
>>
>> Al.
>>
>> Musachy Barroso wrote:
>>>> It is a standalone library, used heavily by the OpenEJB and Geronimo
>>>> guys.
>>>>
>>> oops.
>>>
>>>
>>>> Personally, I favor copying the code over and jarjar'ing the asm
>>>> dependency.
Two quick questions:
"jarjar'ing" the dependency? What does that mean? I hope I'm not the only one
who isn't hip to the lingo! I guess if I knew the context better I could work it
out.
Secondly, I was wondering about the advantages of having fewer dependencies,
especially in this maven era. If something's really great, it's fine to depend
on it, surely?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: classpath scanner
Posted by Don Brown <mr...@twdata.org>.
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 Thu, May 29, 2008 at 4:03 PM, Al Sutton <al...@alsutton.com> wrote:
> How about talking to the author about splitting it into a commons library?
> This would give the usual benefits of propogating bug fixes and avoid
> duplicate work on divergent code bases.
>
> Al.
>
> Musachy Barroso wrote:
>>>
>>> It is a standalone library, used heavily by the OpenEJB and Geronimo
>>> guys.
>>>
>>
>> oops.
>>
>>
>>>
>>> Personally, I favor copying the code over and jarjar'ing the asm
>>> dependency.
>>>
>>
>> +1
>>
>> musachy
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: classpath scanner
Posted by Al Sutton <al...@alsutton.com>.
How about talking to the author about splitting it into a commons
library? This would give the usual benefits of propogating bug fixes and
avoid duplicate work on divergent code bases.
Al.
Musachy Barroso wrote:
>> It is a standalone library, used heavily by the OpenEJB and Geronimo
>> guys.
>>
>
> oops.
>
>
>> Personally, I favor copying the code over and jarjar'ing the asm dependency.
>>
>
> +1
>
> musachy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: classpath scanner
Posted by Musachy Barroso <mu...@gmail.com>.
> It is a standalone library, used heavily by the OpenEJB and Geronimo
> guys.
oops.
>
> Personally, I favor copying the code over and jarjar'ing the asm dependency.
+1
musachy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: classpath scanner
Posted by Don Brown <mr...@twdata.org>.
It is a standalone library, used heavily by the OpenEJB and Geronimo
guys. Most, if not all, of the code was written by David Blevins, one
smart guy. Whether we use the library itself (it is in Maven) or copy
the code, it doesn't matter. The code has been in use for several
years heavily, so it is well-tested and mature.
Personally, I favor copying the code over and jarjar'ing the asm dependency.
Don
On Thu, May 29, 2008 at 7:58 AM, Musachy Barroso <mu...@gmail.com> wrote:
> It is part of geronimo, so is not an standalone library AFAIK. The
> code is straightforward anyway, with a few bugs :)
>
> musachy
>
> On Wed, May 28, 2008 at 5:24 PM, dusty <du...@yahoo.com> wrote:
>>
>> If you already have it working, then great! I don't know anything about it,
>> so my question is only how likely are the authors to update/nurse this
>> library?
>>
>> -D
>>
>>
>>
>> Musachy Barroso wrote:
>>>
>>> Stating new thread for this topic. Don suggested to use this classpath
>>> scanner:
>>>
>>> http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/
>>>
>>> in xwork and plugins. It uses ASM to extract class information and
>>> annotations,so loading classes can be avoided until the last minute
>>> (when you actually need it). I modified convention to use it(not
>>> committed), and it is pretty good. Comment away here.
>>>
>>> musachy
>>> --
>>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>>
>>
>> --
>> View this message in context: http://www.nabble.com/classpath-scanner-tp17519827p17522489.html
>> Sent from the Struts - Dev mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: classpath scanner
Posted by Musachy Barroso <mu...@gmail.com>.
It is part of geronimo, so is not an standalone library AFAIK. The
code is straightforward anyway, with a few bugs :)
musachy
On Wed, May 28, 2008 at 5:24 PM, dusty <du...@yahoo.com> wrote:
>
> If you already have it working, then great! I don't know anything about it,
> so my question is only how likely are the authors to update/nurse this
> library?
>
> -D
>
>
>
> Musachy Barroso wrote:
>>
>> Stating new thread for this topic. Don suggested to use this classpath
>> scanner:
>>
>> http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/
>>
>> in xwork and plugins. It uses ASM to extract class information and
>> annotations,so loading classes can be avoided until the last minute
>> (when you actually need it). I modified convention to use it(not
>> committed), and it is pretty good. Comment away here.
>>
>> musachy
>> --
>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/classpath-scanner-tp17519827p17522489.html
> Sent from the Struts - Dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: classpath scanner
Posted by dusty <du...@yahoo.com>.
If you already have it working, then great! I don't know anything about it,
so my question is only how likely are the authors to update/nurse this
library?
-D
Musachy Barroso wrote:
>
> Stating new thread for this topic. Don suggested to use this classpath
> scanner:
>
> http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/
>
> in xwork and plugins. It uses ASM to extract class information and
> annotations,so loading classes can be avoided until the last minute
> (when you actually need it). I modified convention to use it(not
> committed), and it is pretty good. Comment away here.
>
> musachy
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/classpath-scanner-tp17519827p17522489.html
Sent from the Struts - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: classpath scanner
Posted by James Holmes <ja...@jamesholmes.com>.
Sounds good to me. I'm all for better performance.
On Wed, May 28, 2008 at 3:07 PM, Musachy Barroso <mu...@gmail.com> wrote:
> Stating new thread for this topic. Don suggested to use this classpath
> scanner:
>
> http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/
>
> in xwork and plugins. It uses ASM to extract class information and
> annotations,so loading classes can be avoided until the last minute
> (when you actually need it). I modified convention to use it(not
> committed), and it is pretty good. Comment away here.
>
> musachy
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>