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
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 updated
-
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
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
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 the mapper do
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:
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 (
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 ).
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 yes,
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:
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
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 (
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 (
(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
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; in the
15 matches
Mail list logo
