March 2010 - jboss-dev-forums - Jboss List Archives

[JBoss XML Binding Development] New message: "Re: Regression moving to JBossXB 2.0.2.Beta5"

by Alessio Soldano

JBoss development, A new message was posted in the thread "Regression moving to JBossXB 2.0.2.Beta5": http://community.jboss.org/message/532603#532603 Author : Alessio Soldano Profile : http://community.jboss.org/people/alessio.soldano@jboss.com Message: -------------------------------------------------------------- > mailto:alex.loubyansky@jboss.com ha scritto: > > Ok, it's done. Sorry about that. Let me know if I can close the issue. https://jira.jboss.org/jira/browse/JBXB-243 No problem, thanks for the quick resolution, I've tried the latest snapshots and I don't see those failures with xsd:any. However... there're a couple of other regressions/failures left; I see issues with unmarshalling of elements having xsi:nil=1 attribute. For instance <result xsi:nil='1' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'/> use to be unmarshalled (correctly) to null, while with the recent jboss-xb I get a not-null instance of the type bound to result. The failure is http://jbossws.jboss.org:8180/hudson/job/NATIVE-CORE-AS-6.0.1-SUN-JDK-6/9... Source references: http://anonsvn.jboss.org/repos/jbossws/stack/native/trunk/modules/testsui... http://anonsvn.jboss.org/repos/jbossws/stack/native/trunk/modules/testsui... -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/532603#532603

16 years

1
0
0 / 0

[EJB 3.0 Development] New message: "Re: Deferring instance creation/injection to CDI"

by Marius Bogoevici

JBoss development, A new message was posted in the thread "Deferring instance creation/injection to CDI": http://community.jboss.org/message/532599#532599 Author : Marius Bogoevici Profile : http://community.jboss.org/people/marius.bogoevici Message: -------------------------------------------------------------- Adding to Carlo's comment: I don't think that there's an overlap either - what Andrew has proposed is essentially targeted towards allowing CDI to produce an instance which is: - constructed according to the CDI constructor (either the unique @Inject constructor, or the default one). I wonder if we do need to pass a list of arguments at all, since it's up to CDI to decide on the constructor to invoke and its parameters. Of course, having the ability to pass arguments may be a benefit in other cases. - injected according to CDI rules concerning the processing of @Inject - decorated according to the CDI I suppose that this leaves it to the container to: - inject Java EE resources and fields (@Resource,@EJB references, etc) - apply interceptors (for which we should stick with the current approach) So, the approach of "let EJB3 do the EJB3 work, let CDI do the CDI work" should work fine. Now, I guess we could do the latter directly from within CDI but it would complicate the lives of both CDI and EJB3. The other thing that Carlo mentioned is interceptors - so here there would be two possibilities, as discussed with Andrew on IRC: - leave instance creation + injection to CDI - provide a callback through the SPI (postInterceptorCreation) so that CDI can do the injection. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/532599#532599

16 years

1
0
0 / 0

[EJB 3.0 Development] Document updated/added: "Requirements: EJB Proxies"

by David Lloyd

JBoss development, The document "Requirements: EJB Proxies", was updated Mar 17, 2010 by David Lloyd. To view the document, visit: http://community.jboss.org/docs/DOC-14983#cf Document: -------------------------------------------------------------- This is a requirements document for EJB proxies. *Please direct questions and comments to this thread:* http://community.jboss.org/thread/149477 Please do *not* remove any sections. If a requirement is to be removed, please strike it out so that the numbering remains consistent. * #Invocation_Dispatch ** #Invocation_Components *** #Proxy_Invocation_Handler *** #Invocation **** #Serialized_Format *** #Invocation_Processor *** #Invocation_Dispatcher **** #Default_Implementations *** #Invocation_Target *** #Remove_Invoker_Context **** #Inbound_Invocations *** #Remote_Dispatcher_Identification * #Remote_Proxies * #EJB_Proxies ** #Remote_Proxies_804440 *** #Invocation_201017 **** #Proxy_Deserialization_Constraints ***** #Remote_Invocation_Context **** #Proxy_Serialization_Constraints ***** #Remote_Invocation_Context_785038 *** #High_Availability_and_Clustering h1. Invocation Dispatch h2. Invocation Components h3. Proxy Invocation Handler The invocation handler of an EJB proxy shall convert the invocation details into an +Invocation+ object which contains the details of this invocation. The invocation will then be passed to an +Invocation Processor+ to be handled. h3. Invocation The +Invocation+ object shall consist of the reflection Method which was invoked, as well as the parameters of the method invocation. In addition, it shall provide an +Attachment+ mechanism by which contextual information may be associated with the Invocation (for example, security and transactional information). h4. Serialized Format The serialized format of the invocation should consist of no more or less than a means to identify the target method, the arguments passed to the target method, and the set of attachments which are associated with the invocation. h3. Invocation Processor A mechanism shall be provided by which each Invocation may be preprocessed in one or more steps before it is +dispatched+ to its final target. Such processors should have the opportunity to add or modify Attachments on the Invocation. Processors should also have the opportunity to "short-circuit" an invocation and reply directly, either with a successful return or an exception of some sort. h3. Invocation Dispatcher The Invocation Dispatcher represents the path to the target of the Invocation and shall have the ability to execute an Invocation. For Remote proxies this typically will entail transmitting the Invocation across the network in some form, to be received and forwarded to another Invocation Dispatcher to be executed directly, or passed through another set of Invocation Processors which may or may not correspond to the sending side's Processor set before handing it to a Dispatcher to be executed. Since the Invocation Disptacher is solely responsible for the execution of the method, it can and should impose whatever policy is appropriate for the management of any target objects which may exist (such as a registration policy, or instance pooling, or session management). The Dispatcher need not correspond to one single target object instance, though that may be the common usage outside of EJB. h4. Default Implementations A Dispatcher implementation shall be provided which calls the Invocation method on a given fixed Object. A Dispatcher implementation shall be provided which passes an Invocation through an Invocation Processor to a delegate Invocation Dispatcher. h3. Invocation Target The +target+ of an Invocation is an object upon which the Invocation is ultimately intended to be executed. Since there is not always a one-to-one correspondance between a remote proxy and a target instance, the task of passing an invocation to a target is always fulfilled by an +Invocation Dispatcher+. h3. Remove Invoker Context A +Remote Invoker Context+ is a realm from which invocations originate, and/or to which invocations arrive. h4. Inbound Invocations Inbound invocations are mapped to their unique destination Dispatchers by a +Remote Dispatcher Identifier+. Thus an inbound invocation associated with a given Remote Invoker Context will consist of the Invocation itself, plus a Remote Invoker Identifier which will select the Dispatcher to send the Invocation to. h3. Remote Dispatcher Identification Within a single Remote Invoker Context, h1. Remote Proxies h1. EJB Proxies h2. Remote Proxies h3. Invocation Proxy Serialization and Deserialization When a proxy is deserialized, it is expected that the deserialized Proxy will be functional regardless of where and when the proxy is deserializaed. There shall be constraints on the functionality of deserialized proxies, as follows. h4. Proxy Deserialization Constraints h5. Remote Invocation Context In order for a proxy to be functional after deserialization, it shall be required that the user provide, directly or indirectly, a +Remote Invocation Context+ which is necessary to fully reconstitute a working remote proxy. Proxy instances which are deserialized without the presense of such a context will not be usable and will cause an exception to be thrown upon invocation. h4. Proxy Serialization Constraints h5. Remote Invocation Context A proxy must be serialized in the presence of a Remote Invocation Context. Attempting to serialize a proxy without such a context will cause an object validation exception. A remote invocation proxy will be associated with a Remote Invocation Context, which may contribute to the serialization of a proxy. h3. High Availability and Clustering --------------------------------------------------------------

16 years

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: JBREFLECT-5 - Implementing generics in JavassistClassInfo"

by Kabir Khan

JBoss development, A new message was posted in the thread "JBREFLECT-5 - Implementing generics in JavassistClassInfo": http://community.jboss.org/message/532580#532580 Author : Kabir Khan Profile : http://community.jboss.org/people/kabir.khan@jboss.com Message: -------------------------------------------------------------- Trying to run the kernel tests with the jboss-reflect snapshot and javassist implementation with security disabled results in loads of failures. A lot of these seem to be due to BeanInfo never having been tested with the Javassist implementation, and fall into the following categories: * PropertyInfo.getUnderlyingAnnotation() is not working properly w/ Javassist so we get problems in jbossxb since the @XmlTransient annotation is not read * I need to dig in properly, but it seems that when configuring Collection/Map/Array properties, the individual elements are null rather than containing the expected values * There might be more I am currently creating Javassist versions of the org.jboss.test.beaninfo.test.* tests and fixing what comes up. The first thing I found is that when creating property infos for things like public class BeanInfoGenericInconsistentTypes { public BeanInfoGenericClass<String> getSomething() { return null; } public void setSomething(BeanInfoGenericClass<Integer> x) { } } With the Javassist implementation the 'something' property gets both a getter and a setter, while with introspection it gets only a getter. The code that determines this is this in AbstractBeanInfoFactory.getBeanProperties(): TypeInfo pinfo = thisSetter.getParameterTypes()[0]; if (getter.getReturnType().equals(pinfo) == true) The introspection implementation returns ParameterizedClassInfos containing the generic information for the parameter and return types, so it looks like I will need to implement that for javassist anyway. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/532580#532580

16 years

1
0
0 / 0

[JBoss XML Binding Development] New message: "Re: Regression moving to JBossXB 2.0.2.Beta5"

by Alexey Loubyansky

JBoss development, A new message was posted in the thread "Regression moving to JBossXB 2.0.2.Beta5": http://community.jboss.org/message/532575#532575 Author : Alexey Loubyansky Profile : http://community.jboss.org/people/alex.loubyansky@jboss.com Message: -------------------------------------------------------------- Ok, it's done. Sorry about that. Let me know if I can close the issue. https://jira.jboss.org/jira/browse/JBXB-243 -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/532575#532575

16 years

1
0
0 / 0

[JBoss XML Binding Development] New message: "Re: Regression moving to JBossXB 2.0.2.Beta5"

by Alessio Soldano

JBoss development, A new message was posted in the thread "Regression moving to JBossXB 2.0.2.Beta5": http://community.jboss.org/message/532566#532566 Author : Alessio Soldano Profile : http://community.jboss.org/people/alessio.soldano@jboss.com Message: -------------------------------------------------------------- Yep, once a snapshot version is available I can force a dependency on that in the native ws stack and re-build AS trunk after having modified the component-matrix locally for using your snapshot. Just let me know (also the number of the jira for this issue) -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/532566#532566

16 years

1
0
0 / 0

[JBoss XML Binding Development] New message: "Re: Regression moving to JBossXB 2.0.2.Beta5"

by Alexey Loubyansky

JBoss development, A new message was posted in the thread "Regression moving to JBossXB 2.0.2.Beta5": http://community.jboss.org/message/532563#532563 Author : Alexey Loubyansky Profile : http://community.jboss.org/people/alex.loubyansky@jboss.com Message: -------------------------------------------------------------- I think I found it. The fix appears to be simple. I do have tests that should cover your usecases but will you be able to test xb snapshot to confirm it works for you? I haven't committed it yet. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/532563#532563

16 years

1
0
0 / 0

[JBoss Web Services Development] New message: "modify ENDPOINT_ADDRESS_PROPERTY at runtime"

by simone bagnolesi

JBoss development, A new message was posted in the thread "modify ENDPOINT_ADDRESS_PROPERTY at runtime": http://community.jboss.org/message/532559#532559 Author : simone bagnolesi Profile : http://community.jboss.org/people/bagnos Message: -------------------------------------------------------------- hi, i have some problems about changing ENDPOINT_ADDRESS_PROPERTY inside client soap handler, i have jbossws native and jboss-5.1.0.GA. It works outside the handler with the follow instructions: Sample port1 = service.getSamplePort();String newAddress= "http://-contesto-:8080/COPERGMPS.SOA/PTGateway";((BindingProvider)port1).getRequestContext().put(BindingProvider. +ENDPOINT_ADDRESS_PROPERTY+, newAddress); inside the handler, with the follow: **public ** * *boolean* handleMessage(SOAPMessageContext arg0) { arg0.put(BindingProvider. +ENDPOINT_ADDRESS_PROPERTY+, "http://-contesto-:8080/COPERGMPS.SOA/PTGateway"); *return* *true*;} the above instruction doesn't work. The +ENDPOINT_ADDRESS_PROPERTY + remains the same as the orginal wsdl soap address. The above instruction works with websphere 7.0 , tomcat and jdk. Someone can I help me? thanks * -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/532559#532559

16 years

1
0
0 / 0

[JBoss Web Services Development] New message: "Re: drools application (project) on the web"

by Johanna Voxy

JBoss development, A new message was posted in the thread "drools application (project) on the web": http://community.jboss.org/message/532550#532550 Author : Johanna Voxy Profile : http://community.jboss.org/people/voxy Message: -------------------------------------------------------------- Ok, guys... thanks for your answers. I found a way to to my stufff, using the java servlet, cause it exists a way to use drools rules with the java servlet. I'm still working on it. The first part worked cause i exported well my project (without the rules), and tested it on my localhost. I'm now trying to call my rules. If i find a simple way, i will let you know. Thanks again! -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/532550#532550

16 years

1
0
0 / 0

[JBoss XML Binding Development] New message: "Re: Regression moving to JBossXB 2.0.2.Beta5"

by Alessio Soldano

JBoss development, A new message was posted in the thread "Regression moving to JBossXB 2.0.2.Beta5": http://community.jboss.org/message/532547#532547 Author : Alessio Soldano Profile : http://community.jboss.org/people/alessio.soldano@jboss.com Message: -------------------------------------------------------------- Yep, in the first xml param1 is bound to ArrayOfAny and name and product elements should be unmarshalled to SOAPElements -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/532547#532547

16 years

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 March 2010