RE: [JBoss-dev] DocumentException "missing" in Branch_4_0
by Anil Saldhana
Ruel kept telling that the third party version issue has been fixed.
When in doubt with third party library errors, nuke the third party
folder and do a clean build.
________________________________
From: jboss-development-bounces(a)lists.jboss.org
[mailto:jboss-development-bounces@lists.jboss.org] On Behalf Of Kabir
Khan
Sent: Thursday, September 21, 2006 12:50 PM
To: 'JBoss.org development list'
Subject: RE: [JBoss-dev] DocumentException "missing" in Branch_4_0
A clean checkout works for me
________________________________
From: jboss-development-bounces(a)lists.jboss.org
[mailto:jboss-development-bounces@lists.jboss.org] On Behalf Of Scott M
Stark
Sent: 21 September 2006 18:44
To: JBoss.org development list
Subject: Re: [JBoss-dev] DocumentException "missing" in
Branch_4_0
That is what I am using:
[starksm@succubus build]$ grep common build-thirdparty.xml
<componentref name="jboss/common"
version="snapshot-Branch_1_0"/>
I removed all contents from thirdparty. Is there a new
jboss-common.jar in the repository or was there an update of an existing
one?
Dimitris Andreadis wrote:
I've already handled this, you need to update your thirdparty
libs
(common, snapshot-Branch_1_0)
-----Original Message-----
From: jboss-development-bounces(a)lists.jboss.org
[mailto:jboss-development-bounces@lists.jboss.org] On
Behalf
Of Scott M Stark
Sent: Thursday, September 21, 2006 8:31 PM
To: JBoss.org development list
Subject: Re: [JBoss-dev] DocumentException "missing" in
Branch_4_0
The problem is that there are dom4j dependencies in
jboss-common.jar
(org.jboss.util.state.xml.StateMachineParser
for one), and these will need to be removed to avoid
leaking
this dependency into the bootstrap classpath.
Kabir Khan wrote:
When starting up jboss in Branch_4_0 I get a
load of these errors
2006-09-21 17:27:17,406 WARN
[org.jboss.system.ServiceController]
Problem starting service
jboss.web.deployment:id=-1758252921,war=invoker.war
java.lang.NoClassDefFoundError:
org/dom4j/DocumentException
at
org.jboss.security.jacc.JBossPolicyConfigurationFactory.<init>(JBossPo
licyCo
nfigurationFactory.java:57)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructo
rAcces
sorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCo
nstruc
torAccessorImpl.java:27)
at
java.lang.reflect.Constructor.newInstance(Constructor.java:274)
at
java.lang.Class.newInstance0(Class.java:308)
at java.lang.Class.newInstance(Class.java:261)
at
javax.security.jacc.PolicyConfigurationFactory.getPolicyConfigurationF
actory
(PolicyConfigurationFactory.java:91)
at
org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:351)
at
org.jboss.web.WebModule.startModule(WebModule.java:83)
at
org.jboss.web.WebModule.startService(WebModule.java:61)
at
org.jboss.system.ServiceMBeanSupport.jbossInternalStart(Servic
eMBeanSupport.
java:289)
at
org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBe
anSupp
ort.java:245)
at
sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess
orImpl
.java:25)
But server/all/lib/dom4j.jar contains
org.dom4j.DocumentException. Any
ideas?
19 years, 6 months
RE: [JBoss-dev] DocumentException "missing" in Branch_4_0
by Dimitris Andreadis
I've already handled this, you need to update your thirdparty libs
(common, snapshot-Branch_1_0)
> -----Original Message-----
> From: jboss-development-bounces(a)lists.jboss.org
> [mailto:jboss-development-bounces@lists.jboss.org] On Behalf
> Of Scott M Stark
> Sent: Thursday, September 21, 2006 8:31 PM
> To: JBoss.org development list
> Subject: Re: [JBoss-dev] DocumentException "missing" in Branch_4_0
>
> The problem is that there are dom4j dependencies in
> jboss-common.jar (org.jboss.util.state.xml.StateMachineParser
> for one), and these will need to be removed to avoid leaking
> this dependency into the bootstrap classpath.
>
> Kabir Khan wrote:
> > When starting up jboss in Branch_4_0 I get a load of these errors
> >
> > 2006-09-21 17:27:17,406 WARN [org.jboss.system.ServiceController]
> > Problem starting service
> > jboss.web.deployment:id=-1758252921,war=invoker.war
> > java.lang.NoClassDefFoundError: org/dom4j/DocumentException
> > at
> >
> org.jboss.security.jacc.JBossPolicyConfigurationFactory.<init>(JBossPo
> > licyCo
> > nfigurationFactory.java:57)
> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> > Method)
> > at
> >
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructo
> > rAcces
> > sorImpl.java:39)
> > at
> >
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCo
> > nstruc
> > torAccessorImpl.java:27)
> > at
> java.lang.reflect.Constructor.newInstance(Constructor.java:274)
> > at java.lang.Class.newInstance0(Class.java:308)
> > at java.lang.Class.newInstance(Class.java:261)
> > at
> >
> javax.security.jacc.PolicyConfigurationFactory.getPolicyConfigurationF
> > actory
> > (PolicyConfigurationFactory.java:91)
> > at
> >
> org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:351)
> > at org.jboss.web.WebModule.startModule(WebModule.java:83)
> > at org.jboss.web.WebModule.startService(WebModule.java:61)
> > at
> >
> org.jboss.system.ServiceMBeanSupport.jbossInternalStart(Servic
> eMBeanSupport.
> > java:289)
> > at
> >
> org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBe
> > anSupp
> > ort.java:245)
> > at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source)
> > at
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess
> > orImpl
> > .java:25)
> >
> > But server/all/lib/dom4j.jar contains
> org.dom4j.DocumentException. Any
> > ideas?
> >
> > _______________________________________________
> > 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
>
19 years, 6 months
DocumentException "missing" in Branch_4_0
by Kabir Khan
When starting up jboss in Branch_4_0 I get a load of these errors
2006-09-21 17:27:17,406 WARN [org.jboss.system.ServiceController] Problem
starting service jboss.web.deployment:id=-1758252921,war=invoker.war
java.lang.NoClassDefFoundError: org/dom4j/DocumentException
at
org.jboss.security.jacc.JBossPolicyConfigurationFactory.<init>(JBossPolicyCo
nfigurationFactory.java:57)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAcces
sorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstruc
torAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
at java.lang.Class.newInstance0(Class.java:308)
at java.lang.Class.newInstance(Class.java:261)
at
javax.security.jacc.PolicyConfigurationFactory.getPolicyConfigurationFactory
(PolicyConfigurationFactory.java:91)
at
org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:351)
at org.jboss.web.WebModule.startModule(WebModule.java:83)
at org.jboss.web.WebModule.startService(WebModule.java:61)
at
org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.
java:289)
at
org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupp
ort.java:245)
at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
But server/all/lib/dom4j.jar contains org.dom4j.DocumentException. Any
ideas?
19 years, 6 months
Controlling order of subfolders when checking out
by Kabir Khan
Is there a way to configure the order in which sub-folders are returned when
checking out a svn project? For example when checking out Branch_4_0, trunk
etc. it starts off with ejb3/, and build/ comes late in the checkout. If
possible I would like to see build/ get pulled down earlier, so that I can
start populating the thirdparty stuff while waiting for the checkout to
finish. docbook-support/ and testsuite/ should probably come at the end,
since I can build a working app server without these two huge sub-folders.
19 years, 6 months
RE: [JBoss-dev] jboss-test is missing in maven2
by Rajesh Rajasekaran
Is this assuming that I should know beforehand that a release of
jboss-test includes jboss-test.jar and jboss-test-client.jar?
Just browsing http://repository.jboss.com/maven2/jboss
gives me a big list of modules
I might miss something like
http://repository.jboss.com/maven2/jboss/xyz/1.0.0.CR1
where xyz.jar comes with a release of jboss-test.
Is there a way I could track all the jars that come with a release in
this case?
-----Original Message-----
From: jboss-development-bounces(a)lists.jboss.org
[mailto:jboss-development-bounces@lists.jboss.org] On Behalf Of Scott M
Stark
Sent: Thursday, September 21, 2006 9:38 AM
To: JBoss.org development list
Subject: Re: [JBoss-dev] jboss-test is missing in maven2
There is still no need to redundantly use jboss-test in both the group
id and artifact id.
group id = jboss
artifact id = jboss-test
still provides a non-conflicting repository:
http://repository.jboss.com/maven2/jboss/jboss-test/1.0.0.CR1
http://repository.jboss.com/maven2/jboss/jboss-test-client/1.0.0.CR1
The group id should be jboss or jboss.org and the artifact id whatever
makes sense.
Rajesh Rajasekaran wrote:
> As far as my understanding goes...
>
> The naming convention is,
>
> RepositoryURL/GroupId/ArtifactId/VersionNo
>
> Where GroupId can be any name and ArtifactId should be the name of the
> jar.
>
> In the first case jboss is the GroupId and jboss-logging is the
> artifactId corresponding to jboss-logging-x.x.x.jar
>
> In the second case jboss.jboss-test is the groupId and jboss-test is
the
> artifactId corresponding to jboss-test-x.x.x.jar
>
> The second convention in the best when there are multiple artifacts
for
> a version.
>
> Say for example, we have a jboss-test-x.x.jar and a
> jboss-test-client-x.x.jar.
>
> Then we would have
>
http://repository.jboss.com/maven2/jboss/jboss-test/jboss-test/1.0.0.CR1
>
>
http://repository.jboss.com/maven2/jboss/jboss-test/jboss-test-client/1.
> 0.0.CR1
>
> In this case following the first convention would bring artifacts of
> different products under the same group.
>
> Any other explanations?
>
>
>
> -----Original Message-----
> From: jboss-development-bounces(a)lists.jboss.org
> [mailto:jboss-development-bounces@lists.jboss.org] On Behalf Of Alexey
> Loubyansky
> Sent: Thursday, September 21, 2006 1:45 AM
> To: JBoss.org development list
> Subject: Re: [JBoss-dev] jboss-test is missing in maven2
>
> Could someone, please, explain the naming/path convention in the
> repository?
>
> For example, for jboss-logging it's
> http://repository.jboss.com/maven2/jboss/jboss-logging/
>
> but the jboss-test is in the
> http://repository.jboss.com/maven2/jboss/jboss-test/jboss-test/
>
> Thanks,
> Alexey
>
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
19 years, 6 months
RE: [JBoss-dev] Re: Version numbers in library filenames - Bad
by Ryan Campbell
We will want both, correct? versionless jars for non-maven, versioned
for maven?
________________________________
From: jboss-development-bounces(a)lists.jboss.org
[mailto:jboss-development-bounces@lists.jboss.org] On Behalf Of Scott M
Stark
Sent: Thursday, September 21, 2006 9:44 AM
To: Carlo de Wolf
Cc: JBoss.org development list
Subject: [JBoss-dev] Re: Version numbers in library filenames - Bad
It looks like the jarName can be overriden. I'll see if I can rebuild
the jboss-common jars without the version as it will require a constant
updating of the eclipse projects in jbossas since jbossas is not build
using maven yet.
Carlo de Wolf wrote:
It is possible by specifying extra parameters with the goal.
http://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html
I don't have an example at hand.
Carlo
On Wed, 2006-09-20 at 07:54 -0700, Scott M Stark wrote:
I agree, but this is the maven convention and as far as I know
cannot be
undone short of hacking the jar plugin.
Dimitris Andreadis wrote:
I've seen a few cases where in repository.jboss.com the
version number
for a library is included in the library filename,
E.g.
antlr-2.7.6.jar
addressing-1.0.jar
odmg-3.0.jar
quartz-all-1.5.2.jar
dtdparser121.jar
commons-lang-2.1.jar
myfaces-impl-1.1.3.jar
Even worse:
Cglib/2.1.0/lib/cglib.jar, cglib-2.1.1.jar
This is wrong, because
- whenever a library is updated we have to correct all
explicit
references to it
- If you don't wipe your thirdparty on every update you
may end up with
3 different versions of the same library and wonder for
hours what's
wrong.
The version is encoded in the path and the library's
META-INF/MANIFEST.MF, not the filename, e.g:
apache-logging/1.0.3/lib/commons-logging.jar
For existing libs the harm is already done, but for new
library
additions to repository.jboss.com, please have that in
mind and remove
any version number from the filenames.
Thanks
/Dimitris
19 years, 6 months
Version numbers in library filenames - Bad
by Dimitris Andreadis
I've seen a few cases where in repository.jboss.com the version number
for a library is included in the library filename,
E.g.
antlr-2.7.6.jar
addressing-1.0.jar
odmg-3.0.jar
quartz-all-1.5.2.jar
dtdparser121.jar
commons-lang-2.1.jar
myfaces-impl-1.1.3.jar
Even worse:
Cglib/2.1.0/lib/cglib.jar, cglib-2.1.1.jar
This is wrong, because
- whenever a library is updated we have to correct all explicit
references to it
- If you don't wipe your thirdparty on every update you may end up with
3 different versions of the same library and wonder for hours what's
wrong.
The version is encoded in the path and the library's
META-INF/MANIFEST.MF, not the filename, e.g:
apache-logging/1.0.3/lib/commons-logging.jar
For existing libs the harm is already done, but for new library
additions to repository.jboss.com, please have that in mind and remove
any version number from the filenames.
Thanks
/Dimitris
19 years, 6 months
RE: [JBoss-dev] jboss-test is missing in maven2
by Rajesh Rajasekaran
As far as my understanding goes...
The naming convention is,
RepositoryURL/GroupId/ArtifactId/VersionNo
Where GroupId can be any name and ArtifactId should be the name of the
jar.
In the first case jboss is the GroupId and jboss-logging is the
artifactId corresponding to jboss-logging-x.x.x.jar
In the second case jboss.jboss-test is the groupId and jboss-test is the
artifactId corresponding to jboss-test-x.x.x.jar
The second convention in the best when there are multiple artifacts for
a version.
Say for example, we have a jboss-test-x.x.jar and a
jboss-test-client-x.x.jar.
Then we would have
http://repository.jboss.com/maven2/jboss/jboss-test/jboss-test/1.0.0.CR1
http://repository.jboss.com/maven2/jboss/jboss-test/jboss-test-client/1.
0.0.CR1
In this case following the first convention would bring artifacts of
different products under the same group.
Any other explanations?
-----Original Message-----
From: jboss-development-bounces(a)lists.jboss.org
[mailto:jboss-development-bounces@lists.jboss.org] On Behalf Of Alexey
Loubyansky
Sent: Thursday, September 21, 2006 1:45 AM
To: JBoss.org development list
Subject: Re: [JBoss-dev] jboss-test is missing in maven2
Could someone, please, explain the naming/path convention in the
repository?
For example, for jboss-logging it's
http://repository.jboss.com/maven2/jboss/jboss-logging/
but the jboss-test is in the
http://repository.jboss.com/maven2/jboss/jboss-test/jboss-test/
Thanks,
Alexey
Rajesh Rajasekaran wrote:
> Im adding it now.
> Should be under http://repository.jboss.com/maven2/jboss/jboss-test
>
>
>
>
> -----Original Message-----
> From: jboss-development-bounces(a)lists.jboss.org
> [mailto:jboss-development-bounces@lists.jboss.org] On Behalf Of Alexey
> Loubyansky
> Sent: Wednesday, September 20, 2006 4:42 PM
> To: JBoss.org development list
> Subject: [JBoss-dev] jboss-test is missing in maven2
>
> Can we add jboss-test framework to the maven2 repository?
> I need it for jbossxb local tests.
>
> Thanks,
> Alexey
> _______________________________________________
> 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
19 years, 6 months
RE: [JBoss-dev] Re: Library dependencies/updates for jboss-4.0.5.GA
by Dimitris Andreadis
It's done in Branch_4_0
http://jira.jboss.com/jira/browse/JBAS-3666
> -----Original Message-----
> From: jboss-development-bounces(a)lists.jboss.org
> [mailto:jboss-development-bounces@lists.jboss.org] On Behalf
> Of Dimitris Andreadis
> Sent: Tuesday, September 19, 2006 6:47 PM
> To: JBoss.org development list; Adrian Brock
> Subject: RE: [JBoss-dev] Re: Library dependencies/updates for
> jboss-4.0.5.GA
>
> I think we should take the jarjar approach. Later, we could
> change to use the jaxp APIs.
>
> In the (unlikely) event we break somebody, he could change to
> the other
> CTOR:
>
> public XMBean(Object resource, org.w3c.dom.Element element, String
> version)
>
> > -----Original Message-----
> > From: jboss-development-bounces(a)lists.jboss.org
> > [mailto:jboss-development-bounces@lists.jboss.org] On
> Behalf Of Scott
> > M Stark
> > Sent: Tuesday, September 19, 2006 5:49 PM
> > To: Adrian Brock
> > Cc: JBoss.org development list
> > Subject: Re: [JBoss-dev] Re: Library dependencies/updates for
> > jboss-4.0.5.GA
> >
> > Ok, but there are zero uses of that ctor in the codebase.
> Its going to
> > be broken one way or another if you jarjar or revert to the
> jaxp apis.
> >
> > Adrian Brock wrote:
> > > org.dom4j.Element element = ...
> > > XMBean mbean = new XMBean(object, element, version);
> > > server.registerMBean(mbean);
> > >
> > > Won't work if it is org.jboss.dom4j.Element
> > >
> > >
> >
> > _______________________________________________
> > 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
>
19 years, 6 months
