I've been going through the jboss source code to learn the jboss
internals...great stuff!  and have come up with some questions and some
things that I suspect may be bugs. I've been collecting these on an Oct
17 code base, so some of them may have already been addressed. Here's
the list so far...

1) Why does initService() in SimpleRealmMappingService and
EJBSecurityManagerService create an instance of SimpleRealmMapping and
EJBSecurityManagerDefaultImpl, respectively, and then create a Reference
object for JNDI naming, rather than just insert these instances into
JNDI?

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.

3) TM & Minerva
a) Why are org.jboss.tm.TxManager.suspend() and resume() methods empty
and indicate that they are "useless"?
b) JTA Specification section 3.4.6 states, "The resource adapter needs
to allow the commit process to be executed while the resource is
currently associated with a different global transaction."  It appears
to me that XAResourceImpl.commit() does not allow this.  Instead, it
throws an exception if it is "active".  Is this because XAResourceImpl
is an XAResource implementation to be used only for non-JDBC 2.0
standard extension compliant JDBC drivers, hence only supporting local
transactions, which must be serialized on a given java.sql.Connection?
c) In JTA spec, section 3.4.8, it states, "The implementation of these
transactional resource factory objects are both
javax.naming.Referenceable and java.io.Serializable so that they can be
stored in all JNDI naming contexts."  Why then, do neither
org.jboss.minerva.xa.XADatatSourceImpl nor
org.jboss.minerva.factories.XAConnectionFactory implement Referenceable
or Serializable?  Perhaps I'm confused here, the Minerva code takes some
time to absorb with all of its many classes and interfaces. 

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).  

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?
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.
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?
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.
b) Why doesn't
org.jboss.ejb.plugins.jrmp.interfaces.StatelessSessionProxy implement
java.lang.reflect.InvocationHandler instead of its subclasses in jrmp12
and jrmp13 packages, since the former is the class that defines the
invoke() method?

7) JAWS
a) JAWS meta data:
i) In JawsEntityMetaData constructor, if the primary key is a simple
key, I think it should verify that the primary-key-field is a defined
CMP field after  the line:  
(1) CMPFieldMetaData cmpField =
(CMPFieldMetaData)cmpFields.get(pkFieldName);

8) Jboss Test - Bank
a) Verification:
i) CustomerBean.ejbCreate() returns type java.lang.String but the bank's
ejb-jar.xml file defines the Customer bean
<prim-key-class>org.jboss.test.bank.interfaces.CustomerPK</prim-key-class>. 
The return value from ejbCreate() must match the primary key class.
ii) In JawsEntityMetaData.importXml(), should probably prevent the user
from setting the read-only time-out entity if read-only is set to false,
or should issue a warning to the user and then ignore it.
iii) In FinderMetaData.importXml(), the query field element content from
the banktest application's jaws.xml is not obtained for the jboss
testbean Account. Instead, a null is found and stored in
FinderMetaData.query.  This is because the spaces in the query element
content cause 3 elements to be generated, and
MetaData.getElementContent() returns null.
        query element:  <query>balance &gt; {0}</query>


Regards,

Rick Horowitz


--
--------------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
Problems?:           [EMAIL PROTECTED]

Reply via email to