I got it to work by calling wrapper.registerJMX(context).
StandardWrapper.registerJMX() is a protected method.  I extended the class
so that I can invoke StandardWrapper.registerJMX() from the subclass.

To me it appears like it is a bug.  What is the point in letting a child be
added to an already started context if the mapping does not get updated
automatically?

On Thu, Jan 8, 2009 at 8:54 PM, Filip Hanik - Dev Lists
<devli...@hanik.com>wrote:

> It's been a while since I looked at it, but once the context is started,
> the only way to update mappings it to invoke an additional JMX call to get
> the mapping registered with the connector.
> Take a look at
> org.apache.tomcat.util.http.mapper.Mapper
> org.apache.tomcat.util.http.mapper.MapperListener
>
> That's where I would start, but I think you'll have to do a bit reverse
> engineering here, since I can't remember the exact steps
>
> Filip
>
>
> Vamsavardhana Reddy wrote:
>
>> Here is the problem I want to solve.  I want to add servlet mappings to
>> Axis2ServiceServlet as the URLs come by.  For example, the first
>> servlet-mapping could be to http://localhost:8080/tuscany/service1.  At
>> this
>> time, I create a new StandardContext with contextPath "/tuscany", add a
>> StandardWrapper with mapping "/service1" to the context and add the
>> context
>> to the host.  Now when a second servlet-mapping to
>> http://localhost:8080/tuscany/service2 is to be added, I am locating the
>> context with context-path "/tuscany", and adding a StandardWrapper with
>> mapping "/service2".  As soon as context.addChild(wrapper) is called, the
>> wrapper is started.  But, the Mapper in the Connector is not updated with
>> the mapping info carried by the newly added wrapper object.  Because of
>> this, I am getting an error 404.  Is there a way to make the connector to
>> update the mapper when a new wrapper is added to the context?  I hope my
>> problem is clear.
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>


-- 
Vamsi

Reply via email to