[Microcontainer] - Re: How to hide a bean from other deployments?
by alesj
Finally some time to answer ... been batteling VFS hell. :-)
"obrien" wrote :
| 1. search itself doesn't have any concept of precedence/relationship of two scopes and respective deployment, ie. possible to pick up wrong bean.
|
It somehow has the hierarchy, determined by the scope levels; see PreInstallAction.
But you have to be strict, the mechanism is pretty dumb.
So yes, you can easily pickup wrong bean.
"obrien" wrote :
| I'll solved that for now by provisioning custom LookupStrategy, but within the kernel structure there's not sense of the deployment structure. For example is there easy way how to pickup beans from particular deployment (from jboss-beans.xml for example)?
|
You could mock this by putting particular deployment into unique scope.
"obrien" wrote :
| 2. That leads to the <scope%gt> we've discussed and I think it doesn't make sense to create it in such a manner.
|
| To provide some generalized control of scoping to application developer I realized it would be better to have it on deployment level. Something like this:
|
|
| | <deployment scoped="true" name="myApp" xmlns="urn:jboss:bean-deployer:3.0">
| |
|
| where scoping could be enabled by default. Then it would be just matter to create nested deployments and define visibility/relationship rules between them.
|
You can do this with deployment's annotations; they are then inherited by beans.
"obrien" wrote :
| 3. Rules are needed for merging of deployment scopes(along two different physical deployments).
|
Same scope key == same scoped controller.
"obrien" wrote :
| 4. In such a case Kernel/Controller reference handed over to the application (for example WAR file), would represent just its deployment scope, with resolving functionality by default to be upwards in the structure (as it's currently).
|
Might not be a bad idea.
"obrien" wrote :
| 5. Then concept of the ObjectName as it was used within JMX microkernel could be recreated to support something like maindeployment.subdepl:name=myBean to define cross-scope references.
|
This is just one way of determining scope.
Should be more flexible.
"obrien" wrote :
| 6. And to get this to the extreme, it might be then possible to create RemoteDeployment where the given scope doesn't have to part of the same JVM. with clever mixing of VFS delegation to the other kernel, aspects and bit of dark magic that could work :)
|
MC runs of VFS, so if we're really FS agnostic,
this should then run ootb - we don't care where VFS comes from.
"obrien" wrote :
| *. Which leads me to the question, if there is currently way how to 'include' other XML deployment descriptor?
|
Wildcards?
"obrien" wrote :
| To stay real, there's a small bit I can try to implement - AbstractKernelController to have support to return scope context, because I don't see other way than lookup strategy to get to the scoped beans.
This is a huge overhaul of the system.
And as such it's more of a feature than real requirement.
I'll ping you here when we put this on the dev forum.
Like I already mentioned, this spreads from MDR, unique naming, Deployers, ...
Each of them should properly address possible scoping.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4207396#4207396
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4207396
17 years, 4 months
[Clustering/JBoss] - clustering/JMS problem among machines not using same partiti
by hale2jo
Hello, all. We are using jboss-4.2.3.GA on some machines with CentOS 4.4 and some with CentOS 5. For development purposes we do not like to cluster so we all change our mcast_port in cluster-service.xml to something unique. That was fine for a time. Then we realized that even though JBoss was not clustering, JMS was. I read http://jboss.org/community/docs/DOC-12460 and consequently started using unique partition names and jboss.partition.udpGroup addresses. This LOOKS like it is working, but does not.
Here is the start of my JBoss log on a machine called "cars" at 150.102.65.10:
| ================================================================================
| JBoss Bootstrap Environment
|
| JBOSS_HOME: /usr/jboss-4.2.3.GA
|
| JAVA:
|
| JAVA_OPTS: -server -Xmx512m -XX:PermSize=96m -XX:MaxPermSize=128m -Dprogram.name=jboss
|
| CLASSPATH: /usr/jboss-4.2.3.GA/bin/run.jar:/usr/java/jdk1.5.0_02/lib/tools.jar
|
| CMD_START: /usr/java/jdk1.5.0_02/bin/java -server -Xmx512m -XX:PermSize=96m -XX:MaxPermSize=128m -Dprogram.name=jboss -classpath /usr/jboss-4.2.3.GA/bin/run.jar:/usr/java/jdk1.5.0_02/lib/tools.jar org.jboss.Main -c appServer -b cars -Djava.security.manager=java.lang.SecurityManager -Djava.security.policy=/usr/jboss-4.2.3.GA/server/appServer/conf/server.policy -Djava.rmi.server.codebase="file:/usr/jboss-4.2.3.GA/server/appServer/lib/KDCSservices.jar file:/usr/jboss-4.2.3.GA/server/appServer/lib/kdcsclient.jar" -Djava.rmi.server.hostname=cars -Dkdcs.hostname=cars -Djboss.partition.name=workstation_32_development_Rochester
| -Djboss.partition.udpGroup=228.1.2.10 -Djboss.platform.mbeanserver -Djava.endorsed.dirs=/usr/jboss-4.2.3.GA/lib/endorsed
| ================================================================================
|
| 10:11:13,954 INFO [JChannel] JGroups version: 2.4.1 SP-4
| 10:11:14,661 INFO [STDOUT]
| -------------------------------------------------------
| GMS: address is 150.102.65.10:52299
| -------------------------------------------------------
| 10:11:16,684 INFO [TreeCache] viewAccepted(): [150.102.65.10:52299|0] [150.102.65.10:52299]
| 10:11:16,709 INFO [TreeCache] TreeCache local address is 150.102.65.10:52299
| 10:11:16,709 INFO [TreeCache] State could not be retrieved (we are the first member in group)
| 10:11:16,709 INFO [TreeCache] parseConfig(): PojoCacheConfig is empty
| 10:11:20,919 INFO [NativeServerConfig] JBoss Web Services - Native
| 10:11:20,919 INFO [NativeServerConfig] jbossws-3.0.1-native-2.0.4.GA (build=200803312044)
| 10:11:22,094 INFO [SnmpAgentService] SNMP agent going active
| 10:11:22,610 INFO [JChannel] JGroups version: 2.4.1 SP-4
| 10:11:22,759 INFO [workstation_32_development_Rochester] Initializing
| 10:11:22,809 INFO [STDOUT]
| -------------------------------------------------------
| GMS: address is 150.102.65.10:52303
| -------------------------------------------------------
| 10:11:24,817 INFO [workstation_32_development_Rochester] Number of cluster members: 1
| 10:11:24,818 INFO [workstation_32_development_Rochester] Other members: 0
| 10:11:24,818 INFO [workstation_32_development_Rochester] Fetching state (will wait for 30000 milliseconds):
| 10:11:24,818 INFO [workstation_32_development_Rochester] State could not be retrieved (we are the first member in group)
| 10:11:24,862 INFO [HANamingService] Started ha-jndi bootstrap jnpPort=1100, backlog=50, bindAddress=cars/150.102.65.10
| 10:11:24,868 INFO [DetachedHANamingService$AutomaticDiscovery] Listening on cars/150.102.65.10:1102, group=228.1.2.10, HA-JNDI address=150.102.65.10:1100
| 10:11:26,171 INFO [TreeCache] No transaction manager lookup class has been defined. Transactions cannot be used
| 10:11:26,336 INFO [JChannel] JGroups version: 2.4.1 SP-4
| 10:11:26,481 INFO [STDOUT]
| -------------------------------------------------------
| GMS: address is 150.102.65.10:52309
| -------------------------------------------------------
| 10:11:28,485 INFO [TreeCache] viewAccepted(): [150.102.65.10:52309|0] [150.102.65.10:52309]
| 10:11:28,486 INFO [TreeCache] TreeCache local address is 150.102.65.10:52309
| 10:11:28,640 INFO [JChannel] JGroups version: 2.4.1 SP-4
| 10:11:28,790 INFO [STDOUT]
| -------------------------------------------------------
| GMS: address is 150.102.65.10:52312
| -------------------------------------------------------
| 10:11:30,794 INFO [TreeCache] viewAccepted(): [150.102.65.10:52312|0] [150.102.65.10:52312]
| 10:11:30,796 INFO [TreeCache] TreeCache local address is 150.102.65.10:52312
|
Looks great, right? cars is the only machine in the cluster with the partition name workstation_32_development_Rochester. Before when we all were using DefaultPartition, and only had unique mcast_ports, many other ip addresses showed up in the list following "[TreeCache] viewAccepted():"
Then, for unknown reasons it tries to access another machine called "wizard":
| 10:12:52,894 INFO [QuartzJob] startSingleton(): Start QuartzJob Singleton
| 10:12:57,500 ERROR [QuartzJob] *********************Exception Thrown*********************
| 10:12:57,501 ERROR [QuartzJob] createJobAndTrigger(): null
| 10:12:57,501 ERROR [QuartzJob] *********************End of Exception*********************
| 10:12:57,501 ERROR [STDERR] javax.naming.CommunicationException [Root exception is java.rmi.RemoteException: Service unavailable.; nested exception is:
| java.rmi.ConnectIOException: Exception creating connection to: wizard; nested exception is:
| java.net.NoRouteToHostException: No route to host]
| 10:12:57,502 ERROR [STDERR] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:780)
| 10:12:57,502 ERROR [STDERR] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
| 10:12:57,502 ERROR [STDERR] at javax.naming.InitialContext.lookup(InitialContext.java:351)
| 10:12:57,502 ERROR [STDERR] at kdcs.timers.QuartzJob.jobInvoiceHandlerJob(QuartzJob.java:797)
| 10:12:57,502 ERROR [STDERR] at kdcs.timers.QuartzJob.createJobAndTrigger(QuartzJob.java:849)
| 10:12:57,502 ERROR [STDERR] at kdcs.timers.QuartzJob.startSingleton(QuartzJob.java:390)
| 10:12:57,502 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| 10:12:57,502 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| 10:12:57,503 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| 10:12:57,503 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:585)
| 10:12:57,503 ERROR [STDERR] at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| 10:12:57,503 ERROR [STDERR] at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| 10:12:57,503 ERROR [STDERR] at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
| 10:12:57,503 ERROR [STDERR] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| 10:12:57,503 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| 10:12:57,503 ERROR [STDERR] at org.jboss.ha.singleton.HASingletonController.invokeSingletonMBeanMethod(HASingletonController.java:207)
| 10:12:57,503 ERROR [STDERR] at org.jboss.ha.singleton.HASingletonController.startSingleton(HASingletonController.java:144)
| 10:12:57,503 ERROR [STDERR] at org.jboss.ha.singleton.HASingletonSupport.startNewMaster(HASingletonSupport.java:272)
| 10:12:57,503 ERROR [STDERR] at org.jboss.ha.singleton.HASingletonSupport.makeThisNodeMaster(HASingletonSupport.java:254)
| 10:12:57,503 ERROR [STDERR] at org.jboss.ha.singleton.HASingletonSupport.partitionTopologyChanged(HASingletonSupport.java:196)
| 10:12:57,503 ERROR [STDERR] at org.jboss.ha.jmx.HAServiceMBeanSupport$1.replicantsChanged(HAServiceMBeanSupport.java:247)
| 10:12:57,503 ERROR [STDERR] at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.notifyKeyListeners(DistributedReplicantManagerImpl.java:846)
| 10:12:57,504 ERROR [STDERR] at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.add(DistributedReplicantManagerImpl.java:409)
| 10:12:57,504 ERROR [STDERR] at org.jboss.ha.jmx.HAServiceMBeanSupport.registerDRMListener(HAServiceMBeanSupport.java:255)
| 10:12:57,504 ERROR [STDERR] at org.jboss.ha.jmx.HAServiceMBeanSupport.startService(HAServiceMBeanSupport.java:177)
| 10:12:57,504 ERROR [STDERR] at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
| 10:12:57,504 ERROR [STDERR] at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
| 10:12:57,504 ERROR [STDERR] at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
| 10:12:57,504 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| 10:12:57,504 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:585)
| 10:12:57,504 ERROR [STDERR] at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| 10:12:57,504 ERROR [STDERR] at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| 10:12:57,504 ERROR [STDERR] at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
| 10:12:57,504 ERROR [STDERR] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
|
wizard used to be in cars' /etc/hosts/ file, but I commented it out, so it makes sense that it cannot create a connection.
What I do not understand is, why is it trying to connect to wizard?????
I have searched and searched again and there is no reference to wizard in any config files nor is cars still trying to use DefaultPartition!
Any help would be GREATLY appreciated!!!
Thanks,
Josephine
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4207389#4207389
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4207389
17 years, 4 months
[JBoss Portal] - Cross portal pages portlet communication
by trikyscience
We have a problem with inter-portlets communication (in particular with portlets published in different portal pages). In details, we want to share one or more parameters (for example an ID) between portal-pages that contain portlets deployed in different war application. We tried with public render parameters but the scope of this specific is limited in the portal-page. Moreover, we tried also to pass a parameter between pages with the event (defined in JSR 286) but the scope of an event is also only inner the portal page. So we tried with aliases but doesn't work to.
Is possible that the different public render parameters across the different application (and portal pages) contain the same value. We also cannot use session because portlets are in different war files.
The problem we need to solve is to allow portlets deployed in different war files to talk each other also whether they are in different portal pages.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4207380#4207380
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4207380
17 years, 4 months