8:20 a.m.
Was this just an oversight or was there some specific reason it was not
included? commons-httpclient.jar is in commons/lib and it depends on
commons-codec.
The problem I'm having is that the RichFaces demo has:
<jboss-web>
<class-loading>
<loader-repository>
org.richfaces.samples.richfaces-demo:loader=richfaces-demo-jee5.war
<loader-repository-config>java2ParentDelegation=true</loader-repository-config>
</loader-repository>
</class-loading>
</jboss-web>
It includes commons-httpclient and commons-codec in WEB-INF/lib. Since
parent delegation is true it will use commons-httpclient from
commons/lib and then fail because it can't find commons-codec.
So there are two ways to fix it. Either remove commons-httpclient from
commons/lib or add commons-codec.
Who is depending on commons-httpclient and how would I know this so I
would know who to ask?
Stan
8:44 a.m.
I'm guessing the dependency on commons-httpclient is related to the now
obsolete webdav netboot capability? Otherwise, maybe its from an http
remoting thingy. If we do bundle commons-httpclient, we should also
include commons-codec.
Stan Silvert wrote:
Was this just an oversight or was there some specific reason it was
not included? commons-httpclient.jar is in commons/lib and it depends
on commons-codec.
The problem I'm having is that the RichFaces demo has:
<jboss-web>
<class-loading>
<loader-repository>
org.richfaces.samples.richfaces-demo:loader=richfaces-demo-jee5.war
<loader-repository-config>java2ParentDelegation=true</loader-repository-config>
</loader-repository>
</class-loading>
</jboss-web>
It includes commons-httpclient and commons-codec in WEB-INF/lib.
Since parent delegation is true it will use commons-httpclient from
commons/lib and then fail because it can't find commons-codec.
So there are two ways to fix it. Either remove commons-httpclient
from commons/lib or add commons-codec.
Who is depending on commons-httpclient and how would I know this so I
would know who to ask?
Stan
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
12:57 p.m.
It definitely is the old netboot stuff that is introducing
commons-httpclient.jar:
// If the home URL begins with http add the webav and httpclient jars
if( homeURL.getProtocol().startsWith("http") == true )
{
this.addLibrary("webdavlib.jar");
this.addLibrary("commons-httpclient.jar");
this.addLibrary("commons-logging.jar");
}
We should just remove commons-httpclient.jar from the common/lib
Stan Silvert wrote:
Was this just an oversight or was there some specific reason it was
not included? commons-httpclient.jar is in commons/lib and it depends
on commons-codec.
The problem I'm having is that the RichFaces demo has:
<jboss-web>
<class-loading>
<loader-repository>
org.richfaces.samples.richfaces-demo:loader=richfaces-demo-jee5.war
<loader-repository-config>java2ParentDelegation=true</loader-repository-config>
</loader-repository>
</class-loading>
</jboss-web>
It includes commons-httpclient and commons-codec in WEB-INF/lib.
Since parent delegation is true it will use commons-httpclient from
commons/lib and then fail because it can't find commons-codec.
So there are two ways to fix it. Either remove commons-httpclient
from commons/lib or add commons-codec.
Who is depending on commons-httpclient and how would I know this so I
would know who to ask?
Stan
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
1:04 p.m.
Those 3 libraries were in JBOSS_HOME/lib for webdav support, yes.
I recall something was using httpclient to need to have it in common/lib, don't
remember
what it was though.
Scott Stark wrote:
It definitely is the old netboot stuff that is introducing
commons-httpclient.jar:
// If the home URL begins with http add the webav and httpclient jars
if( homeURL.getProtocol().startsWith("http") == true )
{
this.addLibrary("webdavlib.jar");
this.addLibrary("commons-httpclient.jar");
this.addLibrary("commons-logging.jar");
}
We should just remove commons-httpclient.jar from the common/lib
Stan Silvert wrote:
> Was this just an oversight or was there some specific reason it was
> not included? commons-httpclient.jar is in commons/lib and it depends
> on commons-codec.
>
> The problem I'm having is that the RichFaces demo has:
> <jboss-web>
> <class-loading>
> <loader-repository>
>
> org.richfaces.samples.richfaces-demo:loader=richfaces-demo-jee5.war
>
>
<loader-repository-config>java2ParentDelegation=true</loader-repository-config>
>
> </loader-repository>
> </class-loading>
> </jboss-web>
>
> It includes commons-httpclient and commons-codec in WEB-INF/lib.
> Since parent delegation is true it will use commons-httpclient from
> commons/lib and then fail because it can't find commons-codec.
>
> So there are two ways to fix it. Either remove commons-httpclient
> from commons/lib or add commons-codec.
>
> Who is depending on commons-httpclient and how would I know this so I
> would know who to ask?
>
> Stan
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
1:12 p.m.
Its hard to tell because nothing directly references this jar. Rather
subprojects are referencing the apache.commons.classpath, but most just
are using the commons-logging:
<path id="apache.commons.classpath">
<pathelement path="${apache.collections.lib}/commons-collections.jar"/>
<pathelement path="${apache.logging.lib}/commons-logging.jar"/>
<pathelement path="${apache.httpclient.lib}/commons-httpclient.jar"/>
<pathelement path="${apache.discovery.lib}/commons-discovery.jar"/>
<pathelement path="${apache.fileupload.lib}/commons-fileupload.jar"/>
<pathelement path="${apache.lang.lib}/commons-lang.jar"/>
</path>
[654][valkyrie: Branch_5_0]$ find . -name build.xml -exec grep -l
apache.commons.classpath {} \;
./aspects/build.xml
./cluster/build.xml
./connector/build.xml
./console/build.xml
./hibernate-int/build.xml
./jmx/build.xml
./management/build.xml
./server/build.xml
./system-jmx/build.xml
./testsuite/build.xml
./tomcat/build.xml
./varia/build.xml
Dimitris Andreadis wrote:
Those 3 libraries were in JBOSS_HOME/lib for webdav support, yes.
I recall something was using httpclient to need to have it in
common/lib, don't remember what it was though.
1:14 p.m.
If I look just at the eclipse project .classpaths, only varia and
testsuite reference commons-http.
[655][valkyrie: Branch_5_0]$ find . -name .classpath -exec grep -l
commons-http {} \;
./testsuite/.classpath
./varia/.classpath
The varia reference is old netboot stuff. Some thirdparty jar like
remoting still may need it though.
Dimitris Andreadis wrote:
Those 3 libraries were in JBOSS_HOME/lib for webdav support, yes.
I recall something was using httpclient to need to have it in
common/lib, don't remember what it was though.
Scott Stark wrote:
> It definitely is the old netboot stuff that is introducing
> commons-httpclient.jar:
>
> // If the home URL begins with http add the webav and httpclient
> jars
> if( homeURL.getProtocol().startsWith("http") == true )
> {
> this.addLibrary("webdavlib.jar");
> this.addLibrary("commons-httpclient.jar");
> this.addLibrary("commons-logging.jar");
> }
>
> We should just remove commons-httpclient.jar from the common/lib
>
> Stan Silvert wrote:
>> Was this just an oversight or was there some specific reason it was
>> not included? commons-httpclient.jar is in commons/lib and it
>> depends on commons-codec.
>>
>> The problem I'm having is that the RichFaces demo has:
>> <jboss-web>
>> <class-loading>
>> <loader-repository>
>>
>> org.richfaces.samples.richfaces-demo:loader=richfaces-demo-jee5.war
>>
>>
<loader-repository-config>java2ParentDelegation=true</loader-repository-config>
>>
>> </loader-repository>
>> </class-loading>
>> </jboss-web>
>>
>> It includes commons-httpclient and commons-codec in WEB-INF/lib.
>> Since parent delegation is true it will use commons-httpclient from
>> commons/lib and then fail because it can't find commons-codec.
>>
>> So there are two ways to fix it. Either remove commons-httpclient
>> from commons/lib or add commons-codec.
>>
>> Who is depending on commons-httpclient and how would I know this so
>> I would know who to ask?
>>
>> Stan
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
1:32 p.m.
We need to take a second look at all the 3rd party dependencies and
their versions in the AS.
============
<dependency>
<groupId>apache-velocity</groupId>
<artifactId>velocity</artifactId>
<version>1.4jboss</version>
</dependency>
==============
There are API changes in 1.5 version of velocity. We are using a
patched version of velocity, OSS projects
that depend on velocity will use 1.5+
https://jira.jboss.org/jira/browse/JBAS-6404
Scott Stark wrote:
If I look just at the eclipse project .classpaths, only varia and
testsuite reference commons-http.
[655][valkyrie: Branch_5_0]$ find . -name .classpath -exec grep -l
commons-http {} \;
./testsuite/.classpath
./varia/.classpath
The varia reference is old netboot stuff. Some thirdparty jar like
remoting still may need it though.
Dimitris Andreadis wrote:
> Those 3 libraries were in JBOSS_HOME/lib for webdav support, yes.
>
> I recall something was using httpclient to need to have it in
> common/lib, don't remember what it was though.
>
> Scott Stark wrote:
>> It definitely is the old netboot stuff that is introducing
>> commons-httpclient.jar:
>>
>> // If the home URL begins with http add the webav and
>> httpclient jars
>> if( homeURL.getProtocol().startsWith("http") == true )
>> {
>> this.addLibrary("webdavlib.jar");
>> this.addLibrary("commons-httpclient.jar");
>> this.addLibrary("commons-logging.jar");
>> }
>>
>> We should just remove commons-httpclient.jar from the common/lib
>>
>> Stan Silvert wrote:
>>> Was this just an oversight or was there some specific reason it was
>>> not included? commons-httpclient.jar is in commons/lib and it
>>> depends on commons-codec.
>>>
>>> The problem I'm having is that the RichFaces demo has:
>>> <jboss-web>
>>> <class-loading>
>>> <loader-repository>
>>>
>>> org.richfaces.samples.richfaces-demo:loader=richfaces-demo-jee5.war
>>>
>>>
<loader-repository-config>java2ParentDelegation=true</loader-repository-config>
>>>
>>> </loader-repository>
>>> </class-loading>
>>> </jboss-web>
>>>
>>> It includes commons-httpclient and commons-codec in WEB-INF/lib.
>>> Since parent delegation is true it will use commons-httpclient from
>>> commons/lib and then fail because it can't find commons-codec.
>>>
>>> So there are two ways to fix it. Either remove commons-httpclient
>>> from commons/lib or add commons-codec.
>>>
>>> Who is depending on commons-httpclient and how would I know this so
>>> I would know who to ask?
>>>
>>> Stan
4:12 p.m.
I don't know the history of commons-httpclient.jar in Remoting (it's in
the older Remoting 2.2 branch, for some reason), but Remoting 2.5
doesn't use it.
Scott Stark wrote:
If I look just at the eclipse project .classpaths, only varia and
testsuite reference commons-http.
[655][valkyrie: Branch_5_0]$ find . -name .classpath -exec grep -l
commons-http {} \;
./testsuite/.classpath
./varia/.classpath
The varia reference is old netboot stuff. Some thirdparty jar like
remoting still may need it though.
Dimitris Andreadis wrote:
> Those 3 libraries were in JBOSS_HOME/lib for webdav support, yes.
>
> I recall something was using httpclient to need to have it in
> common/lib, don't remember what it was though.
>
> Scott Stark wrote:
>> It definitely is the old netboot stuff that is introducing
>> commons-httpclient.jar:
>>
>> // If the home URL begins with http add the webav and
>> httpclient jars
>> if( homeURL.getProtocol().startsWith("http") == true )
>> {
>> this.addLibrary("webdavlib.jar");
>> this.addLibrary("commons-httpclient.jar");
>> this.addLibrary("commons-logging.jar");
>> }
>>
>> We should just remove commons-httpclient.jar from the common/lib
>>
>> Stan Silvert wrote:
>>> Was this just an oversight or was there some specific reason it was
>>> not included? commons-httpclient.jar is in commons/lib and it
>>> depends on commons-codec.
>>>
>>> The problem I'm having is that the RichFaces demo has:
>>> <jboss-web>
>>> <class-loading>
>>> <loader-repository>
>>>
>>> org.richfaces.samples.richfaces-demo:loader=richfaces-demo-jee5.war
>>>
>>>
<loader-repository-config>java2ParentDelegation=true</loader-repository-config>
>>>
>>> </loader-repository>
>>> </class-loading>
>>> </jboss-web>
>>>
>>> It includes commons-httpclient and commons-codec in WEB-INF/lib.
>>> Since parent delegation is true it will use commons-httpclient from
>>> commons/lib and then fail because it can't find commons-codec.
>>>
>>> So there are two ways to fix it. Either remove commons-httpclient
>>> from commons/lib or add commons-codec.
>>>
>>> Who is depending on commons-httpclient and how would I know this so
>>> I would know who to ask?
>>>
>>> Stan
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
4:41 a.m.
Dimitris Andreadis wrote:
Those 3 libraries were in JBOSS_HOME/lib for webdav support, yes.
I recall something was using httpclient to need to have it in
common/lib, don't remember what it was though.
AFAIK, old deployment framework needed it to enable scanning of WebDAV
deployment locations.
Scott Stark wrote:
> It definitely is the old netboot stuff that is introducing
> commons-httpclient.jar:
>
> // If the home URL begins with http add the webav and httpclient
> jars
> if( homeURL.getProtocol().startsWith("http") == true )
> {
> this.addLibrary("webdavlib.jar");
> this.addLibrary("commons-httpclient.jar");
> this.addLibrary("commons-logging.jar");
> }
>
> We should just remove commons-httpclient.jar from the common/lib
>
> Stan Silvert wrote:
>> Was this just an oversight or was there some specific reason it was
>> not included? commons-httpclient.jar is in commons/lib and it
>> depends on commons-codec.
>>
>> The problem I'm having is that the RichFaces demo has:
>> <jboss-web>
>> <class-loading>
>> <loader-repository>
>>
>> org.richfaces.samples.richfaces-demo:loader=richfaces-demo-jee5.war
>>
>>
<loader-repository-config>java2ParentDelegation=true</loader-repository-config>
>>
>> </loader-repository>
>> </class-loading>
>> </jboss-web>
>>
>> It includes commons-httpclient and commons-codec in WEB-INF/lib.
>> Since parent delegation is true it will use commons-httpclient from
>> commons/lib and then fail because it can't find commons-codec.
>>
>> So there are two ways to fix it. Either remove commons-httpclient
>> from commons/lib or add commons-codec.
>>
>> Who is depending on commons-httpclient and how would I know this so I
>> would know who to ask?
>>
>> Stan
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
5809
days inactive
5813
days old
jboss-development@lists.jboss.org
8 comments
6 participants
participants (6)
-
Anil Saldhana -
Dimitris Andreadis -
Galder Zamarreno -
Ron Sigal -
Scott Stark -
Stan Silvert