Thanks to everyone who responded to this msg...some more stuff below...
marc fleury wrote:
> |5) Metadata
> |a) Why do you set the classloader in XmlFileLoader when auto-deploying
> |an ejb jar file to the classloader created for that jar file deployment,
> |instead of setting the context classloader and then simply loading
> |classes? Do I misunderstand context classloaders? My understanding is
> |that when you set the context classloader, all subsequent classes loaded
> |from that thread are loaded by the context classloader, irrespective of
> |the classloader used to load the invoking class. Is this correct, or is
> |context classloader simply a mechanism used to pass around a classloader
> |that can be easily obtained (from the thread) and used to explicitly
> |load a class?
>
> pretty much yes, the fact is that RMI classes are well behaved and work on
> the ccl before going to system. It's not a contract in the VM though... we
> are well behaved, tomcat is.
So then jboss is well behaved because it **explicitly** specifies the
ccl on classloads? If it did not, then the cl that defined the invoking
class would be used as the cl? True?
> |c) After standardjboss.xml is processed, jboss.xml is processed.
> |Container configurations defined in jboss.xml result in newly created
> |ConfigurationMetaData objects, even if a ConfigurationMetaData object
> |with the same name existed in standardjboss.conf. This makes it
> |impossible to modify part of a container configuration defined in
> |standardjboss.conf in jboss.conf. Is this the intention?
>
> not correct. the extended jboss.xml overwrites some values and the other
> values are still used. It's usage is to modify *parts* of standardjboss.xml
> ( I suspect that's what you meant )
Yes, but the portion that I was wondering about is in
ApplicationMetaData.importJBossXml(), where it creates a new
ConfigurationMetaData object for each container-configuration element in
jboss.xml. So, jboss.xml reused the name of a container configuration
element defined in standardjboss.xml, it looks to me that it would
create a 2nd instance of ConfigurationMetaData with the same name. Seems
to me this would lead to unexpected behavior for the writer of the
jboss.xml file. Seems to me it should either completely replace the
previously defined instance of ConfigurationMetaData, or overwrite only
those fields updated by jboss.xml. Its a small point, but thought I'd
just point it out.
public void importJbossXml(Element element) throws
DeploymentException {
Iterator iterator;
// all the tags are optional
// find the container configurations (we need them first to use
them in the beans)
Element confs = getOptionalChild(element,
"container-configurations");
if (confs != null) {
iterator = getChildrenByTagName(confs,
"container-configuration");
while (iterator.hasNext()) {
Element conf = (Element)iterator.next();
ConfigurationMetaData configurationMetaData = new
ConfigurationMetaData();
try {
configurationMetaData.importJbossXml(conf);
} catch (DeploymentException e) {
throw new DeploymentException("Error in jboss.xml for
container-configuration " + configurationMetaData.getName() + ": " +
e.getMessage());
}
configurations.add(configurationMetaData);
}
}
Rick Horowitz
