I have a new version of the Class Space code on my laptop that fixes
this issue, but I'm preparing for our upcoming training course. I
should have it checked in late next week or the week after.
-dain
On Thursday, October 2, 2003, at 10:19 AM, gianny DAMOUR wrote:
Hello,
I was just trying to solve the problem of Matt Kurjanowicz, which
seems to be a weird CL problem and during my investigations I have
discovered three points:
- the Eclipse set-up I use to simulate a running server is simply
flawed (grrr...);
- the Resource Adapter Deployer I have submitted does not work, when
deployed within a running instance launched via maven run:main
(grrrrr...); and
- the parent CL of a ClassSpace is the TCCL if defined or the CL of
the ClassSpace class.
Regarding this last point, I really find it weird for the following
reason:
If one creates a ClassSpace for a deployment unit, say a resource
adapter, and if I want to define a specific parent for such a
ClassSpace, I will need to set the TCCL. However, because this TCCL is
outside our control between the moment this TCCL is set and the actual
creation of my ClassSpace (other deployment planners could wish to set
their own TCCL), it is impossible to know for sure which CL will be
the parent of the deployment unit ClassSpace.
So, I would like to know if one can add to ClassSpaceMetadata an
attribute referencing the name of the parent ClassSpace of the
ClassSpace to be created via this ClassSpaceMetadata. This way, a
deployment unit could explicitely defines its direct CL and the parent
of this CL.
I have applied this fix and it solved my resource adapter deployer
problem. More accurately, the parent CL of the ClassSpace containing
the resource adapter archives is the
geronimo.system:role=ClassSpace,name=System ClassSpace (defined during
the boot).
Gianny
