[Design of JBoss Build System] - Re: JBossAS CR1 build plan
by wolfc
"scott.stark(a)jboss.org" wrote : I don't follow why. Sure, both product releases would require separate runs of the top level aggregation entry point, but if both were mavenized, projects properly separated, running the top level jbossas release pom target should be able to build everything.
The jbossas aggregate doesn't know how to build ejb3 artifacts, only the ejb3 aggregate knows this. So if you run mvn release on jbossas it would complain about ejb3 snapshots. Likewise if you run mvn release on ejb3 it would complain about jbossas snapshots.
"scott.stark(a)jboss.org" wrote : In practice I think we should separate the release project from the base artifacts and one would have to run the build in stages. Is that what you mean?
|
Yes, first you do a mvn release of the jbossas-base, then mvn release ejb3, then mvn release jbossas-product.
(In the same sense that we do a mvn release of jboss-metadata, jboss-container & others before we can do the above.)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4128064#4128064
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4128064
18 years, 2 months
[Design of POJO Server] - Re: FIELD granularity web session replication tests
by bstansberry＠jboss.com
I found why BaseClassLoaderDomain.unregisterClassLoader() is never called. It's because WarClassLoaderDeployer overrides the superclass removeClassLoader(DeploymentContext) and turns it into a no-op.
Tried commenting out the override; i.e. just using the superclass behavior. No joy. Didn't seem to break war undeployments in any way, and in a debugger I can see the BaseClassLoaderDomain.unregisterClassLoader() stuff happening nicely. But if I redeploy the war and try to use it, the old invalid classloader still gets used:
| 2008-02-08 17:00:35,073 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/http-scoped-field].[jsp]] Servlet.service() for servlet jsp threw exception
| java.lang.IllegalStateException: BaseClassLoader@17ebc6c{vfsfile:/home/bes/dev/jboss/trunk/testsuite/output/lib/http-field-pass.war} classLoader is not connected to a domain (probably undeployed?) for class sun.reflect.ConstructorAccessorImpl
| at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:579)
| at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:234)
| at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
| at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
| at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
| at sun.misc.Unsafe.defineClass(Native Method)
| at sun.reflect.ClassDefiner.defineClass(ClassDefiner.java:45)
| at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:381)
| at java.security.AccessController.doPrivileged(Native Method)
| at sun.reflect.MethodAccessorGenerator.generate(MethodAccessorGenerator.java:377)
| at sun.reflect.MethodAccessorGenerator.generateConstructor(MethodAccessorGenerator.java:76)
| at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:30)
| at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
| at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
| at java.lang.Class.newInstance0(Class.java:350)
| at java.lang.Class.newInstance(Class.java:303)
| at org.jboss.aop.proxy.ClassProxyFactory.newInstance(ClassProxyFactory.java:103)
| at org.jboss.aop.proxy.ClassProxyFactory.newInstance(ClassProxyFactory.java:71)
| at org.jboss.aop.proxy.ClassProxyFactory.newInstance(ClassProxyFactory.java:66)
| at org.jboss.cache.pojo.collection.CollectionInterceptorUtil.createProxy(CollectionInterceptorUtil.java:50)
| ....
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4128037#4128037
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4128037
18 years, 2 months
[Design of JBoss Build System] - Re: JBossAS CR1 build plan
by ALRubinger
"pgier" wrote : Once ejb3 is mavenized it can still be deployed to the legacy repository using the jboss-deploy plugin or manually. Then the existing build can use the artifacts.
To drive home this point, it's unfortunately more involved than that. :) I'll try to be concise (and repeat some key points).
Problem 1:
EJB3 depends on AS components, many of which do not have their own lifecycle;we're building off snapshots.
Problem 2:
Even if the AS components had an official release, they're tied to the AS build itself. So EJB3 depends on AS, which depends on EJB3. That's the circular dependency.
Problem 3:
Minimal time/resources to address everything in the most clean fashion before CR1. In tandem with TCK.
So the goals as I see it, in order of priority:
1) Resolve circular dependency issues (cannot cut proper release with status-quo)
2) TCK
3) Cleanliness
I'll map out my out-of-scope Utopian wishlist as a jump-off point for debate and cutting back until we have something manageable for CR1.
* Each AS component owner responsible for their own build
* AS Build policy dictating that artifacts must be deployed to Maven repo
* Each AS component in separate release cycle
* Reorganization of AS in SVN to something like: jbossas/components/componentName/[trunk|branches|tags]
* Creation of new AS Assembly Project to bring in all dependent components and package into distribution (The EJB3 Plugin does this currently)
* Centralized POM tracking current versions of each AS component, to be used both by AS Assembly and outside projects (ie. EJB3)
AFAICT, discussion of artifact names and embedded versions seems minute compared with the overall task of defining how we can resolve the above for CR1.
Carlo's suggestion to treat the existing AS trunk as a unified "component", adding the additional AS Assembly has a lot of merit. This way we trim the fat of separately componentizing each module and have a well-defined version upon which EJB3 can depend. The cleanup and reorg can then be shuffled off to post-CR1.
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4128027#4128027
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4128027
18 years, 2 months
[Design of POJO Server] - Re: Problem deploying a -beans.xml in a SAR
by mr.colin.daly
I get this when starting JbossAS 5 Beta4 (revision 69713) with the aspects-1.0.0.jar from the microcontainer examples in the deploy directory i.e not a hot deploy.
Colin
| 10:06:28,044 INFO [AspectDeployer] Deploying xml into org.jboss.aop.AspectManager@87a1904 for BaseClassLoader@44157e43{vfsfile:/home/colin/apps/jboss/jboss-5.0.0.Beta4/server/default/deploy/ejb3-interceptors-aop.xml}
| 10:06:28,379 INFO [AppClientScanningDeployer] mainClass = class org.jboss.kernel.plugins.bootstrap.standalone.StandaloneBootstrap
| 10:06:28,564 ERROR [AbstractKernelController] Error installing to Real: name=vfsfile:/home/colin/apps/jboss/jboss-5.0.0.Beta4/server/default/deploy/aspects-1.0.0.jar state=PostClassLoader mode=Manual requiredState=Real
| org.jboss.deployers.spi.DeploymentException: Error deploying: AspectManager
| at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
| at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:73)
| at org.jboss.system.deployers.TempBeanMetaDataDeployer.deploy(TempBeanMetaDataDeployer.java:48)
| at org.jboss.system.deployers.TempBeanMetaDataDeployer.deploy(TempBeanMetaDataDeployer.java:35)
| at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:65)
| at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
| at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:169)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:853)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:874)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:794)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:327)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1309)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:734)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:862)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:784)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:622)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:411)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:498)
| at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:506)
| at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:246)
| at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:131)
| at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:408)
| at org.jboss.Main.boot(Main.java:208)
| at org.jboss.Main$1.run(Main.java:534)
| at java.lang.Thread.run(Thread.java:595)
| Caused by: java.lang.IllegalStateException: AspectManager is already installed.
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:525)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:398)
| at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:69)
| ... 23 more
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4128021#4128021
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4128021
18 years, 2 months
[Design of JBoss Build System] - Re: JBossAS CR1 build plan
by pgier
"scott.stark(a)jboss.org" wrote : "pgier" wrote :
| | (http://snapshots.jboss.org/maven2/org/jboss/jbossas/jboss-as-system/5.0.0...)
| | See build 8 for an example of the client jar.
| |
| | So while the names are not the same, I tried to follow a pattern in the naming conventions in order to make it easier to find the matching jars. Will this work?
| |
| | I can change jboss-as-system to jboss-system (and follow the pattern for the rest of the artifacts) if it helps. I just chose that convention because I thought it would make it easier to identify app server component vs. mc components, aop components, etc.
| |
| Whatever names we choose, we need to have both builds using them. I'd rather see jbossas as the common prefix. There is still the problem of jars in configurations. These should not have versions in the artifact names so that we have to change config files, jar manifests, docs, etc. We can drop the version in the jar in the local target, but not from the repository without writing a new repository plugin. What can we do about this disconnection in naming conventions?
|
It's not too difficult to write the jars without the version in the name. Then when they are deployed, they have the version. I think this will be clear as far as where jars are coming from.
However one problem is that I'm currently using a snapshot version of the maven assembly plugin. If I can't get an official release of the plugin on apache, then I can just for a version for us internally.
I'll plan to go through the jars and make this change early next week.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4128013#4128013
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4128013
18 years, 2 months