Guess you do not need a licence per client, as you are not runnning the server. I've seen pretty small client side runtimes (under 100k) for other servers. I assume that something like that is possible for the Orion product as well. The jars you mention contain a lot of superfluous stuff (including the console in orion.jar), which cause other things to load, which cause other things to load ... On the up-side (I'm serious), if you load everything from the orion-dir on to your clients, you do get rid of all sorts of configuration problems like which xml parser is used on that machine. With some hacking I guess you can make the total amount to download a lot smaller yourself, but I consider that too tricky. You never know when classes get loaded dynamically. In the past I've had contact with Orion regarding the lots-off-stuff-to-download. They said they would make a smaller client-side runtime, but I guess otherthings do have a higher priority. FE On Tuesday, April 10, 2001 1:41 PM, Julian Richardson [SMTP:[EMAIL PROTECTED]] wrote: > 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 > > >
