Hi,
Alexander Kogan wrote:
>
> Ole Husgaard wrote:
> >
> > Hi,
> >
> > Isn't it your EJB home interface that
> > cannot be found?
> > This is in your EJB jar, and its
> > classes are not served by the web
> > server.
>
> Are you sure? Why then we need the web-server for?
> Only to download jnp-client and jboss-client?
I was not sure; seems I was wrong:
Just had a quick look at the source,
and it looks to me like the
ContainerFactory adds the application
classloader to the web server for its
classes to be served.
Strange, but it looks like these
classloaders are never removed from
the web server again on undeployment.
In fact, it looks to me like currently
classloaders are *never* removed from
the webserver.
That looks like a bug to me: It means
that the classloaders for old containers
are never freed, and that the old
classes of the jar might still be
served (maybe not if the jars these
classloaders use have been overwritten
or removed).
At least the webserver's list of
classloaders will continue to grow at
every deployment and redeployment.
Unless someone comes up with an
explanation, I'll better have a closer
look and possibly raise this on the
jboss-dev list.
> > This is similar to when one EJB jar
> > tries to access classes and defined
> > in another EJB jar.
> > Problem is, while it would make
> > sense to serve the interface classes
> > (but not implementation classes) of
> > the EJB jar, there are no sure way
> > to differentiate what classes are
> > interface and which are
> > implementation.
>
> Actually there is. ejb-jar.xml lists
> Home and Remote interfaces for each bean.
The interface of a bean may be more
than just the home and remote classes.
For entity beans, it also includes the
primary key (and any classes supporting
that, if any). Also other value
classes may be considered part of the
interface.
> > I seperate my EJBs in different jars
> > for implementation and interface.
> > EJB implementation jars go to deploy
> > directory, while interface jars go
> > in classpath.
>
> But it would kill the idea of the hot deployment.
Yes, as long as the bean interface is
changed.
> You can only pray that you never have to change
> the interfaces.
Redeployment does not change classes
already downloaded to clients. So any
hot redeployment involving interface
changes would break clients until they
have been restarted.
IMHO hot redeployment where all clients
have to be restarted is not that hot,
so I use it when only implementation
has been changed.
Best Regards,
Ole Husgaard.
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
