DO NOT REPLY [Bug 37302] New: - Custom context loader unable to find Tomcat jar files

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37302

   Summary: Custom context loader unable to find Tomcat jar files
   Product: Tomcat 5
   Version: 5.5.12
  Platform: Other
OS/Version: other
Status: NEW
  Severity: regression
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I have a custom context classloader that worked with any Tomcat 4 and 5
versions, excepted 5.5.12.
With Tomcat 5.5.12, my loader can't find classes from Tomcat jar files (jar
files from /common/lib).
The problem is that custom loader's constructor receive an instance of
AppClassloader (it looks like it is the 'System' classloader). Previously
loader's constructor received an instance of StandardClassloader (which should
be the 'Common' classloader)

I found the following change in Tomcat 5.5.12 compared to Tomcat 5.5.9 : in
Tomcat 5.5.9 'addRuleInstances' method in 'ContextRuleSet' class contained the
following line :
 digester.addRule(prefix + "Context",
 new CopyParentClassLoaderRule());

In Tomcat 5.5.12, this line was removed. 

Reintegrting this line solve my problem. Maybe this removal was done on purpose
but I didn't find any explanation for it.

Bruno

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Status/Authority of AJP/1.5

[Henri Gomez]

using AJP or HTTP or WHATEVERP protocol you want, the current need for
me in my production systems is to be able to add / remove a tomcat
machine to a LoadBalancing farm without having to restart the Apache 2
web server.

A  WEB admin (I work with them each days) would like to add / remove a
tomcat dynamically, for example using an admin webapp on an
'load-balancing administrator console'  running on a webapp hosted by
a tomcat or may be even a pure Apache 2 application.

If you told me it's impossible to add a REQUEST mapper (ie JkMount)
dynamically to a running Apache 2.0, I say amen and we'll wait for
HTTPD team to allow that.

But something we could do allready is to add/remove a tomcat from a lb worker ?

2005/10/25, Costin Manolache <[EMAIL PROTECTED]>:
> On 10/25/05, Mladen Turk <[EMAIL PROTECTED]> wrote:
> > Costin Manolache wrote:
> > > DBUS is a good example in IMO - I'm not
> > > saying to use their impl, which doesn't fit, just the protocol spec.
> >
> > The major power of AJP protocol is known-header-name indexing, and
> > IMHO there is no other protocol that is HTTP application focused.
>
> Well, any protocol can do this - with the right message.
>
> In this case: it'll be:
>  enum  knownHeadersCode={  }
>  and the message will have an array of ( knownHeaderCode, string ) and
> then ( string string)
>
> Or some other variation - there is nothing so special in Ajp that
> can't be encoded in a standard protocol. Except the fact that ajp is
> not extensible - so it may save a few bytes.
>
>
> > If there is really a need for a completely new protocol,
> > and I doubt there is a real need for that right now, we must presume
> > that the primary intent of the protocol is to allow communication of
> > two well known and defined http applications.
>
> Sure - but this can be expressed as well on top of a more standard (
> or common ) marshalling. Marshalling is not specific to any
> application, not even in ajp ( maybe the stupid 'first chunk' - but
> even this can be expressed with few extra bytes in a normal protocol
> ).
>
> The API you expose - i.e. the message signatures - should remain
> specific to the http
> app. And a standard protocol would allow you to add all kind of extra
> signatures.
>
>
> > If you look at the XDR protocol, each 'string' type message is prefixed
> > with additional two bytes compared with AJP, so beside that, the lack of
> > header indexing would at least double the packet size, and downgrade the
> > performance by twice.
>
> I don't think the 2 extra bytes is such a big problem.
>
> Actually there is one thing that is unique to AJP - the callbacks done
> over the same connection, as responses ( since tomcat can't initiate a
> call ). But even this can be expressed in a proper RPC - by having the
> callback as a normal response.
>
> Costin
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Status/Authority of AJP/1.5

[Chris Lamprecht]

> If you told me it's impossible to add a REQUEST mapper (ie JkMount)
> dynamically to a running Apache 2.0, I say amen and we'll wait for
> HTTPD team to allow that.

You can do this with version 1.2.14 (maybe older versions as well) by
using a JkMountFile instead of JkMount directives.  The JkMountFile
file is re-read every 60 seconds or so, and made live with no restart.

> But something we could do allready is to add/remove a tomcat from a lb worker 
> ?

Yes, this currently requires at apache restart or at least an apache
"graceful" restart.  However, you can dynamically (during runtime) add
and remove _existing_ tomcat workers from a load balancer, using the
JkStatus status worker page.

-Chris

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 37302] - Custom context loader unable to find Tomcat jar files

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37302


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2005-10-29 23:16 ---
This rule is useless.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Status/Authority of AJP/1.5

[Costin Manolache]

On 10/29/05, Henri Gomez <[EMAIL PROTECTED]> wrote:
> using AJP or HTTP or WHATEVERP protocol you want, the current need for
> me in my production systems is to be able to add / remove a tomcat
> machine to a LoadBalancing farm without having to restart the Apache 2
> web server.

Sounds like a very reasonable requirement. My point was that this is
not a requirement for the AJP protocol itself - but a requirement for
Apache and whatever modules are used in apache for load balancing and
forwarding.

How you interact with Apache to dynamically add machines ( and
generally - to configure it ) is yet another separate problem.

I think it is far better for anyone who has this requirement to
decouple the problems, and not try to mix wire protocol for forwarding
with the mechanism and protocol for management.



> A  WEB admin (I work with them each days) would like to add / remove a
> tomcat dynamically, for example using an admin webapp on an
> 'load-balancing administrator console'  running on a webapp hosted by
> a tomcat or may be even a pure Apache 2 application.
>
> If you told me it's impossible to add a REQUEST mapper (ie JkMount)
> dynamically to a running Apache 2.0, I say amen and we'll wait for
> HTTPD team to allow that.

AFAIK apache2 can do this with a restart, or with a module that does
dynamic mapping and has runtime reconfiguration support, like jk2 did.


>
> But something we could do allready is to add/remove a tomcat from a lb worker 
> ?

Yes, it should be possible to do this - but I'm not sure what that has
to do with the AJP protocol.

You need some support in the apache module, and then a way to
interface with the module - eihter using a file + a signal or special
URL, etc, etc.

Costin


>
> 2005/10/25, Costin Manolache <[EMAIL PROTECTED]>:
> > On 10/25/05, Mladen Turk <[EMAIL PROTECTED]> wrote:
> > > Costin Manolache wrote:
> > > > DBUS is a good example in IMO - I'm not
> > > > saying to use their impl, which doesn't fit, just the protocol spec.
> > >
> > > The major power of AJP protocol is known-header-name indexing, and
> > > IMHO there is no other protocol that is HTTP application focused.
> >
> > Well, any protocol can do this - with the right message.
> >
> > In this case: it'll be:
> >  enum  knownHeadersCode={  }
> >  and the message will have an array of ( knownHeaderCode, string ) and
> > then ( string string)
> >
> > Or some other variation - there is nothing so special in Ajp that
> > can't be encoded in a standard protocol. Except the fact that ajp is
> > not extensible - so it may save a few bytes.
> >
> >
> > > If there is really a need for a completely new protocol,
> > > and I doubt there is a real need for that right now, we must presume
> > > that the primary intent of the protocol is to allow communication of
> > > two well known and defined http applications.
> >
> > Sure - but this can be expressed as well on top of a more standard (
> > or common ) marshalling. Marshalling is not specific to any
> > application, not even in ajp ( maybe the stupid 'first chunk' - but
> > even this can be expressed with few extra bytes in a normal protocol
> > ).
> >
> > The API you expose - i.e. the message signatures - should remain
> > specific to the http
> > app. And a standard protocol would allow you to add all kind of extra
> > signatures.
> >
> >
> > > If you look at the XDR protocol, each 'string' type message is prefixed
> > > with additional two bytes compared with AJP, so beside that, the lack of
> > > header indexing would at least double the packet size, and downgrade the
> > > performance by twice.
> >
> > I don't think the 2 extra bytes is such a big problem.
> >
> > Actually there is one thing that is unique to AJP - the callbacks done
> > over the same connection, as responses ( since tomcat can't initiate a
> > call ). But even this can be expressed in a proper RPC - by having the
> > callback as a normal response.
> >
> > Costin
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]