Eric Barroca wrote:
Hi,
Sorry for the delay, end of year was pretty quiet around. :-)
I wish all list's participant a successful and happy new year. And I
it will see Nuxeo 5 grow and succeed.
Here is some answers to your mail and a few questions, too...
On 29 déc. 06, at 10:44, Graham Triggs wrote:
A project that I am working on is currently undertaking an
architecture review. There is a lot of overlap between Nuxeo ECM and
what we are doing, so potentially we could make use of many of the
components, but ne of the key aspects of this review - and what I
specifically want to concern myself with here - is to improve
modularity of the application(s).
So you are not only interested by Nuxeo Runtime, but you are willing
to use other components, right?
Could you share some details about your application's scope/goals? In
which components are you interested in (if it's not the whole platform
of course)?
There are a few ways we could achieve this, but it would seem that
our favoured choice is to use OSGi. I'm keen to avoid just building
directly on OSGi and to take advantage of a more fully-formed
infrastructure. To this end, there are really two possibilities -
Spring-OSGi, and NXRuntime.
Now, from my point of view, NXRuntime has some distinct advantages to
Spring-OSGi - not least that it is ready to use (there are some
issues with Spring-OSGi that will only be resolved with Spring 2.1),
and the extension mechanism, which is closely aligned to some of our
review goals.
Moreover, NXRuntime allow to integrate well Java EE 5 and OSGi. It
basically offer to use OSGi bundle as Java / Java EE components (POJO,
EJB, etc.).
There are a few potential stumbling blocks to our adoption of Nuxeo
technologies, most of which are internal discussion matters. But at a
technical level, it is a problem that only JBoss (and Eclipse, but we
need server, not RCP - at this stage anyway) are supported as
deployment platforms.
As NXRuntime runs on Equinox (for Eclipse), it should be not very
difficult to write a NXRuntime adapter so that it can run on a raw
Equinox and then use Equinox HTTP Server to provide the HTTP service
or a Equinox/Tomcat integration through the Servlet bridge.
Is that a requirement for you to be able to run your application
without a Java EE application server or you just do not want ot use
JBoss?
I never used raw equinox but normally nuxeo runtime should be able to
run on top of such a platform without modifications (as on any OSGi
platform).
If you need integration with specific features you need to write some
code to adapt nuxeo runtime to your needs.
For example in our jboss runtime adapter we have code that adapts
components to jboss mbean, repositories contributed through extensions
to J2EE data-sources etc.
Now, background story out of the way, I'll get to my point: Equinox
provides a servlet bridge. Has anyone considered the possibilities
and/or implications of having NXRuntime/OSGi components running with
Equinox and the servlet bridge inside a single war?
We are not aware of such a try, but we would love to. It is
theoretically possible (maybe with a few tweaks). :-)
In theory at least, you would be trading off the flexible deployment
options, but you would potentially still have components bundled as
JARs, components extending others through the extension mechanism
within the application, and a single war that could be deployed to
any standard servlet container without the need to write additional
adapters.
Definitely. For the flexible deployment, we need to study if Equinox
can provide a hook to register a custom deployer. If yes, we could
port our JBoss deployer to Equinox and allow the same flexibility on
JBoss and on Equinox.
I am not aware of how .war are deployed by equinox. If they are deployed
as OSGi bundle then theoretically it should be possible
to do the same flexible deployment as on jboss. How? The solution is
provided by OSGi itself: OSGi fragments.
Through fragments you can deploy a bundle fragmented in multiple pieces
(fragments).
So, theoretically you can have a fragmented .war as we have now in JBoss.
So, in theory, we should be able to preserve the flexible deployment in
any OSGi platform.
In fact, initially I planed to implement the flexible deployment we have
in jboss through OSGi fragments.
But the OSGi adapter we wrote for jboss is minimal and doesn't support
yet OSGi fragments so, finally, I've chosen to use custom jboss
deployers instead OSGi fragments.
But we may rewrite the deployment in future to use OSGi fragments and
this way we will have an unique deployment model on JBoss and on any
osgi platform without loosing flexibility.
This can be done by moving the preprocessing step from the nuxeo EAR
deployment in the nuxeo OSGi bundle deployment for jboss. (to generate
final bundles from fragments and deploying them in jboss)
Anyway, that is what occurred to me as a theoretical possibility,
does anyone have any comments?
You project seem very interesting and we would be please to learn more
about your project and your goals to help you in this way.
Thanks for your interest,
EB.
--
Éric Barroca - Ex. VP of Operations - +33 6 21 74 77 64
www.nuxeo.com - Nuxeo: Open Source ECM - www.nuxeo.org
Nuxeo EP 5: extensible, Java EE and standards based ECM Platform !
_______________________________________________
ECM mailing list
[email protected]
http://lists.nuxeo.com/mailman/listinfo/ecm
_______________________________________________
ECM mailing list
[email protected]
http://lists.nuxeo.com/mailman/listinfo/ecm
