NXRuntime, Equinox and Servlets

Hi,

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).

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.

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.

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?

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.

Anyway, that is what occurred to me as a theoretical
possibility, does
anyone have any comments?

Thanks,
G

This email has been scanned by Postini.
For more information please visit http://www.postini.com

_______________________________________________
ECM mailing list
ECMlists.nuxeo.com
http://li
sts.nuxeo.com/mailman/listinfo/ecm

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?

> 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.

> 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
ECMlists.nuxeo.com
http://li
sts.nuxeo.com/mailman/listinfo/ecm

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
> ECMlists.nuxeo.com
> http://li
sts.nuxeo.com/mailman/listinfo/ecm
>

_______________________________________________
ECM mailing list
ECMlists.nuxeo.com
http://li
sts.nuxeo.com/mailman/listinfo/ecm

> 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)?

Sure, just bear in mind that I'm not really making any
official
representation on this - it's more my personal view of
potential overlap and
collaboration possibilities, although I am trying to get
others to think
about and discuss this.

The project is DSpace - an open source digital preservation
/ institutional
repository project written in Java. Although the goals are
somewhat
different, many of the problems of storage, retrieval,
transformation,
workflow management share a lot of similarities. Therefore
we may make a lot
of the same decisions when relying on outside specifications
and
technologies (ie. OSGi, JCR, jBPM, etc.), even if we weren't
building on
(and contributing to) your codebase.

So, there is quite a lot - potentially the whole
infrastructure of the
enterprise platform (if not the same data model, to whatever
extent they can
be separate) - that could be useful. But specifically the
focus that I came
away from the architecture meeting with was frameworks and
modularization,
ie. OSGi or Spring. And although OSGi in general seems
preferable, and the
direct integration of an OSGi platform feasible, I at least
think your
Runtime components provide some very useful additional
features that more
closely align to our intentions of modularization than
simply going it
alone.

> 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?

The current application/distribution runs as on 'any'
servlet container (not
sure what spec we support as a minimum). We don't have any
other EE
container usage. 

We do have an explicit goal that it should have an
easy/minimal setup
capability - although setting up JBoss *instead* of Tomcat
doesn't really
break that wish, and we could even have something similar to
the EP RC2
installer that you distribute.

But, most of our existing users will have installations on
Tomcat, and we
wouldn't want to mandate those into moving to a different
server. Also,
having JBoss as the *only* server platform would be / is
seen as a problem.
But combining a servlet/OSGi bridge and Runtime would solve
both those
issues, and allow the future possibility of hosting
components in
alternative environments - be it JBoss, or Eclipse RCP, or
something else -
as and when it is required (and which IMHO, is a significant
advantage
compared to anything we've been discussing).
 
> 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.

Hmmm... possibly. An OSGi provider (or even custom code)
within an
application can manage dynamic loading/unloading/deploying.
But as long as
you bundled your application into a WAR and deployed that to
the servlet
container, the original, unmodified WAR would still be
sitting around inside
the container, and could potentially cause problems later
on.

G

This email has been scanned by Postini.
For more information please visit http://www.postini.com

_______________________________________________
ECM mailing list
ECMlists.nuxeo.com
http://li
sts.nuxeo.com/mailman/listinfo/ecm