I'm still giving this a shot. I'm using the example from A. Rupp's article on openejb posted to theserverside.com (example_02) to test this out with since it's quick and easy. I notice the URL handler that's registered in the JarUtils isn't registered until after the dtds attempt toget loaded, i added a log to the JarUtils where it sets the uri handler, and this is what i see when running maven in the example_02 directory of the test:

validate:
   [java] beginning static block
   [java] getting 2_0 dtd
   [java] setting URI handler for resource

so, now how to register this before the static block of DTDHandler gets loaded..???

Mark Lybarger wrote:

David,

the changes don't seem to be working for me. when disconnected, i'm still getting an error about unable to resolve java.sun.com.
i added some "logging" to the static method in DTDResolver as below. The first message gets displayed, but not the second. I tried to play around with the url being used to load the dtd, but my efforts were useless. i'm on a linux system with sun java 1.4.2


   static {
       byte[] bytes = getDtd("ejb-jar_1_1.dtd");
       System.out.println("beginning static block");
       if(bytes != null) {
           dtds.put("ejb-jar.dtd",     bytes);
           dtds.put("ejb-jar_1_1.dtd", bytes);
           System.out.println("adding ejb-jars to dtds");
       }
       bytes = getDtd("ejb-jar_2_0.dtd");
       if(bytes != null) {
           dtds.put("ejb-jar_2_0.dtd", bytes);
       }
   }

thanks!
~mark
David Blevins wrote:

Hi Mark,

See comments below...

On Thu, Aug 19, 2004 at 04:38:01PM -0400, Mark Lybarger wrote:


when tryinng to deploy an ejb-jar and offline, it seems that openejb is
unable to resolve the dtd. i've read a few places that the openejb is
now including the dtd's in its jar and can resolve them there? when i
check out the openejb-core-1.0-SNAPSHOT.jar, it doesn't contain any
dtd's, just the DTDResolver.


This is an old (that was fixed) back again.  The DTDResolver will do
it's job provided the dtds are packed in the jar.  In the switch from
ant to maven and sourceforge to codehaus, we seem to have overlooked
that detail.

I've patched that up and it should be ok now.

i've also decided to give the 2.0-SNAPSHOT a whirl since my beans use the 2.o dtd. that jar seems to give the same issue (it requires a bit more dependancy jars though). the 2.0 data source configuration seems a bit different than that of 1.0. once i get the issue of dtd resolution resolved, i'll need to see how to properly configure an axion datasource.

any ideas?


The OpenEJB 2.0 code-line doesn't do any of the neat testing stuff
yet.  It will, but basic compliance is first priority in that
code-line.

I've just added local interface support to the 1.0 code so that people
can test beans which would otherwise be 1.1 beans sans the local
interface. This means OpenEJB 1.0 can now deploy ejb 2.0 deployment descriptors
that contain only session beans, BMP entities, or CMP 1.1 entities
with either remote or local interfaces. MDBs or CMP 2.0 entities will
still not deploy or run.


Hopefully this will tide people over till we can get closer to
completion on the OpenEJB 2.0 code.

Should work out great for you if you don't have any CMP 2.0 or MDBs.

I've also updated the snapshot jars in our maven repository, so you
should get the new jars next time you build.

Let us know how it works out or if you have any troubles.

-David









Reply via email to