Remy Maucherat wrote:
> Costin Manolache wrote:
>> If the question is about using JMX1.2 - it was alredy proposed, and it
>> seems nobody objected ( but nobody did it either ). If you want to do
>> that - all you need is update the mbean descriptors, and change all the
>> arrays to use the JNI nam
Costin Manolache wrote:
If the question is about using JMX1.2 - it was alredy proposed, and it
seems nobody objected ( but nobody did it either ). If you want to do
that - all you need is update the mbean descriptors, and change all the
arrays to use the JNI names ( [Ljava.lang.String; instead of
Remy Maucherat wrote:
> Remy Maucherat wrote:
>
>>> BTW - I assume you read the discussion on authorization - the problem
>>> is the same ( mapping requests URIs to constraints ), it would be good
>>> if we can reuse some code.
>>
>>
>> The mapping code is generic. I was thinking about having t
Remy Maucherat wrote:
BTW - I assume you read the discussion on authorization - the problem
is the same ( mapping requests URIs to constraints ), it would be good if
we can reuse some code.
The mapping code is generic. I was thinking about having the mapper do
the constraint mappings (as it's
Costin Manolache wrote:
Remy Maucherat wrote:
Costin Manolache wrote:
Remy Maucherat wrote:
Cast the notification to MBeanServerNotification :-)
Ok, it sort of works now.
The remaining problems:
- some attributes need to send JMX notifications (welcome files,
mappings, etc) so the mappe
Remy Maucherat wrote:
> Costin Manolache wrote:
>> Remy Maucherat wrote:
>
>> Cast the notification to MBeanServerNotification :-)
>
> Ok, it sort of works now.
>
> The remaining problems:
> - some attributes need to send JMX notifications (welcome files,
> mappings, etc) so the mapper can be u
Costin Manolache wrote:
Remy Maucherat wrote:
Cast the notification to MBeanServerNotification :-)
Ok, it sort of works now.
The remaining problems:
- some attributes need to send JMX notifications (welcome files,
mappings, etc) so the mapper can be updated
- the Host handling is not dynami
Remy Maucherat wrote:
> Costin Manolache wrote:
>> Remy Maucherat wrote:
>>
>>
>>>The mapper has a currently unused dependency on JNDI, and I plan to put
>>>it in the org.apache.tomcat.util.http.mapper package.
>>
>>
>> JNDI deps are fine - dependencies on org.apache.naming are not very good
>
Costin Manolache wrote:
Remy Maucherat wrote:
The mapper has a currently unused dependency on JNDI, and I plan to put
it in the org.apache.tomcat.util.http.mapper package.
JNDI deps are fine - dependencies on org.apache.naming are not very good
( since tomcat can be used in an app that uses
Remy Maucherat wrote:
> Speaking of which, I'm missing a registration for the hosts (I don't
> know if it's defined in JSR 77).
> Could we add some custom attributes on the object name for wrapper
> (giving the mapping), as well as the host registration, and still comply
> with the spec (I'd say
Remy Maucherat wrote:
> The mapper has a currently unused dependency on JNDI, and I plan to put
> it in the org.apache.tomcat.util.http.mapper package.
JNDI deps are fine - dependencies on org.apache.naming are not very good
( since tomcat can be used in an app that uses a different naming impl )
Costin Manolache wrote:
Remy Maucherat wrote:
If the question is about using JMX1.2 - it was alredy proposed, and it
seems nobody objected ( but nobody did it either ). If you want to do
that - all you need is update the mbean descriptors, and change all the
arrays to use the JNI names ( [Ljava.
Costin Manolache wrote:
Remy Maucherat wrote:
If the question is about using JMX1.2 - it was alredy proposed, and it
seems nobody objected ( but nobody did it either ). If you want to do
that - all you need is update the mbean descriptors, and change all the
arrays to use the JNI names ( [Ljava.l
Remy Maucherat wrote:
> (This question is for Costin)
>
> As I've mentioned before, I'm writing a new mapper to replace the
> current 5.0 request mapper, which is a major performance problem right
> now.
>
> The implementation goes well enough (I'll likely commit something today
> or tomorrow; i
(This question is for Costin)
As I've mentioned before, I'm writing a new mapper to replace the
current 5.0 request mapper, which is a major performance problem right now.
The implementation goes well enough (I'll likely commit something today
or tomorrow; in the end, there are no fancy algorit
15 matches
Mail list logo