Hi,
Let me share some impressions and thoughts that I have after spending
two days and one night moving our project from jBoss 1.0 to jBoss 2.0
(successfully).
1) DataSourceImpl Mlet doesn't support extended parameters for
getConnection(String, Properties).
I have added the support and I am going to commit it.
Though, if there are any concerning issues, let's discuss them.
2) It is possible to specify Class-Path in the MANIFEST.MF for the EJB
jar, and the ContainerFactory does take it into account.
Unfortunately, BeanVerifier doesn't.
Say, if a parameter of ejbCreate is of some application class that is
not in the global class path, but in the EJB jar Class-Path, then
BeanVerifier throws ClassNotFountException.
Juha, could you fix it or give your blessing to the following plan.
I propose to pass the bean class loader to the verifier instead of EJB
jar URL. At that point the bean class loader is constructed, so why we
make the verifier to construct yet another class loader by adding
the EJB jar URL?
3) Let me return to the question about the application libraries that
contain classes needed for all the beans of some application.
Now we have two options: to add them to the global class path
(say, put in lib/ext) or to add them to the Class-Path in the
MANIFEST.MF.
The first option sometimes is unacceptable: say, if some JDO class is
passed to the bean as a method parameter, it is created by the
global class loader, while Castor assumes the JDO classes are loaded
by the thread context class loader, i.e. bean class loader.
For such cases only the second option remains.
But if the number of the application libraries is big and sometimes
changes, the need to support the up-to-date list of libraries in
MANIFEST.MF becomes annoying.
I propose the following solution: to extend the Class-Path format, to
treat "dir/*" as "all jar files in dir".
I've implemented this, but before committing I ask your:
"Any objections?"
4) I tried to turn off Debug messages for ConsoleLogger, but I
discovered that many of them regard themselves as Information.
In particular, most of the messages during method invocation:
begin tx
I AM LOOKING FOR THE ID 969904529371
SSC:invoke:mi is getRowCount map is getRowCount
commit tx 1
I believe that this is a Debug info.
When I turn off Information messages, the black screen frightens me
:-(
Best regards,
Oleg Nitz
