May 2009 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Profiler] - JBoss Profiler 2.0.Beta4 released

by jesper.pedersen

I have tagged and uploaded JBoss Profiler 2.0 Beta4. Get it from http://www.jboss.org/jbossprofiler/downloads/ Changes over 2.0 Beta3: * Converted reports to HTML * Converted documentation to Docbook and included it as PDF in distribution * Bug-fixes * Initial build environment (cmake) for native backend (JVMTI/HPROF) If you want to work on * Web front-end using JSF / RichFaces * Native backend (did someone say C ?) * Documentation / Screenshots let us know. Have fun! View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4234352#4234352 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4234352

15 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: relative class-path entry resolution

by scott.stark＠jboss.org

"emuckenhuber" wrote : | In general this also seems limited how VFS resolves files, as it can't resolve files outside it's root context. | At the moment the bootstrap/vfs.xml is defining a permanent-root for the deploy/ directory. So resolving files outside of deploy/ would not work by default anyway. | I don't think it makes sense to allow resolution outside of the root context because in general this is an unknown type of VFS. For the case of a given deployment root context being a child of another VFS context, we should be able to resolve up the tree. For the case of a server setup where the libs were on one type of VFS and the profile deploy contents on another, we can build the correct URI to pass to the VFS.getRoot(URI) or getFile(URI) call because we don't know the vfs protocol to use. There can be multiple VFS roots associated with the absolute path "/x/server/libs/test.jar" that differ only by the VFS procotol. However, for the case where "/x/server/default/deploy" and "/x/server/libs" are both vfsfile protocol contexts, we should be able to navigate across the contexts via their comment root. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4234333#4234333 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4234333

15 years, 6 months

1
0
0 / 0

[Design of Management Features on JBoss] - Re: How to Expose MBean Invocation Stats into admin-console?

by emuckenhuber

"ALRubinger" wrote : | Emanuel, I'll also try your patch. :) I couldn't get the KernelDeployment steps we'd discussed working after our IRC chat the other day, so went with the route currently in SVN. I'd still like to avoid, if possible, the jboss-man API calls like: | | ManagedObject mo = managedObjectFactory.initManagedObject(bmd, null, metaData, bmd.getName(), null); | Yes, agreed - basically this is a workaround and should not be needed in the end. I would need a bit more time and testing to resolve the naming conflicts, but i wanted to check why this was not working. I'll also follow up on this when i know more - but at least you should be able to proceed with this. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4234331#4234331 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4234331

15 years, 6 months

1
0
0 / 0

[Design of Management Features on JBoss] - Re: How to Expose MBean Invocation Stats into admin-console?

by ALRubinger

Thanks, guys. Scott, jboss-man:2.1.1-20090531.135556-1 isn't doing it as-is, I'll look into it a bit later. Emanuel, I'll also try your patch. :) I couldn't get the KernelDeployment steps we'd discussed working after our IRC chat the other day, so went with the route currently in SVN. I'd still like to avoid, if possible, the jboss-man API calls like: ManagedObject mo = managedObjectFactory.initManagedObject(bmd, null, metaData, bmd.getName(), null); ...as it's cleaner from the EJB3 perspective to simply attach a @ManagedObject to the DeploymentUnit and have the deployers do the heavy lifting. I'll follow up Monday. S, ALR View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4234330#4234330 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4234330

15 years, 6 months

1
0
0 / 0

[Design of Management Features on JBoss] - Re: How to Expose MBean Invocation Stats into admin-console?

by emuckenhuber

I've been looking into this a bit today as well and got a working Ejb3MetricsDeployer not requiring any further updates. I basically changes those things to get it working: - implement the ManagedObjectCreator interface and process the beans internally. - I only create one KernelDeployment with all the metric beans. - Additionally i had to drop the BeanMetaDataBuilder as the construtor was messing up the controllerContext target, so that it was not possible to retrieve any values from the statistics. I'll attach the changes to the JIRA - so that you can take a look at that. I also have a basic testcase in the AS testsuite which i can commit later on. One thing i see which still should be done is a proper MetaMapping for the getStats() which is a Map<Method, TimeStatistic>. So you might want to look at @MetaMapping and MetaMapper - i can also provide further information how to do that. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4234329#4234329 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4234329

15 years, 6 months

1
0
0 / 0

[Design of Management Features on JBoss] - Re: How to Expose MBean Invocation Stats into admin-console?

by scott.stark＠jboss.org

"ALRubinger" wrote : OK, so I've confirmed name collisions w/ the ManagedObject.getName. | | ... | | Can we change the jboss-deployers behaviour to set the @ManagedObject.name, if not specified, to du.getName + attachmentName? | I think the unconditional override of the MO name is too much. Note that the component names are unique as they correspond to the runtime bean names. We can look to default the MO name to the component name if there is no name given on the ManagementObject in the AbstractManagedObjectFactory. The logic would need to be something like this patch: | Index: /Users/svn/JBossAS/projects/jboss-man/branches/Branch_2_1/managed/src/main/java/org/jboss/managed/plugins/factory/AbstractManagedObjectFactory.java | =================================================================== | --- /Users/svn/JBossAS/projects/jboss-man/branches/Branch_2_1/managed/src/main/java/org/jboss/managed/plugins/factory/AbstractManagedObjectFactory.java (revision 89190) | +++ /Users/svn/JBossAS/projects/jboss-man/branches/Branch_2_1/managed/src/main/java/org/jboss/managed/plugins/factory/AbstractManagedObjectFactory.java (working copy) | @@ -420,6 +420,14 @@ | MutableManagedObject mmo = (MutableManagedObject) result; | ManagedObjectPopulator<Object> populator = getPopulator(moClass); | populator.populateManagedObject(mmo, instance, metaData); | + // Set a default MO.name to the MO.componentName | + Boolean hasDefaultName = (Boolean) mmo.getTransientAttachment("ManagedObject.hasDefaultName"); | + Object compName = mmo.getComponentName(); | + if(hasDefaultName && compName != null) | + { | + String moName = compName.toString(); | + mmo.setName(moName); | + } | } | | return result; | @@ -518,6 +526,7 @@ | | // Process the ManagementObject fields | boolean isRuntime = managementObject.isRuntime(); | + boolean hasDefaultName = true; | String name = classInfo.getName(); | String nameType = null; | String attachmentName = classInfo.getName(); | @@ -528,8 +537,12 @@ | if (managementObject != null) | { | name = managementObject.name(); | + hasDefaultName = false; | if (name.length() == 0 || name.equals(ManagementConstants.GENERATED)) | + { | name = classInfo.getName(); | + hasDefaultName = true; | + } | nameType = managementObject.type(); | if (nameType.length() == 0) | nameType = null; | @@ -862,7 +875,7 @@ | ManagedObjectImpl result = new ManagedObjectImpl(name, properties); | result.setAnnotations(moAnnotations); | // Set the component name to name if this is a runtime MO with a name specified | - if (isRuntime && name.equals(classInfo.getName()) == false) | + if (isRuntime && hasDefaultName == false) | result.setComponentName(name); | if (nameType != null) | result.setNameType(nameType); | @@ -873,6 +886,8 @@ | for (ManagedProperty property : properties) | property.setManagedObject(result); | result.setTransientAttachment(BeanInfo.class.getName(), beanInfo); | + // Propagate whether the name is defaulted | + result.setTransientAttachment("ManagedObject.hasDefaultName", hasDefaultName); | return result; | } | I just uploaded a jboss-managed and related 2.1.1 snapshot to https://snapshots.jboss.org/maven2/org/jboss/man/jboss-man/2.1.1-SNAPSHOT/ with this change, so can you try that out? Also, instead of casting to a MangedObjectImpl, use the MutableManagedObject interface when you need to change ManagedObject settings. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4234323#4234323 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4234323

15 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Messages are lost on Queue?

by clebert.suconic＠jboss.com

Yep.. it also happens on trunk as I expected. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4234293#4234293 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4234293

15 years, 6 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Wrong namespace from designer

by kukeltje

He... did you attend that? hahahaha.... no, I'm much more polite Search the Fine Jira :-P View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4234291#4234291 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4234291

15 years, 6 months

1
0
0 / 0

[Design of Management Features on JBoss] - Re: How to Expose MBean Invocation Stats into admin-console?

by ALRubinger

"ips" wrote : From the Jopr/client perspective, we prefer that each type of MO has a unique component type, rather than having to look at the MO's name to figure out exactly what type of MO it is. For example, we'd much prefer something like... How does this look: http://fisheye.jboss.org/changelog/JBossAS/?cs=89563 ...? S, ALR View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4234290#4234290 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4234290

15 years, 6 months

1
0
0 / 0

[Design of Management Features on JBoss] - Re: How to Expose MBean Invocation Stats into admin-console?

by ALRubinger

OK, so I've confirmed name collisions w/ the ManagedObject.getName. If not specified via @ManagedObject.name, the default behaviour is: name = managementObject.name(); | if (name.length() == 0 || name.equals(ManagementConstants.GENERATED)) | name = classInfo.getName(); ...from AbstractManagedObjectFactory.buildManagedObject. If I apply the following patch, I get what I'm expecting: Index: deployers-spi/src/main/java/org/jboss/deployers/spi/deployer/helpers/DefaultManagedObjectCreator.java | =================================================================== | --- deployers-spi/src/main/java/org/jboss/deployers/spi/deployer/helpers/DefaultManagedObjectCreator.java (revision 89514) | +++ deployers-spi/src/main/java/org/jboss/deployers/spi/deployer/helpers/DefaultManagedObjectCreator.java (working copy) | @@ -21,6 +21,7 @@ | */ | package org.jboss.deployers.spi.deployer.helpers; | | +import java.util.Collection; | import java.util.Map; | import java.util.Set; | | @@ -29,6 +30,7 @@ | import org.jboss.deployers.structure.spi.DeploymentUnit; | import org.jboss.managed.api.ManagedObject; | import org.jboss.managed.api.factory.ManagedObjectFactory; | +import org.jboss.managed.plugins.ManagedObjectImpl; | import org.jboss.managed.plugins.factory.ManagedObjectFactoryBuilder; | import org.jboss.metadata.spi.MetaData; | | @@ -73,14 +75,20 @@ | if(factory == null ) | factory = ManagedObjectFactoryBuilder.create(); | | - for(String name : attachments) | + final Map<String,Object> duAttachments = unit.getAttachments(); | + final Collection<String> attachmentNames = duAttachments.keySet(); | + for(final String attachmentName:attachmentNames) | { | - Object instance = unit.getAttachment(name); | + Object instance = unit.getAttachment(attachmentName); | if (instance != null) | { | - ManagedObject mo = factory.initManagedObject(instance, null, metaData, name, null); | - if (mo != null) | + ManagedObject mo = factory.initManagedObject(instance, null, metaData, attachmentName, null); | + factory.initManagedObject(instance, metaData); | + if (mo != null){ | + ManagedObjectImpl impl = (ManagedObjectImpl) mo; | + impl.setName(unit.getName() + "-" + attachmentName); | managedObjects.put(mo.getName(), mo); | + } | } | } | } Revealing, for instance: ManagedDeployment: vfsfile:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/profileservice-secured.jar/ | +++ ManagedComponent(name=vfsfile:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/profileservice-secured.jar/-jboss.j2ee:service=EJB3,name=SecureDeploymentManager-metrics-invocation, type=(ComponentType{type=MCBean, subtype=*}), compName=jboss.j2ee:service=EJB3,name=SecureDeploymentManager-metrics-invocation, attachment: org.jboss.ejb3.metrics.deployer.ManagedInvocationStatisticsWrapper | ++++++ properties: [stats] | +++ ManagedComponent(name=vfsfile:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/profileservice-secured.jar/-jboss.j2ee:service=EJB3,name=SecureManagementView-metrics-instance, type=(ComponentType{type=MCBean, subtype=*}), compName=jboss.j2ee:service=EJB3,name=SecureManagementView-metrics-instance, attachment: org.jboss.ejb3.metrics.deployer.BasicStatelessSessionInstanceMetrics | ++++++ properties: [removeCount, currentSize, maxSize, createCount, availableCount] | +++ ManagedComponent(name=vfsfile:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/profileservice-secured.jar/-jboss.j2ee:service=EJB3,name=SecureDeploymentManager-metrics-instance, type=(ComponentType{type=MCBean, subtype=*}), compName=jboss.j2ee:service=EJB3,name=SecureDeploymentManager-metrics-instance, attachment: org.jboss.ejb3.metrics.deployer.BasicStatelessSessionInstanceMetrics | ++++++ properties: [removeCount, currentSize, maxSize, createCount, availableCount] | +++ ManagedComponent(name=vfsfile:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/profileservice-secured.jar/-jboss.j2ee:service=EJB3,name=SecureProfileService-metrics-instance, type=(ComponentType{type=MCBean, subtype=*}), compName=jboss.j2ee:service=EJB3,name=SecureProfileService-metrics-instance, attachment: org.jboss.ejb3.metrics.deployer.BasicStatelessSessionInstanceMetrics | ++++++ properties: [removeCount, currentSize, maxSize, createCount, availableCount] | +++ ManagedComponent(name=vfsfile:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/profileservice-secured.jar/-jboss.j2ee:service=EJB3,name=SecureProfileService-metrics-invocation, type=(ComponentType{type=MCBean, subtype=*}), compName=jboss.j2ee:service=EJB3,name=SecureProfileService-metrics-invocation, attachment: org.jboss.ejb3.metrics.deployer.ManagedInvocationStatisticsWrapper | ++++++ properties: [stats] | +++ ManagedComponent(name=vfsfile:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/deploy/profileservice-secured.jar/-jboss.j2ee:service=EJB3,name=SecureManagementView-metrics-invocation, type=(ComponentType{type=MCBean, subtype=*}), compName=jboss.j2ee:service=EJB3,name=SecureManagementView-metrics-invocation, attachment: org.jboss.ejb3.metrics.deployer.ManagedInvocationStatisticsWrapper | ++++++ properties: [stats] BTW my deployer is: http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/metrics-deploy... Can we change the jboss-deployers behaviour to set the @ManagedObject.name, if not specified, to du.getName + attachmentName? S, ALR View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4234288#4234288 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4234288

15 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums May 2009