Hi,

I've just been doing some experimentation with Orion and writing of a web
(servlet-based) client which runs on a remote webserver - I was quite
surprised at the requirements. I've seen a few people asking about how this
is done and checked the mailing list archives but it seems there's been no
definitive answer, so hopefully this will be useful information to
someone...

There's a couple of questions I've raised at the bottom of this email which
I'd be interested in hearing opinions on...

The web client in this case uses ServletExec (a very old version), JDK is
sun's 1.3, and the platform was Redhat 7.0. Orion platform itself was an NT4
box, again with Sun's 1.3 VM.

Firstly, the java.policy file needs a bit of hacking out of the box in order
for this to work (I don't think the same is true of the 1.3 VM on NT systems
for some reason!) so that the VM's security manager doesn't get upset over
all the things that ServletExec and the Orion InitialContext constructor
needs to do. The java.lang.RuntimePermission for "setIO" needs to be enabled
(ServletExec redirects stdout to a logfile), and
java.io.SerializablePermission for "enableSubsititution" needs to be enabled
(Orion's Initialcontext constructor requires this)

Secondly, jndi.properties needs to be in the root directory that contains
the classes which do any object referencing - this took a lot of figuring
out and playing around with locations (within jar files, the root servlet
directory, the current directory, a WEB-INF directory, and a META-INF
directory, amongst others) before I got it to work. The list archives seems
to imply that it differs for different setups though. Similarly I needed a
META-INF/application-client.xml file before anything would run, again
created off the root classes directory.

Thirdly, and this was the most interesting point, was the amount of stuff
needed just for a new InitialContext() call to work; I had to add the
following jar files (from the Orion directory on the core server machine) to
the classpath in my ServletExec kick-off script:

        orion.jar
        jndi.jar
        ejb.jar
        jaxp.jar
        xerces.jar
        parser.jar
        mail.jar

Now, a few questions which are bugging me:

        Is there an easier way than this? Running everything on the same
server works fine, and I suspect this is what most people do anyway. But I'd
quite like to split off the web front-end from the core EJB stuff, partly
for performance reasons and partly because it feels wrong to treat the web
layer as an integral part of the system when it's no different to the
command-line clients I have (I'm not yet sure of what impact doing this has
on scalability within Orion though, if any). Do the Orion guys release a jar
file that just contains the stuff needed to support the InitialContext
constructor call? (obviously I'll always need jndi.jar and ejb.jar anyway on
the client / webserver machine)

        Why on earth is there a reference to Java mail in there? From the
exception thrown when I didn't have mail.jar in the classpath it was
javax.mail.Address that it was looking for, referenced from
com.evermind.xml.XMLConfig

        Is this process documented anywhere? That'd save me having to
document it here for the benefit of others within my company! :-)

        Any ideas on the licensing for doing this? Does this imply that
every client which needs to reference
com.evermind.application.server.applicationClientInitialContextFactory needs
an Orion licence, or do I just worry about the server licence which has
Orion itself installed and can freely distribute Orion.jar onto client
machines as part of my client code as necessary (where a client is some
non-web-based application that we write). That's a little worrying...

cheers

Jules


Reply via email to