You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apps-dev@avalon.apache.org by "Daniel S. Haischt" <si...@gmx.net> on 2002/09/19 14:03:58 UTC

[QUESTION] avalon-phoenix block for OpenEJB

hello,

i am currently developing an avalon-phoenix block
for OpenEJB.

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.

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: daniel.haischt@daniel-s-haischt.biz
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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: AW: [QUESTION] avalon-phoenix block for OpenEJB

Posted by Paul Hammant <Pa...@yahoo.com>.
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:Paul_Hammant@yahoo.com]
>>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: daniel.haischt@daniel-s-haischt.biz
>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:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>  
>




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


AW: [QUESTION] avalon-phoenix block for OpenEJB

Posted by "Daniel S. Haischt" <si...@gmx.net>.
hello,

> -----Ursprüngliche Nachricht-----
> Von: Peter Donald [mailto:peter@apache.org]
> Gesendet: Sonntag, 22. September 2002 07:25
> An: Avalon Applications Developers List
> Betreff: Re: [QUESTION] avalon-phoenix block for OpenEJB
>
>
> On Fri, 20 Sep 2002 21:23, Daniel S. Haischt wrote:
> > 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.
>
> yea!
>
> > 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.
>
> eek. As per last mail. You could possibly place them in a jar and
> put the jar
> in $PHOENIX_HOME/lib
>

ok, placed a jar called openejb-urlhandler.jar into $PHOENIX_HOME/lib.
that did the trick ;-)

regards

daniel s. haischt
--



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [QUESTION] avalon-phoenix block for OpenEJB

Posted by Peter Donald <pe...@apache.org>.
On Fri, 20 Sep 2002 21:23, Daniel S. Haischt wrote:
> 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.

yea!

> 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.

eek. As per last mail. You could possibly place them in a jar and put the jar 
in $PHOENIX_HOME/lib

Anyways feel free to ask any questions. 

-- 
Cheers,

Peter Donald
"All my life I wanted to be someone; I guess I should have been more 
specific."
-- Jane Wagner


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


AW: [QUESTION] avalon-phoenix block for OpenEJB

Posted by "Daniel S. Haischt" <si...@gmx.net>.
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:Paul_Hammant@yahoo.com]
> 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: daniel.haischt@daniel-s-haischt.biz
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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [QUESTION] avalon-phoenix block for OpenEJB

Posted by Paul Hammant <Pa...@yahoo.com>.
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.

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....

    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?

Regards,

- Paul


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: AW: [QUESTION] avalon-phoenix block for OpenEJB

Posted by Paul Hammant <Pa...@yahoo.com>.
Daniel 

>changed all occurences of ClassLoader.getSystemResource() to ...
>
> -> Thread.currentThread().getContextClassLoader().getResource( resource );
>
>allthough, i am not quite sure whether that is a better approach.
>  
>
I tend to recomend people do ..

  this.getClass().getClassLoader().getResource()

.. instead of the context classloader stuff.  Somehow it feels cleaner.

- Paul


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


AW: [QUESTION] avalon-phoenix block for OpenEJB

Posted by "Daniel S. Haischt" <si...@gmx.net>.
hello,

> -----Ursprüngliche Nachricht-----
>
> There are two options for you to fix your problem. You could extract the
> resource URL handler into another jar and place the jar in
> $PHOENIX_HOME/lib.
> However I would instead recomend that you change the OpenEJB code (if you
> have access to it) so that
>
> new URL( "resource:/x.txt" );
>
> is replaced with
>
> getClassLoader().getResource( "/x.txt" );
>
> This will be a lot more portable to different environments,
> should be backward
> compatible and should also work from within phoenix.

changed all occurences of ClassLoader.getSystemResource() to ...

 -> Thread.currentThread().getContextClassLoader().getResource( resource );

allthough, i am not quite sure whether that is a better approach.

regards

daniel s. haischt
--



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [QUESTION] avalon-phoenix block for OpenEJB

Posted by Peter Donald <pe...@apache.org>.
On Thu, 19 Sep 2002 22:03, Daniel S. Haischt wrote:
> i am currently developing an avalon-phoenix block
> for OpenEJB.

Fantastic!

> 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.

Yep. The problem is that each .sar file has it's own ClassLoader and this 
different from the System classloader (which is where the URLStreamHandler is 
loaded from).

> i would appreciate it, if you could explain the
> classloader system of avalon-phoenix a little
> bit further.

The ClassLoader arrangement is actually undergoing some change before the next 
release. However I will try to explain how it currently works. 

We currently have the system classloader that contains all the files in 
$PHOENIX_HOME/bin/phoenix-client.jar and $PHOENIX_HOME/lib/*.jar

The Container classloader has system classloader as parent and loads all 
classes from $PHOENIX_HOME/bin/lib/*.jar

Each Application/.sar file also has it's own classloader with system 
classloader as parent.

In the future we plan to migrate to something like what is described at 
http://jakarta.apache.org/ant/myrmidon/classloader.html (Except replace Antlib 
with .sar file). We also plan to allow users to build their own ClassLoader 
hierarchy (which is more complex but may be useful for you). For an 
explanation of that have a look at

http://jakarta.apache.org/avalon/excalibur/loader/

There are two options for you to fix your problem. You could extract the 
resource URL handler into another jar and place the jar in $PHOENIX_HOME/lib. 
However I would instead recomend that you change the OpenEJB code (if you 
have access to it) so that 

new URL( "resource:/x.txt" );

is replaced with

getClassLoader().getResource( "/x.txt" );

This will be a lot more portable to different environments, should be backward 
compatible and should also work from within phoenix.

-- 
Cheers,

Peter Donald
Sufficiently advanced science is 
 indistinguishable from magic" 
               -- Arthur C. Clarke


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>