Hi,
On 5 janv. 07, at 01:31, Graham Triggs wrote:
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.
No problem, I won't take it for a contract. :-)
It's just to understand better what you are trying to achieve and how/
if Nuxeo's platform can be used for that.
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.
It seems there is a good match, yes. Nuxeo EP is really designed to
support this kind of application.
We aim at building a platform, to support vertical applications. It
seems your application could really benefit from it.
Moreover, it seems like a very interesting project, if I have googled
right. :-)
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.
We basically started the Runtime for this reason: create truly
extensible java components and java web applications (just like
Eclipse RCP / Equinox does).
And to be honest, we really think NXRuntime approach is the best one
currently for that (create extensible and adaptable Java / Java EE
applications). Moreover, we think that create application by
"composition" (taking a set of component and then write a layer on
top to assemble/configure them, including contributing resources/
pages/components to the UI).
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.
I think, it will difficult to run / adapt our components without Java
5. Do you think that Java 5 is an acceptable requirement for you?
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.
Indeed.
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).
I can understand your requirements. And I can see several solutions:
1/ Run Nuxeo Runtime and core components on top of a bare Equinox and
plug Equinox into a servlet container. In this case, you would be
able to use the full power of core components but will be unable to
use EJB ones (but this is not a problem since all core components are
pure POJO)
2/ Use JBoss Microcontainer (but it requires to adapt Nuxeo Runtime
to support the new deployment infrastructure offered by it — Bogdan:
please correct me if I'm wrong :-) ).
3/ Adapt Nuxeo Runtime to work directly on a servlet container (like
Tomcat). It would also prevent to use any EJB components.
On JBoss support: we are planning to support other application
servers (Glassfish, JOnAS, WebLogic) but do not have time right now
to write support for them. It should be a 3 weeks to 1 month work for
each app server. If you are interested, you're welcome. ;-)
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.
The Runtime takes care of it currently on JBoss (hence in Tomcat
since JBoss uses Tomcat as servlet container). It dynamically
assemble and create the final application bundle using composition
description contained in each component (following composition
directive in them).
I think we could recreate this directly on Tomcat using a custom
deployer (if there is this notion) or custom adapter. Bodgan: please
correct/improve this. :-)
Do not hesitate to dig further and ask for more information. I
definitely think that Nuxeo EP could be a great foundation for your
application and speed the development time.
Thanks,
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
