You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <do...@apache.org> on 2001/09/15 08:33:38 UTC
Re: Wrapping Catalina as an Avalon block
On Sat, 15 Sep 2001 16:33, Paul Hammant wrote:
> I've made reasonable progress.
kool.
> I am 90% sure that it's because catalina is tied to it's directory
> structure.
Probably - yes.
> - particularly for jar files. i.e. me putting jars in lib/
> for the sar will never get catalina to work with Phoenix. I suspect
> this because of lines like the below in
> org.apache.catalina.core.StandardContext to do with classloading
>
> File directory = new File(System.getProperty("catalina.home"),
> "jasper");
>
> That also leads onto a second point, the thing relies on catalina.home
> being set to the root of it's peculiar directory structure. In it's
> current form, it's just not going to be sarable.
Maybe the best thing for the long term is try to get the Catalina team to add
an abstraction layer in there that is backwards compatible with their current
system. I will have a look to see about the feasability of that.
> Or how about this as a proposal .... sar file format supports an
> environment.xml (instead of lib/*.jar) that looks like so...
>
> <environment>
> <env-vars>
> <env-var name="catalina.home" value="${sar-root}/catalina"/>
> <env-var name="catalina.base" value="${sar-root}/catalina"/>
> <env-vars>
The above I don't like as it changes things at a JVM level for the aplication.
> <classpath>
...snip...
may be workable. I guess I need to look at it more fully. However I think
that the catalina system does some fairly rigid things with classpath and I
suspect that what you suggest may not work. (Mainly as common has to be in
parent ClassLoader to server ClassLoader (which can not be visible to
servlets).
In the short term I suspect it may work better if common/** is put in
${phoenix.home}/lib while server/** is put in ${app.dir}/lib
> Also, it would be handy for the Block to be able to get the root
> directory of where it's sar has been unpacked to.
like BlockContext.getBaseDirectory() ? ;)
> On the positive side, I think it might be possible for the service to be
> able to have essentially createVirtualHost(...) and publishWebApp(...)
> as methods.
sounds good.
> For those that are interested I am reimplementing the main method from
> org.apache.catalina.startup.Embedded.
Want to chuck it somewhere (avalonia??) so I can have a gander?
> Lastly, Catalina is going to use it's own connection manager and thread
> pool (without code changes, there is 0% change that we could get it
> using ours).
Actually IIRC some of the connection code in Cornerstone originally came from
Catalina ;)
--
Cheers,
Pete
----------------------------------------------------------------
Fools ignore complexity. Pragmatists suffer it.
Some can avoid it. Geniuses remove it.
-- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982
----------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Wrapping Catalina as an Avalon block
Posted by Peter Donald <do...@apache.org>.
On Sun, 16 Sep 2001 22:42, Paul Hammant wrote:
> >>Also, it would be handy for the Block to be able to get the root
> >>directory of where it's sar has been unpacked to.
> >
> >like BlockContext.getBaseDirectory() ? ;)
>
> Doh!
;)
> I kinda figured that Cornerstone/apps was best. Why?
> 1) Tomcat is Apache license.
> 2) If we want the cooperation of the Tomcat team, a source forge mounted
> project will really not help win hearts and minds.
sounds good to me.
> Cool. It's not implementation or heritage I'm worried about, it is
> duplication in one VM. If we push down the road of phoenix can be a
> complete server, then it would be nice to have all sockets going through
> a single implemenetation of connection manager. Many benefits including
> load balancing and firewalling (up to a point as Socket level is not
> packet level). Ideally, Catalina could allow use of an alternative
> "void handleConnect(Socket s)" manager. Just like what I have asked the
> HypersonicSQL team to integrate.
I don't actually mind diversity so much. Diversity may add complexity in
short term but it does help "survival" in an evolving system. Maybe if the
proper abstractions were put in place then Phoenix services could be reused
internally to TC4. I suspect this is possible as long as we also implement
the appropriate TC4 interfaces. This may require a bit more work though ;)
> Can commit to cornerstone/apps/bay (The island of Catalina has an
> "Avalon Bay"). I won't push the catalina jars up, just instructions on
> how to get them or mabe an ant target that goes and gets them... In
> total it's about 20Kb being committed.
sounds good to me.
--
Cheers,
Pete
-------------------------------------------------------------
| Egoism is the drug that soothes the pain of stupidity. |
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Wrapping Catalina as an Avalon block
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>Maybe the best thing for the long term is try to get the Catalina team to add
>an abstraction layer in there that is backwards compatible with their current
>system. I will have a look to see about the feasability of that.
>
Agree, that's best strategy (see below).
>>Or how about this as a proposal .... sar file format supports an
>>environment.xml (instead of lib/*.jar) that looks like so...
>>
>> <environment>
>> <env-vars>
>> <env-var name="catalina.home" value="${sar-root}/catalina"/>
>> <env-var name="catalina.base" value="${sar-root}/catalina"/>
>> <env-vars>
>>
>
>The above I don't like as it changes things at a JVM level for the aplication.
>
Agreed.
>> <classpath>
>>
>...snip...
>
>may be workable. I guess I need to look at it more fully. However I think
>that the catalina system does some fairly rigid things with classpath and I
>suspect that what you suggest may not work. (Mainly as common has to be in
>parent ClassLoader to server ClassLoader (which can not be visible to
>servlets).
>
Of course....
>>Also, it would be handy for the Block to be able to get the root
>>directory of where it's sar has been unpacked to.
>>
>
>like BlockContext.getBaseDirectory() ? ;)
>
Doh!
>>For those that are interested I am reimplementing the main method from
>>org.apache.catalina.startup.Embedded.
>>
>
>Want to chuck it somewhere (avalonia??) so I can have a gander?
>
I kinda figured that Cornerstone/apps was best. Why?
1) Tomcat is Apache license.
2) If we want the cooperation of the Tomcat team, a source forge mounted
project will really not help win hearts and minds.
>>Lastly, Catalina is going to use it's own connection manager and thread
>>pool (without code changes, there is 0% change that we could get it
>>using ours).
>>
>
>Actually IIRC some of the connection code in Cornerstone originally came from
>Catalina ;)
>
Cool. It's not implementation or heritage I'm worried about, it is
duplication in one VM. If we push down the road of phoenix can be a
complete server, then it would be nice to have all sockets going through
a single implemenetation of connection manager. Many benefits including
load balancing and firewalling (up to a point as Socket level is not
packet level). Ideally, Catalina could allow use of an alternative
"void handleConnect(Socket s)" manager. Just like what I have asked the
HypersonicSQL team to integrate.
Can commit to cornerstone/apps/bay (The island of Catalina has an
"Avalon Bay"). I won't push the catalina jars up, just instructions on
how to get them or mabe an ant target that goes and gets them... In
total it's about 20Kb being committed.
Regards,
- Paul H
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org