I just updated AS trunk with a bunch of new MC stuff. Few issues first: (a) new logging-service-metadata is required, using my 1.0.0.CR5-SNAPSHOT atm (b) we now differentiate metadata locations in deployers: https://jira.jboss.org/jira/browse/JBDEPLOY-232 (c) Kernel's lifecycle callbacks are re-written to plain OO (d) ugly warning at undeploy wrt QualifiersMdrUtil (e) saw NPE at undeploy from Carlo's naming hack

For (a) I already asked DML to provide a new release. Wrt (b) some deployers need updating; e.g. JPA, Tld (I fixed this one), ... If somebody was using AOP's pointcuts with (c), they won't work anymore.

Kabir is looking into (d), at least I hope he is. :-)

Carlo needs to fix (e) -- if not yet fixed. New stuff: (a) asynch controller mode in Kernel (b) separate Classpool project -- soon to follow Reflect on Javassist (c) deployers sorting opt (d) annotation plugin matching, less heavy MDR lookup (e) optimized ScopeKey in MDR (f) MC+Weld integration; define services using Weld (g) updated modification synch check -- filtering only known files (h) CDI type of injection lookup; qualifiers based, etc (i) MC+OSGi-facade service mix will be available on new api ... I'm sure some issues will pop-up, so bare with me. Simply report them on our "AS dev" forum: http://www.jboss.org/index.html?module=bb&op=viewforum&f=208 and I'll have a look. _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

I just updated AS trunk with a bunch of new MC stuff. Few issues first: (a) new logging-service-metadata is required, using my 1.0.0.CR5-SNAPSHOT atm (b) we now differentiate metadata locations in deployers: https://jira.jboss.org/jira/browse/JBDEPLOY-232 (c) Kernel's lifecycle callbacks are re-written to plain OO (d) ugly warning at undeploy wrt QualifiersMdrUtil (e) saw NPE at undeploy from Carlo's naming hack For (a) I already asked DML to provide a new release. Wrt (b) some deployers need updating; e.g. JPA, Tld (I fixed this one), ... If somebody was using AOP's pointcuts with (c), they won't work anymore. Kabir is looking into (d), at least I hope he is. :-) Carlo needs to fix (e) -- if not yet fixed. New stuff: (a) asynch controller mode in Kernel (b) separate Classpool project -- soon to follow Reflect on Javassist (c) deployers sorting opt (d) annotation plugin matching, less heavy MDR lookup (e) optimized ScopeKey in MDR (f) MC+Weld integration; define services using Weld (g) updated modification synch check -- filtering only known files (h) CDI type of injection lookup; qualifiers based, etc (i) MC+OSGi-facade service mix will be available on new api ... I'm sure some issues will pop-up, so bare with me. Simply report them on our "AS dev" forum: http://www.jboss.org/index.html?module=bb&op=viewforum&f=208 and I'll have a look. _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

I already know the problem. I'm just running the smoke-tests before I commit the fix. I'll leave it to Ales to figure out how to tidyup the stale org.jboss.microcontainer references, which are likely to show up in broken maven classpaths at some point if they are left there? Adding excludes to the enforcer in component-matrix just raises an error. On Tue, 2010-01-12 at 14:01 -0600, Brian Stansberry wrote: > The testsuite build is failing with: > > [javac] > /home/bes/dev/jboss/clean/trunk/testsuite/src/main/org/jboss/test/profileservice/persistenceformat/test/JBossBeansPersistenceFormatTestCase.java:151: > cannot access org.jboss.dependency.spi.dispatch.LifecycleDispatchContext > [javac] class file for > org.jboss.dependency.spi.dispatch.LifecycleDispatchContext not found > [javac] BeanMetaData bmd = ctx.getBeanMetaData(); > [javac] ^ > [javac] Note: Some input files additionally use or override a > deprecated API. > [javac] Note: Some input files use unchecked or unsafe operations. > [javac] Note: Recompile with -Xlint:unchecked for details. > [javac] 1 error > [javac] 100 warnings > > I'm looking into that. I have a vague feeling it's a maven issue. > > On 01/12/2010 10:57 AM, Ales Justin wrote: >> I just updated AS trunk with a bunch of new MC stuff. >> >> Few issues first: >> (a) new logging-service-metadata is required, using my >> 1.0.0.CR5-SNAPSHOT atm >> (b) we now differentiate metadata locations in deployers: >> https://jira.jboss.org/jira/browse/JBDEPLOY-232 >> (c) Kernel's lifecycle callbacks are re-written to plain OO >> (d) ugly warning at undeploy wrt QualifiersMdrUtil >> (e) saw NPE at undeploy from Carlo's naming hack >> >> For (a) I already asked DML to provide a new release. >> Wrt (b) some deployers need updating; e.g. JPA, Tld (I fixed this one), ... >> If somebody was using AOP's pointcuts with (c), they won't work anymore. >> Kabir is looking into (d), at least I hope he is. :-) >> Carlo needs to fix (e) -- if not yet fixed. >> >> New stuff: >> (a) asynch controller mode in Kernel >> (b) separate Classpool project -- soon to follow Reflect on Javassist >> (c) deployers sorting opt >> (d) annotation plugin matching, less heavy MDR lookup >> (e) optimized ScopeKey in MDR >> (f) MC+Weld integration; define services using Weld >> (g) updated modification synch check -- filtering only known files >> (h) CDI type of injection lookup; qualifiers based, etc >> (i) MC+OSGi-facade service mix will be available on new api >> ... >> >> I'm sure some issues will pop-up, so bare with me. >> Simply report them on our "AS dev" forum: >> http://www.jboss.org/index.html?module=bb&op=viewforum&f=208 >> and I'll have a look. >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development > >

On Tue, 2010-01-12 at 21:14 +0100, Adrian Brock wrote: > I already know the problem. I'm just running the smoke-tests > before I commit the fix. > There's one error in the smoke tests, due to a change in api. I'll commit this, since at least its better than it not compiling. ;-) This public constructor should have been deprecated (possibly with a one time log warning saying to use the factory method instead?) You shouldn't change a public spi in a minor release. i.e. 2.0.0 -> 2.2.0 Caused by: java.lang.IllegalAccessError: tried to access method org.jboss.dependency.spi.ControllerState.<init>(Ljava/lang/String;)V from class org.jboss.ejb3.deployer s.Ejb3DependenciesDeployer$1 at org.jboss.ejb3.deployers.Ejb3DependenciesDeployer $1.deploy(Ejb3DependenciesDeployer.java:67) at org.jboss.ejb3.deployers.Ejb3DependenciesDeployer $1.deploy(Ejb3DependenciesDeployer.java:48) at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy( AbstractRealDeployerWithInput.java:125) -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss by Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

On Tue, 2010-01-12 at 21:34 +0100, Ales Justin wrote: > Is there some formal docs on how to follow versioning wrt spi/api > changes? Binary compatiblity is in the jls http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html You broke rule 13.4.6 But there is more to it than that. e.g. Adding a method to an interface doesn't break existing classes that implement it, providing you don't invoke the new method on that class. But it does stop you recompiling the class without implementing the method - which is a source incompatibility. That's why it is better to add a new method using a mixin interface and test whether the class implements it before invoking it. There's no section on source compatibility in the jls. :-)

Just an FYI, that same problem Adrian reported affects the Weld integration's DynamicDependencyCreator.[1] This afternoon I ran a good chunk of different tests (clustering stuff that touches on a bunch of areas, plus profileservice targets). Saw problems with anything using EJB3 due to this ControllerState issue and with org.jboss.test.deployers.weld.test.WeldTranslatorExampleUnitTestCase due to[1]. Otherwise, it looked pretty good. [1] The failure: 2010-01-12 15:49:04,575 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (WorkerThread#1[127.0.0.1:57823]) Error installing to Configured: name=vfszip:/home/bes/dev/jboss/clean/trunk/testsuite/output/lib/weld-numberguess.war/_WeldBootstrapBean state=Instantiated: java.lang.IllegalAccessError: tried to access method org.jboss.dependency.spi.ControllerState.<init>(Ljava/lang/String;)V from class org.jboss.weld.integration.deployer.env.DynamicDependencyCreator at org.jboss.weld.integration.deployer.env.DynamicDependencyCreator.createDepenencies(DynamicDependencyCreator.java:73) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59) at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:151) at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66) at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300) at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:304) at org.jboss.kernel.plugins.dispatch.InvokeDispatchHelper.invoke(InvokeDispatchHelper.java:112) at org.jboss.kernel.plugins.dependency.InstallsAwareAction.invokeInstalls(InstallsAwareAction.java:107) at org.jboss.kernel.plugins.dependency.InstallsAwareAction.doInstalls(InstallsAwareAction.java:72) at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:55) at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42) at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:378) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1856) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:999) at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1217) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1141) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1048) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:842) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:589) at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:180) On 01/12/2010 02:34 PM, Ales Justin wrote: > Ah, the horrible transitive dependencies. > I'll tidyup tomorrow. > > I can cut a new alpha2 to bring back some lost spi/api. > > Is there some formal docs on how to follow versioning wrt spi/api > changes? > > Sent from my iPod > > On 12.1.2010, at 21:22, Adrian Brock&lt;abrock(a)redhat.com&gt; wrote: > >> On Tue, 2010-01-12 at 21:14 +0100, Adrian Brock wrote: >>> I already know the problem. I'm just running the smoke-tests >>> before I commit the fix. >>> >> There's one error in the smoke tests, due to a change in api. >> I'll commit this, since at least its better than it not compiling. ;-) >> >> This public constructor should have been deprecated (possibly with >> a one time log warning saying to use the factory method instead?) >> >> You shouldn't change a public spi in a minor release. >> i.e. 2.0.0 -> 2.2.0 >> >> Caused by: java.lang.IllegalAccessError: tried to access method >> org.jboss.dependency.spi.ControllerState.<init>(Ljava/lang/String;)V >> from class org.jboss.ejb3.deployer >> s.Ejb3DependenciesDeployer$1 >> at org.jboss.ejb3.deployers.Ejb3DependenciesDeployer >> $1.deploy(Ejb3DependenciesDeployer.java:67) >> at org.jboss.ejb3.deployers.Ejb3DependenciesDeployer >> $1.deploy(Ejb3DependenciesDeployer.java:48) >> at >> org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy( >> AbstractRealDeployerWithInput.java:125) >> >> >> -- >> xxxxxxxxxxxxxxxxxxxxxxxxxxxx >> Adrian Brock >> Chief Scientist >> JBoss by Red Hat >> xxxxxxxxxxxxxxxxxxxxxxxxxxxx >> >> _______________________________________________ >> 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

I just released a new Kernel 2.2.0.Alpha2 which restores this 'new ControllerState'.

On 13 Jan 2010, at 18:05, Ales Justin wrote: >> I just released a new Kernel 2.2.0.Alpha2 which restores this 'new >> ControllerState'. > > The ugly undeploy warnings from QualifiersMdrUtil are still there, > and Kabir is working on it. I have fixed this as part of https://jira.jboss.org/jira/browse/JBAOP-763. As far as I know Flavia has been doing a fair bit of work on AOP Branch_2_1, and she is on holidays. I will wait releasing AOP 2.1.7 until I've had a chance to sync with her early next week. There are a few AOP test failures, which I will fix. Some are need @EnableAopProxy which I will fix now, others are for scoped AOP as mentioned in the "Integration of naming deployers failed" thread > > While I did exclude Carlo's NPEs, > there is some JNDI binding not found exception now. > > I also added some dummy context tracker, > which should help performance a bit -- forgot to do it before. > > _______________________________________________ > 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