someone just reported a problem with some required classes being in
one of the app client jars and no longer being accessible to the
server. I caused this recently :-) by making the app client deployer
copy the files into the app client's configuration rather than the
ear configuration. This makes the app client config independent of
the ear config so it should be possible to deploy it without the ear
config present.
I'm not quite sure what the best solution is....nor am I sure that
having an app client as a manifest dependency of a server side
component is spec compliant.
I think we could either:
(1) if the app client is specified as a manifest cp entry, copy it
into the ear config but just as a jar, so there would be 2 copies,
one in the ear and one in the app client
(2) in this case make the app client config a parent of the ear config
At the moment (1) sounds more reliable to me.
thanks
david jencks
On Mar 14, 2007, at 9:42 AM, Matt Hogstrom wrote:
I'll be working on DT today. My goals are to first get the monster
deployed on trunk (and working or JIRA's opened identifying
issues). I'm also going to next look at primitives for EJB 3.0 and
see where we lack and what needs to be added.
I suspect we would like to keep the AppClients that use WS and for
data integrity verification. Most people don't find them that
useful (only a few postings about what they are). If anyone has an
opinion one way or the other chime in.
I know chris has done some cleanup so maybe all this is already
done :)
