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-02-11 17:05:35
|
... I know I know we did all the best to avoid this, but the JRMP = adaptors depends on SSL RMISocketFactories, so if JSSE not present, no = JRMPAdaptor. If someone finds a better solution without using reflection in the = JRMPAdaptor code, then he/she can remove the jars :P Simon |
|
From: Bordet, S. <Sim...@co...> - 2002-02-11 16:36:41
|
Hi, I committed the revisited RMI adaptor, hehe. As a result CVS may be a little unstable for few days (only the part of = the RMIAdaptor, though), but I will fix everything for the release = candidate. BTW I propose future major release always follow the pattern of 2 beta = releases, one RC then the final. -------o-------- RMIAdaptor This MBean allow clients to connect to the MBeanServer via RMI. Notice = please that RMI is not a protocol, and here must be intended as "remote = method invocation using Java". The underlying protocol can be anyone, = and in fact 2 are supported: JRMP and IIOP. JRMP is the Java Remote Method Protocol, and it's the default protocol = for RMI. IIOP is the Internet Inter Orb Protocol, and it's the CORBA default. As you know, remote method invocation in Java can have JRMP or IIOP as = protocols, and the remote invocation process is usually referred to, = respectively, as "RMI" and "RMI over IIOP". "RMI" is a short for "RMI = over JRMP". So we have the RMI adaptor that is protocol independent, and support for = remote notification listeners and filters. -------o-------- IIOPAdaptor This MBean is a subclass of the RMIAdaptor and handles IIOP specific = operations. -------o-------- JRMPAdaptor This MBean is a subclass of the RMIAdaptor and handles JRMP specific = operations. It supports export on a specific port and with custom socket = factories. It supports SSL, so it is possible to have a JRMPAdaptor over SSL for = secure data transfer. -------o-------- RMIConnector This is the class that remote clients of MBeanServer must use to connect = to the RMIAdaptor subclasses. It serves for both JRMP and IIOP adaptor. = It is based on JNDI to lookup the adaptors, so be sure to configure it = properly to find the adaptor's stub, either from the RMI naming or from = the COS naming (for RMI and CORBA respectively). Don't try to use directly the stub of the adaptors, unless you know what = you're doing :), always use this class. That's it for now. Examples and docs will come soon. Cheers Simon |
|
From: Bordet, S. <Sim...@co...> - 2002-02-11 14:11:48
|
Hi, > > 1) setProcessorName takes an ObjectName. IMHO should take a=20 > String, in > > order to be useful for the management interface, otherwise=20 > from the adaptor > > you cannot stop(), change the processor name, and start()=20 > it again, since > > you cannot create ObjectName and pass them to the adaptor.=20 > Am I missing > > something ? > The HttpAdaptor can accept ObjectName parameters. Great, I didn't know :) Of course won't work with other less advanced http adaptors, but ok for = me. > 2) restart(). Isn't enough to have start() and stop() ? For > > consistency changing parameters when the adaptor is running=20 > should not be > > done. For example, you start the adaptor, then you go to=20 > the management > > interface and change the port, then you forget to restart()=20 > it. Another > > user will see the new port, but in reality it is still=20 > running on the old > > one... IMHO start() and stop() should do the job. > So you suggest to throw an exception when some parameter like=20 > port and host are modified Or throw some exception or do nothing, maybe better the former. I have the same issue for the RMI adaptor, for now I check isRunning() = and do nothing if it is... So restart() can be removed yes ? Please wait to do this change, as I'm integrating SSL on the HTTP = adaptor. I will commit soon. Simon |
|
From: Carlos Q. <car...@we...> - 2002-02-11 14:04:08
|
On Monday 11 February 2002 15:35, Bordet, Simone wrote: > Hi Carlos, > > I'm integrating the SSL support, and take a look to the management > interface of the HTTPAdaptor, and I have some question: > > 1) setProcessorName takes an ObjectName. IMHO should take a String, in > order to be useful for the management interface, otherwise from the adaptor > you cannot stop(), change the processor name, and start() it again, since > you cannot create ObjectName and pass them to the adaptor. Am I missing > something ? The HttpAdaptor can accept ObjectName parameters. 2) restart(). Isn't enough to have start() and stop() ? For > consistency changing parameters when the adaptor is running should not be > done. For example, you start the adaptor, then you go to the management > interface and change the port, then you forget to restart() it. Another > user will see the new port, but in reality it is still running on the old > one... IMHO start() and stop() should do the job. So you suggest to throw an exception when some parameter like port and host are modified > > Simon > > _______________________________________________ > Openjmx-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjmx-devel |
|
From: Bordet, S. <Sim...@co...> - 2002-02-11 13:36:16
|
Hi Carlos, I'm integrating the SSL support, and take a look to the management = interface of the HTTPAdaptor, and I have some question: 1) setProcessorName takes an ObjectName. IMHO should take a String, in = order to be useful for the management interface, otherwise from the = adaptor you cannot stop(), change the processor name, and start() it = again, since you cannot create ObjectName and pass them to the adaptor. = Am I missing something ? 2) restart(). Isn't enough to have start() and stop() ? For consistency = changing parameters when the adaptor is running should not be done. For = example, you start the adaptor, then you go to the management interface = and change the port, then you forget to restart() it. Another user will = see the new port, but in reality it is still running on the old one... = IMHO start() and stop() should do the job. Simon |
|
From: Bordet, S. <Sim...@co...> - 2002-02-11 09:57:22
|
Hi, > > One can think that the same should be required for the RMI=20 > adaptor as well, > > but there is no standard here like there is for HTTP. So it=20 > must be done > > via API, for example via an RMIConnector.login() method.=20 > But here it opens > > up a wide hole, since I may want to pass in user name and=20 > password, a X509 > > certificate, and so on. Furthermore it should be done with JAAS. > What about a login(username, password) RMI method, that will=20 > go with SSL and=20 > will be therfore protected.=20 Yes, I was thinking at login(username, password), but it cannot go over = SSL on this one only, unless providing another remote object that act as = authenticator (which may be a good choice).=20 Once you export the RMI adaptor, either you export it over SSL or not. = You cannot have some method yes and some no. > However, I think the best bet is=20 > to use client=20 > authentication with certificates since that should be=20 > transparent and handled=20 > at the SSL Factory level Yes, exactly. But it is really damn slow.=20 So I guess 95% of users would like to have a weak authentication only to = keep out curioses (of course hackers will access eventually, but if = there are hackers around I will go full SSL). So I send user and password in clear, not even base64, just plain text. > Do you want to use JAAS to implement MBeanServer wide=20 > authentication, that=20 > every adaptor will use? That would be the desiderata, but it is not so simple, since I should = have callbacks on client and authentication on server... JAAS is a very base framework, you have to build something around it in = every case. The goal is to build something extendible, powerful, = reusable, simple and fast around JAAS for our Adaptors ;) Anyhow we can go 1.0 and think more about that for 1.1. Simon |
|
From: Carlos Q. <car...@we...> - 2002-02-11 09:28:37
|
On Monday 11 February 2002 01:12, Bordet, Simone wrote: > Hi all, Hi > > so I'm done with the JRMP over SSL adaptor, it works, I will commit it > soon. > > The last bit to be cleared is client authentication. > > The HTTP adaptor support basic authentication (Carlos, some other that I > don't know of - digest, etc ?), meaning that a user must login before > getting something on the browser. Only basic is implemented. I found digest unecessary since SSL is available, it can be easily implmented if required > > One can think that the same should be required for the RMI adaptor as well, > but there is no standard here like there is for HTTP. So it must be done > via API, for example via an RMIConnector.login() method. But here it opens > up a wide hole, since I may want to pass in user name and password, a X509 > certificate, and so on. Furthermore it should be done with JAAS. What about a login(username, password) RMI method, that will go with SSL and will be therfore protected. However, I think the best bet is to use client authentication with certificates since that should be transparent and handled at the SSL Factory level Do you want to use JAAS to implement MBeanServer wide authentication, that every adaptor will use? > > Any idea or comments ? > > We can also go with 1.0 without it, and do it for OpenJMX 1.1 > > Simon > > _______________________________________________ > Openjmx-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjmx-devel |
|
From: Bordet, S. <Sim...@co...> - 2002-02-10 23:12:54
|
Hi all, so I'm done with the JRMP over SSL adaptor, it works, I will commit it = soon. The last bit to be cleared is client authentication. The HTTP adaptor support basic authentication (Carlos, some other that I = don't know of - digest, etc ?), meaning that a user must login before = getting something on the browser. One can think that the same should be required for the RMI adaptor as = well, but there is no standard here like there is for HTTP. So it must = be done via API, for example via an RMIConnector.login() method. But here it opens up a wide hole, since I may want to pass in user name = and password, a X509 certificate, and so on. Furthermore it should be done with JAAS. Any idea or comments ? We can also go with 1.0 without it, and do it for OpenJMX 1.1 Simon |
|
From: <no...@so...> - 2002-02-09 21:50:37
|
Bugs item #513780, was opened at 2002-02-06 07:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=410050&aid=513780&group_id=34041 >Category: Agent Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Chris Glencross (chrisglencross) >Assigned to: Simone Bordet (biorn_steedom) Summary: Log4JLogger logs everything as DEBUG Initial Comment: The log level numeric constants defined in Logger.java are different than the levels defined in Log4J 1.1.3 (Priority.java), and Log4JLogger isn't performing any conversions. This results in all messages being written to Log4J as DEBUG. ---------------------------------------------------------------------- >Comment By: Simone Bordet (biorn_steedom) Date: 2002-02-09 13:50 Message: Logged In: YES user_id=128193 Fixed, now converting OpenJMX priorities to Log4J's. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=410050&aid=513780&group_id=34041 |
|
From: Bordet, S. <Sim...@co...> - 2002-02-08 16:12:20
|
Hi, > I agree with all your changes and is ok if you make the=20 > changes. I'm in a big=20 > hurry now. Would you make the changes to the HTTPAdaptor too? Yes, I will take care of the HTTP adaptor as well, just few class = renames, you already did everything :) Simon |
|
From: Carlos Q. <car...@ge...> - 2002-02-08 16:08:43
|
Hi Funny I was going to ask if you wanted to add SSL to the RMI connector :-= ) >Hi (Carlos especially), > >I'm implementing RMI over SSL adaptor, and I wanted to share some idea, = since=20 SSL is also used for HTTP adaptor. > >I like very much the idea of having a SSL server socket factory (SSF) as= =20 MBean, given the huge amount of parameters required to setup a SSL SSF. >Furthermore it will be easy to improve it to support client authenticati= on=20 also, not only server authentication. > >Given so, every time I need a HTTP adaptor over SSL, I register a SSL SS= F and=20 then register the HTTP adaptor, passing it the object name of the SSL SSF= in=20 String form. >Now it is not like this (no big deal) but instead the SSL SSF is passed = as=20 Java object as attribute. This of course implies that it is not possible = to=20 stop the HTTP adaptor, change the file from where key information is read= for=20 SSL (in the SSL SSF MBean), and restart the HTTP adaptor from a managemen= t=20 application (such as the HTTP adaptor itself, for example :). We can add that. >I would like to do the same for the RMI adaptor or, to be precise, the J= RMP=20 adaptor (IIOP still does not support SSL from Java API). >So basically I register a SSL SSF with its own parameters, then register= the=20 JRMP adaptor, I will pass it the object name of the SSL SSF MBean, and st= art=20 it. > >Any comment on the above schema ? I definetly support it and clearly suggest to use a common SSF >I find it cleaner than having a RMI adaptor MBean with a *lot* of parame= ters=20 specifying the port for RMI, the key file and so on; we specify SSL=20 parameters to SSL MBean and RMI parameters to RMI MBean, and a pointer to= the=20 SSL MBean if we want to have RMI over SSL. Same for HTTP adaptor. >It will also be very good when server applications are specified in MLet= =20 files, since constructors will take fewer parameters. > >If the above is good, then I propose: > >1) to move the AdaptorSocketFactory from openjmx.adaptor.http to=20 openjmx.adaptor. >2) to change its name to AdaptorServerSocketFactory. >3) to remove setParameters >4) to change createServerSocket() in createServerSocket(int port, int=20 backlog, String hostName); >5) to move SSLFactory from openjmx.adaptor.http.ssl to openjmx.adaptor.s= sl >6) to change its name to SSLAdaptorServerSocketFactory >7) to change its implementation following 3) and 4) >8) to change accordingly the management interface (now SSLFactoryMBean) >9) to move DefaultSocketFactory from openjmx.adaptor.http to openjmx.ada= ptor >10) to rename it Plain(Default)AdaptorServerSocketFactory >11) to change its implementation following 3) and 4) > >About 3 and 4, I find easier to have only one method, and it is the sche= ma=20 used in all the other socket factories present in libraries such as jdk a= nd=20 jsse. >About 10 I prefer Plain, since it is used also in jdk (implementation cl= ass=20 for Socket is PlainSocketImpl). I agree with all your changes and is ok if you make the changes. I'm in a= big=20 hurry now. Would you make the changes to the HTTPAdaptor too? > >I am deeply on it, so I can do all the changes above and commit by the=20 beginning of next week. > >Comments are welcome. > >Cheers, > >Simon > >_______________________________________________ >Openjmx-devel mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/openjmx-devel > |
|
From: Bordet, S. <Sim...@co...> - 2002-02-08 12:30:16
|
Hi (Carlos especially), I'm implementing RMI over SSL adaptor, and I wanted to share some idea, = since SSL is also used for HTTP adaptor. I like very much the idea of having a SSL server socket factory (SSF) as = MBean, given the huge amount of parameters required to setup a SSL SSF. Furthermore it will be easy to improve it to support client = authentication also, not only server authentication. Given so, every time I need a HTTP adaptor over SSL, I register a SSL = SSF and then register the HTTP adaptor, passing it the object name of = the SSL SSF in String form. Now it is not like this (no big deal) but instead the SSL SSF is passed = as Java object as attribute. This of course implies that it is not = possible to stop the HTTP adaptor, change the file from where key = information is read for SSL (in the SSL SSF MBean), and restart the HTTP = adaptor from a management application (such as the HTTP adaptor itself, = for example :). I would like to do the same for the RMI adaptor or, to be precise, the = JRMP adaptor (IIOP still does not support SSL from Java API). So basically I register a SSL SSF with its own parameters, then register = the JRMP adaptor, I will pass it the object name of the SSL SSF MBean, = and start it. Any comment on the above schema ? I find it cleaner than having a RMI adaptor MBean with a *lot* of = parameters specifying the port for RMI, the key file and so on; we = specify SSL parameters to SSL MBean and RMI parameters to RMI MBean, and = a pointer to the SSL MBean if we want to have RMI over SSL. Same for = HTTP adaptor. It will also be very good when server applications are specified in MLet = files, since constructors will take fewer parameters. If the above is good, then I propose: 1) to move the AdaptorSocketFactory from openjmx.adaptor.http to = openjmx.adaptor. 2) to change its name to AdaptorServerSocketFactory. 3) to remove setParameters 4) to change createServerSocket() in createServerSocket(int port, int = backlog, String hostName); 5) to move SSLFactory from openjmx.adaptor.http.ssl to = openjmx.adaptor.ssl 6) to change its name to SSLAdaptorServerSocketFactory 7) to change its implementation following 3) and 4) 8) to change accordingly the management interface (now SSLFactoryMBean) 9) to move DefaultSocketFactory from openjmx.adaptor.http to = openjmx.adaptor 10) to rename it Plain(Default)AdaptorServerSocketFactory 11) to change its implementation following 3) and 4) About 3 and 4, I find easier to have only one method, and it is the = schema used in all the other socket factories present in libraries such = as jdk and jsse. About 10 I prefer Plain, since it is used also in jdk (implementation = class for Socket is PlainSocketImpl). I am deeply on it, so I can do all the changes above and commit by the = beginning of next week. Comments are welcome. Cheers, Simon |
|
From: <no...@so...> - 2002-02-07 22:33:25
|
Bugs item #513698, was opened at 2002-02-06 03:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=410050&aid=513698&group_id=34041 Category: Http Adapter Group: None >Status: Pending >Resolution: Fixed Priority: 5 Submitted By: Chris Glencross (chrisglencross) Assigned to: Carlos Quiroz (tibu) Summary: XSLTProcessor cannot read JARs on Win32 Initial Comment: Using beta 2 (same result in beta 1). Lines 287 and 291 use new File(this.path, path).toString() to build the path to a resource in a JAR file. Unfortunately, on Windows, this results in all '/' characters being replaced with '\', which means that no XSL resources can be found by the classloader. The user sees blank pages. Would it be problematic to change to using string concatenation to build JAR resource paths instead of File.toString()? ---------------------------------------------------------------------- >Comment By: Carlos Quiroz (tibu) Date: 2002-02-07 14:33 Message: Logged In: YES user_id=64333 Added suggested modification including a few extra checks. Tested only in Linux, it will be kept as pending until it is confirmed that it works in Windows ---------------------------------------------------------------------- Comment By: Chris Glencross (chrisglencross) Date: 2002-02-06 05:30 Message: Logged In: YES user_id=337810 Slightly related: Elsewhere in the file URLs are generated by prefixing a file path with "file://". This only really works in Windows if the file path already contains a leading "/", which isn't conventional if a drive prefix is used. I would suggest that new File(path).toURL() be used to create the URL instead in a cross-platform manner. ---------------------------------------------------------------------- Comment By: Carlos Quiroz (tibu) Date: 2002-02-06 05:18 Message: Logged In: YES user_id=64333 Thanks for pointing this. It will be fixed ASAP ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=410050&aid=513698&group_id=34041 |
|
From: <no...@so...> - 2002-02-07 22:31:48
|
Bugs item #513839, was opened at 2002-02-06 09:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=410050&aid=513839&group_id=34041 Category: Http Adapter Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Chris Glencross (chrisglencross) Assigned to: Carlos Quiroz (tibu) Summary: Default XSL stylesheets Initial Comment: Low priority: Would it be possible to change the templates so that results returned are wrapped in an HTML <PRE> block? Currently newlines are displayed as spaces making large blocks of text difficult to read. ---------------------------------------------------------------------- >Comment By: Carlos Quiroz (tibu) Date: 2002-02-07 14:31 Message: Logged In: YES user_id=64333 Added proposed modification ---------------------------------------------------------------------- Comment By: Chris Glencross (chrisglencross) Date: 2002-02-07 00:47 Message: Logged In: YES user_id=337810 I meant the results of the MBean invocation. In the absence of being able to return complex data structures using the HTTP agent, I return some rather large formatted strings containing newline characters. I modified invoke.xsl so that line 37 contains: Result value:<pre><xsl:value-of select="@return"/></pre> so that newline characters in these strings aren't lost when the value is displayed. ---------------------------------------------------------------------- Comment By: Carlos Quiroz (tibu) Date: 2002-02-06 13:26 Message: Logged In: YES user_id=64333 Do you refer specifically to the description fields? I can't image any other field using newlines ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=410050&aid=513839&group_id=34041 |
|
From: Carlos Q. <car...@ge...> - 2002-02-07 14:07:11
|
>... not so important as we will go RC soon, but definitely not to forgot= next=20 time. > >Maybe it's worth to write something on the developer's guide in the docs= =20 about releasing... any takers ? Sorry I forgot that part at 3 AM :-) But let's remember it next time, is quite important > >Simon > >_______________________________________________ >Openjmx-devel mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/openjmx-devel > |
|
From: Bordet, S. <Sim...@co...> - 2002-02-07 14:03:19
|
... not so important as we will go RC soon, but definitely not to forgot = next time. Maybe it's worth to write something on the developer's guide in the docs = about releasing... any takers ? Simon |
|
From: bronwen.cassidy <bro...@ja...> - 2002-02-07 10:57:20
|
Hi, No other libraries are required, some background here, before Simone went away we discussed the implementation of the iiop adaptor, initially it was to be a delegate to the RMIAdaptorImpl class for all the MBeanServer functionality (though this is still an option a small amount of refactoring of the RMIAdaptorImpl needs to be discussed, for the delegation to work, so (a temporary solution) was to bypass the RMIAdaptorImpl and delegate to the MBeanServer the methods of the server, ie. invoke, createMBean etc. I'll commit these files as is (they work :-))I have a couple of examples that i used to test that a client class (not an MBean) could make a request for information from a iiop remote MBean that had been registered via the iiop adaptor. There are massive amount of docs for this as there is the option to create idl from the iiopAdaptorImpl interface and then have a 100% Corba implementation available (The drawback of the rmi-iiop is that the remote interface must be written in java), I'll commit the files now, then start on the docs. Where sould the docs go? Under mbeans? I've started a ex-iiopmbeans.xml file, though am tempted to add to the ex-mbeans.xml Simone did for the RMI adaptor? Ideas? > On Thursday 07 February 2002 00:50, B Cassidy wrote: > > Hi guys :-) you'll probably get 2 of these my e-mail has gone > down at work > > (overload!!) Well the IIOPAdaptor is ready works and runs so this means > > other languages can be managed in a JMX sense. Couple of considerations, > > some input will help. 1) The rmi DGC (Remote Garbage Collection) is not > > available in rmi-iiop!! so some work around required, any > immediate ideas?. > > Ant will need a task added rmic with the switch -iiop. (Could > you do that > > for me Carlos my expertise with ant is not as it should be:) > The class to > > be rmic(ed) is openjmx.adaptor.iiop.IIOPAdaptorImpl. The other > thing before > > i commit is this the ideal package? > Hi Bronwen. > > This is excellent and the package is the right one. > I can write the tasks as soon as you commit. Do you need any > extra library? > > Did you check the JMX IIOP JCP (some acronyms) at > http://jcp.org/jsr/detail/070.jsp Thanx, i'll check this asap :-) Bronwen > The EG was formed on March 2001, so it doesn't seem very active though. > > > > > > > > > Thanx guys > > Bronwen > > > > > > > > _________________________________________________________________ > > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > > > > _______________________________________________ > > 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...@we...> - 2002-02-07 08:53:25
|
On Thursday 07 February 2002 00:50, B Cassidy wrote: > Hi guys :-) you'll probably get 2 of these my e-mail has gone down at work > (overload!!) Well the IIOPAdaptor is ready works and runs so this means > other languages can be managed in a JMX sense. Couple of considerations, > some input will help. 1) The rmi DGC (Remote Garbage Collection) is not > available in rmi-iiop!! so some work around required, any immediate ideas?. > Ant will need a task added rmic with the switch -iiop. (Could you do that > for me Carlos my expertise with ant is not as it should be:) The class to > be rmic(ed) is openjmx.adaptor.iiop.IIOPAdaptorImpl. The other thing before > i commit is this the ideal package? Hi Bronwen. This is excellent and the package is the right one. I can write the tasks as soon as you commit. Do you need any extra library? Did you check the JMX IIOP JCP (some acronyms) at http://jcp.org/jsr/detail/070.jsp The EG was formed on March 2001, so it doesn't seem very active though. > > > Thanx guys > Bronwen > > > > _________________________________________________________________ > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > _______________________________________________ > Openjmx-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjmx-devel |
|
From: <no...@so...> - 2002-02-07 08:47:07
|
Bugs item #513839, was opened at 2002-02-06 09:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=410050&aid=513839&group_id=34041 Category: Http Adapter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Glencross (chrisglencross) Assigned to: Carlos Quiroz (tibu) Summary: Default XSL stylesheets Initial Comment: Low priority: Would it be possible to change the templates so that results returned are wrapped in an HTML <PRE> block? Currently newlines are displayed as spaces making large blocks of text difficult to read. ---------------------------------------------------------------------- >Comment By: Chris Glencross (chrisglencross) Date: 2002-02-07 00:47 Message: Logged In: YES user_id=337810 I meant the results of the MBean invocation. In the absence of being able to return complex data structures using the HTTP agent, I return some rather large formatted strings containing newline characters. I modified invoke.xsl so that line 37 contains: Result value:<pre><xsl:value-of select="@return"/></pre> so that newline characters in these strings aren't lost when the value is displayed. ---------------------------------------------------------------------- Comment By: Carlos Quiroz (tibu) Date: 2002-02-06 13:26 Message: Logged In: YES user_id=64333 Do you refer specifically to the description fields? I can't image any other field using newlines ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=410050&aid=513839&group_id=34041 |
|
From: B C. <bo...@ho...> - 2002-02-06 22:50:58
|
Hi guys :-) you'll probably get 2 of these my e-mail has gone down at work (overload!!) Well the IIOPAdaptor is ready works and runs so this means other languages can be managed in a JMX sense. Couple of considerations, some input will help. 1) The rmi DGC (Remote Garbage Collection) is not available in rmi-iiop!! so some work around required, any immediate ideas?. Ant will need a task added rmic with the switch -iiop. (Could you do that for me Carlos my expertise with ant is not as it should be:) The class to be rmic(ed) is openjmx.adaptor.iiop.IIOPAdaptorImpl. The other thing before i commit is this the ideal package? Thanx guys Bronwen _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com |
|
From: <no...@so...> - 2002-02-06 21:26:47
|
Bugs item #513839, was opened at 2002-02-06 09:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=410050&aid=513839&group_id=34041 Category: Http Adapter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Glencross (chrisglencross) >Assigned to: Carlos Quiroz (tibu) Summary: Default XSL stylesheets Initial Comment: Low priority: Would it be possible to change the templates so that results returned are wrapped in an HTML <PRE> block? Currently newlines are displayed as spaces making large blocks of text difficult to read. ---------------------------------------------------------------------- >Comment By: Carlos Quiroz (tibu) Date: 2002-02-06 13:26 Message: Logged In: YES user_id=64333 Do you refer specifically to the description fields? I can't image any other field using newlines ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=410050&aid=513839&group_id=34041 |
|
From: Dmitri C. <di...@bi...> - 2002-02-06 21:11:03
|
if you need any help - just ask. cheers dim ----- Original Message ----- From: "Jérôme Bernard" <jer...@xt...> To: <ope...@li...> Sent: Thursday, February 07, 2002 3:20 AM Subject: Re: [Openjmx-devel] [Fwd: JMX work, and CustomerBMPBean] > Carlos Quiroz wrote: > > >Yes beta2, no final yet and I agree about the MLET generation. We also > >discussed about using xdoclet for generation of configuration files, but > >that's somthing still in the future :-) > > > I am beginning to work on the mlet template. Just need to dig a little > bit more in the merge system of XDoclet though. > > I hope to have something working by the end of the week or the beginning > of the next one. Depending on how fast the service configuration goes > on, I might also add a template for it. When the format of the XML > document is defined, I will worked on it too. > > Jerome. > > > _______________________________________________ > Openjmx-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjmx-devel > |
|
From: <no...@so...> - 2002-02-06 17:50:12
|
Bugs item #513839, was opened at 2002-02-06 09:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=410050&aid=513839&group_id=34041 Category: Http Adapter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Glencross (chrisglencross) Assigned to: Nobody/Anonymous (nobody) Summary: Default XSL stylesheets Initial Comment: Low priority: Would it be possible to change the templates so that results returned are wrapped in an HTML <PRE> block? Currently newlines are displayed as spaces making large blocks of text difficult to read. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=410050&aid=513839&group_id=34041 |
|
From: B. <jer...@xt...> - 2002-02-06 16:21:48
|
Carlos Quiroz wrote: >Yes beta2, no final yet and I agree about the MLET generation. We also >discussed about using xdoclet for generation of configuration files, but >that's somthing still in the future :-) > I am beginning to work on the mlet template. Just need to dig a little bit more in the merge system of XDoclet though. I hope to have something working by the end of the week or the beginning of the next one. Depending on how fast the service configuration goes on, I might also add a template for it. When the format of the XML document is defined, I will worked on it too. Jerome. |
|
From: <no...@so...> - 2002-02-06 15:07:52
|
Bugs item #513780, was opened at 2002-02-06 07:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=410050&aid=513780&group_id=34041 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Glencross (chrisglencross) Assigned to: Nobody/Anonymous (nobody) Summary: Log4JLogger logs everything as DEBUG Initial Comment: The log level numeric constants defined in Logger.java are different than the levels defined in Log4J 1.1.3 (Priority.java), and Log4JLogger isn't performing any conversions. This results in all messages being written to Log4J as DEBUG. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=410050&aid=513780&group_id=34041 |
1 message has been excluded from this view by a project administrator.
