5:33 a.m.
Hopefully, today I'm going to update jboss-head
to the new deployers, this means the build might be broken
for a bit.
I'd appreciate it if you don't commit anything around the
deployers (that includes the ejb containers, etc.)
so I can do a final merge and standup tests
before committing.
I'll let you know when the commits are in.
NOTE: I'll be disabling webservices for a couple of days
since its deployers are in the webservices project
which I haven't updated to the new deployers yet
and they'll also require a new release of webservices
to be updated.
Apologies for the inconvience. :-(
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
12:19 p.m.
Thanks Carlo! Now I've got to remerge again
and retest before committing.
I'll bet he's not even subscribed to the dev list???? :-)
On Thu, 2007-06-28 at 12:33 +0200, Adrian wrote:
Hopefully, today I'm going to update jboss-head
to the new deployers, this means the build might be broken
for a bit.
I'd appreciate it if you don't commit anything around the
deployers (that includes the ejb containers, etc.)
so I can do a final merge and standup tests
before committing.
I'll let you know when the commits are in.
NOTE: I'll be disabling webservices for a couple of days
since its deployers are in the webservices project
which I haven't updated to the new deployers yet
and they'll also require a new release of webservices
to be updated.
Apologies for the inconvience. :-(
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
4:14 a.m.
You're welcome. :-)
Just out of curiosity, what did you test?
(http://wolf.nerdnet.nl:8180/hudson/job/JBoss_EJB3_TRUNK/13/ )
Meow,
Carlo
On Thu, 2007-06-28 at 19:19 +0200, Adrian wrote:
Thanks Carlo! Now I've got to remerge again
and retest before committing.
I'll bet he's not even subscribed to the dev list???? :-)
On Thu, 2007-06-28 at 12:33 +0200, Adrian wrote:
> Hopefully, today I'm going to update jboss-head
> to the new deployers, this means the build might be broken
> for a bit.
>
> I'd appreciate it if you don't commit anything around the
> deployers (that includes the ejb containers, etc.)
> so I can do a final merge and standup tests
> before committing.
>
> I'll let you know when the commits are in.
>
> NOTE: I'll be disabling webservices for a couple of days
> since its deployers are in the webservices project
> which I haven't updated to the new deployers yet
> and they'll also require a new release of webservices
> to be updated.
> Apologies for the inconvience. :-(
5:21 a.m.
On Fri, 2007-06-29 at 11:14 +0200, Carlo de Wolf wrote:
You're welcome. :-)
Just out of curiosity, what did you test?
(http://wolf.nerdnet.nl:8180/hudson/job/JBoss_EJB3_TRUNK/13/ )
Just the basic stateless and entity standup tests.
Meow,
Carlo
On Thu, 2007-06-28 at 19:19 +0200, Adrian wrote:
> Thanks Carlo! Now I've got to remerge again
> and retest before committing.
>
> I'll bet he's not even subscribed to the dev list???? :-)
>
> On Thu, 2007-06-28 at 12:33 +0200, Adrian wrote:
> > Hopefully, today I'm going to update jboss-head
> > to the new deployers, this means the build might be broken
> > for a bit.
> >
> > I'd appreciate it if you don't commit anything around the
> > deployers (that includes the ejb containers, etc.)
> > so I can do a final merge and standup tests
> > before committing.
> >
> > I'll let you know when the commits are in.
> >
> > NOTE: I'll be disabling webservices for a couple of days
> > since its deployers are in the webservices project
> > which I haven't updated to the new deployers yet
> > and they'll also require a new release of webservices
> > to be updated.
> > Apologies for the inconvience. :-(
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
6:06 a.m.
Carlo, can you validate that the deployment ordering
shown in the DEBUG message here is correct for EJB3
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=112181&a...
I sort of guessed it from what attachments the deployers were
getting/adding. :-)
On Fri, 2007-06-29 at 12:21 +0200, Adrian wrote:
On Fri, 2007-06-29 at 11:14 +0200, Carlo de Wolf wrote:
> You're welcome. :-)
>
> Just out of curiosity, what did you test?
> (http://wolf.nerdnet.nl:8180/hudson/job/JBoss_EJB3_TRUNK/13/ )
>
Just the basic stateless and entity standup tests.
> Meow,
>
> Carlo
>
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
6:32 a.m.
The logs shows how it's supposed to be. :-)
I'm missing the AppClientParsingDeployer. My guess is it will be run
before the AppClientScanningDeployer (as it is now, but not how it
ultimately should be).
The icky part is the EJBRegistrationDeployer telling the
SecurityDeployer to shut up (EJBRegistrationDeployer@line 167). This is
because we don't have a EjbScanningDeployer yet, so the SecurityDeployer
ignores annotations. Somewhere in the EJB 3 code it creates it's own
Jacc policy and stuff. For now this would mean the SecurityDeployer
should go after EJBRegistrationDeployer for icky reasons.
The output of EJBRegistrationDeployer is Ejb3Deployment +
"org.jboss.deployment.security.ignoreMe" and the input of
SecurityDeployer should be: WebMetaData | ApplicationMetaData |
BeanMetaData + "org.jboss.deployment.security.ignoreMe".
Carlo
On Fri, 2007-06-29 at 13:06 +0200, Adrian wrote:
Carlo, can you validate that the deployment ordering
shown in the DEBUG message here is correct for EJB3
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=112181&a...
I sort of guessed it from what attachments the deployers were
getting/adding. :-)
On Fri, 2007-06-29 at 12:21 +0200, Adrian wrote:
> On Fri, 2007-06-29 at 11:14 +0200, Carlo de Wolf wrote:
> > You're welcome. :-)
> >
> > Just out of curiosity, what did you test?
> > (http://wolf.nerdnet.nl:8180/hudson/job/JBoss_EJB3_TRUNK/13/ )
> >
>
> Just the basic stateless and entity standup tests.
>
> > Meow,
> >
> > Carlo
> >
7:03 a.m.
Ok, can you make those changes?
You need to change the setInputs/Outputs for those deployers.
The deployers have a number of methods for adding
inputs/outputs based on either class names or string names.
http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/depl...
NOTE: There is a difference between setInput and setInputs/addInput.
The first is a requirement, i.e. the attachment must exist
for the deployer to be invoked,
the second only defines the ordering. i.e. they are optional.
Thanks,
Adrian
On Fri, 2007-06-29 at 13:32 +0200, Carlo de Wolf wrote:
The logs shows how it's supposed to be. :-)
I'm missing the AppClientParsingDeployer. My guess is it will be run
before the AppClientScanningDeployer (as it is now, but not how it
ultimately should be).
The icky part is the EJBRegistrationDeployer telling the
SecurityDeployer to shut up (EJBRegistrationDeployer@line 167). This is
because we don't have a EjbScanningDeployer yet, so the SecurityDeployer
ignores annotations. Somewhere in the EJB 3 code it creates it's own
Jacc policy and stuff. For now this would mean the SecurityDeployer
should go after EJBRegistrationDeployer for icky reasons.
The output of EJBRegistrationDeployer is Ejb3Deployment +
"org.jboss.deployment.security.ignoreMe" and the input of
SecurityDeployer should be: WebMetaData | ApplicationMetaData |
BeanMetaData + "org.jboss.deployment.security.ignoreMe".
Carlo
On Fri, 2007-06-29 at 13:06 +0200, Adrian wrote:
> Carlo, can you validate that the deployment ordering
> shown in the DEBUG message here is correct for EJB3
>
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=112181&a...
>
> I sort of guessed it from what attachments the deployers were
> getting/adding. :-)
>
> On Fri, 2007-06-29 at 12:21 +0200, Adrian wrote:
> > On Fri, 2007-06-29 at 11:14 +0200, Carlo de Wolf wrote:
> > > You're welcome. :-)
> > >
> > > Just out of curiosity, what did you test?
> > > (http://wolf.nerdnet.nl:8180/hudson/job/JBoss_EJB3_TRUNK/13/ )
> > >
> >
> > Just the basic stateless and entity standup tests.
> >
> > > Meow,
> > >
> > > Carlo
> > >
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
8:39 a.m.
Done, the order looks pretty good now.
Except maybe the Ejb3ClientDeployer it does run after the
EJBStage2Deployer, but not by design. Hmm, it bypasses the meta data to
look for beans and uses the internal registry. Ah, because it depends on
meta data from other deployment units.
How does this work now with ear deployments? Does an attachment fall all
the way through the deployers first or does each deployer go through
every available attachment first?
Carlo
On Fri, 2007-06-29 at 14:03 +0200, Adrian wrote:
Ok, can you make those changes?
You need to change the setInputs/Outputs for those deployers.
The deployers have a number of methods for adding
inputs/outputs based on either class names or string names.
http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/depl...
NOTE: There is a difference between setInput and setInputs/addInput.
The first is a requirement, i.e. the attachment must exist
for the deployer to be invoked,
the second only defines the ordering. i.e. they are optional.
Thanks,
Adrian
On Fri, 2007-06-29 at 13:32 +0200, Carlo de Wolf wrote:
> The logs shows how it's supposed to be. :-)
>
> I'm missing the AppClientParsingDeployer. My guess is it will be run
> before the AppClientScanningDeployer (as it is now, but not how it
> ultimately should be).
>
> The icky part is the EJBRegistrationDeployer telling the
> SecurityDeployer to shut up (EJBRegistrationDeployer@line 167). This is
> because we don't have a EjbScanningDeployer yet, so the SecurityDeployer
> ignores annotations. Somewhere in the EJB 3 code it creates it's own
> Jacc policy and stuff. For now this would mean the SecurityDeployer
> should go after EJBRegistrationDeployer for icky reasons.
> The output of EJBRegistrationDeployer is Ejb3Deployment +
> "org.jboss.deployment.security.ignoreMe" and the input of
> SecurityDeployer should be: WebMetaData | ApplicationMetaData |
> BeanMetaData + "org.jboss.deployment.security.ignoreMe".
>
> Carlo
>
> On Fri, 2007-06-29 at 13:06 +0200, Adrian wrote:
> > Carlo, can you validate that the deployment ordering
> > shown in the DEBUG message here is correct for EJB3
> >
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=112181&a...
> >
> > I sort of guessed it from what attachments the deployers were
> > getting/adding. :-)
> >
> > On Fri, 2007-06-29 at 12:21 +0200, Adrian wrote:
> > > On Fri, 2007-06-29 at 11:14 +0200, Carlo de Wolf wrote:
> > > > You're welcome. :-)
> > > >
> > > > Just out of curiosity, what did you test?
> > > > (http://wolf.nerdnet.nl:8180/hudson/job/JBoss_EJB3_TRUNK/13/ )
> > > >
> > >
> > > Just the basic stateless and entity standup tests.
> > >
> > > > Meow,
> > > >
> > > > Carlo
> > > >
> >
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
9:50 a.m.
On Fri, 2007-06-29 at 15:39 +0200, Carlo de Wolf wrote:
Done, the order looks pretty good now.
Thanks.
Except maybe the Ejb3ClientDeployer it does run after the
EJBStage2Deployer, but not by design. Hmm, it bypasses the meta data to
look for beans and uses the internal registry. Ah, because it depends on
meta data from other deployment units.
How does this work now with ear deployments? Does an attachment fall all
the way through the deployers first or does each deployer go through
every available attachment first?
If I understand your question correctly.
It is width first at the deployment stage level
i.e. all classloaders get constructed before it moves onto
the aop/real deployer stages.
But depth first within a stage. i.e. all deployers for that stage
are run per context then it moves onto the next context.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
1:17 p.m.
New subject: Ready to go Re: WARNING: Update to new deployers
All the changes are in now.
Or at least I think they are??
The eclipse svn support is so flakey, I can't be sure.
It didn't help that my internet connection crashed half way
through the commit, eclipse still thinks there are changes
to commit even though an svn diff clearly shows the files
are the same????
Talk about a bad day. :-)
On Thu, 2007-06-28 at 12:33 +0200, Adrian wrote:
Hopefully, today I'm going to update jboss-head
to the new deployers, this means the build might be broken
for a bit.
I'd appreciate it if you don't commit anything around the
deployers (that includes the ejb containers, etc.)
so I can do a final merge and standup tests
before committing.
I'll let you know when the commits are in.
NOTE: I'll be disabling webservices for a couple of days
since its deployers are in the webservices project
which I haven't updated to the new deployers yet
and they'll also require a new release of webservices
to be updated.
Apologies for the inconvience. :-(
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
2:26 p.m.
New subject: Ready to go Re: WARNING: Update to new deployers
Cool. Looking forward to the writeup on the changes.
Adrian wrote:
All the changes are in now.
Or at least I think they are??
The eclipse svn support is so flakey, I can't be sure.
It didn't help that my internet connection crashed half way
through the commit, eclipse still thinks there are changes
to commit even though an svn diff clearly shows the files
are the same????
Talk about a bad day. :-)
On Thu, 2007-06-28 at 12:33 +0200, Adrian wrote:
> Hopefully, today I'm going to update jboss-head
> to the new deployers, this means the build might be broken
> for a bit.
>
> I'd appreciate it if you don't commit anything around the
> deployers (that includes the ejb containers, etc.)
> so I can do a final merge and standup tests
> before committing.
>
> I'll let you know when the commits are in.
>
> NOTE: I'll be disabling webservices for a couple of days
> since its deployers are in the webservices project
> which I haven't updated to the new deployers yet
> and they'll also require a new release of webservices
> to be updated.
> Apologies for the inconvience. :-(
--
Bill Burke
JBoss, a division of Red Hat Inc.
3:15 p.m.
New subject: @JMX beans fail to deploy WAS: Ready to go Re: WARNING: Update to new deployers
Updated my trunk copy and now any bean annotated with @JMX fails to deploy:
2007-06-28 14:29:20,561 ERROR
[org.jboss.kernel.plugins.dependency.AbstractKernelController] Error
installing to Configured: name=JRMPInvokerHA state=Configured
java.lang.Exception: Error calling callback JMXAdvice for target context
JRMPInvokerHA
at
org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:86)
at
org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1191)
at
org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1172)
at
org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:694)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:813)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:735)
at
org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:525)
at
org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:361)
at
org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:69)
at
org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:42)
at
org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.deploy(AbstractSimpleRealDeployer.java:65)
at
org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:164)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.doInstall(DeployersImpl.java:657)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.doInstall(DeployersImpl.java:672)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.doInstall(DeployersImpl.java:623)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:587)
at
org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:304)
at
org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1257)
at
org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:685)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:813)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:735)
at
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:573)
at
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:374)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:426)
at
org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:340)
at
org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:379)
at
org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:247)
at
org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
at
org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
at
org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
at org.jboss.Main.boot(Main.java:210)
at org.jboss.Main$1.run(Main.java:523)
at java.lang.Thread.run(Thread.java:595)
Caused by: org.jboss.joinpoint.spi.JoinpointException: Method not found
install[org.jboss.dependency.spi.ControllerContext] for class
org.jboss.aop.microcontainer.aspects.jmx.JMXIntroduction
at org.jboss.joinpoint.plugins.Config.findMethodInfo(Config.java:396)
at org.jboss.joinpoint.plugins.Config.findMethodInfo(Config.java:365)
at org.jboss.joinpoint.plugins.Config.findMethodInfo(Config.java:334)
at org.jboss.joinpoint.plugins.Config.getMethodJoinpoint(Config.java:222)
at
org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:254)
at
org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:268)
at
org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:82)
... 32 more
Adrian wrote:
All the changes are in now.
Or at least I think they are??
The eclipse svn support is so flakey, I can't be sure.
It didn't help that my internet connection crashed half way
through the commit, eclipse still thinks there are changes
to commit even though an svn diff clearly shows the files
are the same????
Talk about a bad day. :-)
On Thu, 2007-06-28 at 12:33 +0200, Adrian wrote:
> Hopefully, today I'm going to update jboss-head
> to the new deployers, this means the build might be broken
> for a bit.
>
> I'd appreciate it if you don't commit anything around the
> deployers (that includes the ejb containers, etc.)
> so I can do a final merge and standup tests
> before committing.
>
> I'll let you know when the commits are in.
>
> NOTE: I'll be disabling webservices for a couple of days
> since its deployers are in the webservices project
> which I haven't updated to the new deployers yet
> and they'll also require a new release of webservices
> to be updated.
> Apologies for the inconvience. :-(
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
5:14 a.m.
New subject: @JMX beans fail to deploy WAS: Ready to go Re: WARNING: Update to new deployers
I'm checking out head on a slow connection, but basically the JMXAdvice
should be updated to be
org.jboss.aop.microcontainer.aspects.jmx.JMXLifecycleCallback.
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=105380
Brian Stansberry wrote:
Updated my trunk copy and now any bean annotated with @JMX fails to
deploy:
2007-06-28 14:29:20,561 ERROR
[org.jboss.kernel.plugins.dependency.AbstractKernelController] Error
installing to Configured: name=JRMPInvokerHA state=Configured
java.lang.Exception: Error calling callback JMXAdvice for target context
JRMPInvokerHA
at
org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:86)
at
org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1191)
at
org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1172)
at
org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:694)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:813)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:735)
at
org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:525)
at
org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:361)
at
org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:69)
at
org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:42)
at
org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.deploy(AbstractSimpleRealDeployer.java:65)
at
org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:164)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.doInstall(DeployersImpl.java:657)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.doInstall(DeployersImpl.java:672)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.doInstall(DeployersImpl.java:623)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:587)
at
org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:304)
at
org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1257)
at
org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:685)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:813)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:735)
at
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:573)
at
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:374)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:426)
at
org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:340)
at
org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:379)
at
org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:247)
at
org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
at
org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
at
org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
at org.jboss.Main.boot(Main.java:210)
at org.jboss.Main$1.run(Main.java:523)
at java.lang.Thread.run(Thread.java:595)
Caused by: org.jboss.joinpoint.spi.JoinpointException: Method not found
install[org.jboss.dependency.spi.ControllerContext] for class
org.jboss.aop.microcontainer.aspects.jmx.JMXIntroduction
at org.jboss.joinpoint.plugins.Config.findMethodInfo(Config.java:396)
at org.jboss.joinpoint.plugins.Config.findMethodInfo(Config.java:365)
at org.jboss.joinpoint.plugins.Config.findMethodInfo(Config.java:334)
at
org.jboss.joinpoint.plugins.Config.getMethodJoinpoint(Config.java:222)
at
org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:254)
at
org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:268)
at
org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:82)
... 32 more
Adrian wrote:
> All the changes are in now.
>
> Or at least I think they are??
> The eclipse svn support is so flakey, I can't be sure.
>
> It didn't help that my internet connection crashed half way
> through the commit, eclipse still thinks there are changes
> to commit even though an svn diff clearly shows the files
> are the same????
>
> Talk about a bad day. :-)
>
> On Thu, 2007-06-28 at 12:33 +0200, Adrian wrote:
>> Hopefully, today I'm going to update jboss-head
>> to the new deployers, this means the build might be broken
>> for a bit.
>>
>> I'd appreciate it if you don't commit anything around the
>> deployers (that includes the ejb containers, etc.)
>> so I can do a final merge and standup tests
>> before committing.
>>
>> I'll let you know when the commits are in.
>>
>> NOTE: I'll be disabling webservices for a couple of days
>> since its deployers are in the webservices project
>> which I haven't updated to the new deployers yet
>> and they'll also require a new release of webservices
>> to be updated.
>> Apologies for the inconvience. :-(
--
Kabir Khan
JBoss AOP Lead
JBoss, a division of Red Hat
6:54 a.m.
New subject: @JMX beans fail to deploy WAS: Ready to go Re: [jboss-dev] WARNING: Update to new deployers
The aop snapshot has been updated now, server starts and I can see your
beans in the JMX console
Kabir Khan wrote:
I'm checking out head on a slow connection, but basically the
JMXAdvice
should be updated to be
org.jboss.aop.microcontainer.aspects.jmx.JMXLifecycleCallback.
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=105380
Brian Stansberry wrote:
> Updated my trunk copy and now any bean annotated with @JMX fails to
> deploy:
>
> 2007-06-28 14:29:20,561 ERROR
> [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error
> installing to Configured: name=JRMPInvokerHA state=Configured
> java.lang.Exception: Error calling callback JMXAdvice for target
> context JRMPInvokerHA
> at
>
org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:86)
>
> at
>
org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1191)
>
> at
>
org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1172)
>
> at
>
org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:694)
>
> at
>
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:813)
>
> at
>
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:735)
>
> at
> org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:525)
>
> at
> org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:361)
>
> at
>
org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:69)
>
> at
>
org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:42)
>
> at
>
org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.deploy(AbstractSimpleRealDeployer.java:65)
>
> at
>
org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:164)
>
> at
> org.jboss.deployers.plugins.deployers.DeployersImpl.doInstall(DeployersImpl.java:657)
>
> at
> org.jboss.deployers.plugins.deployers.DeployersImpl.doInstall(DeployersImpl.java:672)
>
> at
> org.jboss.deployers.plugins.deployers.DeployersImpl.doInstall(DeployersImpl.java:623)
>
> at
> org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:587)
>
> at
>
org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:304)
>
> at
> org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1257)
>
> at
>
org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:685)
>
> at
>
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:813)
>
> at
>
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:735)
>
> at
> org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:573)
>
> at
> org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:374)
>
> at
> org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:426)
>
> at
> org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:340)
>
> at
>
org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:379)
>
> at
>
org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:247)
>
> at
> org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
>
> at
> org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
>
> at
> org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
>
> at org.jboss.Main.boot(Main.java:210)
> at org.jboss.Main$1.run(Main.java:523)
> at java.lang.Thread.run(Thread.java:595)
> Caused by: org.jboss.joinpoint.spi.JoinpointException: Method not
> found install[org.jboss.dependency.spi.ControllerContext] for class
> org.jboss.aop.microcontainer.aspects.jmx.JMXIntroduction
> at org.jboss.joinpoint.plugins.Config.findMethodInfo(Config.java:396)
> at org.jboss.joinpoint.plugins.Config.findMethodInfo(Config.java:365)
> at org.jboss.joinpoint.plugins.Config.findMethodInfo(Config.java:334)
> at
> org.jboss.joinpoint.plugins.Config.getMethodJoinpoint(Config.java:222)
> at
> org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:254)
>
> at
>
org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:268)
>
> at
>
org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:82)
>
> ... 32 more
>
> Adrian wrote:
>> All the changes are in now.
>>
>> Or at least I think they are??
>> The eclipse svn support is so flakey, I can't be sure.
>>
>> It didn't help that my internet connection crashed half way
>> through the commit, eclipse still thinks there are changes
>> to commit even though an svn diff clearly shows the files
>> are the same????
>>
>> Talk about a bad day. :-)
>>
>> On Thu, 2007-06-28 at 12:33 +0200, Adrian wrote:
>>> Hopefully, today I'm going to update jboss-head
>>> to the new deployers, this means the build might be broken
>>> for a bit.
>>>
>>> I'd appreciate it if you don't commit anything around the
>>> deployers (that includes the ejb containers, etc.)
>>> so I can do a final merge and standup tests
>>> before committing.
>>>
>>> I'll let you know when the commits are in.
>>>
>>> NOTE: I'll be disabling webservices for a couple of days
>>> since its deployers are in the webservices project
>>> which I haven't updated to the new deployers yet
>>> and they'll also require a new release of webservices
>>> to be updated.
>>> Apologies for the inconvience. :-(
>
>
--
Kabir Khan
JBoss AOP Lead
JBoss, a division of Red Hat
5:49 a.m.
New subject: @JMX beans fail to deploy WAS: Ready to go Re: WARNING: Update to new deployers
Yep, sorry. I saw this also in the connectors,
I just commented out the annotation I need to find out what
the problem is here, its in some new code in the MC.
But I wanted to get code in before somebody else
made me have to do yet another merge. :-)
On Thu, 2007-06-28 at 15:15 -0500, Brian Stansberry wrote:
Updated my trunk copy and now any bean annotated with @JMX fails to
deploy:
2007-06-28 14:29:20,561 ERROR
[org.jboss.kernel.plugins.dependency.AbstractKernelController] Error
installing to Configured: name=JRMPInvokerHA state=Configured
java.lang.Exception: Error calling callback JMXAdvice for target context
JRMPInvokerHA
at
org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:86)
at
org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1191)
at
org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1172)
at
org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:694)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:813)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:735)
at
org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:525)
at
org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:361)
at
org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:69)
at
org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:42)
at
org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.deploy(AbstractSimpleRealDeployer.java:65)
at
org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:164)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.doInstall(DeployersImpl.java:657)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.doInstall(DeployersImpl.java:672)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.doInstall(DeployersImpl.java:623)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:587)
at
org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:304)
at
org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1257)
at
org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:685)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:813)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:735)
at
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:573)
at
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:374)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:426)
at
org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:340)
at
org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:379)
at
org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:247)
at
org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
at
org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
at
org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
at org.jboss.Main.boot(Main.java:210)
at org.jboss.Main$1.run(Main.java:523)
at java.lang.Thread.run(Thread.java:595)
Caused by: org.jboss.joinpoint.spi.JoinpointException: Method not found
install[org.jboss.dependency.spi.ControllerContext] for class
org.jboss.aop.microcontainer.aspects.jmx.JMXIntroduction
at org.jboss.joinpoint.plugins.Config.findMethodInfo(Config.java:396)
at org.jboss.joinpoint.plugins.Config.findMethodInfo(Config.java:365)
at org.jboss.joinpoint.plugins.Config.findMethodInfo(Config.java:334)
at org.jboss.joinpoint.plugins.Config.getMethodJoinpoint(Config.java:222)
at
org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:254)
at
org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:268)
at
org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:82)
... 32 more
Adrian wrote:
> All the changes are in now.
>
> Or at least I think they are??
> The eclipse svn support is so flakey, I can't be sure.
>
> It didn't help that my internet connection crashed half way
> through the commit, eclipse still thinks there are changes
> to commit even though an svn diff clearly shows the files
> are the same????
>
> Talk about a bad day. :-)
>
> On Thu, 2007-06-28 at 12:33 +0200, Adrian wrote:
>> Hopefully, today I'm going to update jboss-head
>> to the new deployers, this means the build might be broken
>> for a bit.
>>
>> I'd appreciate it if you don't commit anything around the
>> deployers (that includes the ejb containers, etc.)
>> so I can do a final merge and standup tests
>> before committing.
>>
>> I'll let you know when the commits are in.
>>
>> NOTE: I'll be disabling webservices for a couple of days
>> since its deployers are in the webservices project
>> which I haven't updated to the new deployers yet
>> and they'll also require a new release of webservices
>> to be updated.
>> Apologies for the inconvience. :-(
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
9:57 a.m.
New subject: @JMX beans fail to deploy WAS: Ready to go Re: [jboss-dev] WARNING: Update to new deployers
No worries. Been going through tedious testsuite fixes all week; this
gave me a badly needed excuse to go do something else. :-)
Kabir, with your changes my build looks good. Thanks for sorting it so
quickly. Well, maybe no thanks -- now I've gotta go back to sorting
testsuite failures. ;)
Adrian wrote:
Yep, sorry. I saw this also in the connectors,
I just commented out the annotation I need to find out what
the problem is here, its in some new code in the MC.
But I wanted to get code in before somebody else
made me have to do yet another merge. :-)
On Thu, 2007-06-28 at 15:15 -0500, Brian Stansberry wrote:
> Updated my trunk copy and now any bean annotated with @JMX fails to deploy:
>
> 2007-06-28 14:29:20,561 ERROR
> [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error
> installing to Configured: name=JRMPInvokerHA state=Configured
> java.lang.Exception: Error calling callback JMXAdvice for target context
> JRMPInvokerHA
> at
>
org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:86)
> at
>
org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1191)
> at
>
org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1172)
> at
>
org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:694)
> at
>
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:813)
> at
>
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:735)
> at
> org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:525)
> at
> org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:361)
> at
>
org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:69)
> at
>
org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:42)
> at
>
org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.deploy(AbstractSimpleRealDeployer.java:65)
> at
>
org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:164)
> at
>
org.jboss.deployers.plugins.deployers.DeployersImpl.doInstall(DeployersImpl.java:657)
> at
>
org.jboss.deployers.plugins.deployers.DeployersImpl.doInstall(DeployersImpl.java:672)
> at
>
org.jboss.deployers.plugins.deployers.DeployersImpl.doInstall(DeployersImpl.java:623)
> at
> org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:587)
> at
>
org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:304)
> at
>
org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1257)
> at
>
org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:685)
> at
>
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:813)
> at
>
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:735)
> at
> org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:573)
> at
> org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:374)
> at
> org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:426)
> at
> org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:340)
> at
>
org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:379)
> at
>
org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:247)
> at
> org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
> at
> org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
> at
> org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
> at org.jboss.Main.boot(Main.java:210)
> at org.jboss.Main$1.run(Main.java:523)
> at java.lang.Thread.run(Thread.java:595)
> Caused by: org.jboss.joinpoint.spi.JoinpointException: Method not found
> install[org.jboss.dependency.spi.ControllerContext] for class
> org.jboss.aop.microcontainer.aspects.jmx.JMXIntroduction
> at org.jboss.joinpoint.plugins.Config.findMethodInfo(Config.java:396)
> at org.jboss.joinpoint.plugins.Config.findMethodInfo(Config.java:365)
> at org.jboss.joinpoint.plugins.Config.findMethodInfo(Config.java:334)
> at org.jboss.joinpoint.plugins.Config.getMethodJoinpoint(Config.java:222)
> at
> org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:254)
> at
>
org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:268)
> at
>
org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:82)
> ... 32 more
>
> Adrian wrote:
>> All the changes are in now.
>>
>> Or at least I think they are??
>> The eclipse svn support is so flakey, I can't be sure.
>>
>> It didn't help that my internet connection crashed half way
>> through the commit, eclipse still thinks there are changes
>> to commit even though an svn diff clearly shows the files
>> are the same????
>>
>> Talk about a bad day. :-)
>>
>> On Thu, 2007-06-28 at 12:33 +0200, Adrian wrote:
>>> Hopefully, today I'm going to update jboss-head
>>> to the new deployers, this means the build might be broken
>>> for a bit.
>>>
>>> I'd appreciate it if you don't commit anything around the
>>> deployers (that includes the ejb containers, etc.)
>>> so I can do a final merge and standup tests
>>> before committing.
>>>
>>> I'll let you know when the commits are in.
>>>
>>> NOTE: I'll be disabling webservices for a couple of days
>>> since its deployers are in the webservices project
>>> which I haven't updated to the new deployers yet
>>> and they'll also require a new release of webservices
>>> to be updated.
>>> Apologies for the inconvience. :-(
>
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
6155
days inactive
6156
days old
jboss-development@lists.jboss.org
15 comments
5 participants
participants (5)
-
Adrian -
Bill Burke -
Brian Stansberry -
Carlo de Wolf -
Kabir Khan