Re: Jo! on Phoenix

[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: AW: AW: Jo! on Phoenix

[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

[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

[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

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