You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Inge Solvoll <in...@gmail.com> on 2010/07/10 18:40:38 UTC
ClassNameLocator does not handle duplicates
Hi!
In our application we have classes packaged in jars. When we make changes to
those classes during development, they are compiled into WEB-INF/classes,
making them override the ones in the jars because WEB-INF/classes is read
first by the classloader. This is a convenient way of developing for us.
But: The ClassNameLocator does not take this into account. So it finds 2
classes with the same name, one from the jar and one from WEB-INF/classes.
Is this the desired behaviour? As you can see from the link, this causes
problems for me when using a component from spreadthesource.
http://spreadthesource.com/2010/07/christophe-as-an-apache-tapestry-5-committer/#comments
Re: ClassNameLocator does not handle duplicates
Posted by Robin Komiwes <ro...@gmail.com>.
Can we open a JIRA for that?
-- Robin Komiwes
On Sat, Jul 10, 2010 at 8:08 PM, Thiago H. de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> On Sat, 10 Jul 2010 13:40:38 -0300, Inge Solvoll <in...@gmail.com>
> wrote:
>
> Hi!
>>
>
> Hi!
>
> In our application we have classes packaged in jars. When we make changes
>> to
>> those classes during development, they are compiled into WEB-INF/classes,
>> making them override the ones in the jars because WEB-INF/classes is read
>> first by the classloader. This is a convenient way of developing for us.
>>
>
> Why are you packaging in JARs classes you're still developing?
>
>
> But: The ClassNameLocator does not take this into account. So it finds 2
>> classes with the same name, one from the jar and one from WEB-INF/classes.
>> Is this the desired behaviour? As you can see from the link, this causes
>> problems for me when using a component from spreadthesource.
>>
>
> I don't know the answer, but having two different versions of the same
> class in the classpath at the same time seem like something that should be
> avoided.
>
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
> and instructor
> Owner, Ars Machina Tecnologia da Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: ClassNameLocator does not handle duplicates
Posted by Inge Solvoll <in...@gmail.com>.
I have tried repeatedly decorating and advising ClassNameLocator, it doesn't
work, my methods are never hit. To be sure, I tried to replace the service
name with another known service (ClientInfrastructure), which worked. Does
anyone see someting wrong with the method below? Or is it not possible to
decorate or advise the ClassNameLocator?
public ClassNameLocator decorateClassNameLocator(ClassNameLocator original,
final ClasspathURLConverter c) {
return new CustomClassNameLocator(c);
}
On Mon, Jul 26, 2010 at 3:55 PM, Inge Solvoll <in...@gmail.com>wrote:
> I'm using eclipse, but it's a big legacy project with lots of custom build
> needs. So it isn't too easy to setup a smooth integrated build
> environment...
>
> I suddenly realized that it shouldn't be too hard decorating the
> ClassNameLocator and strip away duplicates from its result. Seems logical
> when this is a requirement that is very specific to our setup.
>
> Thanks for the hints anyway :)
>
> Inge
>
>
> On Sun, Jul 11, 2010 at 5:03 PM, Thiago H. de Paula Figueiredo <
> thiagohp@gmail.com> wrote:
>
>> On Sun, 11 Jul 2010 11:45:24 -0300, Inge Solvoll <in...@gmail.com>
>> wrote:
>>
>> As I said, it's convenient. Our application consists of many different
>>> maven projects that need to be assembled into one web container as jars.
>>> It's a
>>> complex aggregated application, and it would require extra work to
>>> provide a specific setup for development that doesn't use jar files.
>>> Espescially since it works the way we do it now, and it doesn't seem like
>>> the biggest hack in the world to me. The classloader was probably built like
>>> this (handling
>>> duplicates by priority) for a reason :)
>>>
>>
>> Using m2eclipse, I can open all the projects that comprise my application,
>> edit the sources of each one of them and have the changes being picked up
>> instantly.
>> If you're not using Eclipse, I can see that your setup is needed.
>>
>>
>> --
>> Thiago H. de Paula Figueiredo
>> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
>> and instructor
>> Owner, Ars Machina Tecnologia da Informação Ltda.
>> http://www.arsmachina.com.br
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
Re: ClassNameLocator does not handle duplicates
Posted by Inge Solvoll <in...@gmail.com>.
I'm using eclipse, but it's a big legacy project with lots of custom build
needs. So it isn't too easy to setup a smooth integrated build
environment...
I suddenly realized that it shouldn't be too hard decorating the
ClassNameLocator and strip away duplicates from its result. Seems logical
when this is a requirement that is very specific to our setup.
Thanks for the hints anyway :)
Inge
On Sun, Jul 11, 2010 at 5:03 PM, Thiago H. de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> On Sun, 11 Jul 2010 11:45:24 -0300, Inge Solvoll <in...@gmail.com>
> wrote:
>
> As I said, it's convenient. Our application consists of many different
>> maven projects that need to be assembled into one web container as jars.
>> It's a
>> complex aggregated application, and it would require extra work to provide
>> a specific setup for development that doesn't use jar files. Espescially
>> since it works the way we do it now, and it doesn't seem like the biggest
>> hack in the world to me. The classloader was probably built like this
>> (handling
>> duplicates by priority) for a reason :)
>>
>
> Using m2eclipse, I can open all the projects that comprise my application,
> edit the sources of each one of them and have the changes being picked up
> instantly.
> If you're not using Eclipse, I can see that your setup is needed.
>
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
> and instructor
> Owner, Ars Machina Tecnologia da Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: ClassNameLocator does not handle duplicates
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Sun, 11 Jul 2010 11:45:24 -0300, Inge Solvoll <in...@gmail.com>
wrote:
> As I said, it's convenient. Our application consists of many different
> maven projects that need to be assembled into one web container as jars.
> It's a
> complex aggregated application, and it would require extra work to
> provide a specific setup for development that doesn't use jar files.
> Espescially since it works the way we do it now, and it doesn't seem
> like the biggest hack in the world to me. The classloader was probably
> built like this (handling
> duplicates by priority) for a reason :)
Using m2eclipse, I can open all the projects that comprise my application,
edit the sources of each one of them and have the changes being picked up
instantly.
If you're not using Eclipse, I can see that your setup is needed.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: ClassNameLocator does not handle duplicates
Posted by Inge Solvoll <in...@gmail.com>.
On Sat, Jul 10, 2010 at 8:08 PM, Thiago H. de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> On Sat, 10 Jul 2010 13:40:38 -0300, Inge Solvoll <in...@gmail.com>
> wrote:
>
> Hi!
>>
>
> Hi!
>
> In our application we have classes packaged in jars. When we make changes
>> to
>> those classes during development, they are compiled into WEB-INF/classes,
>> making them override the ones in the jars because WEB-INF/classes is read
>> first by the classloader. This is a convenient way of developing for us.
>>
>
> Why are you packaging in JARs classes you're still developing?
>
>
As I said, it's convenient. Our application consists of many different maven
projects that need to be assembled into one web container as jars. It's a
complex aggregated application, and it would require extra work to provide a
specific setup for development that doesn't use jar files. Espescially since
it works the way we do it now, and it doesn't seem like the biggest hack in
the world to me. The classloader was probably built like this (handling
duplicates by priority) for a reason :)
>
> But: The ClassNameLocator does not take this into account. So it finds 2
>> classes with the same name, one from the jar and one from WEB-INF/classes.
>> Is this the desired behaviour? As you can see from the link, this causes
>> problems for me when using a component from spreadthesource.
>>
>
> I don't know the answer, but having two different versions of the same
> class in the classpath at the same time seem like something that should be
> avoided.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
> and instructor
> Owner, Ars Machina Tecnologia da Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: ClassNameLocator does not handle duplicates
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Sat, 10 Jul 2010 13:40:38 -0300, Inge Solvoll <in...@gmail.com>
wrote:
> Hi!
Hi!
> In our application we have classes packaged in jars. When we make
> changes to
> those classes during development, they are compiled into WEB-INF/classes,
> making them override the ones in the jars because WEB-INF/classes is read
> first by the classloader. This is a convenient way of developing for us.
Why are you packaging in JARs classes you're still developing?
> But: The ClassNameLocator does not take this into account. So it finds 2
> classes with the same name, one from the jar and one from
> WEB-INF/classes.
> Is this the desired behaviour? As you can see from the link, this causes
> problems for me when using a component from spreadthesource.
I don't know the answer, but having two different versions of the same
class in the classpath at the same time seem like something that should be
avoided.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org