RE: [JBoss-dev] Build broken?
by Ruel Loehr
I don't see any problems in a fresh checkout and cruisecontrol looks ok. Jean Fredric, if you are still having problems contact me directly and I will assist you.
Ruel Loehr
JBoss QA
-----------------------------
512-342-7840 ext 2011
Yahoo: ruelloehr
Skype: ruelloehr
AOL: dokoruel
-----Original Message-----
From: jboss-development-bounces(a)lists.jboss.org [mailto:jboss-development-bounces@lists.jboss.org] On Behalf Of Adrian Brock
Sent: Wednesday, August 23, 2006 10:26 AM
To: jboss-development
Cc: Jean-Frédéric Clere
Subject: [JBoss-dev] Build broken?
Jean Fredric just showed me where the latest build
is trying to download repository jars into the wrong place.
e.g. He has libs getting downloaded into
~/thirdparty
when it should be
~/jbossas/thirdparty
I haven't tried it myself, but I think is probably due to Ruel's change
last Friday WRT to the / and - handling in path names.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.11.5/425 - Release Date: 8/22/2006
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.11.5/425 - Release Date: 8/22/2006
20 years
RE: [JBoss-dev] AbstractKernelController behavior inconsistent
by Anil Saldhana
Sorry. I can make ServiceProxy transient myself. I thought it was in
the mc code.
I will make the fix and check the updated testcase.
-----Original Message-----
From: Anil Saldhana
Sent: Wednesday, August 23, 2006 12:16 PM
To: 'JBoss.org development list'
Subject: RE: [JBoss-dev] AbstractKernelController behavior inconsistent
I can check in the updated test case once the ServiceProxy is made
transient. Can you make the fix?
-----Original Message-----
From: jboss-development-bounces(a)lists.jboss.org
[mailto:jboss-development-bounces@lists.jboss.org] On Behalf Of Adrian
Brock
Sent: Wednesday, August 23, 2006 11:40 AM
To: JBoss.org development list
Subject: RE: [JBoss-dev] AbstractKernelController behavior inconsistent
On Wed, 2006-08-23 at 11:14 -0500, Anil Saldhana wrote:
> Should ServiceProxy be serializable?
>
No, the old one wasn't either, since it holds a link to the
MBeanServer (via the ServiceController)
not an MBeanServerConnection (remote version).
The ServiceContext should be, so the ServiceProxy
inside it should be transient. i.e. not part of the
serialized form.
But this looks like a bug that has been there forever.
>
>
> Caused by: java.io.NotSerializableException:
> org.jboss.system.microcontainer.ServiceProxy
>
> at
> java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075)
>
> at
>
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:13
69)
>
> at
>
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1341)
>
>
>
> for:
>
> ServiceControllerMBean scmb = (ServiceControllerMBean)
>
> MBeanServerInvocationHandler.newProxyInstance(server,
> ServiceControllerMBean.OBJECT_NAME,
>
> ServiceControllerMBean.class, false);
>
>
>
> and also for:
>
> ServiceContext sc = (ServiceContext)server.invoke(so,
> "getServiceContext",new Object[]{serviceOName},
>
> new String[]{"javax.management.ObjectName"});
>
>
>
> Why cannot ServiceContext be an attribute on the
> ServiceControllerMBean(feature request?)
>
How can it be an attribute, it takes a parameter?
>
>
>
>
> Basically, when the ServiceController has entered the Error state for
> a service, then I get the state of the service (after
> unregister->create->start) is the state "REGISTERED" (instead of
> Started)
>
I don't understand this? You cannot transistion from
unregistered to create. Once it is unregistered it doesn't exist.
Provide a complete example so we don't have to guess what you
talking about.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
20 years
RE: [JBoss-dev] AbstractKernelController behavior inconsistent
by Anil Saldhana
I can check in the updated test case once the ServiceProxy is made
transient. Can you make the fix?
-----Original Message-----
From: jboss-development-bounces(a)lists.jboss.org
[mailto:jboss-development-bounces@lists.jboss.org] On Behalf Of Adrian
Brock
Sent: Wednesday, August 23, 2006 11:40 AM
To: JBoss.org development list
Subject: RE: [JBoss-dev] AbstractKernelController behavior inconsistent
On Wed, 2006-08-23 at 11:14 -0500, Anil Saldhana wrote:
> Should ServiceProxy be serializable?
>
No, the old one wasn't either, since it holds a link to the
MBeanServer (via the ServiceController)
not an MBeanServerConnection (remote version).
The ServiceContext should be, so the ServiceProxy
inside it should be transient. i.e. not part of the
serialized form.
But this looks like a bug that has been there forever.
>
>
> Caused by: java.io.NotSerializableException:
> org.jboss.system.microcontainer.ServiceProxy
>
> at
> java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075)
>
> at
>
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:13
69)
>
> at
>
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1341)
>
>
>
> for:
>
> ServiceControllerMBean scmb = (ServiceControllerMBean)
>
> MBeanServerInvocationHandler.newProxyInstance(server,
> ServiceControllerMBean.OBJECT_NAME,
>
> ServiceControllerMBean.class, false);
>
>
>
> and also for:
>
> ServiceContext sc = (ServiceContext)server.invoke(so,
> "getServiceContext",new Object[]{serviceOName},
>
> new String[]{"javax.management.ObjectName"});
>
>
>
> Why cannot ServiceContext be an attribute on the
> ServiceControllerMBean(feature request?)
>
How can it be an attribute, it takes a parameter?
>
>
>
>
> Basically, when the ServiceController has entered the Error state for
> a service, then I get the state of the service (after
> unregister->create->start) is the state "REGISTERED" (instead of
> Started)
>
I don't understand this? You cannot transistion from
unregistered to create. Once it is unregistered it doesn't exist.
Provide a complete example so we don't have to guess what you
talking about.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
20 years
jbossas confused when additing user-service.xml
by Jean-frederic Clere
Hi,
I have tried a "weird" thing: copy my jar file and create the
user-service.xml while jbossas is running, that result the following
exception:
++++
18:06:26,668 INFO [Server] JBoss (MX MicroKernel) [5.0.0.Beta (build:
CVSTag=HEAD date=200608231729)] Started in 17s:960ms
18:30:44,639 ERROR [AbstractKernelController] Error installing to
Instantiated: name=test:name=0 state=Described mode=Manual
requiredState=Configured
org.jboss.deployment.DeploymentException: Unable to createMBean for
test:name=0; - nested throwable: (java.lang.ClassNotFoundException: No
ClassLoaders found for: org.jboss.jmx.httpd.MBean)
at
org.jboss.deployment.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:53)
at org.jboss.system.ServiceCreator.install(ServiceCreator.java:141)
at
org.jboss.system.microcontainer.InstantiateAction.installAction(InstantiateAction.java:45)
at
org.jboss.system.microcontainer.ServiceControllerContextAction.install(ServiceControllerContextAction.java:46)
at
org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
at
org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:226)
at
org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:198)
at
org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:709)
at
org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:429)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:538)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:472)
at
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:320)
at
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:190)
at
org.jboss.system.ServiceController.doChange(ServiceController.java:632)
at
org.jboss.system.ServiceController.install(ServiceController.java:250)
at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at
org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.install(Unknown Source)
at org.jboss.deployment.SARDeployer.create(SARDeployer.java:249)
at org.jboss.deployment.MainDeployer.create(MainDeployer.java:962)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:811)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:775)
at sun.reflect.GeneratedMethodAccessor18.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
at
org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
at
org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
at
org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy8.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
at
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:274)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:225)
Caused by: java.lang.ClassNotFoundException: No ClassLoaders found for:
org.jboss.jmx.httpd.MBean
at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:212)
at
org.jboss.mx.loading.UnifiedClassLoader.loadClassImpl(UnifiedClassLoader.java:275)
at
org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:406)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at
org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:1213)
at
org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:286)
at
org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:344)
at
org.jboss.system.ServiceCreator.installPlainMBean(ServiceCreator.java:197)
at org.jboss.system.ServiceCreator.install(ServiceCreator.java:115)
... 45 more
18:30:44,949 ERROR [URLDeploymentScanner] Incomplete Deployment listing:
--- MBeans waiting for other MBeans ---
ObjectName: test:name=0
State: FAILED
Reason: org.jboss.deployment.DeploymentException: Unable to
createMBean for test:name=0; - nested throwable:
(java.lang.ClassNotFoundException: No ClassLoaders found for:
org.jboss.jmx.httpd.MBean)
+++
Any way to tell jbossas to look for new jar files?
Cheers
Jean-Frederic
20 years
RE: [JBoss-dev] AbstractKernelController behavior inconsistent
by Anil Saldhana
Should ServiceProxy be serializable?
Caused by: java.io.NotSerializableException:
org.jboss.system.microcontainer.ServiceProxy
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:13
69)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1341)
for:
ServiceControllerMBean scmb = (ServiceControllerMBean)
MBeanServerInvocationHandler.newProxyInstance(server,
ServiceControllerMBean.OBJECT_NAME,
ServiceControllerMBean.class, false);
and also for:
ServiceContext sc = (ServiceContext)server.invoke(so,
"getServiceContext", new Object[]{serviceOName},
new String[]{"javax.management.ObjectName"});
Why cannot ServiceContext be an attribute on the
ServiceControllerMBean(feature request?)
Basically, when the ServiceController has entered the Error state for a
service, then I get the state of the service (after
unregister->create->start) is the state "REGISTERED" (instead of
Started)
________________________________
From: jboss-development-bounces(a)lists.jboss.org
[mailto:jboss-development-bounces@lists.jboss.org] On Behalf Of Scott M
Stark
Sent: Wednesday, August 23, 2006 8:32 AM
To: JBoss.org development list
Subject: Re: [JBoss-dev] AbstractKernelController behavior inconsistent
The question is which constructs should be working and which should not.
I have added a testErrorInContainedStartRedeployAfterError to the
org.jboss.test.system.controller.lifecycle.test.LifecycleRedeployAfterEr
rorTest on the MC_VDF_WORK branch, and although this does not show a
problem with being able to redeploy a failed deployment, it does show
that the errors from the lifecycle methods are not being propagated back
to the caller. From the test logging, the ContainedMBeanService is
throwing an error because it did not see the expected error from the
contained SimpleMBean start:
1720 ERROR [AbstractKernelController] Error installing to Start:
name=jboss.test:type=test state=Create mode=Manual
requiredState=Installed
java.lang.Error: Did not see expected ERRORINSTART from:
jboss.test:contained=SimpleMBean,type=test
at
org.jboss.test.system.controller.support.ContainedMBeanService.startServ
ice(ContainedMBeanService.java:87)
at
org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupp
ort.java:289)
at
org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBean
Support.java:245)
at
jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Lja
va.lang.Object;)Ljava.lang.Object;(Unknown Source)
at
java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;J)L
java.lang.Object;(Unknown Source)
at
org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.
java:157)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at
org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.jav
a:264)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at
org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:16
7)
at $Proxy0.start()V(Unknown Source)
at
org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(S
tartStopLifecycleAction.java:42)
at
org.jboss.system.microcontainer.ServiceControllerContextAction.install(S
erviceControllerContextAction.java:46)
at
org.jboss.dependency.plugins.AbstractControllerContextActions.install(Ab
stractControllerContextActions.java:51)
at
org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractC
ontrollerContext.java:226)
at
org.jboss.system.microcontainer.ServiceControllerContext.install(Service
ControllerContext.java:198)
at
org.jboss.dependency.plugins.AbstractController.install(AbstractControll
er.java:596)
at
org.jboss.dependency.plugins.AbstractController.incrementState(AbstractC
ontroller.java:346)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(Abstract
Controller.java:438)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(Abstract
Controller.java:379)
at
org.jboss.dependency.plugins.AbstractController.change(AbstractControlle
r.java:263)
at
org.jboss.dependency.plugins.AbstractController.change(AbstractControlle
r.java:164)
at
org.jboss.system.ServiceController.doChange(ServiceController.java:632)
at
org.jboss.system.ServiceController.start(ServiceController.java:407)
at
org.jboss.test.system.controller.SimpleSARDeployer.start(SimpleSARDeploy
er.java:131)
at
org.jboss.test.system.controller.SimpleSARDeployer.deploy(SimpleSARDeplo
yer.java:86)
at
org.jboss.test.system.controller.ControllerTestDelegate.deploy(Controlle
rTestDelegate.java:176)
at
org.jboss.test.system.controller.ControllerTestDelegate.assertDeployFail
ure(ControllerTestDelegate.java:227)
This is the first change in behavior that is breaking Anil's example.
Adrian Brock wrote:
On Wed, 2006-08-23 at 09:53 -0500, Anil Saldhana wrote:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=89066
What about getting the ServiceController to get out of the Error
state
and undeploy the service when asked to?
It already does when you undeploy, I have a test for just that.
Unless you have a test that shows otherwise.
20 years
