> I think that the best way is to create a separate jar containing the
classes
> needed by a client and include that as a library in your EAR. Or, if the
> resource adapter is meant to be available to all applications, include it
in
> lib/ext.
>
> Another option would be to have a JBoss-specific extension whereby you
> nominate a jar in your RAR as the client jar and that gets made
> available to the rest of the EAR.
cool, it's the dr. seuss aproach "there's a jar in your rar, so we know
where they are"
I think I like the latter way a little better since the rar then doesn't
depend on a specific ear being deployed. Even if it is non-standard, It
would seem logical to have something like a lib/shared.jar inside the rar,
and maybe a corresponding classpath entry in the manifest.
Tying the shared files to a particular ear probably wouldn't be so useful -
for example with the blackbox adapter, you wouldn't want to (and possibly
couldn't) implement the jdbc datasource interface again as a session bean
and force people to go through that when you already have the interface you
want right in the adapter itself.
Would it make sense to have to declare the shared classes (or the adapter
itself) as some kind of resource in jboss.xml for the ears? Would there be a
way of sucking in the rar's classloader as the immediate parent for the
ear's classloader?
-d
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
