more on plugins/classloaders
by John Mazzitelli
Tell me where I am wrong.
Suppose I am writing plugin "Z" - there are plugins A, B, C and D that may or may not be deployed. Here's Z's descriptor:
<plugin name="Z">
<depends plugin="A" />
<server name="Z1.server">
<runs-inside>
<parent-resource-type name="B1.server" plugin="B"/>
<parent-resource-type name="C1.server" plugin="C"/>
<runs-inside>
</server>
<server name="Z2.server">
sourcePlugin="D"
sourceType="D1" >
</server>
</plugin>
This means that if I deploy Z, then:
1) plugin 'A' MUST be deployed as well (i.e. if A does not exist, Z will not deploy).
2) plugin D may or may not exist, if it doesn't exist, then.... what is Z2.server? Do we ignore that? Since D1 type definition doesn't exist, then Z2.server can't possibly exist. I think we ignore Z2.server as if it was never there
3) plugin B and plugin C may or may not exist. If they don't exist, then Z1.server is meaningless. I think we ignore Z1.server if B and C are missing
4) When Z1.server is detected, the component's classloader includes what? Its parent classloader is A classloader plus B classloader? Or C?
5) what if there are TWO or more <depends> tags - say <depends plugin="E"> in addition to above. Does Z plugin classloader include the A and E classes? I think so (not sure how I'm gonna implement that)
6) where does this "child first" or "hidden" configuration go? What is its semantics?
Is there anything else i'm missing that I need to consider? anything I need to make sure I impement?
15 years, 11 months
Inverted plugin dependencies / optional dependencies
by Heiko W.Rupp
Hi,
currently we have plugin dependencies that a "child" plugin can say it
depends on a parent plugin
E.g. in the hibernate plugin:
<depends plugin="JMX" />
<depends plugin="JBossAS" useClasses="true"/>
and later
<runs-inside>
<parent-resource-type name="JMX Server" plugin="JMX"/>
<parent-resource-type name="JBossAS Server" plugin="JBossAS"/>
</runs-inside>
Now if I would want to re-use the hibernate plugin in the AS5 plugin,
I could write:
<depends plugin="JMX" />
<depends plugin="JBossAS" useClasses="true"/>
<depends plugin="JBossAS5" useClasses="true"/>
But a) 2x useClasses="true" is probably not allowed and b) it would
require that both the as4 + as5 plugin need always to be present, even
in the case of Embedded Jopr within AS5.
So one way to tackle this could be that the Hibernate plugin is not
declaring a
depencency on the AS* plugins, but that the AS* plugins "import" the
Hibernate plugin
<import plugin="Hibernate"/>
This also has the advantage that the Hibernate plugin would not need
to be
modified when e.g. it should be used within e.g. the Tomcat plugin.
Another option could be to mark/group optional or mutual exclusive
dependencies
<depends plugin="JMX" />
<mutual-exclusive>
<depends plugin="JBossAS" useClasses="true"/>
<depends plugin="JBossAS5" useClasses="true"/>
</mutual-exclusive>
Here only one of AS4 or AS5 plugins needs to be present and the JMX
plugin is required.
One thing we need with both approaches is to meaning fully inject the
parent resource and/or
existing EmsConnections (I have the feeling that very often the parent
is needed because of its
connections to the remote).
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei
München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham,
Charles Cachera
15 years, 11 months
Hit by JOPR-90 ?
by Heiko W.Rupp
Hi,
if you have been hit by the war with <distributable/> tag not
discovered bug:
I need your help.
Have a look at
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4232198#4232198
Thanks
Heiko
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei
München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham,
Charles Cachera
15 years, 12 months
readlink
by John Mazzitelli
(6:00:56 PM) mburchard_enforcer: mazz-out: jshaughn-away: readlink: not found
See: http://jira.rhq-project.org/browse/RHQ-1520
And its doc'ed here:
http://www.redhat.com/docs/en-US/JBoss_ON/2.2/html/Installation_Guide/JON...
"Important
Solaris Admins: Symbolically linking the rhq agent binaries requires invocation of readlink in rhq-agent-wrapper.sh. However, readlink is not supplied by default in some Solaris installations. Solaris users must either download readlink from a third party provider, such as Sunfreeware, or refrain from symbolically linking the agent binaries when using the wrapper script. "
16 years
Automagic parent property reference in plugin descriptor
by Heiko W.Rupp
Hi,
I am just thinking of something like
<server ...
objectName="jboss.foo:service=bar,name="%name%">
<service ..
objectName="jboss.foo:service=bar,name=???,subService=x" />
</server>
Meaning that I'd like to be able to tell my object name in the service
to only find
instances of jboss.foo:service=bar,subService=x where the name
attribute has the same value
as in the server's object name.
And this especially in the view of the MBeanResourceDiscoveryComponent
Do we have something like this? Would this be useful?
Heiko
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei
München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham,
Charles Cachera
16 years
Fwd: New AS Server Version : 4.2.3.GA
by John Mazzitelli
this needs to go out to the community ... forwarding to jopr-dev
----- Forwarded Message -----
From: "Jay Shaughnessy" <jshaughn(a)redhat.com>
Sent: Friday, May 8, 2009 4:38:13 PM GMT -05:00 US/Canada Eastern
Subject: New AS Server Version : 4.2.3.GA
I've just checked in the upgrade from 4.2.1.GA to 4.2.3.GA (rev3924) as the base AS version for the RHQ server. This will have a traumatic effect on your next updated build. Here are the steps I suggest you take when you're ready (note - do not svn up prematurely):
1. Clean everything from RHQ root
> cd <my-build-aread>/rhq-trunk
> mvn clean -Pdev,enterprise
2. Delete some things from your maven repository (typically HOME/.m2/respository)
> cd <m2-repo>
> rm -rf jboss
> rm -rf org.jboss
Or, if you haven't done it in a while, consider wiping out your whole repo and start fresh. This could get rid of a lot of old stuff like outdated dependencies and SNAPSHOTS from 2.2 and maybe even earlier. It will of course slow down your build as everything has to be fetched.
3. Update RHQ
> svn up
4. Build it all again
Note - you don't have to perform a dbsetup, that's all still valid.
> mvn install -Pdev,enterprise -Dmaven.test.skip
5. (optional) Build Jopr
Just svn up and build as usual.
You should be off and running, please let me know if anything fails in this process. And be wary of any new, unusual behavior, perhaps it has to do with one of the several upgraded packages.
-Jay
16 years