Todd Nist wrote:
Bogdan,
Thanks for the response. The approach you outline sounds spot on. If I
understand correctly, the xml for the NuxeoRuntime would look something
like this, it may have other dependencies I am missing:
NXRuntimeService - Interface (Not currently there)
<?xml version="1.0" encoding="UTF-8"?>
<component name="NXRuntimeService">
<implementation class="org.nuxeo.runtime.OSGIRuntimeService"/>
<property name="some.property">some value</property>
<!-- Service to be exposed -->
<service>
<provide interface= "org.nuxeo.runtime.NXRuntimeService"/>
</service>
<component>
Then my component that uses the NXRuntime or someother service would
look something like this:
<?xml version="1.0" encoding="UTF-8"?>
<component name="MyService">
<implementation class="com.tsintech.MyServiceImpl"/>
<!-- service which I provide to others -->
<service>
<provide interface="com.tsintech.MyService"/>
</service>
<reference name="NXRuntimeService"
interface="org.nuxeo.runtime.NXRuntimeService"/>
</component>
And in the activate() method of MyServiceImpl I could do something like
this:
activate(ComponentContext ctx) {
NXRuntimeService runtime =
ctx.locateService("NXRuntimeService");
}
Or alternatively we could use the bind attributes:
<?xml version="1.0" encoding="UTF-8"?>
<component name="MyService">
<implementation class="com.tsintech.MyServiceImpl"/>
<!-- service which I provide to others -->
<service>
<provide interface="com.tsintech.MyService"/>
</service>
<reference name="NXRuntimeService"
interface="org.nuxeo.runtime.RuntimeInterfaceHere"
bind="setRuntime"
unbind="unsetRuntime"
/>
</component>
public class MyServiceImpl {
NuxeoRuntime runtime;
protected void setRuntime( NXRuntimeService rt ) { runtime = rt; }
protected void unsetRuntime( NXRuntimeService rt ) { rt = null; }
protected void activate(ComponentContext ctxt) {
// do something here;
}
}
The above is only meant to be an example, in theory, the NXRutimeService
should really never need to be explicitly required by MyServiceImpl, I
should be able to deploy the service on any other OSGI runtime without
the need of NXRuntimeService. Not that big of an issues since the
application servers we want to run under do not support OSGI at this
time, but it should allow components created to run on both the server
and under Equinox in the Eclipse RCP client that we are creating without
the need for pushing / deploying the NXRuntime with it. Additionally, I
have left the cardinality out to keep it simple, but would be something
required at some point.
So I guess my question now would be, by following the approach you
outlined, the ComponentContext would need to implement the
org.osgi.service.component.ComponentContext, this would provide the
required methods for getServiceReference(), getUsingBundle(),
locateService(), locateServices(), and many other needed methods to
support the Dynamic Services. Is this correct?
Yes this could be an approach: ComponentContext should be derived from
org.osgi.service.component.ComponentContext
So we need to align the current implementation of nxruntime with osgi specs.
For now NXRuntime is not using OSGi structures and classes but its
design is quite similar to OSGi services
so it should not be too difficult to adapt nxruntime to be 100% OSGi
compatible
First we need to detect what objects should be adapted.
One is as you noticed ComponentContext. Also If I remember well in OSGi
there is something as a ComponentInstance
and a ComponentConfiguration. The ComponentInstance already exists in
NXRuntime (but it is not following osgi specs)
so it should be adapted and the ComponentConfiguration I think it is the
same as the RegistrationInfo object from nxrtunime
So first I think we need to identify what OSGi logic already exists in
NXRuntime and identinfy the components which need to be adapted
and then to find what logic is missing and add it.
Also, I think it will be better to not implement the RuntimeService as
a OSGi service
since it is the components manager (a sort of service of services) and
it will be easy to install it on non OSGi frameworks if we want this.
If done this way, then the services built would not be linked to Nuxeo
explicitly since the activate(ComponentContext ctx) would now just
reference the OSGI interface from the osgi.cmpn.jar rather than the
org.nuxeo.runtime.model.ComponentContext.
My final question, based on your last statement is for a clairification:
"I will do what is needed to adapt Nuxeo components to osgi services and
to add missing features to the XML descriptors."
I mean that I can work on the parts that are directly modifying
nxruntime logic or existent objects
but it will be great if you can help me with the other tasks - like
identifying wat is missing in nxruntime, what need to be adapted to osgi
specs
etc.
Regards,
Bogdan
What components would you like us to work on, or are you saying you will
implement the Dynamic Services into the Nuxeo Components. If that's the
case, great, if not let me know what you would like from me and I will
look at allocating the time and resources.
Regards,
Todd
-----Original Message-----
From: Bogdan Stefanescu [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 25, 2007 9:23 AM
To: Todd Nist
Cc: [email protected]
Subject: Re: [Ecm] Incorporating DynamicServices
Todd Nist wrote:
Hi Bogdan,
I apologize for the duplicate post.
I spoke to you late last year about the possibility of implementing an
Adapter for other application servers, specifically WebLogic and OC4J.
However, before I can attempt this, my management would like to see if
it is possible to incorporate DynamicServices into the NuxeoRuntime,
which I am sure is possible.
I have started to look at the current implementation and believe that
I have a general idea as to the steps to take, and am wondering if you
have any advice about how to approach this since I see it is on the
roadmap for April. If we can get it implemented, we will be glad to
contribute it back to the community. So if we do make the effort to
implement this I want to ensure that we conform to your packing and
general coding practices.
So from what I can see from the spec and the current implementation I
need to do the following:
Create a ServiceRegistry.
Implement org.osgi.framework.Filter
Implement org.osgi.framework.ServiceReference
Implement org.osgi.framework.ServiceRegistration
Implement appropriate methods in org.nuxeo.osgi.OSGIBundleContext
Add support for the "Service-Component" header to the
org.nuxeo.jboss.osgi.BundleManifestReader
Add support for the "Service-Component" header to the
org.nuxeo.runtime.osgi.OSGIRuntimeService
Tell Nuxeo runtime to loadService(bundle, context), similar to the
current loadComponents() method.
Create model and parser to parse the "Service-Component" xml, I would
think we could leverage either parts from Equinox or Felix for this.
And then the final part would be supporting the eventing that needs to
occur when a service is registered/unregistered or a bundle is
removed, I need to look at the spec a bit more for all the events.
However, I do have a question, would the eventing need to be added to
the Adapter similar to the way the ComponentAdapter mbean is or can I
just use the ComponentAdapter?
Do you have any suggestions or ideas about implementing this? Is it
possible to leverage any of the eclipse equinox project, perhaps the
org.eclipse.equinox.ds.jar? I thought about doing that but since it is
a service it calls registerService(String clazz, Object service,
Dictionary properties) and throws and exception since it returns
"null" and not a valid ServiceRegistration.
I do not see any other way to implement this with out the inclusion of
the above classes, but I may very well be missing something obvious;
what are your thoughts?
I may be way off and if I am and there is a simpler approach I would
appreciate hearing it. The above is not that much work, just do not
feel like re-inventing the wheel if parts of this are complete or it
is possible to leverage Equinox or Felix in some fashion.
I would greatly appreciate any feedback you may have on the above
approach and where you believe the new classes belong. I'm thinking
that Filter, ServiceReference, ServiceRegistration and ServiceRegistry
would all be located in the OSGIAdapter project, org.nuxeo.osgi.....
As
for the classes to support the parsing of the service-component xml,
I'm not sure where the appropriate spot is?
Thanks in advance for you time and assistance.
Regards,
Todd G. Nist
So if I understand well the features you want can be split in two:
1. Add missing functionality to the OSGiAdapter to be compatible with
most of the OSGi specs.
This is not affecting the nuxeo component model. Obviously the best
approach is to reuse existing code from equinox or felix.
All these functionalities should be developed inside the OSGiAdapter
project
(org.nuxeo.osgi.xxx) . You are free to choose your sub-package names
like org.nuxeo.osgi.filters, org.nuxeo.osgi.xml etc
2. Implement OSGi descriptive services (over the OSGiAdapter)
You can of course use existing code from equinox but this will make a
separation between OSGi services and Nuxeo Components.
In fact I prefer refactoring Nuxeo Components to be compatible with OSGi
services.
(like using compatible XML descriptor files, using compatible API etc)
So what I want is to have NXRuntime components as an extension of OSGi
services (that adds the extension model)
This means accessing nxruntime components as osgi services. Otherwise
you cannot benefit from extension points.
The approach I see is to implement independently OSGi services
infrastructure in OSGiAdapter and register NXRuntime components as
OSGi services when a component is registered (we can do this by using
the nxruntime event system)
So this way you don't need to make something similar to loadComponents()
to load services
but you use NXRuntime XML descriptors as descriptors for your services.
This means if you want 100% compliance with OSGi services we need to
refactor and add missing features to the current component XML
descriptors.
So you don't need to create a loader for OSGi XML services - we can
modify the one used for nuxeo components
In conclusion what I want is to avoid having two separate concepts: OSGi
services ans Nuxeo components - but having a single
one: Nuxeo Components that are also OSGi services (but adds the
extension mechanism)
I will do what is needed to adapt nuxeo components to osgi services and
to add missing features to the XML
descriptors.
What is your opinion about this approach?
Regards,
Bogdan
------------------------------------------------------------------------
_______________________________________________
ECM mailing list
[email protected]
http://lists.nuxeo.com/mailman/listinfo/ecm
_______________________________________________
ECM mailing list
[email protected]
http://lists.nuxeo.com/mailman/listinfo/ecm
