Hi Assaf,
I have something yes.. :)
You will find here an example on how to connect from a servlet to a
remote nuxeo server:
https://svn.nuxeo.org/nuxeo/org.nuxeo.ecm.client/trunk/nuxeo-client-servlet
To generate the WAR run mvn install. This will run only with nuxeo trunk.
The generated war contains is similar to a nuxeo command line client
application - it contain sa directpry app/
with similar content.
In nuxeo command line client you also have a lib directory this one is
was moved to WEB-INF/lib since it needs to be on the web app class path.
in WEB-INF/classes you have two classes - NuxeoServlet - a servlet able
to load a nuxeo runtime and then run your own code
in the form of ServletHandler objects.
It is not possible to have a pure servlet that load the nuxeo framework
- you need to use the ServletHandler abstraction.
This is beacause the servlet container is using it's proper class loader
to instantiate servlets.
To be able to run a pure nuxeo servlet we need to load its class using
with a special class loader.
So to be able to di this we let the servlet container to load
NuxeoServlet as usual and then we load in the init() method the
implementation
of the ServletHandler to be used. The NuxeoServlet will delegate all
HTTP requests to that handler - which is completely under the
nuxeo runtime class loader control.
You can define as many servlets as you want using a NuxeoServlet and
different ServletHandlers configured thorugh the web.xml init-params
elements.
Look at the web.xml in this project to understand how the server should
be configured.
This code was tested with a jboss instance (tomcat) and works well. The
demo ServletHandler provided is not doing
too much it is only printing the path of the document root - a simple
slash :)
But it demonstrate the connection to the remote server.
The host and port parameters in the web.xml are only for demonstration -
in real life apps you may want to use
other mechanisms to specify on ehat server you want to connect.
The only required parameter are "nuxeo-client" and "handler" params:
<init-param>
<param-name>nuxeo-client</param-name>
<param-value></param-value>
<description>The nuxeo client base directory</description>
</init-param>
<init-param>
<param-name>handler</param-name>
<param-value>org.nuxeo.ecm.servlet.DemoServletHandler</param-value>
<description>The servlet handler</description>
</init-param>
The nuxeo-client is by default pointing to the app directory inside the
war directory.
If you want to use compressed wars you can use absolute paths or
relative paths to the war jar.
The handler param is the ServletHandler implementation to be used by the
NuxeoServlet.
Note that nuxeo clients have a "limitation": you cannot have multiple
concurrent connections to different nuxeo servers.
If you want to connect to another server you need to disconnected from
the current one first.
This is because the client is based on a nuxeo runtime instance (on a
framework instance which is a singleton) that is autoconfiguring
itself from the remote server. THis is not really a limitation but a
fact -> it cannot configure itself from multiple servers because these
configurations may be incompatible. For example one server may define
document types which are completely incompatible with other servers.
Since the nuxeo runtime is a singleton service you cannot configure it
for 2 different servers at the same time.
In theory you can manage concurrent connections to different nuxeo
server - but then must manage yourself connections and configuration and
you cannot rely on nuxeo client stack. But this way you cannot benefit
of automatic nuxeo client configuration.
You can make a parallel to eclipse workspaces: you cannot work in
multiple workspaces at same time - if you want to switch to another
workspace you should restart the application context.
Anyway, In applications like app servers which are supporting isolated
enterprise apps - you can connect to different server at the same time
by using two different WAR that are isolated one of each other.
If you have more questions don't hesitate.
Regards,
Bogdan
Assaf Cohen wrote:
Hi Bogdan,
Are there any updates on this?
Regards,
Assaf
On 10/17/07, *Bogdan Stefanescu* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi Assaf,
We have a similar task (accessing a nuxeo server from a servlet on a
remote machine) that will be done until the end of this week or
next week.
I will notify you when this task will be done.
As part of this task I will create a generic servlet that you and
others
will be able to use to connect to a remote nuxeo server.
The ideea in implementing such a servlet is to adapt the nuxeo shell
client (see https://svn.nuxeo.org/nuxeo/org.nuxeo.ecm.client)
to be loaded from a servlet.
In practice you need to put something on the disk the nuxeo shell
application (so that the servlet can access it)
The client application folder contains required nuxeo bundles
(jars) as
for example various nuxeo API, nuxeo runtime and other utilisties
and also third party libraru needed by nuxeo.
The servlet will load the nuxeo runtime using the RuntimeLoader class
and then it will connect to nuxeo server using NuxeoClient class.
This class is able to download required configuration (service
bindings,
streaming server location etc) from the remote server
and will auto configure the local runtime.
This way you don't need anymore writing xml configuration files
Regarding the project nuxeo-api-sample it is outdated and need to be
refactored to use the NuxeoClient class to avoid writing xml
configuration files.
Regards,
Bogdan
Assaf Cohen wrote:
> Hello Bogdan,
> I've been following Nuxeo for many months now (since before 5.0.0.RC
> release) and the ecm mailing list.
> I've read through all the documents on the website and what's
> available in the not-yet-finished 'nuxeo-book'.
> I've successfully built the sample empty project and I agree
that it
> should be easy and efficient to build extensions for the Nuxeo
> platform this way.
> I find great interest in Nuxeo and I believe in its potential (both
> product and company).
>
> But I've been trying over and over fruitlessly to use the remote
API
> from another WAR deployed on the same or another J2EE server (Tomcat
> as an example). The nuxeo-book is empty on this point and the
JIRA and
> mailing list have only puzzling discussions, mostly ending the same
> way - with a reference to the 'nuxeo-api-sample'.
> I've noticed that so far you've been the most knowledgeable and
> helpful person on these issues.
>
> Being a real novice with J2EE deployment issues myself and
seeing that
> there are enough other users with similar issues
> (this guy for instance is trying something similar on Tomcat:
> http://jira.nuxeo.org/browse/NXP-1503
<http://jira.nuxeo.org/browse/NXP-1503>), I've decided it's time
to ask
> for advice:
> Currently, I get a .jar by building 'nuxeo-api-sample' but I'd
like to
> know how to make a deployable WAR out of that sample.
> Would it be possible to document the suggested process of creating
> such a standalone WAR with all the needed .jars and xml
> descriptors, from the ground up in order to have access to nuxeo
> remote API from another web app (lets say: a minimal JSP EL
script on
> Tomcat, for simplicity).
> So far I get countless exceptions and I'm pretty much stuck.
>
> Regards,
> Assaf
>
>
_______________________________________________
ECM mailing list
[email protected] <mailto:[email protected]>
http://lists.nuxeo.com/mailman/listinfo/ecm
_______________________________________________
ECM mailing list
[email protected]
http://lists.nuxeo.com/mailman/listinfo/ecm
