December 2007 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: property values in ManagementViewImpl.applyTemplate

by alex.loubyansky＠jboss.com

I mean for managed objects that represent MCF ManagedObject.getComponentName() returns null (at least what I saw in the test). MO.getName() returns the JNDI name, IIRC. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114516#4114516 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114516

16 years, 5 months

1
0
0 / 0

[Design of POJO Server] - @ManagementRuntimeRef/@ManagementObjectRef/@ManagementObject

by scott.stark＠jboss.org

We need to clarify the usage of the names in the ManagedObject graphs for the purposes of references between related ManagedObjects and references to the underlying runtime component. The current mechanism for naming a ManagedObject is based on the @ManagementObjectID - annotation that identifies a ManagedObject key/type qualifier source. Generally this is on a property without a name value so that the actual name comes from the property value, as this JBossManagedConnectionPool example shows: | @ManagementObjectID(type="DataSource") | @ManagementProperty(use={ViewUse.RUNTIME}) | public String getPoolJndiName() | { | return this.poolJndiName; | } | @ManagementObjectRef - indicates a property that references another ManagedObject. This ManagedConnectionFactoryDeploymentMetaData example shows a property refencing the jmx invoker ManagedObject: | @ManagementProperty(name="jmx-invoker-name") | @ManagementObjectRef(type="JMXInvoker") | public String getJmxInvokerName() | { | return jmxInvokerName; | } | @ManagementRuntimeRef - annotation that can be used to identify which property defines the runtime component name. This annotation takes a transformer: | public interface RuntimeComponentNameTransformer | { | /** | * Transform the name from string. | * | * @param value current name value | * @return transformed name | */ | Object transform(Object value); | } | this is used to identify what the name of the runtime kernel component is. For an mcf deployment, this should be doing the same mapping logic the ManagedConnectionFactoryBuilder.buildObjectName method does in transforming the jndiName property into an ObjectName: | public ObjectName buildObjectName(ManagedConnectionFactoryDeploymentMetaData md) | { | return ObjectNameFactory.create(MCF_JMX + md.getJndiName()); | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114515#4114515 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114515

16 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: property values in ManagementViewImpl.applyTemplate

by alex.loubyansky＠jboss.com

"Scott" wrote : Ales did the dispatch work, so I'm not sure how the component registry | is being maintained. The getComponentName method relies on the | ManagedObject.targetManagedObject setting, and this relies on the | @ManagementObjectRef/@ManagementObjectID annotations for the relations. | | When you say connection factories, what property are you talking about? | A connection factory should have a component name based on its | @ManagementObjectID. The logic in getComponentName should also be | considering ManagedObjects with a proper name as a connection factory | would, based on its jndiName property: | | @ManagementProperty(name="jndi-name", description="The global JNDI | name to bind the factory under") | @ManagementObjectID(type="DataSource") | public String getJndiName() | { | return jndiName; | } | | Looking at the logic for setting the ManagedObject.setComponentName | value, the componentName relies on a ManagementRuntimeRef. This is | something Ales added. Let's move this discussion to the forum as there | needs to be a general understanding of how ManagedObjects are named and | referenced. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114514#4114514 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114514

16 years, 5 months

1
0
0 / 0

[Design of POJO Server] - property values in ManagementViewImpl.applyTemplate

by alex.loubyansky＠jboss.com

The following part in ManagementViewImpl looks strange to me. What is the logic with serializable? The componentName for connection factories is always null. Even if it wasn't, they wouldn't be registered to the kernel, would they? Or I missing the part where they are registered? Thanks! public void applyTemplate(DeploymentPhase phase, String deploymentBaseName, DeploymentTemplateInfo info) | ... | // TODO - decide what is the type of value when we set it | // since currently get always returns MetaValue, but we see some cases | // where plain Serializable is enough | Serializable serializable; | MetaValue metaValue; | Object value = prop.getValue(); | if (value instanceof MetaValue) | { | metaValue = (MetaValue)value; | MetaType metaType = metaValue.getMetaType(); | if (metaType.isSimple()) | serializable = ((SimpleValue)metaValue).getValue(); | else if (metaType.isGeneric()) | serializable = ((GenericValue)metaValue).getValue(); | else | serializable = null; | } | else | { | serializable = (Serializable)value; | metaValue = metaValueFactory.create(value); | } | // I add this check for the tests to pass if(serializable != null) | ctxProp.setValue(serializable); | // todo - should this also dispatch to runtime component? | Object componentName = getComponentName(ctxProp); | if("xa-datasource-properties".equals(ctxProp.getName())) | System.out.println("componentName for prop=" + ctxProp.getName() + ": " + componentName + " " + ctxProp.getManagedObject()); | if (componentName != null) | dispatcher.set(componentName, ctxProp.getName(), metaValue); | } | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114513#4114513 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114513

16 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: ProfileServiceUnitTestCase value/type misuse

by alex.loubyansky＠jboss.com

I made @XmlElement(name="xa-datasource-property") | private List<XAConnectionPropertyMetaData> xaDataSourceProperties = new ArrayList<XAConnectionPropertyMetaData>(); a Map in the management interface. Then there is @XmlElement(name="config-property") | private List<ManagedConnectionFactoryPropertyMetaData> managedConnectionFactoryProperties = new ArrayList<ManagedConnectionFactoryPropertyMetaData>(); ManagedConnectionFactoryPropertyMetaData has three properties: name, type and value. So, it should be a list of entries. I tried List<Map<String,String>> but current unwrap() impl doesn't seem to support it. Map<String,Map<String,String>> does work. So, that's what I decided to go with for now. Any better ideas? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114512#4114512 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114512

16 years, 5 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: captured data , but can not analyze the data, for help

by johnsonpenn

you must return back to your front-end,for example: http://localhost:8085/jboss-profiler you fill the path of your logs in the text,then submit,you can choose the process id of you logs,check it. waiting......it will load the log files View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114509#4114509 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114509

16 years, 5 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Deploying maven built artifacts to the ant repository.

by ALRubinger

Thank you for this enhancement, Paul. Where can I look for examples of using the new override? (I assume it's a new node in the POM under the configuration for the jboss-deploy mojo). S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114491#4114491 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114491

16 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Dependencies clash with jbossxb

by bdaw

I found out that MC and JBossXB duplicates jaxb-api dependency. MC 2.0.0.Beta9 depends on javax,xml.binding/jaxb-api ( JBossXB 2.0.0.CR5 depends on sun-jaxb/jaxb-api So same artifact but different groupId... And btw. as I'm here... Do you have any idea why I'm seeing this exception? I suspect something wrong in my classpath (as its maven...) but I can't track anything: [java] Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: jar:file:/home/bdaw/.m2/repository/org/jboss/unit/jboss-unit-remote/1.1.0-SNAPSHOT/jboss-unit-remote-1.1.0-SNAPSHOT.jar!/org/jboss/unit/remote/driver/jboss-beans.xml@26,49 | [java] at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:177) | [java] at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:139) | [java] at org.jboss.kernel.plugins.deployment.xml.BeanXMLDeployer.deploy(BeanXMLDeployer.java:86) | [java] at org.jboss.unit.remote.driver.RemoteTestDriverClient.initDriver(RemoteTestDriverClient.java:179) | [java] ... 8 more | [java] Caused by: java.lang.NullPointerException | [java] at org.jboss.kernel.plugins.deployment.xml.BeanSchemaBindingHelper.initLazyHandlers(BeanSchemaBindingHelper.java:197) | [java] at org.jboss.kernel.plugins.deployment.xml.BeanSchemaBinding20.initLazy(BeanSchemaBinding20.java:298) | [java] at org.jboss.kernel.plugins.deployment.xml.BeanSchemaBinding20.init(BeanSchemaBinding20.java:249) | [java] at org.jboss.kernel.plugins.deployment.xml.BeanSchemaInitializer20.init(BeanSchemaInitializer20.java:37) I'm migrating stuff from ant to maven so its definitely not because of wrong 'jboss-beans.xml'. Currenlty I'm trying with 2.0.0.Beta9, With 2.0.0.Beta4 (worked in ant build) the NPE happens little later in the flow but in the same class. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114464#4114464 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114464

16 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJBTHREE-1167 -- Resolve API leak for @Clustered

by ALRubinger

Pleasure doing business with you, please come again. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114406#4114406 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114406

16 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJBTHREE-1167 -- Resolve API leak for @Clustered

by bstansberry＠jboss.com

Right; will not be a problem. The ha-client 1.0.0.BETA1 release has its own tag. If you changed ha-client trunk and did a maven deploy, it would create a 1.0.0.BETA2-SNAPSHOT. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114402#4114402 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4114402

16 years, 5 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 December 2007