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
