On Tue, 24 Oct 2000, Rick Horowitz wrote:
> 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?
Not sure without looking, but my left-field guess is they are not
serializable or remote, and objects in JNDI may be used by clients in
different classloaders (such as EJBs in different JARs).
> 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.
That was because until a very short while ago we always used the
same branch ID.
Further, since the XidImpl is only used by our TM, and I believe
our TM always uses == to check for equality in the relevant situations
(actually, I'm not sure this is ever relevant), this function is probably
never called.
However, all that said, we may as well implement it right.
> 3) TM & Minerva
> a) Why are org.jboss.tm.TxManager.suspend() and resume() methods empty
> and indicate that they are "useless"?
I don't think our TM ever calls suspend or resume. When would
they be useful? Only if the you somehow knew that a caller was not going
to use a resource for a while so you could temporarily reuse the resource
for a different caller, and then return later to the original one. I
can't think oof how that would happen. But then, I haven't thought about
it for very long - *is* there some situation where you'd want to suspend
and resume?
> 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?
Yes. There is no doubt that you'd want to use a vendor's
XADataSource impl in a production 2-phase commit environment. However,
these are still few and (for the most part) poorly implemented.
> 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.
I don't have the spec in front of me, so I'm not sure of the
context of your quote. However, I'm pretty sure you're looking in the
wrong place. The only data source that goes in JNDI is the
org.jboss.minerva.datasource.XAPoolDataSource and that one is
Referenceable. It is not serializeable because it would not help if it
was - it has a reference to a DB connection (if you follow the chain a
little) which is not (generally) serializable, so you'd just move the not
serializeable exception over a few classes.
> 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).
On the other hand, once you have run jBoss once successfully, all
parameters for all instances that have parameters are written to the
jboss.jcml file, so you never really need to look up the name (unless it's
that unclear, in which case we should use a better name). Were there
specific entries you had trouble identifying?
> 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.
A stateless session bean doesn't have identity, so it doesn't make
sense to ask for the primary key, to remove it, etc.
> 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?
java.lang.reflect.InvocationHandler is new to 1.3, so it would
break 1.2 code to use it. The classes under jrmp12, you will discover,
use our own implementation istead of the one in java.lang.reflect.
> 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);
Well, that's kind of what the verifier is for...
Aaron
> 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]
>
