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: Carlos Q. <car...@ge...> - 2002-02-01 08:56:06
|
Hi J=E9r=F4me=20 This is really, really good. I had never used xdoclet before and I'm very= =20 impressed. I think I'll move all my MBeans to use xdoclet Regards >-------- Original Message -------- >Subject: JMX work, and CustomerBMPBean >Date: Fri, 1 Feb 2002 00:59:15 +1100 From: "Dmitri Colebatch" <di...@oz...> >To: <xdo...@li...> >CC: J=E9r=F4me BERNARD <jer...@xt...> > > > > >hey all, > >=20 > >firstly - I've just checked in Jerome Bernard's JMX work from the=20 >OpenJMX project, and put the first beta of openjmx in the lib directory=20 >to enable the openjmx specific stuff to compile. the tags are: > >=20 > >class level: > > jmx:mbean extends=3D"" description=3D"" > >=20 > >method level: > > jmx:managed-constructor description=3D"" > > jmx:managed-constructor-parameter postition=3D"" name=3D"" description= =3D"" > >=20 > > jmx:managed-attribute description=3D"" > >=20 > > jmx:managed-operation description=3D"" > > jmx:managed-operation-parameter postition=3D"" name=3D"" description=3D= "" > >=20 > >ok - its only a first cut, I changed a few things, so it will probably=20 >need a little more work (tomorrow night) after Jerome has a look at my=20 >changes. but it should work, hav ea look at the samples. > >=20 > >secondly - CustomerBMPBean seems to be breaking, something to do with=20 >the dataobject. Anyone else seeing this? I had a super quick look, but= =20 >couldn't spot the cause. could someone give me a sanity check? > >=20 > >cheers > >dim > > > >_______________________________________________ >Openjmx-devel mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/openjmx-devel > |
|
From: Carlos Q. <car...@we...> - 2002-01-31 22:54:05
|
On Friday 01 February 2002 00:04, jacobsrimell wrote: > Hi, > Just checking on the correct place to put some examples which cover > FilePersister usage and some MLet loading. > > examples/tools/persister? I think FilePersister belings to tools but MLet to MBeans > > Also where to put the docs? > > examples tools? or examples MBeans? The same for the docs > > Thanx > Bronwen > > > _______________________________________________ > Openjmx-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjmx-devel |
|
From: jacobsrimell <bro...@ja...> - 2002-01-31 22:02:42
|
Hi, Just checking on the correct place to put some examples which cover FilePersister usage and some MLet loading. examples/tools/persister? Also where to put the docs? examples tools? or examples MBeans? Thanx Bronwen |
|
From: B. <jer...@xt...> - 2002-01-31 14:16:55
|
-------- Original Message -------- Subject: JMX work, and CustomerBMPBean Date: Fri, 1 Feb 2002 00:59:15 +1100 From: "Dmitri Colebatch" <di...@oz...> To: <xdo...@li...> CC: J=E9r=F4me BERNARD <jer...@xt...> hey all, =20 firstly - I've just checked in Jerome Bernard's JMX work from the=20 OpenJMX project, and put the first beta of openjmx in the lib directory=20 to enable the openjmx specific stuff to compile. the tags are: =20 class level: jmx:mbean extends=3D"" description=3D"" =20 method level: jmx:managed-constructor description=3D"" jmx:managed-constructor-parameter postition=3D"" name=3D"" description=3D= "" =20 jmx:managed-attribute description=3D"" =20 jmx:managed-operation description=3D"" jmx:managed-operation-parameter postition=3D"" name=3D"" description=3D= "" =20 ok - its only a first cut, I changed a few things, so it will probably=20 need a little more work (tomorrow night) after Jerome has a look at my=20 changes. but it should work, hav ea look at the samples. =20 secondly - CustomerBMPBean seems to be breaking, something to do with=20 the dataobject. Anyone else seeing this? I had a super quick look, but = couldn't spot the cause. could someone give me a sanity check? =20 cheers dim |
|
From: Carlos Q. <car...@ge...> - 2002-01-31 11:13:35
|
Hi >Hi, <snip> > >Ok, so it is useful only for MBeans. Yes that's the idea > >> A more refined version could do the cheking beforehand > >Well, if you use it only for MBeans, no check: use MBeanConstructorInfo=20 metadata. How can you get a MBeanConstructorInfo if your only data is classname? I was thinking to use you MBeanIntrospector class > >> > Finally, unless you perform instantiate and register in 2=20 >> http requests (I >> > guess you don't), doing createMBean or instantiate +=20 >> registerMBean is the >> > same. One call is probably simpler. >> Ok. I'm doing registerMBean, that's also better since if the=20 >> class is not=20 >> MBean it won't be instantiated, will be? > >No, it will be instantiated. Checks are done upon registration. You can=20 create whatever class with instantiate. Perhaps this is not desirable in this case. You would like the object not= to=20 be create unless it can be a MBean. This can be enforced outside the=20 registerMBean method tough > >Simon > > >_______________________________________________ >Openjmx-devel mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/openjmx-devel > |
|
From: B. <jer...@xt...> - 2002-01-31 10:50:46
|
Bordet, Simone wrote: >>If you want to garanty order then if you have one remote >>reference that >>is "dead" (because of network failure or client crash), you >>will block >>the server on this item and the other notifications won't be >>sent before >>a while. Is it really important to have a sequential order of >>notifications? What about adding (like Jini) an eventID and increment >>this ID each time a notification is sent. That way the client can >>"re-construct" the order if it matters. >> > >JMX already has event IDs, fortunately. >I was talking about filter + notify: these are 2 remote calls, and I should not do the second if the first filters it out. So I must wait for the first to complete. > >So, for each listener I can span a thread, but this thread must call filter AND notify. One thread per remote call is not good. > >I don't care notification ordering. > Ok. We were not speaking about the same thing then :-) Perhaps a pool of thread each handling a "filter+notify" operation would be better? Creating threads is really time consuming in Java... Jerome. |
|
From: Bordet, S. <Sim...@co...> - 2002-01-31 10:46:18
|
Hi, > >>The=20 > >>problem with this scheme is that you should try to send some=20 > >>few times=20 > >>the notification (there might be a network congestion for=20 > >>example) if it=20 > >>does not work the first time. The call should be threaded too=20 > >>because we=20 > >>do not want to block the server while calling the client.=20 > >> > > > >No, I do want. At least must be sequential the call for=20 > filtering and notification... > >Actual implementation is in same thread however: for server=20 > there is no difference between local and remote (I know, I know... :) > > > If you want to garanty order then if you have one remote=20 > reference that=20 > is "dead" (because of network failure or client crash), you=20 > will block=20 > the server on this item and the other notifications won't be=20 > sent before=20 > a while. Is it really important to have a sequential order of=20 > notifications? What about adding (like Jini) an eventID and increment=20 > this ID each time a notification is sent. That way the client can=20 > "re-construct" the order if it matters. JMX already has event IDs, fortunately. I was talking about filter + notify: these are 2 remote calls, and I = should not do the second if the first filters it out. So I must wait for = the first to complete. So, for each listener I can span a thread, but this thread must call = filter AND notify. One thread per remote call is not good. I don't care notification ordering. Simon |
|
From: B. <jer...@xt...> - 2002-01-31 10:33:11
|
Bordet, Simone wrote: >>The >>problem with this scheme is that you should try to send some >>few times >>the notification (there might be a network congestion for >>example) if it >>does not work the first time. The call should be threaded too >>because we >>do not want to block the server while calling the client. >> > >No, I do want. At least must be sequential the call for filtering and notification... >Actual implementation is in same thread however: for server there is no difference between local and remote (I know, I know... :) > If you want to garanty order then if you have one remote reference that is "dead" (because of network failure or client crash), you will block the server on this item and the other notifications won't be sent before a while. Is it really important to have a sequential order of notifications? What about adding (like Jini) an eventID and increment this ID each time a notification is sent. That way the client can "re-construct" the order if it matters. Jerome. |
|
From: Bordet, S. <Sim...@co...> - 2002-01-31 10:25:01
|
Hi, > Regarding your question about=20 > filtering at server or client side, I guess both would work.=20 > The lookup=20 > service in service handles that by saying that this is up to=20 > the client.=20 > So all notifications are sent and filtered on the client side.=20 So, only one should work: client side filtering ;) > The=20 > problem with this scheme is that you should try to send some=20 > few times=20 > the notification (there might be a network congestion for=20 > example) if it=20 > does not work the first time. The call should be threaded too=20 > because we=20 > do not want to block the server while calling the client.=20 No, I do want. At least must be sequential the call for filtering and = notification... Actual implementation is in same thread however: for server there is no = difference between local and remote (I know, I know... :) > Like for a lot of RMI application, I think that OpenJMX=20 > should run under=20 > a security manager (the RMI one would be fine) and a=20 > well-secured policy=20 > file. Yes. > We know from where are coming classes (with the help of codebase=20 > annotations) so why not simply add a sort of firewall? We=20 > could say that=20 > we accept for examples classes coming from location A and B. No, this will be done by the policy file. The real problem is that the = JMX security has totally been forgotten. If a JMXPermission must be = needed to install an MBean, then things would be simpler. Simon |
|
From: B. <jer...@xt...> - 2002-01-31 10:20:32
|
Bordet, Simone wrote: [...] >Yes, using MLets you can download jars and install nasty MBeans. This definitely calls for a SecurityManager. There are some trick to be solved (for example how to update the policy file) though. > You can't update a policy file at run-time before JDK 1.4. [...] >2) it will add *a lot* of complexity for use of adaptors: login, credentials, permissions. And all dynamic. The JMX spec does not address security issues, these must be discussed here. For example there should be a super user that allows to add new management users (that then may login to a http adaptor). So, many security levels... it must be well thought. > It depends on the the level of security you want to provide. Jerome. |
|
From: Bordet, S. <Sim...@co...> - 2002-01-31 10:17:46
|
Hi, > > > Second question: > > > What's the best way to do this. Do a createMBean (current > > > option) or do a > > > instantiate and then a registerMBean > > > > So, I did not totally get your feature. > > You can create objects of whatever class that will be=20 > stored along with the > > http session that then you can pass to constructors or=20 > setter methods ? Or > > you just display MBeanConstructorInfo metadata ? > No session ever, never :-) > the constructor request will return the constructors for a=20 > given class (any=20 > class). Then you get a GUI for using that constructor, that=20 > is fiels to set=20 > params and an objectname. Obviously if you query for=20 > java.lang.String you=20 > will get some constructor but if you try to construct it=20 > there will be a=20 > problem because it is not an MBean Ok, so it is useful only for MBeans. > A more refined version could do the cheking beforehand Well, if you use it only for MBeans, no check: use MBeanConstructorInfo = metadata. > > Finally, unless you perform instantiate and register in 2=20 > http requests (I > > guess you don't), doing createMBean or instantiate +=20 > registerMBean is the > > same. One call is probably simpler. > Ok. I'm doing registerMBean, that's also better since if the=20 > class is not=20 > MBean it won't be instantiated, will be? No, it will be instantiated. Checks are done upon registration. You can = create whatever class with instantiate. Simon |
|
From: B. <jer...@xt...> - 2002-01-31 10:11:59
|
J=E9r=F4me BERNARD wrote: [...] > The lookup service in service handles that by saying that this is up=20 > to the client. I meant the lookup service in Jini. Jerome. |
|
From: Bordet, S. <Sim...@co...> - 2002-01-31 10:11:07
|
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=20 > 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=20 > be notified > >of events ? > >The listener is always remote (from server point of view),=20 > and runs in > >the client. > Then you have a MBeanServer on the client side where you set=20 > a listener=20 > listening for events where? on the local MBeans or the RemoteMBeans? > In the later case the events are produced on the server and=20 > the question is=20 > whether to filter them on the server or on the client > Am I clear? No. On Client you have client application and the RMI connector. On Server you have RMI adaptor and MBeanServer, with your MBeans. One of your MBean emit events. MBeanServer dispatches events to = listeners. From client you register a remote listener. This listener is "remote" = for the server. The listener is notified on the client, in the sense = that handleNotification is run on the client JVM. The client becomes the = RMI server and the server the RMI client. Now question is: I want to filter events. I can do this: 1) on client 2) on server Option 1 means also filters are remote objects that are called from the = server. Option 2 means filters are serialized to the server and run there (with = security problems we saw). > Doesn't this problem extend to the MLet service. It is=20 > actually downloading=20 > jars and executing foreign code. My vision is that this=20 > ALWAYS call for a=20 > SecurityManager. Or maybe MLet code should be run in a sandbox "Sandbox" no. Yes, using MLets you can download jars and install nasty MBeans. This = definitely calls for a SecurityManager. There are some trick to be = solved (for example how to update the policy file) though. > Again, to create MBeans remotely you need to have the class=20 > definition on the=20 > server either beforehand (Then it can be considerd trusted)=20 > or later via MLet=20 > in which case there should be a protection. Of course you can=20 > assume that if=20 > somebody can create MLets in the server then the access is=20 > controlled and=20 > trusted Well, in general you cannot. While HTTP adaptor has basic authentication, RMI adaptor has not. So = every one can install it and access the MBeanServer (for now). The point is that with adaptors you need a security manager. However, I will wait to implement this level of security: 1) it will add some complexity to the code (but this does not worry me) 2) it will add *a lot* of complexity for use of adaptors: login, = credentials, permissions. And all dynamic. The JMX spec does not address = security issues, these must be discussed here. For example there should = be a super user that allows to add new management users (that then may = login to a http adaptor). So, many security levels... it must be well = thought. > >I just wanted here to know the opinion on filters, but the security > >issue must be faced. > >Fortunately I know something about it :) > Good ;-) > Perhaps you should take a closer look to the Http/SSL=20 > Adapters, there may be=20 > risks there too. As I told, I would wait to armor our JMX Agent with a tight shield. Simon |
|
From: B. <jer...@xt...> - 2002-01-31 10:07:51
|
Carlos Quiroz wrote: >[...] > >>>>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. >>> >>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. >> >Then you have a MBeanServer on the client side where you set a listener >listening for events where? on the local MBeans or the RemoteMBeans? >In the later case the events are produced on the server and the question is >whether to filter them on the server or on the client >Am I clear? > I do not understand why you need a MBeanServer on the client side. If a remote reference is given to the MBeanServer then it will simply call a remote method (so on the client side). Regarding your question about filtering at server or client side, I guess both would work. The lookup service in service handles that by saying that this is up to the client. So all notifications are sent and filtered on the client side. The problem with this scheme is that you should try to send some few times the notification (there might be a network congestion for example) if it does not work the first time. The call should be threaded too because we do not want to block the server while calling the client. If you choose to filter at server side, then it will be harder for a client to "change its mind" about filtering policies. ><snip> > >>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. >> >Doesn't this problem extend to the MLet service. It is actually downloading >jars and executing foreign code. My vision is that this ALWAYS call for a >SecurityManager. Or maybe MLet code should be run in a sandbox > Like for a lot of RMI application, I think that OpenJMX should run under a security manager (the RMI one would be fine) and a well-secured policy file. >>>My point is that this problem is much broader than only the >>>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. >> >Again, to create MBeans remotely you need to have the class definition on the >server either beforehand (Then it can be considerd trusted) or later via MLet >in which case there should be a protection. > We know from where are coming classes (with the help of codebase annotations) so why not simply add a sort of firewall? We could say that we accept for examples classes coming from location A and B. > Of course you can assume that if >somebody can create MLets in the server then the access is controlled and >trusted > This is another option although the previous item might enforce security. Jerome. |
|
From: Carlos Q. <car...@ge...> - 2002-01-31 09:46:28
|
>Hi, Hi Let's continue this discussion > >> > 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. Then you have a MBeanServer on the client side where you set a listener=20 listening for events where? on the local MBeans or the RemoteMBeans? In the later case the events are produced on the server and the question = is=20 whether to filter them on the server or on the client Am I clear? <snip> >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. Doesn't this problem extend to the MLet service. It is actually downloadi= ng=20 jars and executing foreign code. My vision is that this ALWAYS call for a= =20 SecurityManager. Or maybe MLet code should be run in a sandbox > >> 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. Again, to create MBeans remotely you need to have the class definition on= the=20 server either beforehand (Then it can be considerd trusted) or later via = MLet=20 in which case there should be a protection. Of course you can assume that= if=20 somebody can create MLets in the server then the access is controlled and= =20 trusted > >I just wanted here to know the opinion on filters, but the security >issue must be faced. >Fortunately I know something about it :) Good ;-) Perhaps you should take a closer look to the Http/SSL Adapters, there may= be=20 risks there too. > >Simon > |
|
From: Carlos Q. <car...@we...> - 2002-01-30 22:39:05
|
On Thursday 31 January 2002 00:26, Bordet, Simone wrote:
> Hi,
>
> > Hi all
> >
> > I just added what I believe is a crucial feature of the
> > HttpAdaptor. Now the
> > default MBean view will lead you to a page where you can query the
> > constructors of a given class. As an answer you will get the class'
> > constructors and you can create MBeans.
> >
> > Please give it a try.
> >
> > Some things open:
> > First:
> > How to handle classloaders?
> > Should the classloader be a MBean?
> > I guess so since the createMBean and instantiate methods
> > allow only an
> > ObjectName as loaderName.
>
> The classloader can be an MBean or the classloader of the MBeanServer class
> (on the server), if you specify it null, or the DLR, is you don't specify
> it. Jar must be available through an URL; so or local to the server, or
> served by an http server.
Now is working by using a null classloader
>
> > If so, how can you create a ClassLoader which is MBean and
> > has ObjectName?
> > AFAIK there is no such MBean, please correct me if I'm wrong.
>
> Aaaahhhhhh ! :)
> javax.management.loading.MLet
Right, this is the one. I knew it couldn't be missing :-)
I guess I will add an interface to create MLets, where you can pass a list of
URLs
>
> > Should we
> > create one in none is available?
>
> You can always do that: subclass URLClassLoader and give it a management
> interface (empty for that matters), and register it.
I guess the MLet is enough
>
> > Second question:
> > What's the best way to do this. Do a createMBean (current
> > option) or do a
> > instantiate and then a registerMBean
>
> So, I did not totally get your feature.
> You can create objects of whatever class that will be stored along with the
> http session that then you can pass to constructors or setter methods ? Or
> you just display MBeanConstructorInfo metadata ?
No session ever, never :-)
the constructor request will return the constructors for a given class (any
class). Then you get a GUI for using that constructor, that is fiels to set
params and an objectname. Obviously if you query for java.lang.String you
will get some constructor but if you try to construct it there will be a
problem because it is not an MBean
A more refined version could do the cheking beforehand
> If the latter, then parameter to constructor must be simple types (int,
> strings), right ? Do you use JavaBeans API to convert (PropertyEditors) ?
Now is only basic types + ObjectName. I'm thinking how to do it for adding
custom types in principle is not a problem as fas as you can have an empty
constructor or a constructor that takes a String, that includes things like
ObjectName, URL, Date.
This requires a bit more thinking tough
>
> Finally, unless you perform instantiate and register in 2 http requests (I
> guess you don't), doing createMBean or instantiate + registerMBean is the
> same. One call is probably simpler.
Ok. I'm doing registerMBean, that's also better since if the class is not
MBean it won't be instantiated, will be?
>
> One question: if you have this MBean:
>
> public class Service implements ServiceMBean
> {
> public Service(Info info) {...}
> }
> public class Info
> {
> public Info(String date, String user) {...}
> }
>
> it is not yet possible to create an Info object, store it along with http
> session and tell the adaptor to use that object to create the MBean, right
> ? Just curious.
No. Again no session has been implemented
>
> However, great job Carlos !
>
> Simon
>
> _______________________________________________
> Openjmx-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openjmx-devel
|
|
From: Bordet, S. <Sim...@co...> - 2002-01-30 22:26:49
|
Hi,
> Hi all
>=20
> I just added what I believe is a crucial feature of the=20
> HttpAdaptor. Now the=20
> default MBean view will lead you to a page where you can query the=20
> constructors of a given class. As an answer you will get the class'=20
> constructors and you can create MBeans.
>=20
> Please give it a try.
>=20
> Some things open:
> First:
> How to handle classloaders?
> Should the classloader be a MBean?
> I guess so since the createMBean and instantiate methods=20
> allow only an=20
> ObjectName as loaderName.
The classloader can be an MBean or the classloader of the MBeanServer =
class (on the server), if you specify it null, or the DLR, is you don't =
specify it. Jar must be available through an URL; so or local to the =
server, or served by an http server.
> If so, how can you create a ClassLoader which is MBean and=20
> has ObjectName?=20
> AFAIK there is no such MBean, please correct me if I'm wrong.=20
Aaaahhhhhh ! :)
javax.management.loading.MLet
> Should we=20
> create one in none is available?
You can always do that: subclass URLClassLoader and give it a management =
interface (empty for that matters), and register it.
> Second question:
> What's the best way to do this. Do a createMBean (current=20
> option) or do a=20
> instantiate and then a registerMBean
So, I did not totally get your feature.
You can create objects of whatever class that will be stored along with =
the http session that then you can pass to constructors or setter =
methods ?
Or you just display MBeanConstructorInfo metadata ?
If the latter, then parameter to constructor must be simple types (int, =
strings), right ?
Do you use JavaBeans API to convert (PropertyEditors) ?
Finally, unless you perform instantiate and register in 2 http requests =
(I guess you don't), doing createMBean or instantiate + registerMBean is =
the same. One call is probably simpler.
One question: if you have this MBean:
public class Service implements ServiceMBean
{
public Service(Info info) {...}
}
public class Info=20
{
public Info(String date, String user) {...}
}
it is not yet possible to create an Info object, store it along with =
http session and tell the adaptor to use that object to create the =
MBean, right ? Just curious.
However, great job Carlos !
Simon
|
|
From: Carlos Q. <car...@we...> - 2002-01-30 21:51:27
|
Hi all I just added what I believe is a crucial feature of the HttpAdaptor. Now the default MBean view will lead you to a page where you can query the constructors of a given class. As an answer you will get the class' constructors and you can create MBeans. Please give it a try. Some things open: First: How to handle classloaders? Should the classloader be a MBean? I guess so since the createMBean and instantiate methods allow only an ObjectName as loaderName. If so, how can you create a ClassLoader which is MBean and has ObjectName? AFAIK there is no such MBean, please correct me if I'm wrong. Should we create one in none is available? Second question: What's the best way to do this. Do a createMBean (current option) or do a instantiate and then a registerMBean Regards Carlos Quiroz |
|
From: Dmitri C. <di...@bi...> - 2002-01-30 20:30:39
|
lol. one thing I learnt using junit (only recently) is that to use it in the non-gui mode. you'll need to change the nongui class to call system.exit when all the threads have finished, as swing classes are initialized, and hence you get the swing thread running - it just sits there.... anyway, just in case you get stuck on it (o: cheers dim ----- Original Message ----- From: "Bordet, Simone" <Sim...@co...> To: "OpenJMX-Dev (E-mail)" <ope...@li...> Sent: Thursday, January 31, 2002 3:20 AM Subject: [Openjmx-devel] JUnit flame <flamemode> Ok, JUnit really sucks. REALLY. Apart for very simple stuff, it is really not good. So I thought, ok, should be extensible, and went to take a look at the code. My god, a mess, a real mess. These XP and pattern experts (Beck and Gamma) did an awful job. You can find in Javadocs: "Parts of this method was written at 2337 meters in the Hüffihütte, Kanton Uri". Hey, Switzerland is beautiful, but this one burned his brain at that altitude, and wrote crappy stuff. Has anyone tried to write tests so that some initialization code is run once per test class in an easy way (and please don't talk to me about TestSetup, another crappy thing) ? This is only one of the missing pieces. Wanna take a look to a bad design ? Interface Test depends on class TestResult, ok this far. Test should be the main interface for tests: wanna write a fully custom test ? just implement it. You cannot, because TestResult depends on a subclass of Test, TestCase :( And no separation between what the user implements and framework classes that run that implementation. Sooner or later, I will replace it. Hurts me. </flamemode> :) Simon _______________________________________________ Openjmx-devel mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/openjmx-devel |
|
From: Carlos Q. <car...@we...> - 2002-01-30 19:16:33
|
On Wednesday 30 January 2002 17:14, Bordet, Simone wrote:
> Hi,
>
> > > 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 ?
> >
> > It works form me
>
> Because you have mail.jar...
Yes in the lib dir
>
> > You should see a message at the beginning saying
> >
> > java.mail=true
> >
> > indicating that the required classes are found. If you get
> >
> > java.mail=javamail.present
>
> instead I get
>
> "jsse.present=${jsse.present}"
That's because your don't have JSSE jars (Nor not JDK 1.4 for that matter)
>
> which is very confusing...
>
> Can this message be more explicit ?
> For example:
>
> "JSSE classes not found, module SSLHTTPAdaptor will not be built."
>
> and similar for JavaMail ?
I agree that should be better I'd look for a solution
>
> Thanks
>
> Simon
>
> _______________________________________________
> Openjmx-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openjmx-devel
|
|
From: Carlos Q. <car...@we...> - 2002-01-30 19:15:04
|
On Wednesday 30 January 2002 18:06, Bronwen Cassidy wrote: > Hi, > The SSLHttpAdapter class is declared to have package examples.adaptor.http; > but it is in directory examples.tools.adaptor.http > can we update the package statement? Yea sure, that probably happened during the transition > > ******************************* > Name: Bronwen Cassidy > Title: Software Engineer > Jacobs Rimell > London > UK > e-mail address: bro...@ja... > tel: +44 (0)20 7786 4000 > fax: +44 (0)20 7786 4004 > Address: www.jacobsrimell.com > This email is confidential, may be legally privileged, and is for the > intended recipient only. If you are not the intended recipient, please > inform the sender and delete the email immediately. > ****************************** > > > > _______________________________________________ > Openjmx-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openjmx-devel |
|
From: Bordet, S. <Sim...@co...> - 2002-01-30 16:20:52
|
<flamemode> Ok, JUnit really sucks. REALLY. Apart for very simple stuff, it is really not good. So I thought, ok, should be extensible, and went to take a look at the = code. My god, a mess, a real mess. These XP and pattern experts (Beck and Gamma) did an awful job. You can find in Javadocs: "Parts of this method was written at 2337 meters in the H=FCffih=FCtte, = Kanton Uri". Hey, Switzerland is beautiful, but this one burned his brain at that = altitude, and wrote crappy stuff. Has anyone tried to write tests so that some initialization code is run = once per test class in an easy way (and please don't talk to me about = TestSetup, another crappy thing) ? This is only one of the missing pieces. Wanna take a look to a bad design ? Interface Test depends on class TestResult, ok this far.=20 Test should be the main interface for tests: wanna write a fully custom = test ? just implement it.=20 You cannot, because TestResult depends on a subclass of Test, TestCase = :( And no separation between what the user implements and framework classes = that run that implementation. Sooner or later, I will replace it. Hurts me. </flamemode> :) Simon |
|
From: Bronwen C. <Bro...@ja...> - 2002-01-30 16:07:54
|
Hi, The SSLHttpAdapter class is declared to have package examples.adaptor.http; but it is in directory examples.tools.adaptor.http can we update the package statement? ******************************* Name: Bronwen Cassidy Title: Software Engineer Jacobs Rimell London UK e-mail address: bro...@ja... tel: +44 (0)20 7786 4000 fax: +44 (0)20 7786 4004 Address: www.jacobsrimell.com This email is confidential, may be legally privileged, and is for the intended recipient only. If you are not the intended recipient, please inform the sender and delete the email immediately. ****************************** |
|
From: B. <jer...@xt...> - 2002-01-30 15:26:10
|
Ok. Will write one (anyway am in need of one). I just have to dig into java source code in order to figure out how to start/stop RMID. Jerome. Bordet, Simone wrote: >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 >>not really rmiregistry... >> > >Yes. Go on ! > >Devil-ly yours ]:-) > >Simon > |
|
From: Bordet, S. <Sim...@co...> - 2002-01-30 15:14:48
|
Hi,
> > 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
Because you have mail.jar...
> You should see a message at the beginning saying
>=20
> java.mail=3Dtrue
>=20
> indicating that the required classes are found. If you get
>=20
> java.mail=3Djavamail.present
instead I get=20
"jsse.present=3D${jsse.present}"
which is very confusing...
Can this message be more explicit ?
For example:
"JSSE classes not found, module SSLHTTPAdaptor will not be built."
and similar for JavaMail ?
Thanks
Simon
|
1 message has been excluded from this view by a project administrator.
