Daniel,
Good news you have it working. Hopefully Peter's suggestion is the correct one for a solution that does not require modification of the phoenix bootloader.
Here is another idea, that means some subtle changes, but is more Phoenix friendly.
Presently you have things like
class MyComponent {
int x, y;
MyComponent() {
doConfiguration(new URL("resource://fred.txt"));
}
void doConfiguration(..) {
// assign x & y
}
// the rest of the methods for the comp
}We could change this a little (backards compatible) to be ...
class MyComponentCore {
int x, y;
public void setX(int x) {
this.x = x
}
public void setY(int y) {
this.y = y
}
// the rest of the methods for the comp
}
class MyComponent extends MyComponentCore {
MyComponent() {
doConfiguration(new URL("resource://fred.txt"));
}
public void doConfiguration(..) {
setX(..);
setY(..);
}
}
class ConfigurableComponent extends MyComponentCore implements Configurable {
public void configure(Configuration conf) throws ConfigurationException{
setX(conf.getChild("X").getValue());
setY(conf.getChild("Y").getValue());
}
}
This would essentially mean that each OpenEJB component could be instantiatble from stand-alone OpenEJB and from within an Avalonized OpenEJB. It means that the thing you are writing now has some consequences on the core OpenEJB codebase, but it should be possible to make this backwards compatible. Those that prefer comps to get their own config (props files etc), have a way of launching OpenEJB, those that prefer comps to recieve their configuration from the container also have a way of doing this.
The benefit to the Phoenix block usage of OpenEJB is that all the configuration for comps could be in config.xml
All of this depends on how much consent you can get from the rest of the OpenEJB committers of course. People tend to warm to Avalon, it's patterns and the lifecycle very slowly. More often that not other projects are happier to clone the Avalon-framework methods than use them. I guess in the end this is OK too, as it facilitates easy wrapping. The worst-fit projects are the ones that are massively tied to, say, Log4J and other massively static APIs and factories.
Hopefully this is the start of a great relationship.
Regards,
- Paul
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.
Well it is a tree of classloaders primarily. One per SAR file, above ait 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.
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]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
