geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Questions about o.a.g.kernel.deployment.service.ClassSpaceMetadata
Date Mon, 01 Dec 2003 18:28:24 GMT
On Sunday, November 30, 2003, at 08:43 AM, gianny DAMOUR wrote:

> Jacek Laskowski wrote:
>> Could anyone care to comment on 
>> o.a.g.kernel.deployment.service.ClassSpaceMetadata's (final) 
>> attributes - CREATE_* - in a form of javadoc?

Sometimes I forget that this stuff is not obvious.  This code is on my 
refactor and document list.

>> Although the names are selfexplanatory, neither is their use.
>> org.apache.geronimo.kernel.deployment.task.CreateClassSpace's 
>> perform() does the following:
>>   if (!server.isRegistered(name)) {
>>     if (metadata.getCreate() == ClassSpaceMetadata.CREATE_NEVER) {
>>       throw new DeploymentException("No class space is registerd with 
>> name: objectName=" + metadata.getName());
>>     }
>>     // other lines follow
>>   } else {
>>     if (metadata.getCreate() == ClassSpaceMetadata.CREATE_ALWAYS) {
>>       throw new DeploymentException("A class space is already 
>> registered with name: objectName=" + metadata.getName());
>>     }
>>   }
>> So, I'm reading it when a class space name is not registered *and* 
>> that class space's attribute is set to CREATE_ALWAYS 
>> DeploymentException is thrown.
> I think that one should understand it like this:
> If the ClassSpace to be created or updated is not registered and if it 
> should never be created, then there is an issue and one throws an 
> exception.
> For instance, suppose that one configures a service S1, which uses the 
> ClassSpace A. One implements a service, S2, which needs to share the 
> same ClassSpace than S1. To do so, one configures for S2 a ClassSpace, 
> which re-uses the ClassSpace A. More accurately, one sets its name to 
> A and in order to avoid typographic errors - a possible usage of this 
> "create" attribute - one also sets its "create" attribute to "false".

Correct.  There are three cases here:

Always Create - you use this when you expect to be the only deployment 
creating the class space which usually means that you want it to be a 
private class space.  Another use case is you want to have a specific 
implementation of the class loader held by the class space.  The class 
loader implementation can only be set by the deployment that first 
creates the class space. (I'm not sure this feature actually works, but 
that was the idea)

Never Create - you use this when you are expecting to join another 
preexisting class space.  The class space should already be initialized 
and you are only reusing the current urls or expanding the class space 
set of urls.

Don't care - you honestly don't care if there is an existing class 
space or not.  This is the default.

>> Another note is about getUrls() method. Shouldn't the method return 
>> Collections.unmodifiableList? Why is the list allowed to be modified 
>> by external entities?
> As you can see, there is no method to add a URL to a 
> ClassSpaceMetaData. External entities add URLs to a ClassSpaceMetaData 
> by retrieving the modifiable URL list and adding to it some URLs. Have 
> a look to ClassSpaceMetadataXMLLoader.

Yep.  It is a common pattern in the metadata classes (you can blame 
Jeremy if you don't like it ;)


View raw message