[JBoss-dev] How about integrating JSR77 via notifications
A problem that keeps popping up with the JSR77 integration is that it is rather invasive and if it fails it breaks existing code. A better integration path would be strictly as external listeners to JMX events. This would clean up the integration, make it easy to disable and require that key events were being made available for purposes other than JSR77. Scott Stark Chief Technology Officer JBoss Group, LLC ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] How about integrating JSR77 via notifications
Hi Scott A problem that keeps popping up with the JSR77 integration is that it is rather invasive and if it fails it breaks existing code. A better integration path would be strictly as external listeners to JMX events. This would clean up the integration, make it easy to disable and require that key events were being made available for purposes other than JSR77. I don't think this is possible. We are already listening to JMX events to determine the state of a component. But this is only the easy part of JSR-77. Even thought that JSR-77 spec. does not really cover what it was supposed to do the main part currenlty is to retrieve and calculate performance statstics. The rest is just to provide a JSR-77 compliant view to an application server. BTW I am not aware that JSR-77 breaks existing code. Mostely it was the other way around that changes where made and the JSR-77 stuff was left out and broke. The design is made that the invasive part is as small as possible. So what is the source of the problem ? Have fun - Andy ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] How about integrating JSR77 via notifications
The source of the problem is management setup such as this from
SARDeployer where over 60% of the code is JSR77 setup with
implicit dependencies on the org.jboss.management.* pkgs that
if it fails, prevents the service from being created. Why can't these
steps be performed based on an event generated from here rather
than embedding all of this here? Its not a question of breaking this
code now, its maintainability and mixing of functionality.
public void create(DeploymentInfo di)
throws DeploymentException
{
try
{
// install the MBeans in this descriptor
log.debug(Deploying SAR, create step: url + di.url);
// Register the SAR UCL as an mbean so we can use it as the service
loader
ObjectName uclName = di.ucl.getObjectName();
log.debug(Registering service UCL=+uclName);
getServer().registerMBean(di.ucl, uclName);
// Create JSR-77 SAR-Module
String lURL = di.url.toString();
int lIndex = lURL.lastIndexOf( / );
String lName = lURL.substring( lIndex = 0 ? lIndex + 1 : 0 );
// This is to go around the project dependencies
Class lServiceModule = Class.forName(
org.jboss.management.j2ee.ServiceModule );
Method lCreateSAR = lServiceModule.getMethod(
create,
new Class[] {
MBeanServer.class,
String.class,
URL.class
}
);
ObjectName lSARName = (ObjectName) lCreateSAR.invoke(
null,
new Object[] {
server,
lName,
di.localUrl
}
);
log.info( Created ServiceModule: + lSARName );
List mbeans = di.mbeans;
mbeans.clear();
List descriptorMbeans =
serviceController.install(di.document.getDocumentElement(), uclName);
mbeans.addAll(descriptorMbeans);
// create the services
for (Iterator iter = di.mbeans.iterator(); iter.hasNext(); )
{
ObjectName service = (ObjectName)iter.next();
// The service won't be created until explicitly dependent
mbeans are created
serviceController.create(service);
}
// This is to go around the project dependencies
Class lMBean = Class.forName( org.jboss.management.j2ee.MBean );
Method lCreate = lMBean.getMethod(
create,
new Class[] {
MBeanServer.class,
String.class,
String.class,
ObjectName.class
}
);
ObjectName[] lNames = (ObjectName[]) mbeans.toArray( new
ObjectName[ 0] );
for( int i = 0; i lNames.length; i++ ) {
// If ServiceModule is not created yet, do it now
if( lSARName == null ) {
lSARName = (ObjectName) lCreateSAR.invoke(
null,
new Object[] {
server,
lName,
di.localUrl
}
);
log.info( Created ServiceModule: + lSARName );
}
// Create JSR-77 MBean
log.info( Create MBean, name: + lNames[ i ] + , SAR Module:
+lSARName );
lCreate.invoke(
null,
new Object[] {
server,
lNames[ i ] + ,
lSARName == null ? null : lSARName + ,
lNames[ i ]
}
);
}
}
catch (Exception e)
{
destroy(di);
throw new DeploymentException(create operation failed for package
+ di.url, e);
}
}
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Andreas Schaefer [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; Scott M Stark
[EMAIL PROTECTED]
Sent: Friday, May 24, 2002 2:23 PM
Subject: Re: [JBoss-dev] How about integrating JSR77 via notifications
I don't think this is possible. We are already listening to JMX events
to determine the state of a component. But this is only the easy part
of JSR-77. Even thought that JSR-77 spec. does not really cover
what it was supposed to do the main part currenlty is to retrieve
and calculate performance statstics. The rest is just to provide a
JSR-77 compliant view to an application server.
BTW I am not aware that JSR-77 breaks existing code. Mostely
it was the other way around that changes where made and the
JSR-77 stuff was left out and broke.
The design is made that the invasive part is as small as possible.
So what is the source of the problem ?
Have fun - Andy
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
Re: [JBoss-dev] How about integrating JSR77 via notifications
Hi Scott The source of the problem is management setup such as this from SARDeployer where over 60% of the code is JSR77 setup with implicit dependencies on the org.jboss.management.* pkgs that if it fails, prevents the service from being created. Why can't these steps be performed based on an event generated from here rather than embedding all of this here? Its not a question of breaking this code now, its maintainability and mixing of functionality. NOTE: this is an experiment because JSR-77 does not know anything about SAR,services etc. I wanted to extrapolate and see what we can gain from. Therefore the implementation is everyting that stable. We could wrap the whole thing in a try-catch block or we can check if the classes are available before going on any further. What is the best way to do so ? If all else fails we can take the part around ServiceModule and management-MBean out. As I mentioned JSR-77 is not what it claims it would be. One of the big missing parts is that you cannot create or destroy any part. Therefore you cannot create a new DataSource, JCA, Queue, Topic etc. which is an important part of J2EE management, isn't it? Like the ServiceModule/MBean I would like to add this as a vendor-specific feature (one feature more than the competition). Have fun - Andy BTW the intrusive stuff is coming with the performance statistics integration because then we need to track the statistics in each service (JMS, JCA, EJBs, etc.) and on demand provide these values to the client (of course massaged when it is running in a cluster). ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] How about integrating JSR77 via notifications
The point is that the current integration is too heavy for something that is at best experimental and I should be able to configure a deployment that runs without it. I would like to see a looser integration that allows for this. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Andreas Schaefer [EMAIL PROTECTED] To: [EMAIL PROTECTED]; Scott M Stark [EMAIL PROTECTED] Sent: Friday, May 24, 2002 3:05 PM Subject: Re: [JBoss-dev] How about integrating JSR77 via notifications Hi Scott The source of the problem is management setup such as this from SARDeployer where over 60% of the code is JSR77 setup with implicit dependencies on the org.jboss.management.* pkgs that if it fails, prevents the service from being created. Why can't these steps be performed based on an event generated from here rather than embedding all of this here? Its not a question of breaking this code now, its maintainability and mixing of functionality. NOTE: this is an experiment because JSR-77 does not know anything about SAR,services etc. I wanted to extrapolate and see what we can gain from. Therefore the implementation is everyting that stable. We could wrap the whole thing in a try-catch block or we can check if the classes are available before going on any further. What is the best way to do so ? If all else fails we can take the part around ServiceModule and management-MBean out. As I mentioned JSR-77 is not what it claims it would be. One of the big missing parts is that you cannot create or destroy any part. Therefore you cannot create a new DataSource, JCA, Queue, Topic etc. which is an important part of J2EE management, isn't it? Like the ServiceModule/MBean I would like to add this as a vendor-specific feature (one feature more than the competition). Have fun - Andy BTW the intrusive stuff is coming with the performance statistics integration because then we need to track the statistics in each service (JMS, JCA, EJBs, etc.) and on demand provide these values to the client (of course massaged when it is running in a cluster). ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
