|2) In org.jboss.tm.XidImpl.equals() - comment says we should check
|branch id for equals, but does not do so in the current code.
yes fixed by sebastien yesterday
|3) TM & Minerva
|a) Why are org.jboss.tm.TxManager.suspend() and resume() methods empty
|and indicate that they are "useless"?
because they are :), we use the thread association explicitely
|4) Configuration
|a) Jboss.jcml usage is confusing because one must examine the source
|code to determine the JMX name of an object. Makes it hard for jboss
|newbies to understand this aspect of configuration because the name used
|to configure an object in jboss.jcml doesn't match the mbean created in
|jboss.conf. Perhaps part of the mbean name could be changed so that it
|uses the mlet's class name (without package name).
hmmmmm interesting... finding an object with JMX Is A Pain...
|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.
|b) In TestBeans.jar, the entity nextgen.EntityBMP contains a
|<primkey-field>name</primkey-field> definition.
|EntityMetaData.ImportEjbJarXml(), however, doesn't read this field or
|store it in the meta-data. Either this is a bug or the bean is
|incorrectly defined.
could be, i don't know, sebastien any ideas?
|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 )
|d) In AbstractInstancePool.importXml(), why is only subelement
|MaximumSize obtained, and not MinimumSize?
|e) In StatelessSessionContainer.java, most of the EJBHome methods are
|not implemented. Is this a known limitation?
|
|6) Stateless session bean invocation:
|a) In StatelessSessionContainer, several methods are not yet
|implemented: remove, getHandle, getPrimaryKey, isIdentical, removeHome,
|getEJBMetaDataHome, getHomeHandleHome.
they are on the client, look at the proxy. However we can't just remove
them for now due to a design introduced early on... we will in time
marc
|Regards,
|
|Rick Horowitz
|
|
|--
|--------------------------------------------------------------
|To subscribe: [EMAIL PROTECTED]
|To unsubscribe: [EMAIL PROTECTED]
|Problems?: [EMAIL PROTECTED]
|
|
