rick,
you obviously have done your homework...
but this is not the right forum for it,
please go to jboss-dev and get a discussion going
marc
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Rick Horowitz
|Sent: Tuesday, October 24, 2000 2:22 PM
|To: jBoss User
|Subject: [jBoss-User] Possible bugs / definite questions
|
|
|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 > {0}</query>
|
|
|Regards,
|
|Rick Horowitz
|
|
|--
|--------------------------------------------------------------
|To subscribe: [EMAIL PROTECTED]
|To unsubscribe: [EMAIL PROTECTED]
|Problems?: [EMAIL PROTECTED]
|
|
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
