>
> 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/
> 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
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/
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
h
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
<[EMAIL PROTECTED]> wrote:
> Hi,
>
>
>> The xbean class
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.p
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 <[EMAIL PROTECTED]> wrote:
> maven-shade-plugin works
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 wor
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 <[EMAIL PROTECTED]> wrote:
>
> On May 30, 2008, at 2:09 AM, Ada
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 t
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
-
On Fri, May 30, 2008 at 7:09 PM, Adam Hardy
<[EMAIL PROTECTED]> 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
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
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
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
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
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
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
--- 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
---
> 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
--
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
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
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
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(
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
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.
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 Cla
> 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: [EMAIL PROTECTED]
For a
ate/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/
t; 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/ger
n 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
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
> scan
Sounds good to me. I'm all for better performance.
On Wed, May 28, 2008 at 3:07 PM, Musachy Barroso <[EMAIL PROTECTED]> wrote:
> Stating new thread for this topic. Don suggested to use this classpath
> scanner:
>
> http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbe
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
34 matches
Mail list logo
