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

[JBoss Microcontainer Development] - Re: Testing Deployers with new Reflect + ClassPool

by flavia.rainone＠jboss.com

"kabir.khan(a)jboss.com" wrote : The output shows G and A to always have a classloader, probably because the testScenario call maintains a strong reference to the loader? B sometimes is shown to have null loader, so createChildURLLoader needs to be reworked somehow to maintain a strong reference to the loader. You are right, Kabir. The class loader you mentioned had no hard reference on it, that's what's probably causing the error you found. Can you please rerun the tests on JDK5/Mac OS to confirm that the error is gone? Thanks a million! View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4270056#4270056 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4270056

15 years, 1 month

1
0
0 / 0

[JBoss XML Binding Development] - Re: JBXB-100

by alex.loubyansky＠jboss.com

Since you keep ignoring my questions on the issue I have nothing to add. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4270001#4270001 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4270001

15 years, 1 month

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Supporting qualifiers in MC

by kabir.khan＠jboss.com

"alesj" wrote : | I wouldn't bother too much. | If the user overrides class info or existing MDR info with xml, then that's what we should use. | If he wants something more on the plain inject, let him add qualifiers via xml as well. | Actually it is worse than I said yesterday. It doesn't really matter whether the injection point qualifier annotations come from bmd/xml or not, the trigger for looking for the annotations is @Inject. This will work | public class AnnotatedTarget | { | @Inject @SomeQualifier | public void setBean(Bean bean){} | } | but this will not | public class Target | { | @SomeQualifier | public void setBean(Bean bean){} | } | | <bean name="Target" class="Target"> | <property name="bean"> | <inject/> | </property> | </bean> | I would have to do | <bean name="Target" class="Target"> | <property name="bean"> | <inject> | <qualifier>@SomeQualifier</qualifier> | </inject> | </property> | </bean> | but @SomeQualifier already exists in the class, so that is not ideal. The qualifier annotations need to be added some other way. I've had a look at plugging this into the annotation adapters, but it doesn't really "fit". What is happening at the moment is 1) PreInstallAction describeVisits the BeanMetaData 2) Inspect the parent nodes in AbstractInjectionValueMetaData during describeVisit() to determine the injection point type. 3) AIVMD.describeVisit() creates a qualifier dependency item if explicit qualifiers are in place. Otherwise a normal SearchClassContextDependencyItem is created. 4) PreInstallAction populates the MDR 5) PreInstallAction pushes the context's explicit qualifiers to MDR I think what I will do is 1) PreInstallAction describeVisits the BeanMetaData as before 2) Determine the relevant parent nodes in AbstractInjectionValueMetaData during describeVisit(). 3) Either a) See if I can get rid of SearchClassContextDependencyItem, since it should just be a special case of a qualifier dependency item with no qualifiers. b) Create dependency items as before Stash the nodes determined in 1) into the dependency item 4) PreInstallAction populates the MDR as before 5) Extend this step to look at all the dependency items. For the relevant ones (SearchClassContextDependencyItem/qualifier dependency item) check the parent nodes for qualifiers and add to the dependency item. Is this too much of a hack? At least this way we don't have to go through everything again. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4269993#4269993 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4269993

15 years, 1 month

1
0
0 / 0

[JBoss XML Binding Development] - JBXB-100

by richard.opalka＠jboss.com

Hi Alexey, below is the code we're talking about in JBXB-100. JBossWS code is reusing org.jboss.xb.binding.SimpleTypeBindings for un/marshalling. The methods we're using requires String for payload to be de/serialized. Our request is for supporting javax.xml.transform.Source instead of String. Our sourceToString() method takes too much processing time. (~20 % of invocation time). If you would provide this improvement in JBXB, you'd help us improve our invocation performance very significantly. package org.jboss.ws.core.jaxrpc.binding; | | import javax.xml.namespace.QName; | import javax.xml.transform.Source; | import org.jboss.logging.Logger; | import org.jboss.ws.core.binding.BindingException; | import org.jboss.ws.core.binding.DeserializerSupport; | import org.jboss.ws.core.binding.SerializationContext; | import org.jboss.xb.binding.SimpleTypeBindings; | | public class SimpleDeserializer extends DeserializerSupport | { | public Object deserialize(QName xmlName, QName xmlType, | Source xmlFragment, SerializationContext serContext) throws BindingException { | | String jbxb100Workaround = sourceToString(xmlFragment); // [JBXB-100] | return deserialize(xmlName, xmlType, jbxb100Workaround, serContext); | | } | | private Object deserialize(QName xmlName, QName xmlType, String xmlFragment, SerializationContext serContext) throws BindingException | { | String valueStr = unwrapValueStr(xmlFragment); | | if (valueStr != null) | { | return SimpleTypeBindings.unmarshal( | xmlType.getLocalPart(), valueStr, serContext.getNamespaceRegistry()); // [JBXB-100] | } | | return null; | } | } | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4269992#4269992 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4269992

15 years, 1 month

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Testing Deployers with new Reflect + ClassPool

by flavia.rainone＠jboss.com

"flavia.rainone(a)jboss.com" wrote : "alesj" wrote : I wouldn't go with this null, but just with a simple CP exclude -- only for tests purposes. | | e.g. | | Map the AppCL with DefaultCP, but somehow exclude all but java.* and our test packages. | | Actually make this exclusion configurable, as we have it in CL/Deployers. | | | The point with null is to reproduce the fact that String.class.getClassLoader() is null. | The problem is that we won't be able of mapping all the bootstrap just by matching the package names. | If you prefer to have the exclusion for ClassPools, then we will go that way. I'll let you know when this is done so you can finally debug the failure you are seeing. I've done some investigation, trying to find a better solution, but it looks like there isn't one, really. The only thing I can do is doing this exclusion not invasive in the code, or as Ales said, making it configurable: | interface ClassPoolParentFactory | { | public ClassPool getClassPoolParent(ClassLoader classLoader) | } | | class DefaultClassPoolParentFactory implements ClassPoolParentFactory | { | public ClassPool getClassPoolParent(ClassLoader classLoader) | { | if (classLoader == null) return ClassPool.getDefault(); | else return repository.register(classLoader); | } | } | And then, in the tests: | class FilteredClassPoolParentFactory | { | | | public ClassPool getClassPoolParent(ClassLoader classLoader) | { | if (classLoader == null) | return new FilteredClassPoolAdapter(ClassPool.getDefault(), classFilter); | else return repository.register(classLoader); | } | } | | class FilteredClassPoolAdapter extends ClassPool | { | private ClassPool delegate; | private ClassFilter filter; | | public void get(String className) throws NotFoundException | { | if (filter.matchesClassName(className)) | { | delegate.get(className); | } | throw new NotFoundException("..."); | } | .... | } | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4269991#4269991 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4269991

15 years, 1 month

1
0
0 / 0

[jBPM Development] - Re: jpdl syntax for jms activity

by koen.aers＠jboss.com

OK about the connection-factory, I should have thought about it in the first place. I am certainly not married to the destination attribute. It actually would make things easier to implement as well if it was split in queue and topic. I also agree on your refactoring of the message element into meaningful tags. So pretty much agreed about everything ;-) Cheers, Koen View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4269984#4269984 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4269984

15 years, 1 month

1
0
0 / 0

[jBPM Development] - Re: jpdl syntax for ejb method invoke activity

by koen.aers＠jboss.com

Ok, these opinions are pretty clear and a lot like I anticipated. Cheers, Koen View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4269981#4269981 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4269981

15 years, 1 month

1
0
0 / 0

[JBoss ESB Development] - Re: SOAPProxy+AS5: INVM contract unavailable w/classpath URI

by Kevin.Conner＠jboss.com

This problem highlights two issues, one of which we already know about First, only when WSDL is exposed through the HTTP/JBR endpoints should the contract publisher be registered. https://jira.jboss.org/jira/browse/JBESB-2913 seems to cover this. Second, these processors need to be scoped correctly with their deployments otherwise they will never be guaranteed to load required resources/classes (for example during transformation) and this has probably existed since they were introduced. This could affect both as4 and as5 deployments, especially if the esb was scoped. We should use https://jira.jboss.org/jira/browse/JBESB-3034 to focus on the classloading aspect and the other to focus on when they are published. Kev View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4269955#4269955 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4269955

15 years, 1 month

1
0
0 / 0

[jBPM Development] - Re: jpdl syntax for ejb method invoke activity

by jbarrez

"tom.baeyens(a)jboss.com" wrote : I think the invoking an ejb should be called just 'java' I agree. As Ronald also stated before, this makes a lot of sense in for example a Seam environment. "tom.baeyens(a)jboss.com" wrote : | 1) there is a <jndi jndi-name="..." /> element in the wiring section of jpdl. What is then the most consistent way of naming the jndi element ? In that case the full element specifies only jndi so i don't really know what is the most consistent here. Where is that jndi element used today? I think an attribute makes sense. "tom.baeyens(a)jboss.com" wrote : | 2) do we need to distinct between session and entity beans ? or can we use reflection to find out ? or maybe that doesn't matter any more in ejb 3 ? i don't know. EJB 3 'entity beans', or JPA, don't have a JNDI name. So this use case doesn't make much sense. "tom.baeyens(a)jboss.com" wrote : | I think ejb 3 to get started with in incubation. Then if we get enough requests for ejb 2 we can consider it. I agree. EJB3 is the way to go. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4269952#4269952 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4269952

15 years, 1 month

1
0
0 / 0

[jBPM Development] - Re: jpdl syntax for jms activity

by tom.baeyens＠jboss.com

we should also consider the properties. e.g. <jms name="send message" | connectionFactory="ConnectionFactory" | queue="queue/MyQueue"> | <text> | This is the body | </text> | <property name="aString"><string value="txt" /></property> | <property name="aBoolean"><false /></property> | <property name="aShort"><short value="8" /></property> | <property name="aByte"><byte value="8" /></property> | <property name="anInt"><int value="4" /></property> | <property name="aLong"><long value="8888888888" /></property> | ... and so on for all basic types... | | <property name="someExpression" expr="#{person.address.number}" /> | <transition to="wait" /> | </jms> | for the expression, (and probably for the other basic types too) you can use the setObjectProperty method. it only accepts the basic types that are supported. but we can leave it to that jms message to throw an exception if a non-supported type is supplied via the expression. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4269946#4269946 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4269946

15 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums December 2009