hello, first of all the good news - OpenEJB runs now within phoenix. i am working out some minor issues such as getting rid of some test that fails while running OpenEJB within phoenix.
i consider the current setup a real hack ;-) i had to copy the URL handler classes to the phoenix-loader.jar to get it recognized during the startup phase. that means, that i did not manipulate the phonix classes itself but i added some classes to the phoenix-loader.jar file. > -----Urspr�ngliche Nachricht----- > Von: Paul Hammant [mailto:[EMAIL PROTECTED] > Gesendet: Freitag, 20. September 2002 08:46 > An: Avalon Applications Developers List > Betreff: Re: [QUESTION] avalon-phoenix block for OpenEJB > > > Daniel, > > >i am currently developing an avalon-phoenix block > >for OpenEJB. > > > > > Nexct to the release of Pheonix, this is probably the most significant > news all year for the Avalon project. Wellcome Daniel, I hope this is > the start of a great relationship. > > >i am having some problems with the avalon classloader. > > > >OpenEJB uses a custom java.net.URLStreamHandler that > >manages resources of the form 'resource:/'. that handler > >is contained within the openejb.jar file and gets > >registered by setting the 'java.protocol.handler.pkgs' > >system property. > > > >this happens before initializing any OpenEJB specific > >component. > > > >allthough i am still having problems, loading files > >from the SAR file using the 'resource:/' identifier. > >it seems that the protocol handler wont be found, > >allthough it is definitly within the block's SAR file. > > > >i would appreciate it, if you could explain the > >classloader system of avalon-phoenix a little > >bit further. > > > > > Well it is a tree of classloaders primarily. One per SAR file, above a > couple that constiture Phoenix and perhaps its bootloader. in the past i adopted the Tomcat classloader hierarchy and had the same problem with the custom URL handler. do you delegate requests to the parent classloader, if a class could not be found within the current classloader? i mean the tomcat folks are delegating their requests up to the system classloader if they are unable to find classes in their own classloaders. there was a text file within the phoenix/avalon CVS tree that described a modular classloader system. did u implement that proposal? > > Is there any chance you could make a URLStreamHandler using modal block > say based on the 'Hello' demo (avalon-apps/demo) that works when lanched > via main, but does not when launched in phoenix? Actually it seems an > obvious thing to make myself, so I'll give it a go on Saturday. > > I'm look for other solutions, and at the OpenEJB source now. It is a > neat way of loading resource files.... personally i think it might be a neat way, but it caused also alot of problems to me during the past. the current URL handler is tightly bound to the OpenEJB architecture. as said before, the URL handler was the first peace of code that caused problems if i tried to integrate OpenEJB into a different application server. another issue is that every util helper class that loads classes from a classloader in OpenEJB, are calling ClassLoader.getSystemResource() and not getResource(). that approach causes the system to _allways_ search for resources withing the system classloader scope. actually the resources aren't ther. they are located in the SAR file or in a different Jar that has its own classloader. > > Searching for: resource: > src\facilities\org\openejb\alt\config\ConfigUtils.java(716): URL > defaultConfig = new URL("resource:/default.openejb.conf"); > src\facilities\org\openejb\alt\config\Deploy.java(660): > out.print("\nResource: "); > src\facilities\org\openejb\alt\config\Deploy.java(871): > versionInfo.load( new URL( "resource:/openejb-version.properties" > ).openConnection().getInputStream() ); > src\facilities\org\openejb\alt\config\Deploy.java(884): > versionInfo.load( new URL( "resource:/openejb-version.properties" > ).openConnection().getInputStream() ); > src\facilities\org\openejb\alt\config\Deploy.java(893): InputStream > in = new URL( "resource:/openejb/deploy.txt" > ).openConnection().getInputStream(); > src\facilities\org\openejb\alt\config\Deploy.java(909): > versionInfo.load( new URL( "resource:/openejb-version.properties" > ).openConnection().getInputStream() ); > src\facilities\org\openejb\alt\config\Deploy.java(918): InputStream > in = new URL( "resource:/openejb/deploy-examples.txt" > ).openConnection().getInputStream(); > src\facilities\org\openejb\alt\config\DTDResolver.java(76): // load > resource:/openejb/dtds/ejb-jar_1_1.dtd > src\facilities\org\openejb\alt\config\DTDResolver.java(77): URL dtd > = new URL("resource:/openejb/dtds/"+dtdName); > src\main\org\openejb\OpenEJB.java(158): versionInfo.load( new URL( > "resource:/openejb-version.properties" > ).openConnection().getInputStream() ); > src\main\org\openejb\util\JarUtils.java(71): * of the form > "resource:/path". > src\main\org\openejb\util\JarUtils.java(90): URL url = new > URL("resource:/"+path); > src\main\org\openejb\util\JarUtils.java(94): * URL or a resource: > URL, we must strip off the config file location > src\main\org\openejb\util\Logger.java(72): System.setProperty( > "log4j.configuration", "resource:/default.logging.conf" ); > src\server\org\openejb\server\EjbDaemon.java(1100): > versionInfo.load( new URL( "resource:/openejb-version.properties" > ).openConnection().getInputStream() ); > src\server\org\openejb\server\EjbDaemon.java(1112): > versionInfo.load( new URL( "resource:/openejb-version.properties" > ).openConnection().getInputStream() ); > src\server\org\openejb\server\EjbDaemon.java(1121): InputStream in = > new URL( "resource:/openejb/ejbserver.txt" > ).openConnection().getInputStream(); > src\server\org\openejb\server\EjbDaemon.java(1137): > versionInfo.load( new URL( "resource:/openejb-version.properties" > ).openConnection().getInputStream() ); > src\server\org\openejb\server\EjbDaemon.java(1146): InputStream in = > new URL( "resource:/openejb/ejbserver-examples.txt" > ).openConnection().getInputStream(); > src\server\org\openejb\server\Stop.java(114): versionInfo.load( new > URL( "resource:/openejb-version.properties" > ).openConnection().getInputStream() ); > src\server\org\openejb\server\Stop.java(123): InputStream in = new > URL( "resource:/openejb/stop.txt" ).openConnection().getInputStream(); > src\server\org\openejb\server\Stop.java(139): versionInfo.load( new > URL( "resource:/openejb-version.properties" > ).openConnection().getInputStream() ); > src\server\org\openejb\server\Stop.java(148): InputStream in = new > URL( "resource:/openejb/stop-examples.txt" > ).openConnection().getInputStream(); > src\server\org\openejb\server\admin\HttpResponse.java(196): > versionInfo.load( new URL( "resource:/openejb-version.properties" > ).openConnection().getInputStream() ); > src\server\org\openejb\server\admin\text\Command.java(120): URL dir > = new URL("resource:/openejb/server/commandlist.txt"); > src\server\org\openejb\server\admin\text\Version.java(68): > versionInfo.load( new URL( "resource:/openejb-version.properties" > ).openConnection().getInputStream() ); > Found 26 occurrence(s) in 11 file(s) > > ... but a little away from the normal Phoenix block configuration (see > use of Configurable in the demos). Having said that, as long as there > is only one OpenEJB server in a single Phoenix instance it should work > perfectly (that is when we get it working). Do you have a CVS depot or > branch that represents your working state? > personally i would like to see an architecture that implements each single container, that is the MDB container the CMP container etc., as a avalon service. frankly, i don't really appreciate the aproach of adopting OpenEJB 100%. i would like to have some parts, like that underlying application server infrastructure, solely implemented using avalon. the other parts that are EJB specific, like the containers etc. could than be completly adopted from the OpenEJB project. right now, for me it seems that the current solution is just a wrapper that encapsulates the complete OpenEJB architecture to be phoenix compliant. btw - the complete OpenEJB ConfigurationFactory can be dropped. it's just a facillity that can be replaced. that way it should be possible to write a configuration/assembly system that is phoenix compliant. i am currently setting up a new OS project that aims to provide a complete embedded application server system for mobile devices (such as cell phones, PocketPCs palm sized devices etc.) the project is called iChilli - and aims to provide a distributed application server system that provides caching and replication capabilities. the system consists of ... -> one client peer that is able to operate partitially in offline mode. that is important cause mobile devices are not allways connected to the internet. for that the user to a specific application. the application including the needed data, gets transfered to the client device. after working in offline mode, the client has to go online from time to time to replicate its partitioned data. -> a server peer that is J2EE compatible. if possible i want to implement that part using avalon/phoenix. it will demonstrate that it's possible to implement real complex systems using avalon/phoenix. additionally to the J2EE specification, it will be possible to subscribe to applications, transfere them to a mobile device and finally reintegrate the manipulated data back to the J2EE application server. i have in mind that this scenario has to somehow work similar to the Coda distributed filesystem. i can send you some powerpoint slides about iChilli, if you wish. the project will be available at sourceforge.net. hopfully i am able to setup a first version of the web site today, including a copy if my local CVS modules that am i currently maintaining @ home. btw - is this the right list, or should i subscribe to another avalon list? With best regards / Mit freundlichen Gruessen Daniel S. Haischt IT Consulting ______________________________ [revolutionary and alpha geek] Daniel S. Haischt Grabenstrasse 11 D-71083 Herrenberg G E R M A N Y FON: +49 -7032-992909 +49 -700-DHAISCHT FAX: +49 -7032-992910 CELLULAR: +49 -172-7668936 email: [EMAIL PROTECTED] web: http://www.daniel-s-haischt.biz -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS dx s:- a- C++ UB++++ P+++ L++++ E W+++ N+++ o-- K- w--- O++ M++ V- PS+ PE++ Y+ PGP++ t+++ 5+ X+++ R+ tv++ b+++ DI+ D+++ G e++ h-- r+ y+++++ ------END GEEK CODE BLOCK------ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
