> If I understand you right, the TestBeans.jar is just lacking jBoss-2
> compatible deployment descriptors.
That is correct.
> Does ejboss (1.0) have a jaws.xml? Is it fully compatible (i.e. either
> the same or a proper subset) with jBoss 2.0?
a jBoss 2.0 file will deploy on jBoss 1.0.
A jBoss 1.0 file will not deploy on a jBoss 2.0 installation.
>
> If so, it should be possible to make a jar that will deploy on either
> ejboss (1.0) or jboss (2.0). If not, this needs to be fixed, either
> by ensuring that they use same descriptor, or by introducing a jaws2.xml
> for jboss 2.0.
it is the dependency on jaws.xml that i find silly. There must simple ways
to provide defaults, since the design is pretty insulated supposedly.
However as I start deploying without these default files the errors come
from many parts in the server (pools init, jaws, etc) and it doesn't look
that clean... so... I am still hacking at a portability but it is silly work
too.
The reason I don't want the files is that jBoss' claim to fame is the ease
of use. we could work from ejb-jar.xml in 95% cases. Most developers are
familiar with ejb-jar.xml as they already have them (they are standard
files) so a bean would deploy right away, and people focused on the "wow, it
deployed and created my tables" instead of learning the jaws.xml
significance and GUI...
It's no biggy and I hope to be done soon, it is just grudgy work and I had
hoped it would be more encapsulated/documented.
> caller
> |
> | (1)
> (2) V (3)
> bean metadata<------JAWSPersistenceManager-------->entityBean
> |
> | (4)
> V
> JDBC
>
> You are working in the "bean metadata" space. I see you through
> interface (2), which in principle is negotiable, but I am regarding that
> interface as fixed (frozen) for now.
Yes I am working on 2, however nothing is froze AT ALL. Trust me on that.
marc
>
> Interface (1) is fixed by the overall jBoss architecture.
>
> Interface (3) is fixed by EJB.
....
> Interface (4) is fixed by JDBC.
>
> --
> Justin Forder
>
>
