October 2008 - jboss-dev-forums - Jboss List Archives

[Design of Clustering on JBoss] - HANamingService IllegalStateException: Must call setClustere

by scott.stark＠jboss.org

As I'm testing moving the beans from conf/jboss-service.xml to deploy, and I'm now seeing this exception when the HANamingService is starting: | 21:01:30,619 INFO [HANamingService] Started HAJNDI bootstrap; jnpPort=1100, backlog=50, bindAddress=/127.0.0.1 | 21:01:30,623 INFO [DetachedHANamingService$AutomaticDiscovery] Listening on /127.0.0.1:1102, group=230.0.0.4, HA-JNDI address=127.0.0.1:1100 | 21:01:30,632 ERROR [AbstractKernelController] Error installing to Start: name=HAJNDI state=Create | java.lang.IllegalStateException: Must call setClusteredCache before starting | at org.jboss.ha.jndi.impl.jbc.JBossCacheDistributedTreeManager.init(JBossCacheDistributedTreeManager.java:128) | at org.jboss.ha.jndi.HAJNDI.init(HAJNDI.java:89) | at org.jboss.ha.jndi.DetachedHANamingService.startService(DetachedHANamingService.java:376) | at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:376) | at org.jboss.system.ServiceMBeanSupport.pojoStart(ServiceMBeanSupport.java:216) | I don't see how the bean move would be causing this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181989#4181989 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181989

16 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - JBMICROCONT-362, InstanceClassFactory or override ManagedObj

by scott.stark＠jboss.org

ManagedObject for mcbean deployments are not being created correctly because the AbstractManagedObjectFactory/AbstractManagedObjectPopulator requires that the attachment metadata is what is annotated with the management information. Its the underlying bean that users place the management annotations on. This is similar to service mbeans. For service mbeans we created a InstanceClassFactory that returns the underlying mbean class to scan for annotations. We can do the same for mcbeans, but we have overriden the ManagedObjectCreator.build method in the BeanDeployer with a TODO to create the ManagedObjects from the bean metadata. This might have been added before we had the InstanceClassFactory in place. I'm going to prototype a InstanceClassFactory since that can be specified at the server level, but I wanted to check if there was a reason to continue with the BeanDeployer ManagedObjectCreator override. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181987#4181987 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181987

16 years, 3 months

1
0
0 / 0

[Design of POJO Server] - [jboss-metadata] No LocalBindingMetaData

by ALRubinger

So far we've gotten by without a LocalBindingMetaData class because we set the necessary values directly in LocalBindingProcessor: public void process(JBossSessionBeanMetaData metaData, Class<?> type) | { | LocalBinding annotation = finder.getAnnotation(type, LocalBinding.class); | if(annotation == null) | return; | | if(annotation.jndiBinding() != null && annotation.jndiBinding().length() > 1) | metaData.setLocalJndiName(annotation.jndiBinding()); | } But this doesn't model the metadata properly, and is preventing me from doing some validation as defined by JBMETA-117. Any objections to adding LocalBindingMetaData and the other necessary support? Then metaData.setLocalJndiName() gets called somewhere else. I'm hoping to task Emanuel on this one? S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181986#4181986 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181986

16 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: ProfileService Guidance

by scott.stark＠jboss.org

Its related to JBMICROCONT-362. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181984#4181984 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181984

16 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: [jboss-metadata] Validation on completely merged view

by ALRubinger

I'm also giving the ValidatorChain the ability to report all Validation failures at once, instead of fail-fast (should make things easier for bean providers) org.jboss.metadata.validation.ValidationException: An @RemoteBinding was defined on EJB MyStatelessBean, but this bean has no remote business interfaces defined. [JBMETA-117] ...becomes: org.jboss.metadata.validation.chain.ValidatorChainException: Validation has failed due to the following ValidationException(s) raised: | An @RemoteBinding was defined on EJB MyStatelessBean, but this bean has no remote business interfaces defined. [JBMETA-117] S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181982#4181982 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181982

16 years, 3 months

1
0
0 / 0

[Design of POJO Server] - console-mgr.sar jars being registered as mbeans?

by scott.stark＠jboss.org

For some reason I'm seeing the following type of errors when running the profileservice config: | 19:28:02,819 WARN [AbstractDeploymentContext] Unable to register deployment mbean vfszip:/Users/svn/JBossHead/jboss-head/build/output/jboss-5.0.0.GA/server/profileservice/deploy/management/console-mgr.sar/console-mgr-classes.jar | javax.management.InstanceAlreadyExistsException: jboss.deployment:id="vfszip:/Users/svn/JBossHead/jboss-head/build/output/jboss-5.0.0.GA/server/profileservice/deploy/management/console-mgr.sar/console-mgr-classes.jar",type=SubDeployment already registered. | at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:767) | at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:236) | at sun.reflect.GeneratedMethodAccessor73.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.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431) | at java.security.AccessController.doPrivileged(Native Method) | at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426) | at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376) | at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:989) | at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:998) | at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:998) | at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.postRegister(AbstractDeploymentContext.java:964) | at org.jboss.mx.server.AbstractMBeanInvoker.invokePostRegister(AbstractMBeanInvoker.java:974) | at org.jboss.mx.server.AbstractMBeanInvoker.postRegister(AbstractMBeanInvoker.java:681) | at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:338) | at sun.reflect.GeneratedMethodAccessor73.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.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431) | at java.security.AccessController.doPrivileged(Native Method) | at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426) | at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376) | at org.jboss.deployers.plugins.deployers.DeployersImpl.registerMBean(DeployersImpl.java:1573) | at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:726) | at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:541) | at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:265) | at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:143) | at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:409) | at org.jboss.Main.boot(Main.java:209) | at org.jboss.Main$1.run(Main.java:544) | at java.lang.Thread.run(Thread.java:613) | Why would jars in a sar be seen as mbean deployments? These are just library jars. I'm not seeing this in the default config which is also strange. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181978#4181978 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181978

16 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: [jboss-metadata] Validation on completely merged view

by ALRubinger

This is tracked in https://jira.jboss.org/jira/browse/JBMETA-118 and has been committed in r79433. The only place I've triggered the ValidatorChain to run is from JBoss50Creator. Can we think of other instances in which we'd need to validate a fully-merged metadata? S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181975#4181975 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181975

16 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: java.beans.XMLEncoder Useless?

by scott.stark＠jboss.org

It wouldn't be. Its different only by virtue of being created by the admin layer. Most attachments don't support an id attribute, so any extra information we want to keep around such as timestamps, change set info, etc. would have to be outside of the attachment serialized form. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181945#4181945 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181945

16 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: [jboss-metadata] Validation on completely merged view

by ALRubinger

"emuckenhuber" wrote : Hmm, no there is not such a validation mechanism - we were thinking of adding smth like that, but this is actually not planned for the next future. Any objections to my adding a validator chain to be run at the end of Creator.create() please speak now or forever hold your piece. "emuckenhuber" wrote : But not really sure if that makes sense to add all to merging!? Merge merges, validators validate. :) Then we can even make the validation configurable/pluggable in the future if we want. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181939#4181939 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181939

16 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: [jboss-metadata] Validation on completely merged view

by emuckenhuber

"ALRubinger" wrote : | Is there a mechanism to validate metadata after all the processing/merging is completed? I'm envisioning something in the form of a chain of validators run by by JBoss50Creator.create() after everything is merged. | Hmm, no there is not such a validation mechanism - we were thinking of adding smth like that, but this is actually not planned for the next future. Maybe you can add this check to merging? There you also have the xml data, if someone added the remote interface in the xml. But not really sure if that makes sense to add all to merging!? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181932#4181932 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181932

16 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2008