module updates in AS trunk
by Dimitris Andreadis
FYI, some recent upgrades in AS trunk:
jboss-remoting to 2.4.0.GA
jboss-aop to 2.0.0.CR10
hibernate to 3.3.0.CR1
hibernate-commons-annotations to 3.1.0.CR1
hibernate-annotations to 3.4.0.CR1
hibernate-entity-manager to 3.4.0.CR1
hibernate-validator to 3.1.0.CR1
hibernate-core and hibernate-jmx are now included with the server libs.
(note old name: hibernate.jar, new name: hibernate-core.jar. I changed the tck config
accordingly)
If additional hibernate modules are needed, they would need to be added.
Things we are missing:
http://jira.jboss.com/jira/browse/JBAS-5121
jboss-vfs 2.0.0.CR1
jboss-integration 5.0.0.CR1
jboss-managed 2.0.0.CR1
jboss-metadata 2.0.0.CR1
jboss-microcontainer & friends 2.0.0.CR1
jgroups 2.6.3 that contains bug fixes
I guess, the following won't make it for AS5 CR1, since they depend on other components
reaching GA
pojo-cache 2.2.0.GA
jboss-ha-client 1.1.0.GA
jboss-ha-servera-api 1.1.0.GA
18 years, 1 month
Change groupId for integration modules
by Paul Gier
I am planning to change the maven groupId for the integration subprojects. So
these dependencies will change:
org.jboss:jboss-classloading-spi
org.jboss:jboss-corba-ots-spi
org.jboss:jboss-transaction-spi
Instead of org.jboss the groupId will become org.jboss.integration for the CR1
release tomorrow. In addition, two new modules will have the new groupId:
org.jboss.integration:jboss-deployment-spi
org.jboss.integration:jboss-jca-spi
This will make deployment a little cleaner in the maven repository. I would
like all jboss projects to follow the groupId
org.jboss.<project>
or
org.jboss.<project>.<subproject>
Thanks!
18 years, 1 month
AS testsuite regression
by Dimitris Andreadis
The latest AS5 testsuite runs reveals 243 failures, 100+ from our usual numbers:
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.0.x-Test...
A lot of them look cluster related, others are security, aop & deployment errors.
Your help is needed.
Also, it is a known problem that the custom configs in our testsuite are easy to break when
doing tomcat/jboss-web configuration changes. In this case you need to monitor subsequent
runs to see if the full testsuite can execute and make adjustments accordingly, otherwise we
can easily loose 2-3 days of results.
Thanks
/D
18 years, 1 month
AS trunk - boot.log WARNings
by Dimitris Andreadis
Those WARNings in boot.log are new:
14:21:54,250 WARN [BeanAnnotationAdapterFactory] Exception while creating bean annotation
adapter instance: java.lang.IllegalAccessException: Class
org.jboss.reflect.plugins.introspection.ReflectionUtils can not access a member of class
org.jboss.kernel.plugins.annotations.BasicBeanAnnotationAdapter with modifiers "protected"
...
14:21:58,343 WARN [AbstractKernelController] Additional matching bean - contextual
injection already used for class: class org.jboss.classloading.spi.dependency.Module
...
14:21:59,359 WARN [AbstractKernelController] Additional matching bean - contextual
injection already used for class: class org.jboss.classloading.spi.dependency.Module
...
14:22:00,375 WARN [AbstractKernelController] Additional matching bean - contextual
injection already used for class: class org.jboss.classloading.spi.dependency.Module
...
14:22:01,468 WARN [AbstractKernelController] Additional matching bean - contextual
injection already used for class: class org.jboss.classloading.spi.dependency.Module
...
18 years, 1 month
AS testsuite - Null dependency - .war deployment failures
by Dimitris Andreadis
Something that changed recently causes .war deployment failures, at least in the
tomcat-federation tests.
Maybe the change http://jira.jboss.com/jira/browse/JBAS-5558?
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.0.x-Test...
Caused by: org.jboss.deployers.spi.DeploymentException: Error creating rar deployment
vfsfile:/qa/services/hudson/hudson_workspace/workspace/JBoss-AS-5.0.x-TestSuite-sun15/trunk/build/output/jboss-5.0.0.CR1/server/tomcat-federation/deploy/http-invoker.sar/invoker.war/
at
org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
at org.jboss.web.deployers.AbstractWarDeployer.deployWebModule(AbstractWarDeployer.java:703)
at org.jboss.web.deployers.AbstractWarDeployer.deploy(AbstractWarDeployer.java:449)
... 23 more
Caused by: java.lang.IllegalArgumentException: Null dependency
at
org.jboss.system.metadata.ServiceInjectionValueMetaData.setDependency(ServiceInjectionValueMetaData.java:114)
at
org.jboss.system.metadata.ServiceInjectionValueMetaData.<init>(ServiceInjectionValueMetaData.java:91)
at
org.jboss.system.metadata.ServiceInjectionValueMetaData.<init>(ServiceInjectionValueMetaData.java:79)
at
org.jboss.system.metadata.ServiceInjectionValueMetaData.<init>(ServiceInjectionValueMetaData.java:68)
at org.jboss.web.deployers.AbstractWarDeployer.deployWebModule(AbstractWarDeployer.java:670)
... 24 more
18 years, 1 month
org.jboss:javassist or javassist:javassist
by Carlo de Wolf
What's it going to be?
Now I have org.hibernate:hibernate-annotations:3.3.1.GA declaring a
dependency on javassist:javassist:3.4.GA and
org.jboss.aop:jboss-aop:2.0.0.CR7 declaring a dependency on
org.jboss:javassist:3.6.0.GA, thus ending me up with (what Debian would
call) an unstable configuration.
Depending on the wind, state of the moon, the weather in general Maven
will put either on first on the class path. Which results in an
unpredictable build.
My preference goes to javassist:javassist, because that reflects the
package name and thus has less chance of name conflict.
maxb of Maven suggests the same:
(01:00:29 PM) wolfc: maxb_: I hope too that the first set of duplicates
match central. As for the second set, it contains a lot of legacy and
changing insights. So I was hoping to find something similar to
'obsoletes' in rpm or 'replaces' in dpkg. Or even a directive which
forbids the use of javassist:javassist in the org.jboss:javassist pom.
(01:01:16 PM) maxb_: Well, I'd suggest going the other way, and using
javassist:javassist, since that's the name that *has* made it into central
On the other hand org.jboss reflects our zone.
So before the week is done I want either artifact on the banned
dependency list (which I'm now introducing in EJB3 build and I'll
suggest to Dimitris to do the same for AS).
Note: I'm putting org.jboss.microcontainer:jboss-container on the ban
right now, because I can almost spell out the getBeanInfo BeanAccess
signature error in my dreams.
Carlo
18 years, 1 month
