Message could not be delivered
by MAILER-DAEMON
The original message was received at Fri, 21 Aug 2009 00:20:33 +0200
from [177.140.171.60]
----- The following addresses had permanent fatal errors -----
jopr-dev(a)lists.jboss.org
16 years, 11 months
avail reports
by John Mazzitelli
Through performance testing, we have decided to increase the time agents wait before sending up availability reports and we've increased the quiet time the server allows between receiving avail reports before "backfilling" an agent (that is, marking the platform and all of its resources down).
Now, the default will be 5 minutes between avail reports getting sent by the agent (this is configurable, of course, on the agent via the rhq.agent.plugins.availability-scan.period-secs preference).
The server will have a default quiet time of 15 minutes - again, configurable - its done using the administration>server configuration>settings page.
I checked this into trunk - if anyone see problems let me know...
See: http://jira.rhq-project.org/browse/RHQ-1098
16 years, 12 months
Re: [jopr-dev] EmsException?
by John Mazzitelli
EmsBean bean = connection.getBean(AE_WEBMODULE_BEAN);
String aePath = bean.getAttribute("path").getValue().toString();
Which line throws that exception? You should temporarily break this up so you can get a good indication of where that error comes from:
EmsBean bean = connection.getBean(AE_WEBMODULE_BEAN);
Attribute attrib = bean.getAttribute("path")
Object value = attrib.getValue();
String aePath = value.toString();
I'll assume bean is coming back non-null (other wise, the next line would throw an NPE).
If the getAttribute() is the one throwing it, I'll assume your MBean does not have a "getPath()" method on it.
Just a guess but that's what I would look at... see what attributes the AE_WEBMODULE_MBEAN has on it and make sure it has a readable "getPath" no-arg attribute method on it.
----- Original Message -----
From: "Bruno Wassermann" <bruno.wassermann(a)googlemail.com>
To: "jopr-dev" <jopr-dev(a)lists.jboss.org>
Sent: Thursday, August 6, 2009 1:39:28 PM GMT -05:00 US/Canada Eastern
Subject: [jopr-dev] EmsException?
Hi again,
I have come across some weird(seeming) problem. In my ActiveBPEL discovery component, I connect to the JMX server on my Tomcat instance to look up the existence of a bean and extract a value from it, like so:
private final static String AE_WEBMODULE_BEAN = "Catalina:j2eeType=WebModule,name=//localhost/active-bpel,J2EEApplication=none,J2EEServer=none";
....
EmsConnection connection = null;
try {
connection = context.getParentResourceComponent().getEmsConnection();
EmsBean testBean = connection.getBean("Catalina:type=Server");
String testPort = testBean.getAttribute("port").getValue().toString();
log.debug(LOG_PREFIX + "THE PORT BEAN: " + testPort);
log.debug(LOG_PREFIX + "CONNECTION URL: " + connection.getConnectionProvider().getConnectionSettings().getServerUrl());
EmsBean bean = connection.getBean(AE_WEBMODULE_BEAN);
String aePath = bean.getAttribute("path").getValue().toString();
The poor agent ends up complaining as follows: EmsException: Could not load attribute value null.
Now, the same code works for retrieving a very similar MBean for Axis, the ActiveBPEL MBean name I'm using seems to be okay, testPort above is as expected. Why would it not be able to get the bean and its attributes?
Has anyone come across this in a similar context? I have read something about a Jopr/RHQ bug that results in the same exception...
Thanks,
-- Bruno
_______________________________________________
jopr-dev mailing list
jopr-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jopr-dev
16 years, 12 months
bad file name in the source tree?
by Rick.Carroll＠cox.com
I have tried several ways to download the source tree. Every time I get a maven exception trying to work with this file..
http://anonsvn.jboss.org/repos/jopr/docs/enterprise/JON/2.0.old/What_is_J...
SVN doesn't like the ? in the name.. there are 2 similarly named files with ? in the name.. .xml and .ent
It causes my download to crash every time.
Thanks,
Rick Carroll
----------------------------------------------------------------
Senior Infrastructure Engineer - Web Strategies
Cox Communications
404.269.5050 | ofc
678.923.0234 | cell
17 years
EmsException?
by Bruno Wassermann
Hi again,
I have come across some weird(seeming) problem. In my ActiveBPEL discovery
component, I connect to the JMX server on my Tomcat instance to look up the
existence of a bean and extract a value from it, like so:
private final static String AE_WEBMODULE_BEAN =
"Catalina:j2eeType=WebModule,name=//localhost/active-bpel,J2EEApplication=none,J2EEServer=none";
....
EmsConnection connection = null;
try {
connection =
context.getParentResourceComponent().getEmsConnection();
EmsBean testBean = connection.getBean("Catalina:type=Server");
String testPort =
testBean.getAttribute("port").getValue().toString();
log.debug(LOG_PREFIX + "THE PORT BEAN: " + testPort);
log.debug(LOG_PREFIX + "CONNECTION URL: " +
connection.getConnectionProvider().getConnectionSettings().getServerUrl());
EmsBean bean = connection.getBean(AE_WEBMODULE_BEAN);
String aePath = bean.getAttribute("path").getValue().toString();
The poor agent ends up complaining as follows: EmsException: Could not load
attribute value null.
Now, the same code works for retrieving a very similar MBean for Axis, the
ActiveBPEL MBean name I'm using seems to be okay, testPort above is as
expected. Why would it not be able to get the bean and its attributes?
Has anyone come across this in a similar context? I have read something
about a Jopr/RHQ bug that results in the same exception...
Thanks,
-- Bruno
17 years
Re: [jopr-dev] Hudson Plugin
by Tiago Bruno Pires Gomes
John Mazzitelli a écrit :
> Did you take a look at the hudson plugin prototype that is already in the RHQ SVN:
>
> http://svn.rhq-project.org/repos/rhq/trunk/modules/plugins/hudson/
>
> You can probably see how it did auto-discovery.
>
Yes, I did start from this plugin (i checkout the trunk). I did spot a
discoverResources method inside the HudsonServerDiscoveryComponent,
however it does requires an urlBase.
My real issue here is how can I make Jopr understand that the JBoss
instance it has already "autodiscovered" is an Hudson instance ?
>> "If JBoss AS Free Memory is running too low, invoke a Hudson operation such
>> as 'kill all current builds' ". Does it sounds possible (and sensible) to you ?
>>
>
> This is a long desired feature not yet implemented (I'll see if I can dig out that JIRA). We need a way to have an alert triggered on one resource to execute an operation on another resource. That we do not have yet, so you can't do this today. BUT! What you could do is expose a "Free Memory" metric directly on your Hudson resource (you would need to collect that metric yourself in the Hudson component - but that's not difficult to do). That way, you have a metric AND the operation on the same resource, which would allow you to do what you want.
>
> ----- Original Message -----
> From: "Tiago Bruno Pires Gomes" <tiago-bruno.piresgomes(a)atosorigin.com>
> To: jopr-dev(a)lists.jboss.org
> Cc: "romain pelisse" <romain.pelisse(a)atosorigin.com>
> Sent: Wednesday, July 29, 2009 10:10:06 AM GMT -05:00 US/Canada Eastern
> Subject: [jopr-dev] Hudson Plugin
>
> Hi
>
> I work on Hudson plugin for Jopr for several weeks now. I manage to some operations and metrics (not really usefull in this context) working. The plugin is still a beta but I feel it is working enough to be at release for review by jopr developer and contributor.
>
> The plugin (and its history) is availaible on BitBucket, as a mercurial repository :
>
> http://bitbucket.org/tpiresgo/hudsonplugin/
>
> Also, I have some troubles understanding how auto discovery works, can someone help me with this ?
>
> Once I'll get auto discovery working fine, I would like to know if such an operation sounds possible to you:
>
> "If JBoss AS Free Memory is running too low, invoke a Hudson operation such as 'kill all current builds' ". Does it sounds possible (and sensible) to you ?
------------------------------------------------------------------------
17 years
wsdl
by John Mazzitelli
Now that I have to endure an extra 60+ seconds of build time, can someone tell me what I get out of the webservices build :)
I see it doing something with wsdl generation. It used to be in the old prototype, http://localhost:7080/jbossws/services got me to a page with links to all the WSDLs... but that link isn't good.
What does this webservices build give me? Can I go to some URL to see the WSDLs? Or does something else have to be enabled for the web services to work?
17 years
Re: [jopr-dev] Plugin Dependencies
by mazz＠redhat.com
Bruno - FWIW, your previous email prodded me to update the "writing plugins" and "plugin extensions" wiki pages to explain further the new way we do plugin deployment and classloading... so, "this is all for you" :-)
http://jopr.org/confluence/display/RHQ/Writing+Custom+Plugins
http://jopr.org/confluence/display/RHQ/AMPS-Plugin+Extensions
----- Original Message -----
From: "Bruno Wassermann" <bruno.wassermann(a)googlemail.com>
To: "John Mazzitelli" <mazz(a)redhat.com>
Cc: "jopr-dev" <jopr-dev(a)lists.jboss.org>
Sent: Monday, August 3, 2009 4:21:23 AM GMT -05:00 US/Canada Eastern
Subject: Re: [jopr-dev] Plugin Dependencies
Hi John,
This was very useful, thank you and my plugin is working now :-)
-- Bruno
On Fri, Jul 31, 2009 at 3:10 PM, < mazz(a)redhat.com > wrote:
(be prepared: this is a long email :)
First of all, the plugin/classloading system is not as robust as the Eclipse plugin system, so please don't assume if you can do it in Eclipse, you can do it in the Jopr plugin system :-)
Second, when you say:
"This package is not declared in Tomcat's <plugin name... package="org.jboss.on.plugins.tomcat" declaration and therefore it won't be loaded by the Axis plugin class loader."
this is an incorrect assumption. The package= attribute has no bearing on the classloading or what classes get shared. This is only used to allow for "shorthand" classnames in the descriptor. Any relative classnames (not fully qualified) specified in the descriptor will be assumed to be in that package. That is all it is used for.
Third, yes there is this concept of transative deps such that if you have plugin A depend on plugin B depend on plugin C then C classes are in A (because C's classloader is the parent of B's classloader which is in turn the parent to A's classloader).
Forth, if you have this:
<depends plugin="A" />
<depends plugin="B" useClasses="true" />
The only dependency on plugin "A" is its metadata - NOT its classes. In the Jopr plugin system, you can only have a "useClasses" dependency on ONLY ONE plugin. So do not assume you can access "A"s classes in your plugin - you can only inherit its metadata and resource types. You do have access to Plugin B's classes in addition to its metadata/resource types.
In the new classloader stuff introduced in trunk (not in any releases yet but it is explained in that wiki page I posted earlier), think of <depends> as a "required" dependency - i.e. your plugin will NOT be able to be deployed UNLESS plugins A and B are deployed. Think of the <runs-inside> as an inferred dependency - called an "optional dependency". If you only have an optional dependency on plugin "A" (i.e. you have a <runs-inside> on a plugin "A" resource type) you don't have to have plugin A deployed - its "optional". The old way (in the current release) you have to have a <depends> for any external resource type you specify in the descriptor. This forces you to ensure that "A" and "B" are deployed along with your plugin (which sometimes you don't want to require, which is one reason for the new way we implemented).
However, the new way still has the restriction of only ONE <depends> can have a "useClasses". That sounds restrictive, and it is, but in our experience it usually is not a blocker because usually, plugins that depend on other plugins can usually rely on stacked/transative dependencies. For example, you have this:
<depends plugin="JMX" />
<depends plugin="Tomcat" useClasses="true" />
You do not need to specify the dependency on JMX. Since Tomcat has a <depends plugin="JMX">, you pick it up by <depend>ing on Tomcat. You don't have to specify it too.
Your component code is probably going to monitor Axis using JMX - so you can use the JMX components and classes to do the work, in the same way Tomcat plugin monitors other Tomcat things. And because you are depending on Tomcat, you can INJECT your resource types directly into the Tomcat type hierarchy. This sounds like the piece you are missing. There are two types of extending the type hierarchy in Jopr - Injection and Extension. You want Injection because you want to INJECT a "Axis" server type inside the Tomcat Server.
For more on this Injection/Extension stuff, see: http://jopr.org/confluence/display/RHQ/AMPS-Plugin+Extensions
So, in your descriptor, I suspect you'll want something like this:
<depends plugin="Tomcat" />
<server name="Axis"
discovery="org.rhq.plugins.jmx.MBeanResourceDiscoveryComponent"
class="AxisComponent"
description="Embedded Axis server running in Tomcat">
<runs-inside>
<parent-resource-type name="Tomcat Server" plugin="Tomcat"/>
</runs-inside>
<plugin-configuration>
<c:simple-property name="objectName" readOnly="true" default="..the Axis MBean ObjectName here..."/>
<c:simple-property name="nameTemplate" default="Axis"/>
<c:simple-property name="descriptionTemplate" default="Embedded Axis server running in Tomcat"/>
</plugin-configuration>
... your metric definitions, operations, etc. that you want to support for managing Axis ...
</server>
If you still can't get it, I'd be interested in helping you get off the ground with this. Feel free to email me your current plugin (zipped up with the source) and I'll take a quick look.
Also, let me know what version of Jopr you are using.
Thanks,
John Mazz
----- Original Message -----
From: "Bruno Wassermann" < bruno.wassermann(a)googlemail.com >
To: "John Mazzitelli" < mazz(a)redhat.com >
Cc: "jopr-dev" < jopr-dev(a)lists.jboss.org >
Sent: Friday, July 31, 2009 6:36:30 AM GMT -05:00 US/Canada Eastern
Subject: Re: [jopr-dev] Plugin Dependencies
Okay, I think I figured it out. The Tomcat plugin class I want to reuse in the Axis plugin is in package org.jboss.on.plugins.tomcat.helper. This package is not declared in Tomcat's <plugin name... package="org.jboss.on.plugins.tomcat" declaration and therefore it won't be loaded by the Axis plugin class loader.
Two observations. One could argue that I shouldn't write Axis code as a separate plugin, but rather include it as a server in the Tomcat plugin. That would solve the problem and seems to follow the approach generally taken in Jopr. In that case, is there a guarantee that all Tomcat instances will have been discovered, before the discovery component for Axis servers gets called? If not, how do you deal with that?
Second, it might be nice to allow plugin developers to specify the packages they want exposed to other plugins (i.e. that will be loaded by A's plugin class loader, if it depends on B). If someone has already implemented some useful feature, it would seem better to reuse it instead of duplicating the code. There is a similar feature for Eclipse plugins. However, with Eclipse you will usually build a reference implementation exercising your plugins' extension points and hence have an opportunity to figure out which packages you need to expose like that and which ones can remain internal. How a developer of Jopr plugins can figure this out is not entirely clear.
-- Bruno
On Fri, Jul 31, 2009 at 10:58 AM, Bruno Wassermann < bruno.wassermann(a)googlemail.com > wrote:
Hm,
I checked the plugin name in my depend, added an explicit useCases=true, but it still doesn't have TomcatConfig loaded at runtime. Is there, like for Eclipse plug-ins, a concept of internal and external (visible to other plugins that have some relationship with this plugin) classes and packages? I haven't seen any evidence for that, but just checking.
Are dependencies transitive? If we have plugins A, B, C and B depends on C and A depends on B and C, is it sufficient for A to declare its dependency on B with the dependency on C being implied?
Here's an excerpt from Axis' rhq-plugin.xml. Maybe you can spot something obvious that's wrong here?
<plugin
name="Axis"
displayName="Axis Server"
package="uk.ac.ucl.cs.sse.plugins.axis"
description="Discovery, measurment and management of Axis and deployed Web services"
xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance "
xmlns="urn:xmlns:rhq-plugin"
xmlns:c="urn:xmlns:rhq-configuration">
<depends plugin="JMX" />
<depends plugin="Tomcat" useClasses="true" />
<server
name="Axis Server"
...
-- Bruno
On Fri, Jul 31, 2009 at 3:41 AM, < mazz(a)redhat.com > wrote:
It sounds like what you are doing is correct. If you have a plugin "A" and it has some classes that you want available to plugin "B", then plugin "B"'s descriptor should have a <depends> tag on plugin "A":
<plugin name="B" ...>
<depends plugin="A" useClasses="true" />
...
</plugin>
What this does is put A's plugin classloader as the parent to B's plugin classloader. You do not have to do anything else other than put that <depends> in your descriptor (no need to put the plugin jar in your plugin jar's lib directory).
FYI: The useClasses, if not defined, is inferred on the last <depends> tag listed in the descriptor. If you only have one <depends> tag, its useClasses is assumed true if its not specified.
BTW: recently, alot of work has gone into trunk that performs more classloading "stuff". See: http://jopr.org/confluence/display/RHQ/Plugin+Dependencies+and+Class+Loaders
----- Original Message -----
From: "Bruno Wassermann" < bruno.wassermann(a)googlemail.com >
To: "jopr-dev" < jopr-dev(a)lists.jboss.org >
Sent: Thursday, July 30, 2009 5:46:05 PM GMT -05:00 US/Canada Eastern
Subject: Re: [jopr-dev] Plugin Dependencies
Whoops, it should rather be <depends plugin="xyz" useClasses="true/>, right? Sorry about the premature question :(
-- Bruno
On Thu, Jul 30, 2009 at 10:41 PM, Bruno Wassermann < bruno.wassermann(a)googlemail.com > wrote:
Hi,
This may be a typical newbie question...
I want the Axis plugin to be able to reuse some classes defined in the Tomcat plugin, namely TomcatConfig. To achieve this lofty goal I add the following to Axis.rhq-plugin.xml: <depends plugin="Tomcat"/>.
However, at runtime the class loader for the Axis plugin doesn't seem to have loaded Tomcat's classes. Asking the agent to run a discovery scan, the Axis plugin reports a NoClassDefFoundError for org.jboss.on.tomcat.helper.TomcatConfig.
What am I getting wrong here? Do I have to manually add the Tomcat plugin's jar file to my plugin?
Many thanks,
-- Bruno
_______________________________________________
jopr-dev mailing list
jopr-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jopr-dev
_______________________________________________
jopr-dev mailing list
jopr-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jopr-dev
_______________________________________________
jopr-dev mailing list
jopr-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jopr-dev
17 years
Re: [jopr-dev] Plugin Dependencies
by mazz＠redhat.com
(be prepared: this is a long email :)
First of all, the plugin/classloading system is not as robust as the Eclipse plugin system, so please don't assume if you can do it in Eclipse, you can do it in the Jopr plugin system :-)
Second, when you say:
"This package is not declared in Tomcat's <plugin name... package="org.jboss.on.plugins.tomcat" declaration and therefore it won't be loaded by the Axis plugin class loader."
this is an incorrect assumption. The package= attribute has no bearing on the classloading or what classes get shared. This is only used to allow for "shorthand" classnames in the descriptor. Any relative classnames (not fully qualified) specified in the descriptor will be assumed to be in that package. That is all it is used for.
Third, yes there is this concept of transative deps such that if you have plugin A depend on plugin B depend on plugin C then C classes are in A (because C's classloader is the parent of B's classloader which is in turn the parent to A's classloader).
Forth, if you have this:
<depends plugin="A" />
<depends plugin="B" useClasses="true" />
The only dependency on plugin "A" is its metadata - NOT its classes. In the Jopr plugin system, you can only have a "useClasses" dependency on ONLY ONE plugin. So do not assume you can access "A"s classes in your plugin - you can only inherit its metadata and resource types. You do have access to Plugin B's classes in addition to its metadata/resource types.
In the new classloader stuff introduced in trunk (not in any releases yet but it is explained in that wiki page I posted earlier), think of <depends> as a "required" dependency - i.e. your plugin will NOT be able to be deployed UNLESS plugins A and B are deployed. Think of the <runs-inside> as an inferred dependency - called an "optional dependency". If you only have an optional dependency on plugin "A" (i.e. you have a <runs-inside> on a plugin "A" resource type) you don't have to have plugin A deployed - its "optional". The old way (in the current release) you have to have a <depends> for any external resource type you specify in the descriptor. This forces you to ensure that "A" and "B" are deployed along with your plugin (which sometimes you don't want to require, which is one reason for the new way we implemented).
However, the new way still has the restriction of only ONE <depends> can have a "useClasses". That sounds restrictive, and it is, but in our experience it usually is not a blocker because usually, plugins that depend on other plugins can usually rely on stacked/transative dependencies. For example, you have this:
<depends plugin="JMX" />
<depends plugin="Tomcat" useClasses="true" />
You do not need to specify the dependency on JMX. Since Tomcat has a <depends plugin="JMX">, you pick it up by <depend>ing on Tomcat. You don't have to specify it too.
Your component code is probably going to monitor Axis using JMX - so you can use the JMX components and classes to do the work, in the same way Tomcat plugin monitors other Tomcat things. And because you are depending on Tomcat, you can INJECT your resource types directly into the Tomcat type hierarchy. This sounds like the piece you are missing. There are two types of extending the type hierarchy in Jopr - Injection and Extension. You want Injection because you want to INJECT a "Axis" server type inside the Tomcat Server.
For more on this Injection/Extension stuff, see: http://jopr.org/confluence/display/RHQ/AMPS-Plugin+Extensions
So, in your descriptor, I suspect you'll want something like this:
<depends plugin="Tomcat" />
<server name="Axis"
discovery="org.rhq.plugins.jmx.MBeanResourceDiscoveryComponent"
class="AxisComponent"
description="Embedded Axis server running in Tomcat">
<runs-inside>
<parent-resource-type name="Tomcat Server" plugin="Tomcat"/>
</runs-inside>
<plugin-configuration>
<c:simple-property name="objectName" readOnly="true" default="..the Axis MBean ObjectName here..."/>
<c:simple-property name="nameTemplate" default="Axis"/>
<c:simple-property name="descriptionTemplate" default="Embedded Axis server running in Tomcat"/>
</plugin-configuration>
... your metric definitions, operations, etc. that you want to support for managing Axis ...
</server>
If you still can't get it, I'd be interested in helping you get off the ground with this. Feel free to email me your current plugin (zipped up with the source) and I'll take a quick look.
Also, let me know what version of Jopr you are using.
Thanks,
John Mazz
----- Original Message -----
From: "Bruno Wassermann" <bruno.wassermann(a)googlemail.com>
To: "John Mazzitelli" <mazz(a)redhat.com>
Cc: "jopr-dev" <jopr-dev(a)lists.jboss.org>
Sent: Friday, July 31, 2009 6:36:30 AM GMT -05:00 US/Canada Eastern
Subject: Re: [jopr-dev] Plugin Dependencies
Okay, I think I figured it out. The Tomcat plugin class I want to reuse in the Axis plugin is in package org.jboss.on.plugins.tomcat.helper. This package is not declared in Tomcat's <plugin name... package="org.jboss.on.plugins.tomcat" declaration and therefore it won't be loaded by the Axis plugin class loader.
Two observations. One could argue that I shouldn't write Axis code as a separate plugin, but rather include it as a server in the Tomcat plugin. That would solve the problem and seems to follow the approach generally taken in Jopr. In that case, is there a guarantee that all Tomcat instances will have been discovered, before the discovery component for Axis servers gets called? If not, how do you deal with that?
Second, it might be nice to allow plugin developers to specify the packages they want exposed to other plugins (i.e. that will be loaded by A's plugin class loader, if it depends on B). If someone has already implemented some useful feature, it would seem better to reuse it instead of duplicating the code. There is a similar feature for Eclipse plugins. However, with Eclipse you will usually build a reference implementation exercising your plugins' extension points and hence have an opportunity to figure out which packages you need to expose like that and which ones can remain internal. How a developer of Jopr plugins can figure this out is not entirely clear.
-- Bruno
On Fri, Jul 31, 2009 at 10:58 AM, Bruno Wassermann < bruno.wassermann(a)googlemail.com > wrote:
Hm,
I checked the plugin name in my depend, added an explicit useCases=true, but it still doesn't have TomcatConfig loaded at runtime. Is there, like for Eclipse plug-ins, a concept of internal and external (visible to other plugins that have some relationship with this plugin) classes and packages? I haven't seen any evidence for that, but just checking.
Are dependencies transitive? If we have plugins A, B, C and B depends on C and A depends on B and C, is it sufficient for A to declare its dependency on B with the dependency on C being implied?
Here's an excerpt from Axis' rhq-plugin.xml. Maybe you can spot something obvious that's wrong here?
<plugin
name="Axis"
displayName="Axis Server"
package="uk.ac.ucl.cs.sse.plugins.axis"
description="Discovery, measurment and management of Axis and deployed Web services"
xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance "
xmlns="urn:xmlns:rhq-plugin"
xmlns:c="urn:xmlns:rhq-configuration">
<depends plugin="JMX" />
<depends plugin="Tomcat" useClasses="true" />
<server
name="Axis Server"
...
-- Bruno
On Fri, Jul 31, 2009 at 3:41 AM, < mazz(a)redhat.com > wrote:
It sounds like what you are doing is correct. If you have a plugin "A" and it has some classes that you want available to plugin "B", then plugin "B"'s descriptor should have a <depends> tag on plugin "A":
<plugin name="B" ...>
<depends plugin="A" useClasses="true" />
...
</plugin>
What this does is put A's plugin classloader as the parent to B's plugin classloader. You do not have to do anything else other than put that <depends> in your descriptor (no need to put the plugin jar in your plugin jar's lib directory).
FYI: The useClasses, if not defined, is inferred on the last <depends> tag listed in the descriptor. If you only have one <depends> tag, its useClasses is assumed true if its not specified.
BTW: recently, alot of work has gone into trunk that performs more classloading "stuff". See: http://jopr.org/confluence/display/RHQ/Plugin+Dependencies+and+Class+Loaders
----- Original Message -----
From: "Bruno Wassermann" < bruno.wassermann(a)googlemail.com >
To: "jopr-dev" < jopr-dev(a)lists.jboss.org >
Sent: Thursday, July 30, 2009 5:46:05 PM GMT -05:00 US/Canada Eastern
Subject: Re: [jopr-dev] Plugin Dependencies
Whoops, it should rather be <depends plugin="xyz" useClasses="true/>, right? Sorry about the premature question :(
-- Bruno
On Thu, Jul 30, 2009 at 10:41 PM, Bruno Wassermann < bruno.wassermann(a)googlemail.com > wrote:
Hi,
This may be a typical newbie question...
I want the Axis plugin to be able to reuse some classes defined in the Tomcat plugin, namely TomcatConfig. To achieve this lofty goal I add the following to Axis.rhq-plugin.xml: <depends plugin="Tomcat"/>.
However, at runtime the class loader for the Axis plugin doesn't seem to have loaded Tomcat's classes. Asking the agent to run a discovery scan, the Axis plugin reports a NoClassDefFoundError for org.jboss.on.tomcat.helper.TomcatConfig.
What am I getting wrong here? Do I have to manually add the Tomcat plugin's jar file to my plugin?
Many thanks,
-- Bruno
_______________________________________________
jopr-dev mailing list
jopr-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jopr-dev
_______________________________________________
jopr-dev mailing list
jopr-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jopr-dev
17 years
