[Design of POJO Server] - Re: JBAS-5259, JMS Destination Names is showing as QueueServ
by mark.spritzler
After building from JBoss-head/trunk and running the server created in the build/output directory, I am see the following exceptions.
On to running the test.
13:24:01,062 INFO [ManagementViewImpl] Creating hsqldb-ds.xml ManagedDeployment
13:24:02,078 WARN [ManagementViewImpl] Failed to create ManagedDeployment for: vfsfile:/C:/JBossSVN/jboss-head/build/ou
tput/jboss-5.0.0.CR1/server/default/deploy/messaging/
org.jboss.deployers.spi.DeploymentException: Error building managed objects for vfsfile:/C:/JBossSVN/jboss-head/build/ou
tput/jboss-5.0.0.CR1/server/default/deploy/messaging/destinations-service.xml
at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.build(DeployerWrapper.java:221)
at org.jboss.deployers.plugins.deployers.DeployersImpl.getManagedObjects(DeployersImpl.java:364)
at org.jboss.deployers.plugins.main.MainDeployerImpl.getManagedObjects(MainDeployerImpl.java:774)
at org.jboss.deployers.plugins.main.MainDeployerImpl.processManagedDeployment(MainDeployerImpl.java:823)
at org.jboss.deployers.plugins.main.MainDeployerImpl.getManagedDeployment(MainDeployerImpl.java:755)
at org.jboss.profileservice.management.ManagementViewImpl.loadProfile(ManagementViewImpl.java:186)
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:585)
at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:56)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:847)
at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:101)
at org.jboss.remoting.Client.invoke(Client.java:1685)
at org.jboss.remoting.Client.invoke(Client.java:589)
at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:62)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at AOPProxy$1.loadProfile(AOPProxy$1.java)
at org.rhq.plugins.jbossas5.factory.ProfileServiceFactory.refreshCurrentProfileView(ProfileServiceFactory.java:1
02)
at org.rhq.plugins.jbossas5.ProfileJBossServerDiscoveryComponent.discoverResources(ProfileJBossServerDiscoveryCo
mponent.java:54)
at org.rhq.core.pc.inventory.AutoDiscoveryExecutor.pluginDiscovery(AutoDiscoveryExecutor.java:189)
at org.rhq.core.pc.inventory.AutoDiscoveryExecutor.call(AutoDiscoveryExecutor.java:98)
at org.rhq.core.pc.inventory.AutoDiscoveryExecutor.call(AutoDiscoveryExecutor.java:65)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
at java.util.concurrent.FutureTask.run(FutureTask.java:123)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.j
ava:65)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:168
)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.RuntimeException: Error creating annotation for @org.jboss.system.deployers.managed.ManagementObjec
tClass(code=org.jboss.jms.server.destination.QueueServiceMO)
at org.jboss.system.metadata.ServiceAnnotationMetaData.getAnnotationInstance(ServiceAnnotationMetaData.java:109)
at org.jboss.system.deployers.managed.ServiceMetaDataICF.getManagedObjectClass(ServiceMetaDataICF.java:100)
at org.jboss.system.deployers.managed.ServiceMetaDataICF.getManagedObjectClass(ServiceMetaDataICF.java:55)
at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.initManagedObject(AbstractManagedObjectFactory
.java:170)
at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.getValue(AbstractManagedObjectFactory.java:760
)
at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.populateValues(AbstractManagedObjectFactory.ja
va:600)
at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.populateManagedObject(AbstractManagedObjectFac
tory.java:549)
at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.initManagedObject(AbstractManagedObjectFactory
.java:183)
at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.build(AbstractParsingDeployerWithO
utput.java:311)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.build(DeployerWrapper.java:217)
... 35 more
Caused by: java.lang.RuntimeException: java.lang.ClassNotFoundException: org.jboss.jms.server.destination.QueueServiceMO
at org.jboss.annotation.factory.AnnotationCreator.visit(AnnotationCreator.java:228)
at org.jboss.annotation.factory.ast.ASTIdentifier.jjtAccept(ASTIdentifier.java:37)
at org.jboss.annotation.factory.AnnotationCreator.visit(AnnotationCreator.java:102)
at org.jboss.annotation.factory.ast.ASTMemberValuePair.jjtAccept(ASTMemberValuePair.java:37)
at org.jboss.annotation.factory.AnnotationCreator.createAnnotation(AnnotationCreator.java:364)
at org.jboss.annotation.factory.AnnotationCreator.createAnnotation(AnnotationCreator.java:386)
at org.jboss.system.metadata.ServiceAnnotationMetaData.getAnnotationInstance(ServiceAnnotationMetaData.java:105)
... 44 more
Caused by: java.lang.ClassNotFoundException: org.jboss.jms.server.destination.QueueServiceMO
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:242)
at org.jboss.annotation.factory.AnnotationCreator.visit(AnnotationCreator.java:162)
... 50 more
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137907#4137907
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137907
18 years
[Design the new POJO MicroContainer] - Re: beanfactory extensions
by alesj
"scott.stark(a)jboss.org" wrote :
| The only missing piece right now is not being able to set a factoryClass on a beanfactory.
|
I can hack this pretty fast.
As long as it's approved. :-)
"scott.stark(a)jboss.org" wrote :
| The BeanContainer is only acting as a wrapper around the PooledFactoryType to expose the createBean method as a property. Arguably this can be dropped in factory of a factory injection notion that would call createBean() to obtain the injected value?
|
You already have this. ;-)
| <bean name="BeanUser#2" class="org.jboss.test.kernel.deployment.support.container.BeanUser">
| <property name="bean1"><value-factory bean="PooledFactoryType1" method="createBean" /></property>
| <property name="bean2"><value-factory bean="PooledFactoryType2" method="createBean"/></property>
| </bean>
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137906#4137906
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137906
18 years
[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Used of JGroups shared transport in AS 5
by bstansberry＠jboss.com
Next, some implementation details.
In JGroups .2.6.2 the API for getting a shared transport channel vs. a multiplexed one isn't particularly clean.
Channel's in AS 5 will be gotten from the deploy/cluster/jgroups-channelfactory.sar's "JChannelFactory" bean. That implements the org.jgroups.ChannelFactory interface; clients should code to that interface.
The interface exposes the following methods for getting a shared resource channel:
| Channel createMultiplexerChannel(String stack_name, String id) throws Exception;
| Channel createMultiplexerChannel(String stack_name, String id,
| boolean register_for_state_transfer,
| String substate_id) throws Exception;
|
The name of the method and the javadoc somewhat imply these methods will return a MuxChannel+Multiplexer+JChannel. However, they do not explicitly state this. The return type is just "Channel", an abstract parent of both JChannel and MuxChannel. Clients should of course be coding to the Channel API and not assuming any further implementation details.
The std ChannelFactory impl, JChannelFactory exposes a method createChannel(String stack_name) which would be the more correct API to call if you just wanted a plain JChannel (shared transport or not). Unfortunately, in JG 2.6.2 this method was inadvertently left out of the ChannelFactory interface (fixed in 2.6.3). JG 2.6.2 will be used in AS 5, so AS 5 services cannot code to this method. They are stuck coding to one of the "createMultiplexerChannel" methods above.
In any case, JBC and probably JBM are too far along in their release cycle to code to a different method anyway.
So, how to get a shared transport channel rather than a multiplexed one?
The AS's channel factory bean is already an AS-specific impl of the ChannelFactory interface. I intend to alter the impl of the "createMultiplexerChannel" methods so they analyze the configuration of the specified protocol stack. If it supports a shared transport, I will return a shared transport channel. If not, I will return a MuxChannel+Multiplexer+JChannel. This is a bit hacky, given the name of the method, but I think the benefits are worth it.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137901#4137901
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137901
18 years
[Design of Clustering on JBoss (Clusters/JBoss)] - Used of JGroups shared transport in AS 5
by bstansberry＠jboss.com
First in a series of posts re: use of the JGroups "shared transport" in AS 5 instead of the JGroups multiplexer. There's been some discussion of this on the public jbosscache-dev mailing list, and too many private discussions, but this needs to go in front of a wider audience.
JIRA for this is http://jira.jboss.com/jira/browse/JBAS-5329
Shared JGroups Resources
The purpose of both the multiplexer and the shared transport is to make it possible for different services that need to use JGroups to share some of the resources JGroups uses. In AS 4 and earlier, each clustered service needed to open its own JGroups channel; no resources were shared. This has become a bigger and bigger issue as the number of clustered services has grown.
The resources most desirable for sharing are:
1) Network sockets. Sharing these between services simplifies configuration and administration and saves memory (i.e. network buffers).
2) Threads. A JGroups channel creates a thread pool for passing incoming messages up to the clustered service. A pool that is shared across services can more effectively manage the number of threads in use.
The JGroups multiplexer was the original way JGroups sought to provide sharable resources. Basically, an entire underlying JChannel was shared, with an adapter (Multiplexer+MuxChannel) on top that multiplexed/demultiplexed messages and passed them to the appropriate service. See http://www.jgroups.org/javagroupsnew/docs/manual/html_single/index.html#d... for details.
The shared transport was added in JGroups 2.6.2. Here the shared object is not an entire JChannel, but rather the transport protocol (UDP or TCP) that makes up the bottommost element in its protocol stack. The network sockets and the thread pool are all managed by the transport protocol, so just sharing this protocol lets us achieve the most desirable sharing. See http://www.jgroups.org/javagroupsnew/docs/manual/html_single/index.html#d... for more.
With both approaches, a key goal is that an application using JGroups does not need to know if it is using shared resources or not. The application codes to the abstract org.jgroups.Channel class' API; whether that API is implemented using a JChannel+Multiplexer+MuxChannel or by a shared transport JChannel or just by a plain JChannel should be transparent to the application.
Advantages of Shared Transport over Multiplexer
The shared transport has a number of major advantages over the multiplexer:
1) No "impedence mismatch". A number of JChannel behaviors, particularly around view management, need to be massaged/hidden from the application if the Multiplexer+MuxChannel is used. E.g. the underlying JChannel sees the group membership as {A, B, C}. But, if Service1 connects a MuxChannel on nodes A and B but not C, Service1 should get a view of just {A, B}. The Multiplexer+MuxChannel needs to have some pretty complex (and fragile) logic to resolve the impedence mismatch between what the JChannel says is the view and what the application needs to see as the view.
2) Testability. A transport protocol has a much more limited set of behaviors than a full JChannel. It also has a known and limited set of configuration options, whereas a JChannel is infinitely configurable. As a result, rigorous testing of sharing behavior is much more manageable with a transport protocol.
3) Greater configuration independence. Different services that wish to share a transport protocol need only agree on the configuration of that transport protocol. The rest of their protocol stack can be completely different. It was clear that getting agreement on a multiplexed channel's protocol stack for all AS 5 services was either not going to happen or would force a kind of lowest common denominator config.
4) FLUSH. The FLUSH protocol stops all activity on a channel for a period. Mostly happens around view changes and state transfer. This is somewhat disruptive to the service using the channel. With the multiplexer, a FLUSH initiated by Service1 also effects Service2, Service3 and Service4, with no benefit to those other services. With a shared transport, a FLUSH on Service1's channel is transparent to the channels used by Service2, Service3 and Service4.
Advantages of Multiplexer over Shared Transport
The one advantage of the multiplexer is improved startup times. Until a few members have joined a JChannel's group, the discovery sequence takes a few seconds. With the multiplexer there is only one JChannel so the discovery sequence only occurs once per VM. With shared transport, it occurs once per service.
I want to do some stuff to help mask this, particularly lazy initializing the AS's clustered caches. This will speed the standard start time; the cost of the discovery is only incurred if the user deploys things that need the clustered caches.
Bottom Line
I think the advantages of the shared transport far outweigh the disadvantages, and intend to use it in AS 5. Bela strongly agrees. We both lack confidence in the multiplexer as a reliable solution.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137897#4137897
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137897
18 years
[Design the new POJO MicroContainer] - beanfactory extensions
by scott.stark＠jboss.org
I need to be able to do something like this to delegate ee container injection to the mc:
| <deployment xmlns="urn:jboss:bean-deployer:2.0">
| <beanfactory name="PooledFactoryType1"
| factoryClass="org.jboss.test.kernel.deployment.support.container.TestPooledBeanFactory"
| class="org.jboss.test.kernel.deployment.support.container.BeanType1">
| <property name="prop1">prop1DefaultValue</property>
| </beanfactory>
| <bean name="BeanContainerType1" class="org.jboss.test.kernel.deployment.support.container.BeanContainer">
| <property name="factory"><inject bean="PooledFactoryType1"/></property>
| </bean>
|
| <beanfactory name="PooledFactoryType2"
| factoryClass="org.jboss.test.kernel.deployment.support.container.TestPooledBeanFactory"
| class="org.jboss.test.kernel.deployment.support.container.BeanType2">
| <property name="bean1"><inject bean="BeanContainerType1" property="bean"/></property>
| </beanfactory>
| <bean name="BeanContainerType2" class="org.jboss.test.kernel.deployment.support.container.BeanContainer">
| <property name="factory"><inject bean="PooledFactoryType2"/></property>
| </bean>
|
| <bean name="BeanUser#1" class="org.jboss.test.kernel.deployment.support.container.BeanUser">
| <property name="bean1"><inject bean="BeanContainerType1" property="bean"/></property>
| <property name="bean2"><inject bean="BeanContainerType2" property="bean"/></property>
| </bean>
| <bean name="BeanUser#2" class="org.jboss.test.kernel.deployment.support.container.BeanUser">
| <property name="bean1"><inject bean="BeanContainerType1" property="bean"/></property>
| <property name="bean2"><inject bean="BeanContainerType2" property="bean"/></property>
| </bean>
| </deployment>
|
The only missing piece right now is not being able to set a factoryClass on a beanfactory.
The BeanContainer is only acting as a wrapper around the PooledFactoryType to expose the createBean method as a property. Arguably this can be dropped in factory of a factory injection notion that would call createBean() to obtain the injected value?
| <bean name="BeanUser#2" class="org.jboss.test.kernel.deployment.support.container.BeanUser">
| <property name="bean1"><inject factory="PooledFactoryType1" /></property>
| <property name="bean2"><inject factory="PooledFactoryType2"/></property>
| </bean>
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137896#4137896
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137896
18 years