You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Paul Hammant <Pa...@yahoo.com> on 2001/10/29 09:41:13 UTC
Jo! on Phoenix
Hendrik Schreiber, the author of the excellent webserver Jo! has added
Phoneix compatability as a feature.
The homepage for Jo! is http://www.tagtraum.com/jo.html
Hendrik is keen to see a release of Phoenix (he is more or less
compatabile with the latest CVS versions) *before* he lists the
availability of the sar download. Actually that's the key point, he has
done all the work himself with almost no help from me and wants to keep
the code/libraries in his source tree.
As for features, this is a full webserver with full war file webapp
capability. Not only that, but the deployment and undeployment of war
files for hosts are exposed as a service :
public void deployWAR(String hostName, String name, String ctxPath,
String warUrl) throws Exception;
public void undeployWAR(String hostName,String name) throws Exception;
This is a really significant development. Hendrik is "away from desk"
for some days, but I'd like to be the first to welcome him to our
commmunity.
Given that 'SAR-INF/lib' introduced major changes to Phoenix, could we
think of another release and announcement? The JAMES team might catch
up at that time too.
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AW: AW: Jo! on Phoenix
Posted by Peter Donald <do...@apache.org>.
On Mon, 5 Nov 2001 02:11, Hendrik Schreiber wrote:
> > It would be much nicer if there was one version of license(s) in
> > project and
> > each source file had a small pointer to them.
>
> well, I guess you are right... but on the other hand I am using this really
> slick ide IDEA by intellij (http://www.intellij.com) that automatically
> shows me the beginning of the source code whenever I open a java file...
> BTW: I am not affiliated with intellij, but IDEA is the best ide I have
> seen in a loooong time :-)
agreed. I just converted my company from using 8 different editors to using
just this one editor. All in under two hours. It is the fastyest I have seen
them change their minds about anything ! ;)
> > You will want to create a MemoryContext per web application and
> > populate it
> > with all the things appropriate. Then you will have to create an
> > InitialContextFactory. This factory would get the base context for the
> > current web application (usually stored in a ThreadLocal variable). After
> > that it *should* work ;)
>
> OK - I did a bit of reading today and my understanding of the matter is the
> following:
>
> o To support the url "java:" a javaURLContextFactory needs to be written.
> see section 3.2.2 of the current spec (jndispi.pdf)
right. The naming toolkit in excalibur I mentioned, has an
AbstractURLContextFactory that should make this easy.
> o To support different environments per war (this is a necessity), the
> context "comp" needs to have an ObjectFactory that returns different
> subcontexts depending on the contextclassloader of the calling thread. This
> is necessary because different wars are executed by a set of threads. There
> is no war-to-thread one-to-one relationship. This also means that
> ThreadLocal does not work. However a war has always a distinct Classloader
> that can be used to identify the calling war.
ContextClassLoaders are just thread locals (InheritableThreadLocals to be
precise) so ThreadLocals should work for JNDI context factory. You just have
to make sure that everywhere that the ContextClassLoader is set, so is the
JNDI context.
> o The comp context needs to be bound at some point. When?
everywhere ContextClassLoader is set (essentially before any method of .war
is claeed).
--
Cheers,
Pete
*------------------------------------------------------*
| "Common sense is the collection of prejudices |
| acquired by age 18. " -Albert Einstein |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
AW: AW: Jo! on Phoenix
Posted by Hendrik Schreiber <hs...@tagtraum.com>.
> It would be much nicer if there was one version of license(s) in
> project and
> each source file had a small pointer to them.
well, I guess you are right... but on the other hand I am using this really slick ide IDEA by intellij (http://www.intellij.com) that automatically shows me the beginning of the source code whenever I open a java file...
BTW: I am not affiliated with intellij, but IDEA is the best ide I have seen in a loooong time :-)
> yep. There would still need to be support inside jo! though as it
> has to make
> sure that it is mapped per-war. Phoenix could map it per-sar but
> that still
> needs to be reworked a bit for jo!
>
> > The way it works with JBoss is that while deploying a WAR, the
> DOM tree and
> > the webapps ContextClassLoader are handed to JBoss, which in
> turn creates a
> > "env" subcontext for "java:comp" which is specific for a
> particular webapp.
> > Of course that could be easily done by jo! as long as proper JNDI is
> > present.
>
> kool.
>
> > How much is actually provided by the standard JNDI RI that
> comes with the
> > JDK. Does it have "java:comp" contexts built in? If so, it should be a
> > piece of cake. If not, how difficult can that be?
>
> Actually JNDI is one API where you are required to write tons of
> code to get
> it up and running gracefully. However I mostly have this done and
> it can be
> grabbed from the excalibur project in the package
>
> org.apache.avalon.excalibur.naming.*
>
> You will want to create a MemoryContext per web application and
> populate it
> with all the things appropriate. Then you will have to create an
> InitialContextFactory. This factory would get the base context for the
> current web application (usually stored in a ThreadLocal variable). After
> that it *should* work ;)
OK - I did a bit of reading today and my understanding of the matter is the following:
o To support the url "java:" a javaURLContextFactory needs to be written. see section 3.2.2 of the current spec (jndispi.pdf)
o To support different environments per war (this is a necessity), the context "comp" needs to have an ObjectFactory that returns different subcontexts depending on the contextclassloader of the calling thread. This is necessary because different wars are executed by a set of threads. There is no war-to-thread one-to-one relationship. This also means that ThreadLocal does not work. However a war has always a distinct Classloader that can be used to identify the calling war.
o The comp context needs to be bound at some point. When?
I have never used JNDI a lot and certainly not implemented it... so just think of the things mentioned above as suggestions. but I do think they should be taken care of on the JNDI side.
cheers,
-hendrik
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AW: Jo! on Phoenix
Posted by Peter Donald <do...@apache.org>.
On Sat, 3 Nov 2001 21:15, Hendrik Schreiber wrote:
> Hi!
>
> > Had a look at it and it has one of the best user manuals around - I was
> > shocked ;)
>
> Well, I studied journalism :-)
ahhh ;)
> Though it also has a book/license at the top of each
>
> > source file
> > that is kinda ugly ;(
>
> I am not sure which version you looked at, but I changed the license to
> LPGL plus the unfortunately necessary Sun stuff.
I looked at the version before your last release (b5 I think?). You had to
scroll down 3 times to get to first line of code. The license does not really
need to be included at the top of every file - especially as parts (ie sun
stuff) have zero relevence to file contents abut are only relevent to
distribution as a whole.
It would be much nicer if there was one version of license(s) in project and
each source file had a small pointer to them.
> > Do you know if he plans to do servlet 2.3 ?
>
> I will, as soon as I have time.
kool.
> > excelent. Do you know off hand if he supports JNDI enc
> > references. The reason
> > is that the one of the four remaining jobs to do before Phoenix
> > goes beta is
> > to get a management console up and running. I was thinking that
> > it would be
> > very very fun to have that as a .war file that had the
> > MBeanServer passed in
> > via JNDI.
>
> jo! doesn't have any jndi support built in. Wouldn't it be a good idea to
> build JNDI support as separate block/service and let jo! use that?
yep. There would still need to be support inside jo! though as it has to make
sure that it is mapped per-war. Phoenix could map it per-sar but that still
needs to be reworked a bit for jo!
> The way it works with JBoss is that while deploying a WAR, the DOM tree and
> the webapps ContextClassLoader are handed to JBoss, which in turn creates a
> "env" subcontext for "java:comp" which is specific for a particular webapp.
> Of course that could be easily done by jo! as long as proper JNDI is
> present.
kool.
> How much is actually provided by the standard JNDI RI that comes with the
> JDK. Does it have "java:comp" contexts built in? If so, it should be a
> piece of cake. If not, how difficult can that be?
Actually JNDI is one API where you are required to write tons of code to get
it up and running gracefully. However I mostly have this done and it can be
grabbed from the excalibur project in the package
org.apache.avalon.excalibur.naming.*
You will want to create a MemoryContext per web application and populate it
with all the things appropriate. Then you will have to create an
InitialContextFactory. This factory would get the base context for the
current web application (usually stored in a ThreadLocal variable). After
that it *should* work ;)
> Here is what I will do - if jo! can create the context and add all the
> entries, it will, if not, it won't. So if an appropriate JNDI context is
> present, it will be used.
>
> What do you think?
works for me ;)
--
Cheers,
Pete
-------------------------------------------------
"Sometimes its better to keep your mouth shut and
let people think your an idiot, than to open it
and remove all doubt."
-------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
AW: Jo! on Phoenix
Posted by Hendrik Schreiber <hs...@tagtraum.com>.
Hi!
> Had a look at it and it has one of the best user manuals around - I was
> shocked ;)
Well, I studied journalism :-)
Though it also has a book/license at the top of each
> source file
> that is kinda ugly ;(
I am not sure which version you looked at, but I changed the license to LPGL plus the unfortunately necessary Sun stuff.
> Do you know if he plans to do servlet 2.3 ?
I will, as soon as I have time.
> excelent. Do you know off hand if he supports JNDI enc
> references. The reason
> is that the one of the four remaining jobs to do before Phoenix
> goes beta is
> to get a management console up and running. I was thinking that
> it would be
> very very fun to have that as a .war file that had the
> MBeanServer passed in
> via JNDI.
jo! doesn't have any jndi support built in. Wouldn't it be a good idea to build JNDI support as separate block/service and let jo! use that?
The way it works with JBoss is that while deploying a WAR, the DOM tree and the webapps ContextClassLoader are handed to JBoss, which in turn creates a "env" subcontext for "java:comp" which is specific for a particular webapp. Of course that could be easily done by jo! as long as proper JNDI is present.
How much is actually provided by the standard JNDI RI that comes with the JDK. Does it have "java:comp" contexts built in? If so, it should be a piece of cake. If not, how difficult can that be?
Here is what I will do - if jo! can create the context and add all the entries, it will, if not, it won't. So if an appropriate JNDI context is present, it will be used.
What do you think?
> Heya hendrik!
Heya back!
cheers,
-hendrik
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jo! on Phoenix
Posted by Peter Donald <do...@apache.org>.
On Mon, 29 Oct 2001 19:41, Paul Hammant wrote:
> Hendrik Schreiber, the author of the excellent webserver Jo! has added
> Phoneix compatability as a feature.
>
> The homepage for Jo! is http://www.tagtraum.com/jo.html
fun.
Had a look at it and it has one of the best user manuals around - I was
shocked ;) Though it also has a book/license at the top of each source file
that is kinda ugly ;(
It looks like a much more "raw"/"to the metal" kinda servlet engine than
others (such as catalina). I guess that is speedier to serve request but I
expect it would also make it a little harder to maintain than a a more
layered design. Do you know if he plans to do servlet 2.3 ?
> Hendrik is keen to see a release of Phoenix (he is more or less
> compatabile with the latest CVS versions) *before* he lists the
> availability of the sar download.
sounds like a good idea. I can probably do a release sometime next week or at
latest next weekend. Before that time we need to make sure everything is good
and stable and the documentation has to be updated. But other than that we
should be fine.
> Actually that's the key point, he has
> done all the work himself with almost no help from me and wants to keep
> the code/libraries in his source tree.
kool.
> As for features, this is a full webserver with full war file webapp
> capability. Not only that, but the deployment and undeployment of war
> files for hosts are exposed as a service :
>
> public void deployWAR(String hostName, String name, String ctxPath,
> String warUrl) throws Exception;
> public void undeployWAR(String hostName,String name) throws Exception;
excelent. Do you know off hand if he supports JNDI enc references. The reason
is that the one of the four remaining jobs to do before Phoenix goes beta is
to get a management console up and running. I was thinking that it would be
very very fun to have that as a .war file that had the MBeanServer passed in
via JNDI.
I have been looking at some products that have great web consoles recently
and want to try to do the same for phoenix ;)
> This is a really significant development. Hendrik is "away from desk"
> for some days, but I'd like to be the first to welcome him to our
> commmunity.
Heya hendrik!
> Given that 'SAR-INF/lib' introduced major changes to Phoenix, could we
> think of another release and announcement? The JAMES team might catch
> up at that time too.
works for me given above.
--
Cheers,
Pete
----------------------------------
Ancient Go proverb: "Only amateurs
try to come up with 'fancy' moves"
----------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: managing blocks
Posted by Peter Donald <pe...@apache.org>.
On Tue, 1 Jan 2002 09:40, vinay nair wrote:
> <Phoenix related>
> What is the way to expose a block as a managed
> resource (maybe re-using the mbeanserver present
> inside the DefaultManager)
> </Phoenix related>
Right not it is not really possible. It is however one of the things I plan
to do next with Phoenix as soon as I get some time ;)
--
Cheers,
Pete
---------------------------------------------
We shall not cease from exploration, and the
end of all our exploring will be to arrive
where we started and know the place for the
first time -- T.S. Eliot
---------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
managing blocks
Posted by vinay nair <vi...@yahoo.com>.
<Phoenix related>
What is the way to expose a block as a managed
resource (maybe re-using the mbeanserver present
inside the DefaultManager)
</Phoenix related>
Vinay.
__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
AW: AW: AW: AW: Jo! on Phoenix - compile problems
Posted by Hendrik Schreiber <hs...@tagtraum.com>.
> The problem is that I can only produce the error when the JVM is force
> shutdown (ie by ctrl-c ing the application)
if that is the only situation it occurs, that's good news :-)
> So I did a siguit just prior to shutdown. It seems that "get_self" is the
> name of the signal handler for SIGUSR2. It is located in
> libhpi.so (an IBM
> JVM library). Heres the relevent part of log
>
> SIGUSR2 : get_self (libhpi.so)
Hm. That doesn't tell me anything.
Please turn up the log level by setting jo.loglevel in etc/server.properties to a higher value - maybe 5. Also please set host.eventloglevel in hosts.properties to 5. There should be some more info in the log files server.log and event.log (all the things you never wanted to know :-)). Could you please mail me fresh logfiles with the loglevels set high. With them I might be able to better point you at some part in jo! and see where it gets stuck...
Thanks,
-hendrik
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AW: AW: AW: Jo! on Phoenix - compile problems
Posted by Peter Donald <do...@apache.org>.
On Sat, 3 Nov 2001 21:19, Hendrik Schreiber wrote:
> Pete,
>
> > Well it stalls the whole JVM with that message and I am forced to
> > kill -9 it.
> > I will try it again tomorrow and see if I can track down exactly where it
> > occurs.
>
> If it does it again, can you try a sig quit instead of the -9 (in case you
> haven't tried that) and mail the thread dump to me.
The problem is that I can only produce the error when the JVM is force
shutdown (ie by ctrl-c ing the application) and thus it is already in a
signal handler and wont get the sig quit. If I shutdown JVM gracefully (via
the test web interface thingie) then it goes down fine and I dont get that
wierd message.
So I did a siguit just prior to shutdown. It seems that "get_self" is the
name of the signal handler for SIGUSR2. It is located in libhpi.so (an IBM
JVM library). Heres the relevent part of log
SIGUSR2 : get_self (libhpi.so)
Not sure if this makes it easier to understand what
"get_self can't find pthread_self"
means. I may have to go through and put lots of System.out.printlns() in jo
to see where exactly the issue is.
--
Cheers,
Pete
--------------------------------------------------
you've made a dangerous leap right over common
sense, like some kind of metaphysical Evil Knievel
--------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
AW: AW: AW: Jo! on Phoenix - compile problems
Posted by Hendrik Schreiber <hs...@tagtraum.com>.
Pete,
> Well it stalls the whole JVM with that message and I am forced to
> kill -9 it.
> I will try it again tomorrow and see if I can track down exactly where it
> occurs.
If it does it again, can you try a sig quit instead of the -9 (in case you haven't tried that) and mail the thread dump to me.
Thanks,
-hendrik
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AW: AW: Jo! on Phoenix - compile problems
Posted by Peter Donald <do...@apache.org>.
On Fri, 2 Nov 2001 22:10, Hendrik Schreiber wrote:
> > Actually I seem to get the following printed out to console.
> >
> > get_self can't find pthread_self
> >
> > Haven't ever seen this before ...has anyone else? Does anyone
> > else get this
> > problem when running jo! ?
> >
> > I have a feeling it may be something to do with my OS/JVMs combo
> > (linux + sun
> > 1.3_001 and IBM 1.3.0).
>
> I tried it with Linux Sun JDK 1.3 and haven't seen this. There is some
> issue with some IBM JDKs that I will eventually look into... Can you give
> some more details? Does it cause problems?
Well it stalls the whole JVM with that message and I am forced to kill -9 it.
I will try it again tomorrow and see if I can track down exactly where it
occurs.
--
Cheers,
Pete
--------------------------------------------------
you've made a dangerous leap right over common
sense, like some kind of metaphysical Evil Knievel
--------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
AW: AW: Jo! on Phoenix - compile problems
Posted by Hendrik Schreiber <hs...@tagtraum.com>.
Peter,
> > works for me!
cool.
> Actually I seem to get the following printed out to console.
>
> get_self can't find pthread_self
>
> Haven't ever seen this before ...has anyone else? Does anyone
> else get this
> problem when running jo! ?
>
> I have a feeling it may be something to do with my OS/JVMs combo
> (linux + sun
> 1.3_001 and IBM 1.3.0).
I tried it with Linux Sun JDK 1.3 and haven't seen this. There is some issue with some IBM JDKs that I will eventually look into... Can you give some more details? Does it cause problems?
Thanks,
-hendrik
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AW: Jo! on Phoenix - compile problems
Posted by Peter Donald <do...@apache.org>.
On Fri, 2 Nov 2001 21:10, Peter Donald wrote:
> > To try it out,
> > - get a fresh cvs checkout of phoenix
> > - build dist
> > - download the jo! release -> http://www.tagtraum.com/
> > - unpack somehwere
> > - cd to JO_HOME/integration/phoenix4.0/
> > - set the property "phoenix.home" in build.xml to your phoenix
> > dist-directory
> > - execute ant install
> > - start phoenix
> > - jo! should be running on port 8080
> >
> > Please let me know if something is broken.
>
> works for me!
Actually I seem to get the following printed out to console.
get_self can't find pthread_self
Haven't ever seen this before ...has anyone else? Does anyone else get this
problem when running jo! ?
I have a feeling it may be something to do with my OS/JVMs combo (linux + sun
1.3_001 and IBM 1.3.0).
--
Cheers,
Pete
*-----------------------------------------------------------------------*
PROGRAM: n. a magic spell cast over a computer allowing it to turn
one's input into error messages. v.t. to engage in a pastime similar
to banging one's head against a wall, but with fewer opportunities for
reward.
*-----------------------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: AW: Jo! on Phoenix - compile problems
Posted by Peter Donald <do...@apache.org>.
On Fri, 2 Nov 2001 00:47, Hendrik Schreiber wrote:
> Hi,
hi ;)
> I just uploaded the jo! release that contains the integration code with
> Avalon-Phoenix.
kool. Will have to go download it again ;)
> To try it out,
> - get a fresh cvs checkout of phoenix
> - build dist
> - download the jo! release -> http://www.tagtraum.com/
> - unpack somehwere
> - cd to JO_HOME/integration/phoenix4.0/
> - set the property "phoenix.home" in build.xml to your phoenix
> dist-directory
> - execute ant install
> - start phoenix
> - jo! should be running on port 8080
>
> Please let me know if something is broken.
works for me!
>
> I would appreciate, if you guys released a version of phoenix that features
> the new SAR structure.
well try for end of next week or so. That work for you ?
--
Cheers,
Pete
--------------------------------
My opinions may have changed,
but not the fact that I am right
--------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
AW: Jo! on Phoenix - oops, actually no compile problems
Posted by Hendrik Schreiber <hs...@tagtraum.com>.
... forget the subject - I started a mail, that I never sent, instead - well
you know :-)
-hendrik
> -----Ursprungliche Nachricht-----
> Von: Hendrik Schreiber [mailto:hs@tagtraum.com]
> Gesendet: Thursday, November 01, 2001 14:48
> An: Avalon Developers List
> Betreff: AW: Jo! on Phoenix - compile problems
>
>
> Hi,
>
> thanks for praising, Paul :-)
>
> I just uploaded the jo! release that contains the integration code with
> Avalon-Phoenix.
>
> To try it out,
> - get a fresh cvs checkout of phoenix
> - build dist
> - download the jo! release -> http://www.tagtraum.com/
> - unpack somehwere
> - cd to JO_HOME/integration/phoenix4.0/
> - set the property "phoenix.home" in build.xml to your phoenix
> dist-directory
> - execute ant install
> - start phoenix
> - jo! should be running on port 8080
>
> Please let me know if something is broken.
>
> I would appreciate, if you guys released a version of phoenix
> that features
> the new SAR structure.
>
> Cheers,
>
> -hendrik
> __________________________________________________________________
> innoQ Deutschland GmbH Harkortstr. 21-23 D-40880 Ratingen
> Tel +49 2102 771 620 Fax +49 2102 771 601 Mobil +49 173 577 0740
> mailto:hendrik.schreiber@innoq.com
>
>
> > -----Ursprungliche Nachricht-----
> > Von: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> > Gesendet: Monday, October 29, 2001 09:41
> > An: Avalon Development
> > Betreff: Jo! on Phoenix
> >
> >
> > Hendrik Schreiber, the author of the excellent webserver Jo! has added
> > Phoneix compatability as a feature.
> >
> > The homepage for Jo! is http://www.tagtraum.com/jo.html
> >
> > Hendrik is keen to see a release of Phoenix (he is more or less
> > compatabile with the latest CVS versions) *before* he lists the
> > availability of the sar download. Actually that's the key point, he has
> > done all the work himself with almost no help from me and wants to keep
> > the code/libraries in his source tree.
> >
> > As for features, this is a full webserver with full war file webapp
> > capability. Not only that, but the deployment and undeployment of war
> > files for hosts are exposed as a service :
> >
> > public void deployWAR(String hostName, String name, String ctxPath,
> > String warUrl) throws Exception;
> > public void undeployWAR(String hostName,String name) throws
> Exception;
> >
> > This is a really significant development. Hendrik is "away from desk"
> > for some days, but I'd like to be the first to welcome him to our
> > commmunity.
> >
> > Given that 'SAR-INF/lib' introduced major changes to Phoenix, could we
> > think of another release and announcement? The JAMES team might catch
> > up at that time too.
> >
> > Regards,
> >
> > - Paul H
> >
> >
> > --
> > 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>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
AW: Jo! on Phoenix - compile problems
Posted by Hendrik Schreiber <hs...@tagtraum.com>.
Hi,
thanks for praising, Paul :-)
I just uploaded the jo! release that contains the integration code with
Avalon-Phoenix.
To try it out,
- get a fresh cvs checkout of phoenix
- build dist
- download the jo! release -> http://www.tagtraum.com/
- unpack somehwere
- cd to JO_HOME/integration/phoenix4.0/
- set the property "phoenix.home" in build.xml to your phoenix
dist-directory
- execute ant install
- start phoenix
- jo! should be running on port 8080
Please let me know if something is broken.
I would appreciate, if you guys released a version of phoenix that features
the new SAR structure.
Cheers,
-hendrik
__________________________________________________________________
innoQ Deutschland GmbH Harkortstr. 21-23 D-40880 Ratingen
Tel +49 2102 771 620 Fax +49 2102 771 601 Mobil +49 173 577 0740
mailto:hendrik.schreiber@innoq.com
> -----Ursprungliche Nachricht-----
> Von: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> Gesendet: Monday, October 29, 2001 09:41
> An: Avalon Development
> Betreff: Jo! on Phoenix
>
>
> Hendrik Schreiber, the author of the excellent webserver Jo! has added
> Phoneix compatability as a feature.
>
> The homepage for Jo! is http://www.tagtraum.com/jo.html
>
> Hendrik is keen to see a release of Phoenix (he is more or less
> compatabile with the latest CVS versions) *before* he lists the
> availability of the sar download. Actually that's the key point, he has
> done all the work himself with almost no help from me and wants to keep
> the code/libraries in his source tree.
>
> As for features, this is a full webserver with full war file webapp
> capability. Not only that, but the deployment and undeployment of war
> files for hosts are exposed as a service :
>
> public void deployWAR(String hostName, String name, String ctxPath,
> String warUrl) throws Exception;
> public void undeployWAR(String hostName,String name) throws Exception;
>
> This is a really significant development. Hendrik is "away from desk"
> for some days, but I'd like to be the first to welcome him to our
> commmunity.
>
> Given that 'SAR-INF/lib' introduced major changes to Phoenix, could we
> think of another release and announcement? The JAMES team might catch
> up at that time too.
>
> Regards,
>
> - Paul H
>
>
> --
> 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>