[Design of OSGi Integration] - Re: ServiceReferences outside of OSGi Deployers
by johnbailey
I will take a crack at coming up with a ServiceRegistration/ServiceReference determination model.
On a similar note, what is the best way to get the KernelController, KernelConfigurator, and the KernelEventEmitter? The BundleContextImpl uses them for the ServiceRegistration. I am doing it as follows, but I want to see if there is a more correct way of doing it:
| protected KernelController controller;
|
| protected KernelEventEmitter emitterDelegate;
|
| protected KernelConfigurator configurator;
|
| ....
|
| public BundleContextImpl(DeploymentUnit deploymentUnit)
| {
| this.deploymentUnit = deploymentUnit;
| controller = getKernelController(deploymentUnit);
| emitterDelegate = controller.getKernel().getEventManager();
| configurator = controller.getKernel().getConfigurator();
| }
|
| ....
|
| private KernelController getKernelController(DeploymentUnit deploymentUnit)
| {
| return (KernelController) deploymentUnit
| .getAttachment(ControllerContext.class.getName(), ControllerContext.class)
| .getController();
| }
|
I am sure there is a better way, as there always is :)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133788#4133788
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133788
18 years, 1 month
[Design of POJO Server] - Re: jndiName
by bytor99999
Thanks. ;)
I mean there is already a jndi-name property, I think this might be related to the Template being out of sync. Maybe the template has jndiName, and the ManagedProperty is annotated as jndi-name.
This is from the -ds.xml file that was created
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<local-tx-datasource>
<jndi-name>MarkDS</jndi-name>
<use-java-context>true</use-java-context>
<min-pool-size>0</min-pool-size>
<max-pool-size>10</max-pool-size>
<blocking-timeout-millis>30000</blocking-timeout-millis>
<idle-timeout-minutes>30</idle-timeout-minutes>
<background-validation>false</background-validation>
<background-validation-minutes>0</background-validation-minutes>
<validate-on-match>true</validate-on-match>
<prepared-statement-cache-size>0</prepared-statement-cache-size>
<share-prepared-statements>false</share-prepared-statements>
<set-tx-query-timeout>false</set-tx-query-timeout>
<query-timeout>0</query-timeout>
<driver-class>org.hsqldb.jdbcDriver</driver-class>
<connection-url>jdbc:hsqldb:.</connection-url>
</local-tx-datasource>
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133783#4133783
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133783
18 years, 1 month
[Design of POJO Server] - jndiName
by bytor99999
So in our code I am creating a LocalTX Datasource, the -ds.xml file is being created and has all the right properties and values, so I don't understand why I get the following warning, then the whole ManagedDeployment errors
21:47:32,312 WARN [AbstractManagedObjectFactory] Cannot create String name from non-Simple property: ManagedProperty{jn
di-name,jndiName,metaType=SimpleMetaType:java.lang.String}, value=null
21:47:32,687 WARN [HDScanner] Failed to process changes
org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR
DETAILS):
*** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
jboss.jca:name=MarkDS,service=ManagedConnectionFactory
vfsfile:/C:/JBossServers/jboss-5.0.0.CR1/server/default/deploy/MarkDS-ds.xml
at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:576)
at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:559)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:291)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:221)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:280)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:135)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.j
ava:65)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.
java:142)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:166
)
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)
21:47:32,750 INFO [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=M
arkDS' to JNDI name 'java:MarkDS'
21:47:32,843 WARN [ManagementViewImpl] Failed to create ManagedDeployment for: MarkDS-ds.xml
org.jboss.deployers.spi.DeploymentException: Context MarkDS-ds.xml not found
at org.jboss.deployers.plugins.main.MainDeployerImpl.getDeploymentContext(MainDeployerImpl.java:173)
at org.jboss.deployers.plugins.main.MainDeployerImpl.getManagedDeployment(MainDeployerImpl.java:650)
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:795)
at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:101)
at org.jboss.remoting.Client.invoke(Client.java:1634)
at org.jboss.remoting.Client.invoke(Client.java:548)
at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:62)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
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)
21:47:32,890 INFO [ManagementViewImpl] Creating hsqldb-ds.xml ManagedDeployment
21:47:32,937 WARN [AbstractManagedObjectFactory] Cannot create String name from non-Simple property: ManagedProperty{JN
DIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null
21:47:32,937 WARN [AbstractManagedObjectFactory] Cannot create String name from non-Simple property: ManagedProperty{JN
DIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null
Thanks
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133779#4133779
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133779
18 years, 1 month
[Design of OSGi Integration] - Re: ServiceReferences outside of OSGi Deployers
by adrian＠jboss.org
The KernelController should already be able to give you most of the
ServiceReference information.
The two difficulties you'll find with the ServiceReferences are
1) What interfaces (if any) should they be exposed as.
For StandardMBeans this is easier since there is spec defined mechanism to
determine the management interface or there is the @JMX annotation.
However sometimes the MBean is not really what you want.
e.g. The JCA ConnectionManager is not the DataSource ;-)
For POJOs, a simple analysis gives you two options:
a) Don't expose an it unless there is specific configuration telling you
what the OSGi service interface is.
e.g.
| @org.jboss.osgi.Service(interfaces={X,Y})
| public class MyClass implements X,Y,Z {}
|
b) Expose them using any of the interfaces (there already is a class->target map)
inside the controller for the type based injection.
However, I'm sure you can think of other mechanisms/policy?
2) What deployment does it belong to?
This information is sort of there but it is not in the format you want it
and not public.
The DeploymentContext has a getControllerContextNames().
But this is Deployment->Names, you want Name->Deployment.
In fact, except for the bootstrap, all MBeans/POJOs go through
the relevant component deployers, so you can intercept this information
and make some registry of your own.
But it would be better if we could do this natively rather than
duplicating information.
e.g. pseudo code (similar to what is already done to build the info
in the deployment context)
| public class MyRegistry extends AbstractDeployer
| {
| public MyRegistry()
| {
| setComponentsOnly(true);
| }
|
| public void deploy(DeploymentUnit unit)
| {
| // A component unit name is the name in the MC
| // The bundle is the top level deployment
| map.put(unit.getName(), unit.getTopLevel());
| }
|
| public void undeploy(DeploymentUnit unit)
| {
| map.remove(unit.getName());
| }
| }
|
OTHER WORK
Don't forget you've also got to emit ServiceEvents for these as well
otherwise users won't know when they appear/disappear.
Finally, longer term we want also to expose things like EJBs as services
through their home or business interface.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133777#4133777
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133777
18 years, 1 month
[Design of OSGi Integration] - ServiceReferences outside of OSGi Deployers
by johnbailey
The BundleContext provides a registerService method to allow Bundles to registers services into the framework. The current implementation installs the Service using the BeanMetaData and the KernelController.
BeanMetaDataBuilder builder = BeanMetaDataBuilderFactory.createBuilder(GUID.asString(), serviceInfo.getName());
| BeanMetaData metaData = builder.getBeanMetaData();
| KernelControllerContext context;
| try
| {
| context = controller.install(metaData, service);
| }
| catch (Throwable t)
| {
| throw new InternalOSGiFacadeException(t);
| }
| // todo - get underlying bundle --> ServiceReference
| return new ServiceRegistrationImpl(this, context, serviceId, serviceMap);
In this case, we could create a ServiceReference for the ServiceRegistration, and hold onto it for any subsequent calls to getServiceReference. What will we do in the case of a Deployment that was not deployed using the OSGi Deployers? If our goal is to provide a Facade over the MC and allow deployments to be viewed as Bundles, we would need a generic way to get ServiceReferences for other Deployments, that is if we want to use ServiceReferences in this case.
What would the equivalent MC component be? Would it be any Bean created in a similar fashion (BeanMetaData installed into Controller). If so, how do we trace it back to the Deployment it came from?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133775#4133775
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133775
18 years, 1 month