November 2008 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: xml persistent format for attachments

by scott.stark＠jboss.org

"emuckenhuber" wrote : | Concerning unmarshalling of the persisted attachment i think we can try to rebuild the ManagedObject | from the metadata and due to this WritethroughManagedProperty we actually should be able to directly reuse the attachment. | Most probably there are some ManagementProperty annotations missing in some parts (e.g. ServiceMetaData) | to persist and restore everything needed, as i'm currently only planning to persist ViewUse.CONFIGURATION only. | | But maybe we want to do the delta thing later on and see how far we can get with restoring the attachment that way? | As it should not require changes to the persistence format itself. | I'm not really following. You have the marshalled form of the ManagedObject and build it back up, to apply to the deployment attachment or are you talking about something else? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191057#4191057 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191057

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: Why do Topic/Queue descriptors need extra metadata in or

by scott.stark＠jboss.org

Its needed because the mbeans from the messaging project are not annotated with the jboss-managed information. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191056#4191056 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191056

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: xml persistent format for attachments

by emuckenhuber

Ah before i forget, i think we should update the DeploymentRepository interface to: | public void updateDeployment(VFSDeployment d, DeploymentPhase phase, ManagedComponent component) | | or | | public void updateDeployment(VFSDeployment d, DeploymentPhase phase, ManagedObject object) | | instead of: | | public void updateDeployment(VFSDeployment d, DeploymentPhase phase, Map<String, Object> attachments) | Baiscally i'm already putting the ManagedComponent in the map to persist the attachment. Furthermore i think we could delete the: | public void addManagedObject(String vfsPath, Attachments edits) | as this does not seem to make sense anymore. Maybe we can add something similar later on if needed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191052#4191052 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191052

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: xml persistent format for attachments

by emuckenhuber

"scott.stark(a)jboss.org" wrote : Also, if we are only persisting the managed object view of the attachment, it won't be a predetermined attachment any longer. Its a delta against the original transient managed attachment, so we would have to integrate the change in a PRE_REAL deployer. Not that this is a big issue, but there is no authoritative view of the metadata out on disk somewhere. | Concerning unmarshalling of the persisted attachment i think we can try to rebuild the ManagedObject from the metadata and due to this WritethroughManagedProperty we actually should be able to directly reuse the attachment. Most probably there are some ManagementProperty annotations missing in some parts (e.g. ServiceMetaData) to persist and restore everything needed, as i'm currently only planning to persist ViewUse.CONFIGURATION only. But maybe we want to do the delta thing later on and see how far we can get with restoring the attachment that way? As it should not require changes to the persistence format itself. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191049#4191049 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191049

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: Missing org.jnp.server.NamingServer_Stub

by dimitris＠jboss.org

The client pom.xml includes only | <include name="org/jnp/interfaces/**" /> | <include name="org/jboss/naming/**" /> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191045#4191045 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191045

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: Missing org.jnp.server.NamingServer_Stub

by dimitris＠jboss.org

It uses the client/jnp-client.jar that contains no org.jnp.server classes: View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191044#4191044 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191044

17 years, 4 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Privileged Blocks Issue : JBAOP-675

by anil.saldhana＠jboss.com

I do not know what the dangers are of making the entire content of getAdvisor method in a privileged block. I have an inclination to suggest that. Have you tried weaving in a block into the weaved class as: | public WeavedClass | { | | private static final Advisor aop$advisor$aop = SecurityActions.getAdvisor(AspectManager, this.getClass); | ... | } | or | public WeavedClass | { | | private static final Advisor aop$advisor$aop = | AccessController.doPrivileged(new PrivilegedAction<Advisor>() { | public Advisor run() | { | return AspectManager.instance().getAdvisor(this.getClass); | } | ); | ... | } | Is that doable? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191039#4191039 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191039

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Why do Topic/Queue descriptors need extra metadata in order

by charles.crouch＠jboss.com

Looking at our example queues... http://anonsvn.jboss.org/repos/jbossas/trunk/messaging/src/etc/deploy/com... I see they contain the following piece of metadata: <annotation> | @org.jboss.system.deployers.managed.ManagementObjectClass(code=org.jboss.jms.server.destination.QueueServiceMO) | </annotation> This appears to be needed in order for the Queue/Topic to be reachable through the profile service. The only problem with this is all the existing Topic/Queue descriptors created by users which won't have the extra metadata. Is there anyway to avoid having to get people to update all of their deployment descriptors in order to make these resources manageable? Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191038#4191038 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191038

17 years, 4 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Privileged Blocks Issue : JBAOP-675

by flavia.rainone＠jboss.com

I have to fix this inside AspectManager. This is what is happening. JBoss AOP inserts an advisor field into the weaved class. This field is static and is initialized with AspectManager.getAdvisor(this.getClass()): public WeavedClass | { | | private static final Advisor aop$advisor$aop = AspectManager.instance().getAdvisor(this.getClass); | ... | } | So, I'm not sure if Javassist allows to edit clinit, and I can't edit the aop$advisor$aop field initialization, replacing the call to getAdvisor by an if/else field. Plus, I need to know exactly what kind of permission it needs (why is the check failing on line 707 exactly?), as this method is called elsewhere inside of JBoss AOP. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191037#4191037 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191037

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: MetaValue representation of javax.management.ObjectNames

by scott.stark＠jboss.org

The type on the underlying mbean is ObjectName, so either we could create a ObjectNameMetaValueHandler to simplify the building/viewing of the CompositeValue, or make use of the ManagementProperty.marshallerFactory() to map the ObjectName to/from a string MetaValue. This later bit does not seem tested, so I'll have to look at that. In terms of the values not being set, I'll update our JmsDestinationUnitTestCase to set these values and assert that they are not null. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191031#4191031 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191031

17 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums November 2008