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-03-01 17:53:18
|
Hi all, MX4J beta 3 has been released.=20 MX4J is the new name of the OpenJMX project, that had to change name = since 'JMX' is a registered trademark of Sun Microsystems. Checkout the new project page at http://mx4j.sourceforge.net, and = download the new release ! The new release contains few bug fixes, the whole suite of RMI = adaptors/connectors, and a Jython MBean. Enjoy it ! Simon |
|
From: GUPTA,SUMIT (HP-NewJersey,ex2) <sum...@hp...> - 2002-02-27 21:09:37
|
Hi, I get an java.io.NotSerializableException: javax.management.modelmbean.DescriptorSupport while trying to getMBeanInfo remotely. Could DescriptorSupport be tagged as serializable? Thanks. Sumit |
|
From: Bordet, S. <Sim...@co...> - 2002-02-27 18:35:04
|
Unfortunately is not possible for the project administrator to move all = subscribers from OpenJMX's mailing list to MX4J, since to subscribe you = have to enter a password. Therefore you have to unsubscribe from OpenJMX's and subscribe to MX4J, = choosing the format and the password you like. Simon |
|
From: Bordet, S. <Sim...@co...> - 2002-02-27 18:02:31
|
Hi all as you may know we have been contacted by Sun because OpenJMX is a name = that violates the trademark rules, since JMX is a trademark of Sun. We have to change name, we decided the new name be "MX4J", accordingly = with Sun's trademark lawyers that approved this choice. The new project, MX4J, is hosted by sourceforge, here: = http://sourceforge.net/projects/mx4j I will try to automatically subscribe all mailing list subscribers from = OpenJMX to MX4J, but I don't know if it is possible. For now: 1 - Committers, don't commit anything from now on 2 - Please wait one-two days for the new project to be completely = operative OpenJMX project will still remain alive for a while, but will point to = MX4J. Simon |
|
From: Bronwen C. <Bro...@ja...> - 2002-02-25 09:59:20
|
Hi, 1) MX4J - gets first vote OpenMX4J is a choice to add to list > -----Original Message----- > From: Bordet, Simone [mailto:Sim...@co...] > Sent: 25 February 2002 09:54 > To: OpenJMX-Dev (E-mail); ope...@li... > Subject: [Openjmx-devel] OpenJMX Name change: VOTE your favorite ! > > > OpenJMX should be very likely change its name, since the JMX > part is trademark of Sun. > > We have several proposal, we ask you to vote or propose for > your favorite ! > > 1) MX4J (Management eXtensions for Java) > 2) OMX4J (Open Management eXtensions for Java) > 3) OpenMeX > 4) OpenMeX4J > 5) MeX4J > > Propose your own, or vote your favorite ! > > Simon > > _______________________________________________ > Openjmx-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjmx-devel > |
|
From: Bordet, S. <Sim...@co...> - 2002-02-25 09:54:05
|
OpenJMX should be very likely change its name, since the JMX part is = trademark of Sun. We have several proposal, we ask you to vote or propose for your = favorite ! 1) MX4J (Management eXtensions for Java) 2) OMX4J (Open Management eXtensions for Java) 3) OpenMeX 4) OpenMeX4J 5) MeX4J Propose your own, or vote your favorite ! Simon |
|
From: Bordet, S. <Sim...@co...> - 2002-02-22 23:08:02
|
Why is there a setMBeanServer not defined by the spec ? Simon |
|
From: <bou...@ya...> - 2002-02-22 16:09:26
|
confirm 955921 ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com |
|
From: Carlos Q. <car...@we...> - 2002-02-20 18:19:12
|
On Wednesday 20 February 2002 20:09, Bordet, Simone wrote: > I will put out the release candidate 1.0 by the end of this week. > > Any objection ? No objections, but I'm afraid I cannot help, I'm too busy this week > > Simon > > _______________________________________________ > Openjmx-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjmx-devel |
|
From: Bordet, S. <Sim...@co...> - 2002-02-20 18:09:32
|
I will put out the release candidate 1.0 by the end of this week. Any objection ? Simon |
|
From: Bordet, S. <Sim...@co...> - 2002-02-20 18:08:41
|
Carlos, are the query finished ? If so, can you update SF task manager ? Simon |
|
From: Carlos Q. <car...@we...> - 2002-02-17 22:12:32
|
Hi all
Tired of writing long Java management code for simple tasks? Do them in
jython :-)
I just commited the JythonRunner MBean. It basically allows you to use jython
scripts which may reduce the size of your code and allow changes in runtime.
The scripts are loaded at every run, and can be modified in runtime. The
MBean can be tied to a NotificationBroadcaster (monitor, timer, etc..) and it
will be executed when a notification is emitted. You can also call directly
runScript().
The variable server is automatically available and points to the current
server. Statements like these below are valid
#makes a list of all mbeans
[server.queryMBean(None, None)]
#prints the description of the MBean Domain:name=test
print server.getMBeanInfo(ObjectName("Domain:name=test")).description
I also added a openjmx module which is automatically imported and it adds all
the jmx core classes and a proxy class. The proxy class is similar to the
StandardMBeanProxy and can be used like this:
name = ObjectName("Domain:name=test")
#create proxy
p = proxy(name)
#print attribute counter
print p.counter
#change attribute attr
p.attr=5
#invoke method start (Notice that method with arguments are not availabe yet
p.start()
The docs are comming soon
Regards
Carlos Quiroz
|
|
From: Carlos Q. <car...@we...> - 2002-02-14 23:19:43
|
Hi all From now on the commits list wil recive a daily build report, which is the same that generates the daily test report and documentation. Regards Carlos Quiroz |
|
From: Bordet, S. <Sim...@co...> - 2002-02-14 15:26:07
|
Hi, > BTW I got this creating the docs >=20 > [style] Error > [style] java.io.FileNotFoundException:=20 > /home/tibu/openjmx/src/docs/dev-intro.xml (No such file or directory) > [style] Failed to process /home/tibu/openjmx/src/docs/index.xml I just removed it few minutes ago, try now. Simon |
|
From: Carlos Q. <car...@we...> - 2002-02-14 15:22:37
|
On Thursday 14 February 2002 15:30, Bordet, Simone wrote:
> Are they built ?
No. last time was on Feb 11, now is fixed.
BTW I got this creating the docs
[style] Error
[style] java.io.FileNotFoundException:
/home/tibu/openjmx/src/docs/dev-intro.xml (No such file or directory)
[style] Failed to process /home/tibu/openjmx/src/docs/index.xml
Will try to do some docs this weekend
>
> It seems to me they're old...
>
> Simon
>
> _______________________________________________
> Openjmx-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openjmx-devel
|
|
From: Bordet, S. <Sim...@co...> - 2002-02-14 15:11:27
|
There are no more TODO's in the documentation, although it can be = greatly improved. Contributions are welcome, lazy developers ! We're very close to RC, maybe beginning of next week. Simon |
|
From: Bordet, S. <Sim...@co...> - 2002-02-14 13:30:27
|
Are they built ? It seems to me they're old... Simon |
|
From: Bordet, S. <Sim...@co...> - 2002-02-13 12:11:05
|
Hi,=20 take a look in CVS :) Simon |
|
From: Bordet, S. <Sim...@co...> - 2002-02-13 11:33:39
|
Hi,=20 I setup a project page also on FreshMeat, to be updated every time we = submit a new release or a new News. http://freshmeat.net/projects/openjmx/ Just to give us some more visibility, freshmeat is only an advertising = site. Simon |
|
From: Carlos Q. <car...@we...> - 2002-02-12 18:39:20
|
On Tuesday 12 February 2002 19:29, Bordet, Simone wrote: > Hi all, > > so I have just finished the RMI adaptors, and found a better architecture > to implement them. > > Current one is: > > RMIConnector --> network --> RMIProtocolAdaptor --> MBeanServer > > where RMIAdaptor sits on top of the RMIProtocolAdaptor to give > manageability to it. > > New one will be: > > RMIConnector --> network --> RMIProtocolAdaptor --> Interceptor 1 --> > Interceptor 2 --> ... --> Interceptor n --> MBeanServer > > Every interceptor is an MBean and it's registered along with the RMIAdaptor > MBean. It is possible to enable/disable the interceptors, and every > interceptor can perform operations based on the informations it has. For > example one can write an interceptor that uses JAAS to allow or not certain > users to perform some operations, or not use JAAS and do the same kind of > checks. Or another interceptor that will record different users, or one > that records the hit per second of the interceptors, and so on. This sounds very interesting, and we could actually use it for the HTTP Adaptor as well. I guess we'll be providing some interceptors with openjmx. I can imagine an interceptor which knows of other MBean Agents in the network and can communicate with them. Somehting like RMIConnector --> network --> RMIProtocolAdaptor --> Interceptor 1 --> Interceptor 2 --> RMIConnection --> network --> Interceptor n --> MBeanServer (in another node) I say, go for it > > I've already done 90% of the new architecture and seems to work well. > > It will have much more dynamicity, manageability, and it is easily > extendible by a user that wants custom interceptors. > > I think I will replace the old architecture with this new one, keeping all > the good features of the previous (IIOP, SSL, remote listeners, etc). The > new architecture only affects the management part, and slightly the > implementation. For example for users is transparent: the usage is the same > I don't have even to change the documentation :) > > Opinions are welcome > > Simon > > _______________________________________________ > Openjmx-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjmx-devel |
|
From: Bordet, S. <Sim...@co...> - 2002-02-12 17:29:55
|
Hi all, so I have just finished the RMI adaptors, and found a better = architecture to implement them. Current one is: RMIConnector --> network --> RMIProtocolAdaptor --> MBeanServer where RMIAdaptor sits on top of the RMIProtocolAdaptor to give = manageability to it. New one will be: RMIConnector --> network --> RMIProtocolAdaptor --> Interceptor 1 --> = Interceptor 2 --> ... --> Interceptor n --> MBeanServer Every interceptor is an MBean and it's registered along with the = RMIAdaptor MBean. It is possible to enable/disable the interceptors, and every interceptor = can perform operations based on the informations it has. For example one can write an interceptor that uses JAAS to allow or not = certain users to perform some operations, or not use JAAS and do the = same kind of checks. Or another interceptor that will record different users, or one that = records the hit per second of the interceptors, and so on. I've already done 90% of the new architecture and seems to work well. It will have much more dynamicity, manageability, and it is easily = extendible by a user that wants custom interceptors. I think I will replace the old architecture with this new one, keeping = all the good features of the previous (IIOP, SSL, remote listeners, = etc). The new architecture only affects the management part, and = slightly the implementation. For example for users is transparent: the = usage is the same I don't have even to change the documentation :) Opinions are welcome Simon |
|
From: <no...@so...> - 2002-02-12 13:16:48
|
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: Nobody/Anonymous (nobody) Date: 2002-02-12 05:12 Message: Logged In: NO I got the same problem and what I did was to replace all the back slashes with slashes just by using File.toString ().replace('\','/'). It is not so elegant as your suggestion but it works as well. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-02-12 05:08 Message: Logged In: NO I got the same problem and what I did was to replace all the back slashes with slashes just by using File.toString ().replace('\','/'). It is not so elegant as your suggestion but it works as well. ---------------------------------------------------------------------- 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-12 13:12:43
|
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: Nobody/Anonymous (nobody) Date: 2002-02-12 05:08 Message: Logged In: NO I got the same problem and what I did was to replace all the back slashes with slashes just by using File.toString ().replace('\','/'). It is not so elegant as your suggestion but it works as well. ---------------------------------------------------------------------- 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: Carlos Q. <car...@we...> - 2002-02-11 18:27:23
|
On Monday 11 February 2002 18:35, Bordet, Simone wrote: > 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. Agreed > > -------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". This is a very good explanation (now I understand it :-)), please add it to the docs > > 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 > > > > > _______________________________________________ > Openjmx-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjmx-devel |
|
From: Carlos Q. <car...@we...> - 2002-02-11 18:26:03
|
On Monday 11 February 2002 19:05, Bordet, Simone wrote: > ... 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 I think is ok, they are not that big anyway > > Simon > > _______________________________________________ > Openjmx-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjmx-devel |
1 message has been excluded from this view by a project administrator.
