Deployment Support

What is the difference between the bean-providers JAR and deployer’s JAR?

The EJB spec does define the output of the bean provider which should contain the various EJB interfaces and classes, but it is not the case that the container/server must use this EJB-jar file at deployment time. The specification does not specify everything about deployment JAR format since it will definitely contain vendor specific generated code and other information.

So, if someone gives you an EJB-jar file, and you want to deploy it in the Inprise Container, take these steps:
1) un-jar the file
2) run the java2iiop compiler on the home interfaces
3) compile the generated code
4) migrate the Deployment Descriptor information to Inprise supported EJB 1.1 XML format.
4) run jar utility to produce a new deployment jar file
5) deploy the jar in the container

How should I migrate deployment data from WebLogic to Inprise Container?

If one has a deployment descriptor text file from Weblogic, the steps to follow to generate the Inprise descriptor are as follows:
1) Extract the serialized DD from the Weblogic jar file (using jar xvf ).
2) Run our dd2xml tool on Tengah's DD to generate EJB 1.1 XML descriptors. This works fine if you don't have to modify the DD. However, typically a DD requires minor modification. Further Weblogic DDs are a sub-class of the DDs in the EJB specification. dd2xml only captures the standard vendor independent information in a Serialized Descriptor. So,
3) Edit the XML to modify/add information, if necessary (using our XML DD editor). Add any information that was contained in WebLogic's DD extensions. Presumably this will include information such as the Database URL, the table, etc.
4) Use jar utility to create a new EJB-Jar, containing the XML files etc.

Why do you have two XML files in every ejb-jar?

1) The ejb-jar.xml file is as per the EJB 1.1 specification, adhering exactly to the DTD in the Public Release of the EJB 1.1 spec

2) A vendor specific deployment descriptor file in XML, for Inprise Container specific deployment information. Some of this stuff is absolutely required to complete a deployment description, such as specifying the JNDI name of the EJBs, and configuring the JDBC datasources. Some stuff is more proprietary in nature, such as specifying various optimization parameters, and configuring a simple OR mapping for supporting CMP. The IAS4 DD editor provides editing capabilities for this file.

It is expected that Primetime will be used at development time producing EJB Jar files with (1) in it. Then the IAS4 DD editor will allow the user to add (2) to the Jar.

How is the DTD for the XML descriptors found? Stated otherwise, should I embed the DTD in the XML file or use the PUBLIC Id mechanism?

All XML files need have a grammar to conform to. The easiest is to embed the entire DTD at the top of any XML file. This may not be good always (for obvious consistency and versioning issues) so there exists this “include” mechanism in XML whereby a referenced file can be searched for externally. Infact the EJB 1.1 spec mandates the latter where the Sun defined ejb-jar.xml file must have a PUBLIC Id that points to the DTD hosted on their http URL. So by default if the tools don’t do something smart then an URL connection will be attempted to this URL (say when you are trying to do some EJB work on a cross country flight!) Fortunately the Inprise tools optimize this.

Both the Sun standard DTD and the Inprise DTD are part of the distribution (in vbejb.jar). If you do not have a typo in the PUBLIC Id URL for these DTDs, i.e. you simply follow the style of the EJB examples or use the DD Editor, we have an optimization whereby the DTD is picked up locally from the product distribution and if not found, then searched for by URL.

This has an additional advantage. Say the DTD is changed by the spec authors in a future release of the spec to “add” a few elements without fundamentally disrupting the structure of it. It will be possible to allow for such (inevitable) changes in the DTD from always requiring a patch release from us to users. If it changes "additively" - meaning lets say Sun decides to add a new sub element to their element; then without changing source code and sending out a new version of the product it should be possible for users to overlay the central DTD with the new one and write their XML conforming to this new DTD and still have our validating XML parser and the EJB verifier work. Of course we will not take notice of this additional information but atleast we'll not break. OTOH, if the DTD change "interferes" e.g. gets scoped within a as has happened recently in the spec, then we shall have to upgrade the source code.

Note that *if* the XML has an inlined DTD that will get preference, which is the usual XML parsing rule.

What is the composition of a client jar?

On a client you need to have class files for
- The Client itself
- The remote and home interfaces and any dependent Java objects (like PrimaryKeyClass, return types, argument types, etc)
- java2iiop generated *Helper.class and *Holder.class
- java2iiop generated *Operations.class and *_Stub.class

The GUI Console provides a way to automatically generate the client jar.

Can I dynamically add an ejb jar to a running Container without bringing it down?

Sure. You do that all the time when using the Console. Further we provide a commandline utility com.inprise.ejb.util.Deploy that can be used to instruct the Container to dynamically load/unload/reload ejb-jar(s). The usage is printed when you run the command without any arguments.

What is a typical usage of the Deploy utility?

New ejbs can be deployed to a running Container i.e. you can start a blank Container using

% vbj com.inprise.ejb.Container ejbcontainer -jns -jts -jss -jdb

and then "add" ejb-jars to it e.g.

% vbj com.inprise.ejb.util.Deploy ejbcontainer -load  /home/fred/ejb_repository/sort_beans.jar
[paths *relative* to the directory in which you started the Container also work, but it is suggested that you use the full path name, since that forms a unique key to identify the jar]

% [run SortClient etc on the deployed Sort bean]

Now without bringing down the Container you may

% vbj com.inprise.ejb.util.Deploy ejbcontainer  -load    <path>/cart_beans.jar

[continue running SortClient, run CartClient, etc.]

You may then decide to reload the sort_beans.jar thus:
% vbj com.inprise.ejb.util.Deploy ejbcontainer -reload    /home/fred/ejb_repository/sort_beans.jar

and finally undeploy them using,
% vbj com.inprise.ejb.util.Deploy ejbcontainer -unload   /home/fred/ejb_repository/sort_beans.jar    <path>/cart_beans.jar

As you can see the com.inprise.ejb.util.Deploy utility has a "list jars", "load new jars", "unload jars" and "reload jars" capability. Look at the usage message when you run with no arguments. The Console can be used to do the above too.

We would like to clarify that this dynamic deploy capability is primarily targeted to developers ease of use, at least in this release. Complex versioning issues have not been really resolved.

What scenarios should I avoid when using dynamic deployment?