I've got it. Try this:
public interface LifeCycle
| {
| public void create() throws Exception;
| public void start() throws Exception;
|
| public void destroy();
| public void stop();
| }
@Management(LifeCycle.class)
| @Service(objectName = myorg:service=MBeanB)
Agreed. What do we do with it now? Should I raise a JIRA? Or do you?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4182907#4182907
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4182907
On the other hand, come to think of it, the requirement to call the life cycle
methods at the right time is strictly EJB3.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4182911#4182911
Reply to the post :
Raised https://jira.jboss.org/jira/browse/EJBTHREE-1530
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4182922#4182922
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4182922
___
I added 'Starting' logs to my MBeans and got:
2008/10/16 09:35:43.366 INFO (main)
[com.myorg.rac.server.bwallocator.BWAllocatorAdminMBean.start:50] Starting
BWAllocatorAdminMBean
|
| 2008/10/16 09:35:45.661 ERROR (main)
[org.jboss.logging.util.LoggerStream.write:156]
I've attached a debugger to the server and placed a break-point in
BWAllocatorAdminMBean.start. Here's the stack trace in the main thread:
[EMAIL PROTECTED], priority=5, in group 'jboss', status: 'RUNNING'
| at
The thirdparty directory seems to cover a lot of (only?) non-jboss stuff. For
example, AbstractController.java is not under the 5.0 source directory
anywhere, and it seems to be an important player here. I found a copy of it
under viewvc, but it's obviously a different version as the line
Look closely at the chain of calls between the lower installMBean and the
resolveContexts calls. Further down inside the install call from installMBean
the code eventually transitions the state of StatisticsMBean to created, then
started, then installed, constantly calling
Here are the various classes involved, pruned down to the relevant bits. Let
me know if I've done too much pruning.
// MBeanB in the initial post
| @Management(StatisticsAdmin.class)
| @Service(objectName = com.alcatel.tpapps.common:service=StatisticsAdmin)
| @RemoteBinding(jndiBinding =
I should probably add that to get this far, I had to download, build and apply
the 1.0.0-Beta4 release of the EJB3 module.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4182236#4182236
Reply to the post :
I'm having difficulty with MBean start ordering in AS 5.0CR2. I've got two
MBeans: MBeanA with an @Depends annotation referencing the other, plus an
injected (@Resource) reference to it. In the start method of MBeanB I
initialize a POJO singleton. When MBeanA's start method is called, it
OK, thanks. I'm trying to make progress migrating to AS 5.0, but have been
stopped by the 'Call setBeanContext, not setTarget' bug [EJBTHREE-1430]. I was
hoping to patch that part to get things going again. The plugin thing sounds a
little convoluted for just getting a couple jars... I
After playing around with a couple xml files, then restoring them both, I'm no
longer able to reproduce this. In my playing around I also moved stuff out and
back into the deploy directory, but all that, too, was restored.
Not sure whether directory order might affect the outcome, but I tried
I see the release notes for it, but can't find anywhere to download it.
Or are the release notes just a work-in-progress page?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4180882#4180882
Reply to the post :
I'm having trouble getting my singletons to work after migrating to 5.0 (from
4.2.1).
I have the prescribed
@Depends(jboss.ha:service=HASingletonDeploy,type=Barrier) on my beans (MDB,
Mgmt, doesn't matter) but at startup I get:
*** CONTEXTS MISSING DEPENDENCIES: Name - Dependency{Required
Thanks for the reply.
What about keeping everything outside of an ear: par's, sar's, etc? Should the
services then be able, somehow, to reference a persistence unit deployed
directly in the deploy directory? I've given this a quick try and couldn't get
it to work, but perhaps there's
Excellent. Thanks for your help.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4180325#4180325
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4180325
___
jboss-user mailing list
The code in
DefaultPersistenceUnitDependencyResolver.resolvePersistenceUnitSupplier seems
to fairly deliberately search only within the context of an application.
So is this intended behaviour? (I.e. that services within an ear may only
reference persistence units that are also contained in
I've got similar issues with the CR load. Many ears using the same persistent
units, so the PUs are in separate jars. It is unable to find the PU.
If I throw the pars into one of the ears, and only deploy that ear, all is well.
This worked fine under JBoss 4.
View the original post :
I realize this thread is over a year old, but for others who find their way
here experiencing similar problems...
I was adding JBM 1.4.0 to AS4.2.1 and had similar problems. My configuration
was correct (createJBossMQDestination was false, and my JNDI names were
correct).
The issue seems to
I get this error as well with AS4.2.1 and WS2.0.3, as well as with AS4.2.3. I
get it on 3 out of 8 web services. All 8 are simple JSR-181 web services and
SLSBs - the 3 that fail have @Depends annotations, that being the only
commonality I can find. One of the 3 failing ones doesn't even
First of all, thanks alot for the prompt replies!
And in response to:
1) Thanks, I'll make sure I do that.
2) The jboss-service.xml is just a stub (empty server tag), as we rely
exclusively on annotations. Here are the annotations, though:
@Management(DatabaseManager.class)
|
Forgot to mention...
I'm using 4.0.4.GA, with EJB3.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3984905#3984905
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3984905
___
I copied the object name from the log output :
I just tried packaging in a sar but I get the same result.
I have actually been playing with a barrier mbean as well to find a work-around
for this issue. What I did is move all of my par's, dependent ear's, and the
datasource definition into a
I don't know what happeend to my property definition in that post. I checked
the 'Disable HTML in this post' box... did I misunderstand the meaning of that?
Anyway, here it is, minus the angle-brackets just to be safe:
property name=jboss.depends.1
While we're on barriers, the documentation seems to suggest that a singleton
barrier mbean will have it's 'create' method called at system startup,
deferring the 'start' method call until the node becomes the master.
I'm not seeing my create method get called until the node becomes master
26 matches
Mail list logo