Menu
▾
▴
openjmx-devel — OpenJMX Developers list
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(277) |
Dec
(103) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(320) |
Feb
(100) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|
From: Bordet, S. <Sim...@co...> - 2002-01-30 15:12:27
|
Hi, > I guess it would be nice too to be able to control RMID with a MBean. > For filters, this is RMID you are going to be in need of and=20 > not really rmiregistry... Yes. Go on !=20 Devil-ly yours ]:-) Simon |
|
From: B. <jer...@xt...> - 2002-01-30 15:09:18
|
I guess it would be nice too to be able to control RMID with a MBean. For filters, this is RMID you are going to be in need of and not really rmiregistry... Jerome. |
|
From: Carlos Q. <Car...@ge...> - 2002-01-30 15:05:41
|
> -----Original Message----- > From: Bordet, Simone [mailto:Sim...@co...] > Sent: 30 January 2002 17:02 > To: ope...@li... > Subject: RE: [Openjmx-devel] SMTP MBean >=20 > Hi, >=20 > > >where the heck is it packaged ? Which jar ? > > It goes to openjmx-tools.jar >=20 > Are you sure ? Cannot find it running main target. It is not built because > I don't have mail.jar ? It works form me You should see a message at the beginning saying java.mail=3Dtrue indicating that the required classes are found. If you get java.mail=3Djavamail.present Then your missing either mail.jar or activation.jar >=20 > Simon >=20 > _______________________________________________ > Openjmx-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjmx-devel |
|
From: Bordet, S. <Sim...@co...> - 2002-01-30 15:01:51
|
Hi, > >where the heck is it packaged ? Which jar ? > It goes to openjmx-tools.jar Are you sure ? Cannot find it running main target. It is not built = because I don't have mail.jar ? Simon |
|
From: Carlos Q. <Car...@ge...> - 2002-01-30 14:57:16
|
> -----Original Message----- > From: Bronwen Cassidy [mailto:Bro...@ja...] > Sent: 30 January 2002 16:52 > To: Openjmx-Devel (E-mail) > Subject: RE: [Openjmx-devel] SMTP MBean >=20 > The jaf.jar can be downloaded from this link > http://java.sun.com/products/javabeans/glasgow/jaf.html :-) Actually the jar is activation.jar (Don't know why) And is not required to compile but to run. However it seemed to me better to put it as required to compile to remind you that you need it >=20 >=20 > > -----Original Message----- > > From: Bordet, Simone [mailto:Sim...@co...] > > Sent: 30 January 2002 14:48 > > To: ope...@li... > > Subject: RE: [Openjmx-devel] SMTP MBean > > > > > > Hi, > > > > where the heck is it packaged ? Which jar ? > > > > Simon > > > > > -----Original Message----- > > > From: Carlos Quiroz [mailto:car...@ge...] > > > Sent: mercoledi 30 gennaio 2002 14:57 > > > To: ope...@li... > > > Subject: [Openjmx-devel] SMTP MBean > > > > > > > > > Hi all > > > > > > I just commited a SMTP MBean as an extra tool. It is > > > basically meant to send > > > e-mails if something happens for instance some monitor notification. > > > > > > If you want to compile add the mail.jar and activation.jar > > > (From JavaMail 1.2 > > > and JAF 1.0.1) to the lib dir. > > > > > > The class should be included in the openjmx-tools.jar > > > > > > I'll be writing docs soon > > > > > > Regards > > > > > > Carlos Quiroz > > > > > > _______________________________________________ > > > Openjmx-devel mailing list > > > Ope...@li... > > > https://lists.sourceforge.net/lists/listinfo/openjmx-devel > > > > > > > _______________________________________________ > > Openjmx-devel mailing list > > Ope...@li... > > https://lists.sourceforge.net/lists/listinfo/openjmx-devel > > >=20 > _______________________________________________ > Openjmx-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjmx-devel |
|
From: Bronwen C. <Bro...@ja...> - 2002-01-30 14:53:20
|
The jaf.jar can be downloaded from this link http://java.sun.com/products/javabeans/glasgow/jaf.html :-) > -----Original Message----- > From: Bordet, Simone [mailto:Sim...@co...] > Sent: 30 January 2002 14:48 > To: ope...@li... > Subject: RE: [Openjmx-devel] SMTP MBean > > > Hi, > > where the heck is it packaged ? Which jar ? > > Simon > > > -----Original Message----- > > From: Carlos Quiroz [mailto:car...@ge...] > > Sent: mercoledi 30 gennaio 2002 14:57 > > To: ope...@li... > > Subject: [Openjmx-devel] SMTP MBean > > > > > > Hi all > > > > I just commited a SMTP MBean as an extra tool. It is > > basically meant to send > > e-mails if something happens for instance some monitor notification. > > > > If you want to compile add the mail.jar and activation.jar > > (From JavaMail 1.2 > > and JAF 1.0.1) to the lib dir. > > > > The class should be included in the openjmx-tools.jar > > > > I'll be writing docs soon > > > > Regards > > > > Carlos Quiroz > > > > _______________________________________________ > > Openjmx-devel mailing list > > Ope...@li... > > https://lists.sourceforge.net/lists/listinfo/openjmx-devel > > > > _______________________________________________ > Openjmx-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjmx-devel > |
|
From: Carlos Q. <car...@ge...> - 2002-01-30 14:53:02
|
>Hi, > >> Hi >>=20 >> Shall we add docs as Tools/Naming, Tools/SMTP at top level and=20 >> Examples/Tools/... > >I would rename chapter 4 to Tools, so that will result this: > >4. Tools > Adaptors > HTTPAdaptor > XSLTProcessor > RMIAdaptor > Naming > JavaMail Agreed > >For chapter 5, I will propose this: > >5. Examples > Services > RelationService > MLet > ... > MBeans > RMI MBean > JavaMail MBean > Naming MBean > Tools > XDoclet > >What do you think ? Yeah I think is ok. Do you have time to change index.xml? > >Simon > >_______________________________________________ >Openjmx-devel mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/openjmx-devel > |
|
From: Carlos Q. <car...@ge...> - 2002-01-30 14:52:07
|
>Hi, > >where the heck is it packaged ? Which jar ? It goes to openjmx-tools.jar > >Simon > >> -----Original Message----- >> From: Carlos Quiroz [mailto:car...@ge...] >> Sent: mercoledi 30 gennaio 2002 14:57 >> To: ope...@li... >> Subject: [Openjmx-devel] SMTP MBean >>=20 >>=20 >> Hi all >>=20 >> I just commited a SMTP MBean as an extra tool. It is=20 >> basically meant to send=20 >> e-mails if something happens for instance some monitor notification. >>=20 >> If you want to compile add the mail.jar and activation.jar=20 >> (From JavaMail 1.2=20 >> and JAF 1.0.1) to the lib dir. >>=20 >> The class should be included in the openjmx-tools.jar >>=20 >> I'll be writing docs soon >>=20 >> Regards >>=20 >> Carlos Quiroz >>=20 >> _______________________________________________ >> Openjmx-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/openjmx-devel >>=20 > >_______________________________________________ >Openjmx-devel mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/openjmx-devel > |
|
From: Bordet, S. <Sim...@co...> - 2002-01-30 14:48:40
|
Hi, where the heck is it packaged ? Which jar ? Simon > -----Original Message----- > From: Carlos Quiroz [mailto:car...@ge...] > Sent: mercoledi 30 gennaio 2002 14:57 > To: ope...@li... > Subject: [Openjmx-devel] SMTP MBean >=20 >=20 > Hi all >=20 > I just commited a SMTP MBean as an extra tool. It is=20 > basically meant to send=20 > e-mails if something happens for instance some monitor notification. >=20 > If you want to compile add the mail.jar and activation.jar=20 > (From JavaMail 1.2=20 > and JAF 1.0.1) to the lib dir. >=20 > The class should be included in the openjmx-tools.jar >=20 > I'll be writing docs soon >=20 > Regards >=20 > Carlos Quiroz >=20 > _______________________________________________ > Openjmx-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjmx-devel >=20 |
|
From: Bordet, S. <Sim...@co...> - 2002-01-30 14:48:06
|
Hi,
> Hi
>=20
> Shall we add docs as Tools/Naming, Tools/SMTP at top level and=20
> Examples/Tools/...
I would rename chapter 4 to Tools, so that will result this:
4. Tools
Adaptors
HTTPAdaptor
XSLTProcessor
RMIAdaptor
Naming
JavaMail
For chapter 5, I will propose this:
5. Examples
Services
RelationService
MLet
...
MBeans
RMI MBean
JavaMail MBean
Naming MBean
Tools
XDoclet
What do you think ?
Simon
|
|
From: Carlos Q. <car...@ge...> - 2002-01-30 14:40:42
|
>Hi,=20 > >I just committed a Naming MBean. > >It basically wraps the rmiregistry and does not need any additional libr= ary,=20 since the whole stuff is in the JDK. > >It allows to run inVM the rmiregistry. > >For now there are no particular classloader tricks to keep the codebase=20 annotation, they might me added later. Hi Shall we add docs as Tools/Naming, Tools/SMTP at top level and=20 Examples/Tools/... Regards > >Simon > >_______________________________________________ >Openjmx-devel mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/openjmx-devel > |
|
From: Bordet, S. <Sim...@co...> - 2002-01-30 14:36:18
|
Hi,=20 I just committed a Naming MBean. It basically wraps the rmiregistry and does not need any additional = library, since the whole stuff is in the JDK. It allows to run inVM the rmiregistry. For now there are no particular classloader tricks to keep the codebase = annotation, they might me added later. Simon |
|
From: Bordet, S. <Sim...@co...> - 2002-01-30 14:04:54
|
Hi, > > If you serialize the filter it is uploaded to the agent, yes. > > My scenario is with the agent running in some server and the client > (Let's say a swing app) writes the filter above and adds a listener. > Then the listener will be serialized and sent to the agent.=20 Of course no ! If the listener is run in the server, how can the swing app be notified of events ? The listener is always remote (from server point of view), and runs in the client. > Are we talking about the same idea? > >=20 > > > How using for instance a web > > > server in the codebase? > >=20 > > Not following. > > Obviously you cannot just send a serialized object to the agent and > expect it to know how to deserialize it and execute.=20 > You have to also > download the class definition which may be available in a web=20 > server.=20 No, the server already has it. It will be a pain to force the clients to do all the above. I set up a better implementation, client needs to do nothing :) > If > you don't allow this then the code has to be introduced beforehand and > is therefore trusted. Maybe you could clarify this but I think this > scenario always calls for a security manager Not necessarly, see above. We serialize known and trusted classes, client code is transparent. The proxy pattern. > My point is that this problem is much broader than only the=20 > filter. You > could upload a MBean which does something similar Yes, the problem is broader. Once you add adaptors, you need the Agent run under security manager, since by design you can create MBeans from a client. I just wanted here to know the opinion on filters, but the security issue must be faced. Fortunately I know something about it :) Simon |
|
From: Carlos Q. <car...@ge...> - 2002-01-30 13:57:35
|
Hi all I just commited a SMTP MBean as an extra tool. It is basically meant to s= end=20 e-mails if something happens for instance some monitor notification. If you want to compile add the mail.jar and activation.jar (From JavaMail= 1.2=20 and JAF 1.0.1) to the lib dir. The class should be included in the openjmx-tools.jar I'll be writing docs soon Regards Carlos Quiroz |
|
From: Carlos Q. <Car...@ge...> - 2002-01-30 13:46:52
|
> -----Original Message-----
> From: Bordet, Simone [mailto:Sim...@co...]
> Sent: 30 January 2002 15:38
> To: OpenJMX-Dev (E-mail)
> Subject: RE: [Openjmx-devel] RMI adaptor and remote notifications
>=20
> Hi,
>=20
> > > Look at this filter
> > >
> > > class MyFilter implements NotificationFilter
> > > {
> > > public boolean isNotificationEnabled(Notification n)
> > > {
> > > List l =3D MBeanServerFactory.findMBeanServer(null);
> > > for (Iterator i =3D l.iterator(); i.hasNext();)
> > > {
> > > MBeanServer s =3D (MBeanServer)i.next();
> > > MBeanServerFactory.releaseMBeanServer(s);
> > > }
> > > return true;
> > > }
> > > }
> > Would you upload this code to the Agent?
>=20
> If you serialize the filter it is uploaded to the agent, yes.
My scenario is with the agent running in some server and the client
(Let's say a swing app) writes the filter above and adds a listener.
Then the listener will be serialized and sent to the agent. Are we
talking about the same idea?
>=20
> > How using for instance a web
> > server in the codebase?
>=20
> Not following.
Obviously you cannot just send a serialized object to the agent and
expect it to know how to deserialize it and execute. You have to also
download the class definition which may be available in a web server. If
you don't allow this then the code has to be introduced beforehand and
is therefore trusted. Maybe you could clarify this but I think this
scenario always calls for a security manager
>=20
> > I think this will be always a problem using RMI, and you
> > would normally
> > run it with a security manager.
>=20
> No, if the filter is remote.
>=20
> > There are many other things
> > that can be
> > done if you are uploading code (spyware, viruses, etc...)
>=20
> Yes, so ?
My point is that this problem is much broader than only the filter. You
could upload a MBean which does something similar
>=20
> Remote filters ?
>=20
> Simon
>=20
> _______________________________________________
> Openjmx-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openjmx-devel
|
|
From: Bordet, S. <Sim...@co...> - 2002-01-30 13:38:23
|
Hi,
> > Look at this filter
> >=20
> > class MyFilter implements NotificationFilter
> > {
> > public boolean isNotificationEnabled(Notification n)
> > {
> > List l =3D MBeanServerFactory.findMBeanServer(null);
> > for (Iterator i =3D l.iterator(); i.hasNext();)
> > {
> > MBeanServer s =3D (MBeanServer)i.next();
> > MBeanServerFactory.releaseMBeanServer(s);
> > }
> > return true;
> > }
> > }
> Would you upload this code to the Agent?=20
If you serialize the filter it is uploaded to the agent, yes.
> How using for instance a web
> server in the codebase?
Not following.
> I think this will be always a problem using RMI, and you=20
> would normally
> run it with a security manager.=20
No, if the filter is remote.
> There are many other things=20
> that can be
> done if you are uploading code (spyware, viruses, etc...)
Yes, so ?
Remote filters ?
Simon
|
|
From: Carlos Q. <Car...@ge...> - 2002-01-30 13:32:14
|
> -----Original Message-----
> From: Bordet, Simone [mailto:Sim...@co...]
> Sent: 30 January 2002 15:26
> To: OpenJMX-Dev (E-mail)
> Subject: RE: [Openjmx-devel] RMI adaptor and remote notifications
>=20
> Hi,
>=20
> > > > > I've added possibility to receive in the client
> > notifications from
> > a
> > > > > remote MBeanServer.
> > > > >
> > > > > Listeners are always remote, but NotificationFilters may be
> > > > serialized
> > > > to
> > > > > the server and be executed there.
> > > > >
> > > > > Is there any preference on how filters must be treated ?
> > > > >
> > > > > 1) Always as remote, like listeners (will be executed in the
> > client)
> > > > > 2) Always serialized to the server (will executed in the
server)
> > > > I'm sure this is a lot more Network efficient
> > > >
> > > > > 3) try first with 2, if fails fall through to 1
> > > > When may this happen?
> > >
> > > When filter implementation is not serializable.
> > Ok, then my vote is for 3
>=20
> Eh, not that simple.
>=20
> Look at this filter
>=20
> class MyFilter implements NotificationFilter
> {
> public boolean isNotificationEnabled(Notification n)
> {
> List l =3D MBeanServerFactory.findMBeanServer(null);
> for (Iterator i =3D l.iterator(); i.hasNext();)
> {
> MBeanServer s =3D (MBeanServer)i.next();
> MBeanServerFactory.releaseMBeanServer(s);
> }
> return true;
> }
> }
Would you upload this code to the Agent? How using for instance a web
server in the codebase?
I think this will be always a problem using RMI, and you would normally
run it with a security manager. There are many other things that can be
done if you are uploading code (spyware, viruses, etc...)
>=20
> This will force us to run the agent always under security manager...
>=20
> We want to leave open this security hole, and go for a simpler
> implementation ?
>=20
> We want many remote calls for each notification ?
>=20
> Mumble, mumble...
>=20
> Simon
>=20
> _______________________________________________
> Openjmx-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openjmx-devel
|
|
From: Bordet, S. <Sim...@co...> - 2002-01-30 13:26:38
|
Hi,
> > > > I've added possibility to receive in the client=20
> notifications from
> a
> > > > remote MBeanServer.
> > > >
> > > > Listeners are always remote, but NotificationFilters may be
> > > serialized
> > > to
> > > > the server and be executed there.
> > > >
> > > > Is there any preference on how filters must be treated ?
> > > >
> > > > 1) Always as remote, like listeners (will be executed in the
> client)
> > > > 2) Always serialized to the server (will executed in the server)
> > > I'm sure this is a lot more Network efficient
> > >
> > > > 3) try first with 2, if fails fall through to 1
> > > When may this happen?
> >=20
> > When filter implementation is not serializable.
> Ok, then my vote is for 3
Eh, not that simple.
Look at this filter
class MyFilter implements NotificationFilter=20
{
public boolean isNotificationEnabled(Notification n)=20
{
List l =3D MBeanServerFactory.findMBeanServer(null);
for (Iterator i =3D l.iterator(); i.hasNext();)=20
{
MBeanServer s =3D (MBeanServer)i.next();
MBeanServerFactory.releaseMBeanServer(s);
}
return true;
}
}
This will force us to run the agent always under security manager...
We want to leave open this security hole, and go for a simpler
implementation ?
We want many remote calls for each notification ?
Mumble, mumble...
Simon
|
|
From: Bronwen C. <Bro...@ja...> - 2002-01-30 13:20:59
|
Agreed 3 sounds the best Bronwen > -----Original Message----- > From: Carlos Quiroz [mailto:Car...@ge...] > Sent: 30 January 2002 13:16 > To: OpenJMX-Dev (E-mail) > Subject: RE: [Openjmx-devel] RMI adaptor and remote notifications > > > > > > -----Original Message----- > > From: Bordet, Simone [mailto:Sim...@co...] > > Sent: 30 January 2002 15:16 > > To: Carlos Quiroz; OpenJMX-Dev (E-mail) > > Subject: RE: [Openjmx-devel] RMI adaptor and remote notifications > > > > Hi, > > > > > > I've added possibility to receive in the client > notifications from > a > > > > remote MBeanServer. > > > > > > > > Listeners are always remote, but NotificationFilters may be > > > serialized > > > to > > > > the server and be executed there. > > > > > > > > Is there any preference on how filters must be treated ? > > > > > > > > 1) Always as remote, like listeners (will be executed in the > client) > > > > 2) Always serialized to the server (will executed in the server) > > > I'm sure this is a lot more Network efficient > > > > > > > 3) try first with 2, if fails fall through to 1 > > > When may this happen? > > > > When filter implementation is not serializable. > Ok, then my vote is for 3 > > > > > Simon > > _______________________________________________ > Openjmx-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjmx-devel > |
|
From: Carlos Q. <Car...@ge...> - 2002-01-30 13:17:49
|
> -----Original Message----- > From: Bordet, Simone [mailto:Sim...@co...] > Sent: 30 January 2002 15:16 > To: Carlos Quiroz; OpenJMX-Dev (E-mail) > Subject: RE: [Openjmx-devel] RMI adaptor and remote notifications >=20 > Hi, >=20 > > > I've added possibility to receive in the client notifications from a > > > remote MBeanServer. > > > > > > Listeners are always remote, but NotificationFilters may be > > serialized > > to > > > the server and be executed there. > > > > > > Is there any preference on how filters must be treated ? > > > > > > 1) Always as remote, like listeners (will be executed in the client) > > > 2) Always serialized to the server (will executed in the server) > > I'm sure this is a lot more Network efficient > > > > > 3) try first with 2, if fails fall through to 1 > > When may this happen? >=20 > When filter implementation is not serializable. Ok, then my vote is for 3 >=20 > Simon |
|
From: Bordet, S. <Sim...@co...> - 2002-01-30 13:16:44
|
Hi, > > I've added possibility to receive in the client notifications from a > > remote MBeanServer. > >=20 > > Listeners are always remote, but NotificationFilters may be=20 > serialized > to > > the server and be executed there. > >=20 > > Is there any preference on how filters must be treated ? > >=20 > > 1) Always as remote, like listeners (will be executed in the client) > > 2) Always serialized to the server (will executed in the server) > I'm sure this is a lot more Network efficient >=20 > > 3) try first with 2, if fails fall through to 1 > When may this happen? When filter implementation is not serializable. Simon |
|
From: Carlos Q. <Car...@ge...> - 2002-01-30 13:13:06
|
> -----Original Message----- > From: Bordet, Simone [mailto:Sim...@co...] > Sent: 30 January 2002 15:10 > To: OpenJMX-Dev (E-mail) > Subject: [Openjmx-devel] RMI adaptor and remote notifications >=20 > Hi, Hi >=20 > I've added possibility to receive in the client notifications from a > remote MBeanServer. >=20 > Listeners are always remote, but NotificationFilters may be serialized to > the server and be executed there. >=20 > Is there any preference on how filters must be treated ? >=20 > 1) Always as remote, like listeners (will be executed in the client) > 2) Always serialized to the server (will executed in the server) I'm sure this is a lot more Network efficient > 3) try first with 2, if fails fall through to 1 When may this happen? >=20 > Any other opinion ? >=20 > Simon >=20 > _______________________________________________ > Openjmx-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjmx-devel |
|
From: Bordet, S. <Sim...@co...> - 2002-01-30 13:10:01
|
Hi, I've added possibility to receive in the client notifications from a = remote MBeanServer. Listeners are always remote, but NotificationFilters may be serialized = to the server and be executed there. Is there any preference on how filters must be treated ? 1) Always as remote, like listeners (will be executed in the client) 2) Always serialized to the server (will executed in the server) 3) try first with 2, if fails fall through to 1 Any other opinion ? Simon |
|
From: Carlos Q. <Car...@ge...> - 2002-01-30 08:58:01
|
> -----Original Message----- > From: J=E9r=F4me BERNARD [mailto:jer...@xt...] > Sent: 30 January 2002 10:41 > To: ope...@li... > Subject: Re: [Openjmx-devel] Proposed bug fix in the XSLT stylesheets >=20 > That's fine for me. > Thanks. Cool. I'll update the docs setting xalan as the highly and only recommended XSLT processor. We have to find every page that uses href=3D"OBJECTNAME" and update it >=20 > Jerome. >=20 > Carlos Quiroz wrote: >=20 > >On Tuesday 29 January 2002 20:00, J=E9r=F4me BERNARD wrote: > > > >>Hi, > >> > > > >Hi I commited my solution. Please take a look and give me your comments > >Regards > > > >>I have been experiencing problems with ObjectNames containing spaces. > >>The way the XSTL stylesheets are built is a problem because the URL > >>produced are not valid. > >> > >>I have found (and implemented) a "trick" in order to solve that: we can > >>add a method in common.xsl (I called it urlencode) that encodes properly > >>the URL and do a window.location to this newly created url. > >> > >>We replace all href values with urlencode(the old href value) and we're > >>done. > >> > >>Is anyone ok for such a fix? > >> > >>If so I will start updating all the stylesheet and commit. > >> > >> > >>Jerome. > >> >=20 >=20 >=20 > _______________________________________________ > Openjmx-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjmx-devel |
|
From: B. <jer...@xt...> - 2002-01-30 08:42:57
|
That's fine for me. Thanks. Jerome. Carlos Quiroz wrote: >On Tuesday 29 January 2002 20:00, J=E9r=F4me BERNARD wrote: > >>Hi, >> > >Hi I commited my solution. Please take a look and give me your comments >Regards > >>I have been experiencing problems with ObjectNames containing spaces. >>The way the XSTL stylesheets are built is a problem because the URL >>produced are not valid. >> >>I have found (and implemented) a "trick" in order to solve that: we can= >>add a method in common.xsl (I called it urlencode) that encodes properl= y >>the URL and do a window.location to this newly created url. >> >>We replace all href values with urlencode(the old href value) and we're= >>done. >> >>Is anyone ok for such a fix? >> >>If so I will start updating all the stylesheet and commit. >> >> >>Jerome. >> |
1 message has been excluded from this view by a project administrator.
