September 2007 - jboss-dev-forums

by scott.stark＠jboss.org

We need a release of the combined jbossxb/jbossxb-builder that at least has JBXB-109 working in some form. As I mentioned on another thread, there are unit test issues as well that are due to both defaults overrides, and apparent regressions due to thirdparty updates. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087274#4087274 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087274

18 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: ManagedObject support in next messaging release

by clebert.suconic＠jboss.com

anonymous wrote : I'd rather just add the annotations to the current classes and live with the necessary imports. | This would force us to add jboss-managed.jar (from jboss-5) into jboss4/lib when installing jboss-messaging. If there is no issue on adding that jar, I would prefer doing it this way also. (Actually Scott, why don't you see if we could have jboss-managed.jar officially distributed as part of jboss-4. This way annotated services would be able to be deployed on both servers). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087264#4087264 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087264

18 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: ManagedOperation aspects for the ProfileService.Manageme

by alesj

"adrian(a)jboss.org" wrote : | We need to find a way to remove the getClassLoader() | and make it an implementation detail, or introduce a permission check | into the implementations. Exposing classloaders in public methods is a security hole. | | See Class.getClassLoader() or Thread.currentThread().getContextClassLoader() | for the kind of checks required. | Is this enough: | public ClassLoader getClassLoader() throws Throwable | { | SecurityManager sm = System.getSecurityManager(); | if (sm != null) | sm.checkPermission(SecurityConstants.GET_CLASSLOADER_PERMISSION); | return Configurator.getClassLoader(getBeanMetaData()); | } | Or I need to 'find' something equivalent for the ccl in | public ClassLoader getClassLoader() { | ClassLoader cl = getClassLoader0(); | if (cl == null) | return null; | SecurityManager sm = System.getSecurityManager(); | if (sm != null) { | ClassLoader ccl = ClassLoader.getCallerClassLoader(); | if (ccl != null && ccl != cl && !cl.isAncestor(ccl)) { | sm.checkPermission(SecurityConstants.GET_CLASSLOADER_PERMISSION); | } | } | return cl; | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087263#4087263 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087263

18 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Unifying metadata

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : | This is how you define it generically | | | public class ListElementWildcard | | { | | private List<Element> wildcard; | | | | public List<Element> getWildcard() | | { | | return wildcard; | | } | | | | @XmlAnyElement(lax=true) | | public void setWildcard(List<Element> wildcard) | | { | | this.wildcard = wildcard; | | } | | | | You can also make it recognise specific types, e.g. we could define | the known JMSContainerInvoker config, etc. by adding @XmlElements | and specific types but then you need to make List<Object> | if you also want it to have raw Elements as well as real types. | | The real problem is that it just isn't implemented | (at least in the version in the JBossXB project) | | | @XmlType(name="invoker-proxy-bindingType") | | public class InvokerProxyBindingMetaData extends NamedMetaDataWithDescriptions | | { | | ... | | | | /** The proxy factory config */ | | // TODO DOM private Element proxyFactoryConfig; | | I had unquoted this section in the merged jbossxb project, and that is what produced the errors seen in the JBXB-109 issue. Even if I change this to: | @XmlType(name="invoker-proxy-bindingType") | public class InvokerProxyBindingMetaData extends NamedMetaDataWithDescriptions | { | /** The proxy factory config */ | private List<Element> proxyFactoryConfig; | ... | | public List<Element> getProxyFactoryConfig() | { | return proxyFactoryConfig; | } | | @XmlAnyElement(lax=true) | public void setProxyFactoryConfig(List<Element> proxyFactoryConfig) | { | this.proxyFactoryConfig = proxyFactoryConfig; | } | } | I'm seeing the same error, which is happening on an xml fragment that does not even have the proxy-factory-config element: anonymous wrote : | Caused by: java.lang.ClassCastException: java.util.ArrayList | at org.jboss.javaee.metadata.support.MappedAnnotationMetaData.add(MappedAnnotationMetaData.java:39) | at org.jboss.xb.builder.runtime.CollectionPropertyHandler.handle(CollectionPropertyHandler.java:133) | ... 40 more | | If you or Alexey can look into the JBXB-109 issue it would help. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087261#4087261 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087261

18 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Unifying metadata

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : | Why do you need to merge standardjboss.xml? | | standardjboss.xml should just be parsed once into a JBossMetaData | and then it should just be a case of delegating. | | If you merge standardjboss.xml into the JBossMetaData then you'll loose the | reversability. Let's not make the same mistakes as the old metadata did! Ok, I'll look at that approach. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087255#4087255 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087255

18 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Unifying metadata

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | This works in the MC stuff, so its obviously not defined correctly in the annotations | for the ejb stuff. | This is how you define it generically | public class ListElementWildcard | { | private List<Element> wildcard; | | public List<Element> getWildcard() | { | return wildcard; | } | | @XmlAnyElement(lax=true) | public void setWildcard(List<Element> wildcard) | { | this.wildcard = wildcard; | } | You can also make it recognise specific types, e.g. we could define the known JMSContainerInvoker config, etc. by adding @XmlElements and specific types but then you need to make List if you also want it to have raw Elements. The real problem is that it just isn't implemented (at least in the version in the JBossXB project) | @XmlType(name="invoker-proxy-bindingType") | public class InvokerProxyBindingMetaData extends NamedMetaDataWithDescriptions | { | ... | | /** The proxy factory config */ | // TODO DOM private Element proxyFactoryConfig; | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087232#4087232 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087232

18 years, 6 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Next step in ServiceController Lifecycle

by adrian＠jboss.org

Related to this thread http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087219#4087219 Where I'd really like to get to is that the JMX lifecycle is tied to the POJO lifecycle. Currently the ServiceController advice just does a start() straight away once the object is registered in jmx | MBeanServer server = serviceController.getMBeanServer(); | server.registerMBean(mbean, objectName); | try | { | serviceController.start(objectName); | } | But what I really want is the following for the POJO states: NOT_INSTALLED => MBean registered but with no management interface (Note 1) INSTANTIATED => MBean gets real management interface CREATE => serviceController.create(ObjectName) START => serverController.start(ObjectName) etc. The Note 1 is because there should a simple management interface where users can choose to start "on-demand" POJOs. But I'm not sure what this would look like with the new lifecycle stuff. What would the aop config look like for the different callbacks at different pojo events? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087223#4087223 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087223

18 years, 6 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: aspect library config for jbossas

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | The only difference between the old and the new JMX lifecycle is the | service controller lifecycle is now invoked for the MBean. | But this test is NOT looking at the lifecycle it is just looking for the registered MBean, | there has been no change to this. | i.e. the registerMBean() is still in the same place. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087219#4087219 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087219

18 years, 6 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: aspect library config for jbossas

by adrian＠jboss.org

The first problem is because the POJO names are the same as the JMX names. With the new ServiceController implementation, the JMX objects are real contexts in the MC that you can depend upon. i.e. they go through the ServiceController lifecycle. I don't understand the second test. It says jboss.aop:name=BeanWithDependency should not have been found? The only difference between the old and the new JMX lifecycle is the service controller lifecycle is now invoked for the MBean. But this test is NOT looking at the lifecycle it is just looking for the registered MBean, there has been no change to this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087218#4087218 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087218

18 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: ManagedOperation aspects for the ProfileService.Manageme

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | Correct. If that's not correct then the dispatch context is wrong for the same reason. | While we are on subject the InvokeDispatchContext IS incorrect. 1) The getTarget() is redundant, since that is on the plain ControllerContext interface. 2) The getClassLoader() should not be there. As far as I can tell, the classloader is used to get the parameters when they are expressed as strings in the metadata/xml We need to find a way to remove the getClassLoader() and make it an implementation detail, or introduce a permission check into the implementations. Exposing classloaders in public methods is a security hole. See Class.getClassLoader() or Thread.currentThread().getContextClassLoader() for the kind of checks required. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087205#4087205 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087205

18 years, 6 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 September 2007