Hi all, I'm interested whether somebody got combo to work....

I experianeced really strange errors, while trying to run under
JRockit:

18:06:09,957 ERROR [InfobitConfig] unable to configure infobit manager
java.lang.VerifyError: (class: net/sf/cglib/BCELBackend, method: if_icmpeq signature: (Ljava/lang/Object;)V) Incompatible argument to function
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:140)
at net.sf.cglib.CodeGenerator.class$(CodeGenerator.java:63)
at net.sf.cglib.CodeGenerator.<init>(CodeGenerator.java:105)
at net.sf.cglib.KeyFactoryGenerator.<init>(KeyFactoryGenerator.java:93)
at net.sf.cglib.KeyFactory.create(KeyFactory.java:114)
at net.sf.hibernate.impl.SessionFactoryImpl.<clinit>(SessionFactoryImpl.java:318)
at net.sf.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:618)
at com.infodesire.infobit.hibernate.BaseSessionProvider.init(BaseSessionProvider.java:59)
at com.infodesire.infobit.InfobitPool.init(InfobitPool.java:161)
at com.infodesire.infobit.config.InfobitConfig$ConfigHandler.endElement(InfobitConfig.java:120)
at org.apache.xerces.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:559)
at org.apache.xerces.impl.XMLNamespaceBinder.endElement(XMLNamespaceBinder.java:646)
at org.apache.xerces.impl.dtd.XMLDTDValidator.handleEndElement(XMLDTDValidator.java:2978)
at org.apache.xerces.impl.dtd.XMLDTDValidator.endElement(XMLDTDValidator.java:918)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.handleEndElement(XMLDocumentFragmentScannerImpl.java:1145)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:988)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1446)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:333)
at org.apache.xerces.parsers.StandardParserConfiguration.parse(StandardParserConfiguration.java:529)
at org.apache.xerces.parsers.StandardParserConfiguration.parse(StandardParserConfiguration.java:585)
at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:147)
at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1148)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:345)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:143)
at com.infodesire.infobit.config.InfobitConfig.configure(InfobitConfig.java:63)
at com.infodesire.infobit.InfobitConfiguration.<init>(InfobitConfiguration.java:52)
at com.infodesire.infobit.InfobitConfiguration.<init>(InfobitConfiguration.java:38)


JBoss 3.2.0 was fine, JBoss 3.2.2 throw this exception while loading my .war where I'm using hibernate...

Funny thing is, that I'm able to run all the tests outside JBoss without a single complain from JRockIt...

Or shall I consider this so much hyped JVM piece of shit,
( though really fast shit.. ) and return back to good-old sun jvm?

Sun 1.4.2 JVMs seem to be very close to Jrocket if you tune. Most problems are related to garbage collection. The main difference is on multi-cpu machines because Sun's older JVMs had to complete their garbage collection cycle before getting to work generating more garbage. If you have 8 CPUs generating garbage and only one picking it up you have a big problem. That is also why IBM's JVMs have been so much faster on big systems. With 1.4.1_? they started addressing this.

Well, performace is OK. It's just so, that it does work with jboss...
I tried 2 different versions of jboss, and there vere diferent problems.

3.2.0 quickly ran out of ifle descriptors ( even tried 16384... ) while compiling JSPs, and 3.2.2 just crashed / failed class validation on
the very same .war archive...

Looks like it is "compile once ..." problem, try to recompile cglib. It can be a problem in JRockit verifier too, try to dissable it.

BTW you can try cglib-asm-1.0.jar, but I am not sure it can help. Looks like JVM needs to verify BCELBackend class any way.

Well, I tried this....

Disabling verification leads to coredump, and recompiling GLIB is
somehow complicated. If I recompile it, then I have to go
to very latest hibernate, then I have to modify mine 10-15
subprojects depending on it

Maven build failed in the tests ( and you had small typo
yesterday in sources ) ....

And funny thing, that there were no complaints with older jboss version, and the same .war archive.

So It just seems to be unreliable to me, and I'd rather leave my fingers off it...

It must be trivial to recompile cglib. Source code comes with distribution (you can retrieve any cglib version from cvs -r TAG_NAME too),
use "ant dist" to build it. You can remove BCELBackend form CodeGenerator and use ASMBackend without "autodetection" workaround.
It must be possible to modify/experiment and to build JRocket friendly jar.

"And funny thing, that there were no complaints with older jboss version"

older jboss versions do not have BCEL.jar in class path, It must not break JVM, but ...

3.2.0 ( I was referring as old ) has very same bcel.jar in his class path as 3.2.2 ( verified with binary diff ) ....

And I'm not sure the problem with open files will dissapear in 3.2.2

Of course, I can recompile CGLIB, but then there will be next bug
in another library... And in yet another library....

So it's not only CGLIB, but general unreliability...