Aaron,
Thanks very much for your response. You've cleared a bunch of things up
for me...very much appreciated. Some follow-up questions below...
For anyone else with an inclination to read through my original msg
(which is included below) I think there I may have found a couple of
bugs.. Also, would still very much appreciate answers to some of my
other questions that Aaron did not touch on.
Cheers,
Rick Horowitz
Aaron Mulder wrote:
>
> 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).
I'm still not clear on the reason for not just binding the objects into
JNDI directly instead of binding refs? What value do the refs provide?
>
> > 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?
No, I don't, but I'm still very much in the process of trying to absorb
all this stuff, JTA, JBoss, JDBC 2.0 std extension, minerva, etc. so
don't take my opinion for much on this subject (at least for now :) ). I
just saw the comment and it didn't make sense, but now I understand the
reasoning.
>
> > 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.
Yes, I've gotten that drift from readin the jboss list.
>
> > 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.
That seems to explain it...yes.
>
> > 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?
I didn't really understand the relationships in general between
jboss.conf and jboss.jcml until I started reading the code. Perhaps I'm
just being dense...don't know, but it seems to me that the ease-of-use
goal of jBoss would be well served by somehow (perhaps my suggestion, or
perhaps some other way) of better tying together the naming of the
mbeans identified in jboss.conf with the configuration of those mbeans
in jboss.jcml. just my 2 cents.
>
> > 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]
> >
