Re: Axis2 - HttpServletContext via MessageContext
Amit Patel wrote: > I have a question regarding retrieving MessageContext with Axis2 in > attempt to retrieve ServletContext. > > I used the following code in Axis1, which worked perfectly: > > MessageContext = MessageContext.getCurrentContext(); > HttpServlet servlet = (HttpServlet) mycontext > .getProperty(HTTPConstants.MC_HTTP_SERVLETREQUEST); > ServletConfiltered= servlet.getServletContext() in Axis2 use the following msgCtx.getProperty(Constants.SERVLET_CONTEXT); > > However, the getCurrentContext static method is no longer supported > with the Axis2 implementation of MessageContext. yes , Axis2 does not have that concept. > > How can I retrieve the MessageContext and/or ServletContext with Axis2? Its depend on the location where you are trying to access that , if you want to access that inside a handler then of course you can do that. > > Thanks, > > Amit > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > -- Thanks, Deepal ~Future is Open~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-938) Plugpoint to allow for migration between context and TLS
[ http://issues.apache.org/jira/browse/AXIS2-938?page=comments#action_12423995 ] Davanum Srinivas commented on AXIS2-938: Here's my train of thought: - 3 changes to classes under jaxws look ok. - 3 new classes (ThreadContext*.java) look ok. - But, those 3 classes are not used in modules/core so they can be moved to modules/jaxws (addThreadContextMigrator can take in an Object - if push comes to shove) - Now, there is only one change left in modules/core which is the change to AxisConfiguration.java - There are 3 methods in that change, which is to maintain the List of threadContextMigrators. - First of all, that LinkedList can be added as a get/set property with a special key in ConfigurationContext, then you won't need to touch AxisConfiguration.java at all. - Since AxisConfiguration is not meant to hold runtime information (AxisConfiguration is only for loading and deploying stuff) and ConfigurationContext is...So ConfigurationContext is a better location to store that LinkedList. So, if you move the LinkedList to ConfigurationContext, then all the changes will be limited to modules/jaxws which is perfect because the new Interface class is not really usable by anyone else other than jaxws as the hooks are not called/used anywhere in the core anyways. What do you think? thanks, dims > Plugpoint to allow for migration between context and TLS > > > Key: AXIS2-938 > URL: http://issues.apache.org/jira/browse/AXIS2-938 > Project: Apache Axis 2.0 (Axis2) > Issue Type: New Feature > Components: core, jaxws >Reporter: Bill Nagy > Assigned To: Bill Nagy > Attachments: tlsmigrator.patch > > > We have an issue with some APIs (e.g. security, Tx) requiring that data be > present on Thread Local Storage (TLS). I believe that we can work around (at > least for now) needing to migrate information between threads, and can simply > get away with storing it in one of the contexts and then moving it to TLS > before we get into user space (i.e. up through the service programming model) > and then back again if need be. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Plugpoint to allow for migration between context and TLS
This took a little longer than I would have liked, but I've opened a JIRA issue (Axis2-938) and attached my patch. Comments are welcome. -Bill On Wed, 2006-07-12 at 14:20 -0400, Bill Nagy wrote: > Hi Sanjiva, > > Logically, you can think of them as an extension to the handler > mechanism that runs at the border between the core Axis2 code and the > programming model layer (e.g. in the JAX-WS case they'll be run inside > of the JAXWSMessageReceiver, the jaxws...AxisInvocationController, and > the jaxws...AxisCallback (I believe.)) They're really just a set of > utility methods that get invoked to bridge between the Axis2 context > model and the external programming model that is exposed to the end > user, so they don't have a lifecycle per say. I specifically haven't > tied the registration of the migrators (I'm happy for a different name > 8-]) to a handler or module, as (1) they are programming model specific, > while the modules/handlers deal with the Axis2 model and (2) on the > sender side, the modules may not have been engaged by the time that this > code needs to execute. Implementation of the migrators falls somewhere > between the responsibility of the programming model implementor and the > QoS implementor -- as I said, it's really bridging code. > > I will try to send out the diffs of my code later today after I get the > changes put into the new JAX-WS code. > > -Bill > > > On Wed, 2006-07-12 at 22:12 +0530, Sanjiva Weerawarana wrote: > > On Wed, 2006-07-12 at 09:40 -0400, Bill Nagy wrote: > > > Hi dims, > > > > > > Sure. You are correct, there is no TLS code currently in Axis2. > > > However we (IBM) have several cases (e.g. security) where we need to > > > migrate information between the Axis2 contexts and TLS. For example, we > > > have identity APIs that rely upon tokens being placed in TLS. While we > > > can have the handler place the information in the MessageContext for > > > example, we need to move it to TLS before we enter "user space," so that > > > if the user invokes one of our security APIs the information will be > > > available. (We also need to make sure that the info is removed from TLS > > > when we're done, hence the flowComplete() method.) > > > > So is this basically a utility class that a specific handler invokes? Or > > are you suggesting that people register these "migrators" against a > > handler and then they get invoked upon entry/exit? I guess the lifecycle > > and programming model for TCMigrators is not clear enough to me yet! > > > > Sanjiva. > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-938) Plugpoint to allow for migration between context and TLS
[ http://issues.apache.org/jira/browse/AXIS2-938?page=all ] Bill Nagy updated AXIS2-938: Attachment: tlsmigrator.patch > Plugpoint to allow for migration between context and TLS > > > Key: AXIS2-938 > URL: http://issues.apache.org/jira/browse/AXIS2-938 > Project: Apache Axis 2.0 (Axis2) > Issue Type: New Feature > Components: core, jaxws >Reporter: Bill Nagy > Assigned To: Bill Nagy > Attachments: tlsmigrator.patch > > > We have an issue with some APIs (e.g. security, Tx) requiring that data be > present on Thread Local Storage (TLS). I believe that we can work around (at > least for now) needing to migrate information between threads, and can simply > get away with storing it in one of the contexts and then moving it to TLS > before we get into user space (i.e. up through the service programming model) > and then back again if need be. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-938) Plugpoint to allow for migration between context and TLS
Plugpoint to allow for migration between context and TLS Key: AXIS2-938 URL: http://issues.apache.org/jira/browse/AXIS2-938 Project: Apache Axis 2.0 (Axis2) Issue Type: New Feature Components: core, jaxws Reporter: Bill Nagy Assigned To: Bill Nagy Attachments: tlsmigrator.patch We have an issue with some APIs (e.g. security, Tx) requiring that data be present on Thread Local Storage (TLS). I believe that we can work around (at least for now) needing to migrate information between threads, and can simply get away with storing it in one of the contexts and then moving it to TLS before we get into user space (i.e. up through the service programming model) and then back again if need be. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-910) JAXWS: Update AxisInvocationController to use the OperationClient instead of the ServiceClient
[ http://issues.apache.org/jira/browse/AXIS2-910?page=all ] Bill Nagy resolved AXIS2-910. - Resolution: Fixed > JAXWS: Update AxisInvocationController to use the OperationClient instead of > the ServiceClient > -- > > Key: AXIS2-910 > URL: http://issues.apache.org/jira/browse/AXIS2-910 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Improvement > Components: jaxws >Reporter: Nick Gallardo > Assigned To: Bill Nagy > Attachments: 910-src-patch.txt, 910-test-patch.txt, > jaxws-test-patch.txt > > > For the purposes of greater flexibility, the AxisInvocationController should > use the Axis2 OperationClient API rather than using the ServiceClient. I've > started a little bit of this work in a sandbox and will hopefully have > patches to post later on today. > Also, this work is dependant upon the patch that I posted for JIRA issue 909. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Axis2 - HttpServletContext via MessageContext
I have a question regarding retrieving MessageContext with Axis2 in attempt to retrieve ServletContext. I used the following code in Axis1, which worked perfectly: MessageContext = MessageContext.getCurrentContext(); HttpServlet servlet = (HttpServlet) mycontext.getProperty(HTTPConstants.MC_HTTP_SERVLETREQUEST); ServletConfiltered= servlet.getServletContext() However, the getCurrentContext static method is no longer supported with the Axis2 implementation of MessageContext. How can I retrieve the MessageContext and/or ServletContext with Axis2? Thanks, Amit __Do You Yahoo!?Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
?WSDL option generates SOAP1.1 based WSDL
Hi, Using Axis 1.4, I generated code from a WSDL that referred to SOAP1.2. The code generated and the service deployed correctly and when I access the service and check the SOAP request/response messages they conform to the SOAP 1.2 standards. But when I try to use the ?wsdl option in the service listing it gives me WSDL that refers to SOAP 1.1 standards. I need the ?wsdl option to work. Is this a bug in Axis 1.4? Or is there anythign else that I need to do? Any help will be appreciated. Thanks, SA How low will we go? Check out Yahoo! Messengers low PC-to-Phone call rates.
[jira] Created: (AXIS2-937) WSDL2Java not generating parameters for stib methods
WSDL2Java not generating parameters for stib methods Key: AXIS2-937 URL: http://issues.apache.org/jira/browse/AXIS2-937 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: Tools Reporter: William Ferguson Attachments: JasperService.wsdl WSDL2Java from the nightly snapshot of 23-jul-2006 generates the stub/interface, but tyhe methods on the stub don't have any parameters when they should. The stub is created fine using WSDL2Java from Axis2-1.0 WSDL2Java params: I will attach the WSDL in question -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-937) WSDL2Java not generating parameters for stib methods
[ http://issues.apache.org/jira/browse/AXIS2-937?page=all ] William Ferguson updated AXIS2-937: --- Attachment: JasperService.wsdl The WSDL which wotks for Axis2-1.0 but not for the nightly build of 23-jul-06 > WSDL2Java not generating parameters for stib methods > > > Key: AXIS2-937 > URL: http://issues.apache.org/jira/browse/AXIS2-937 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug > Components: Tools >Reporter: William Ferguson > Attachments: JasperService.wsdl > > > WSDL2Java from the nightly snapshot of 23-jul-2006 generates the > stub/interface, but tyhe methods on the stub don't have any parameters when > they should. The stub is created fine using WSDL2Java from Axis2-1.0 > WSDL2Java params: > > > > > > > > > > > I will attach the WSDL in question -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS-2386) Java2WSDL changes type double array into a single double.
[
http://issues.apache.org/jira/browse/AXIS-2386?page=comments#action_12423906 ]
Christine Chen commented on AXIS-2386:
--
This problem started to manifest after I switched the style (-y) from RPC to
WRAPPED when running java2wsdl (Axis 1.4) against my Interface/Impl classes.
My tester classes contain a single method with 2 INOUT params of Holder types:
public void listContexts( ArrayOfStringHolder Contexts, ArrayOfDummyHolder
Dummys);
The wsdl generated has the correct complex type definition for ArrayOfDummy,
but instead of providing a definition for ArrayOfString, it just has string.
After debugging a bit, the problem seems to be with
axis.description.JavaServiceDesc::getTypeQName(), the javaClass being passed in
is "[Ljava.lang.String". Because I used WRAPPED style, it will go to:
typeQName = tm.getTypeQNameExact(javaClass);
if (typeQName == null && javaClass.isArray()) {
typeQName = tm.getTypeQName(javaClass.getComponentType());
}
The first line returns null because "[Ljava.lang.String" is not in the
typemappings (which I think do not contain any array types). Realising the
class is an array type, it will try to look up the QName for the component
type. which is string. Thus getTypeQName() returns 'string' as the QName for
my ArrayOfStringHolder type.
In the RPC style case, it will just call the following and return null.
if (style == Style.RPC) {
typeQName = tm.getTypeQName(javaClass);
}
Looks to me a paramDesc with null QName will prompt java2wsdl to generate a
complex type as expected.
For my case, perhaps the fix can be put in
axis.description.JavaServiceDesc::createOperationForMethod():
Class heldClass = JavaUtils.getHolderValueType(type);
System.out.println("heldClass: " + heldClass.getName());
if (heldClass != null) {
paramDesc.setMode(ParameterDesc.INOUT);
QName qname = getTypeQName(heldClass);
if the class was a Holder type, call some overloaded class of getTypeQName()
that does not look up the QName for the array's component type.
For now, I'm thinking of wrapping String inside a class, say MyString, and
declare a holder with MyString[] to work around the problem until the bug is
fixed.
> Java2WSDL changes type double array into a single double.
> -
>
> Key: AXIS-2386
> URL: http://issues.apache.org/jira/browse/AXIS-2386
> Project: Apache Axis
> Issue Type: Bug
> Components: WSDL processing
>Affects Versions: 1.2.1, 1.3
> Environment: Linux 2.4.26, java version "1.5.0_04", Tomcat 5.5
>Reporter: Eric Webster
>Priority: Minor
> Attachments: DataSet.wsdl, IncorrectDataSet.wsdl
>
>
> Java2WSDL changes type double array into a single double.
> This happens when you run Java2WSDL manually on the command line or when a
> wsdl file is generated from a service_name?wsdl url.
> Currently to fix this I just manually edit the generated WSDL file and
> distrobute that.
> The Java code originally came from a hand made WSDL file. WSDL2Java was used
> to generate the Java code. The section that is affected by this problem is
> the 'ValueVector' complexType which contains and element 'values' which is an
> array of doubles. After converting to Java and then back to WSDL 'values'
> becomes a single double.
> Here is the original WSDL file.
>
> targetNamespace="dataset.odin.cirg.washington.edu"
> xmlns:apachesoap="http://xml.apache.org/xml-soap";
> xmlns:impl="dataset.odin.cirg.washington.edu"
> xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/";
> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
> xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";>
>
> xmlns="http://www.w3.org/2001/XMLSchema";>
> http://schemas.xmlsoap.org/soap/encoding/"/>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>wsdl:arrayType="impl:Attribute[]"/>
>
>
>
>
>
>
>
>
>
>
> nillable="true"/>
> nillable="true"/>
>
>
>
>
>
>wsdl:arrayType="impl:ValueVector[]"/>
>
>
>
>
>
>
> nillable="true"/>
>
>
>
>
>
Re: [Axis2] JSR 181 support
Nicholas,So sorry for the late reply, somehow I have missed it :-(>>Sorry to jump in the middle here, but can you explain what the meta annotation is and from which spec files it would be removed? I'm assuming you're talking >>about the JSR-181 spec annotations declarations, but just wanted to make sure.No need to appologize, sorry for not explaining it properly.Annogen requires you to add an annotation, which it uses to generate the AnnoBeans. @AnnogenInfo( annoBeanClass = "org.codehaus.annogen.examples.stored_override.DeploymentInfoAnnoBean")So I used the annotation on the spec files. For example on the javax.jws.WebService which describes the @WebService annotation. However it's illegal to modify a spec file without permission, so what we did was to remove the annotation after we generated the necessary AnnoBeans.The generated AnnoBeans were checked into the main source tree (since they never change as the spec files are static) >>Just for clarity, you are getting those from the WSM jars, correct?Yes they come with the WSM jars. They will most likely be available in the repos from today.Hope this helps.Regards,Rajith On 7/24/06, Nicholas L Gallardo <[EMAIL PROTECTED]> wrote: Rajith, Sorry to jump in the middle here, but can you explain what the meta annotation is and from which spec files it would be removed? I'm assuming you're talking about the JSR-181 spec annotations declarations, but just wanted to make sure. Just for clarity, you are getting those from the WSM jars, correct? Thanks, Nicholas Gallardo WebSphere - WebServices Development [EMAIL PROTECTED] Phone: 512-838-1182 Building: 901 / 5G-016 "Davanum Srinivas" <[EMAIL PROTECTED]> 07/24/2006 04:52 PM Please respond to axis-dev@ws.apache.org To axis-dev@ws.apache.org cc Subject Re: [Axis2] JSR 181 support Sounds good to me. -- dims On 7/24/06, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > Dims, > > Eddie was suggesting that we remove the meta annotation from the spec files > since we already have the generated code. > Since the spec file is static we can safely include the generated AnnoBeans > in the main source tree. > > If we do that approach we can safely avoid the legal issue :-) > > What do u think? > > Regards, > > Rajith > > > On 7/20/06, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > > > > Hi All, > > > > I created a deployment hook which uses ASM to scan a jar file thats thrown > into the axis2 repository to identify classes annotated with @WebServices. > > Therefore there is no need for a services.xml to be present in the jar > file. > > > > Currently support for @SOAPBinding, @HandlerChain, @SOAPMessageHandlers > (on Axis2 side, the WSMModel is complete) and generating the WSDL is still > outstanding. > > > > Comments/suggestions/reviews are most welcomed. > > > > I will wait for a general nod from the community about the direction, > before I start on any further work. > > > > All required patches are attached to AXIS2-883 > > > > Regards, > > > > > > Rajith > > > > > > > > > > > > On 7/11/06, Eddie O'Neil <[EMAIL PROTECTED]> wrote: > > > Rajith-- > > > > > > I'm not super familiar with the Axis2 architecture, but in the > > > absence of both a .aar file and service.xml, is there some default > > > binding between a URL and a Java class? If so, the metadata could be > > > checked and processed at runtime to dynamically wire-up a service > > > based on the shape of a web service implementation class (and optional > > > service endpoint). > > > > > > To close the loop on Dennis's question from a while ago, it *is* > > > possible to get all of the type declarations that are annotated with a > > > specific annotation. This method is available here: > > > > > > > http://java.sun.com/j2se/1.5.0/docs/guide/apt/mirror/com/sun/mirror/apt/AnnotationProcessorEnvironment.html#getDeclarationsAnnotatedWith(com.sun.mirror.declaration.AnnotationTypeDeclaration) > > > > > > and returns a collection of types (classes, fields, parameters) that > > > are marked with some annotation. > > > > > > This doesn't really help us for wiring up web services at runtime, > > > but it makes the build time very easy. > > > > > > Eddie > > > > > > > > > On 7/11/06, Rajith Attapattu <[EMAIL PROTECTED] > wrote: > > > > Hi Guillaume, > > > > > > > > if the service deployed as an ".aar" then we know which classes to > > > > introspect or use ASM. > > > > If there is a service.xml then we can easily figure out what the class > is. > > > > The above approach will make life easier. > > > > > > > > But I think the expectation is that service.xml is optional. > > > > Also there maybe an expectation that the annotated POJO's need not be > > > > deployed as an ".aar" > > > > > > > > I maybe wrong here, but it would be interesting to know what the > expectation > > > > is within the community. > > > > ideas/comments please? > > > > > > > > Regards, > > > > > > > > Rajith > > > > > > > > On 7/11/06, Guillaume Sauthier > > > > < [E
[jira] Commented: (AXIS2-935) Connections are not properly released causing them to stick in the "CLOSE_WAIT" state and cause "Too many files open"
[ http://issues.apache.org/jira/browse/AXIS2-935?page=comments#action_12423880 ] Jeff Peterson commented on AXIS2-935: - I forgot to mention, I noticed another interesting symptom. If I force the app server to perform garbage collection most of the connections in the CLOSE_WAIT state get cleaned up. > Connections are not properly released causing them to stick in the > "CLOSE_WAIT" state and cause "Too many files open" > - > > Key: AXIS2-935 > URL: http://issues.apache.org/jira/browse/AXIS2-935 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug > Components: core >Affects Versions: 1.0 > Environment: Weblogic 8.1.2, Solaris 8 (dont ask!) >Reporter: Jeff Peterson >Priority: Critical > > It appears that org.apache.axis2.transport.http.SOAPOverHTTPSender does not > properly cleanup the http post connection after payload has been sent. > The symptoms of this problem show up in `netstat` as literally hundreds of > connections in the "CLOSE_WAIT" state. On a busy server this can cause the > application to report exceptions with the message "Too many open files." > I looked in the source code for axis2 1.0 and discovered that in > SOAPOverHTTPSender.java the releaseConnection() is never called on the > postMethod variable. This seems to be a likely candidate for the source of > the issue. > See SOAPOverHTTPSender.java:97-118 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-935) Connections are not properly released causing them to stick in the "CLOSE_WAIT" state and cause "Too many files open"
[ http://issues.apache.org/jira/browse/AXIS2-935?page=comments#action_12423877 ] Jeff Peterson commented on AXIS2-935: - I''ve done some more digging through the code and I am no longer convinced that this is an issue with the SOAPOverHTTPSender class. Perhaps there is another culprit... My MEP looks like the following: Service1Service2 | OUT/IN Sync | | ->| | < | || | IN | | < | || | IN | | < | || | IN | | < | > Connections are not properly released causing them to stick in the > "CLOSE_WAIT" state and cause "Too many files open" > - > > Key: AXIS2-935 > URL: http://issues.apache.org/jira/browse/AXIS2-935 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug > Components: core >Affects Versions: 1.0 > Environment: Weblogic 8.1.2, Solaris 8 (dont ask!) >Reporter: Jeff Peterson >Priority: Critical > > It appears that org.apache.axis2.transport.http.SOAPOverHTTPSender does not > properly cleanup the http post connection after payload has been sent. > The symptoms of this problem show up in `netstat` as literally hundreds of > connections in the "CLOSE_WAIT" state. On a busy server this can cause the > application to report exceptions with the message "Too many open files." > I looked in the source code for axis2 1.0 and discovered that in > SOAPOverHTTPSender.java the releaseConnection() is never called on the > postMethod variable. This seems to be a likely candidate for the source of > the issue. > See SOAPOverHTTPSender.java:97-118 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-891) Allow the WS-Addressing action to be set, in the client, without also setting the SOAP action
[ http://issues.apache.org/jira/browse/AXIS2-891?page=all ] Brian DePradine updated AXIS2-891: -- Attachment: newerpatch.txt Hi, I am attaching an updated patch that simplifies the code, and adds the new property as a named constant in the org.apache.axis2.Constants class. > Allow the WS-Addressing action to be set, in the client, without also setting > the SOAP action > - > > Key: AXIS2-891 > URL: http://issues.apache.org/jira/browse/AXIS2-891 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Improvement > Components: core >Reporter: Brian DePradine > Attachments: newerpatch.txt, newpatch.txt, patch.txt > > > Modify the Options class to allow a user to set the WS-Addressing action > without also setting the soap action. This is important as, according to the > WS-Addressing 1.0 SOAP Binding Spec, it will allow the ability to obscure the > action through SOAP-level security mechanisms, without having to resort to > transport level security mechanisms. Patch to follow. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-922) WSDL2Java generates incorrect code for multiple faults
[ http://issues.apache.org/jira/browse/AXIS2-922?page=all ]
Davanum Srinivas resolved AXIS2-922.
Resolution: Invalid
marking as invalid as per reporter's comments.
> WSDL2Java generates incorrect code for multiple faults
> --
>
> Key: AXIS2-922
> URL: http://issues.apache.org/jira/browse/AXIS2-922
> Project: Apache Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: Tools
>Reporter: Dave Cowing
> Attachments: Services.wsdl, Services.wsdl, UpdateMemberSkeleton.java
>
>
> When I run WSDL2Java on a wsdl that has 3 faults for a service, the generated
> skeleton is incorrect.
> 1) the service method declaration in the skeleton has the right number of
> faults in the throws portion, but they're all the same:
>throws
> com.example.cis.UpdateMemberSkeleton.InvalidMemberIdFaultException,com.example.cis.UpdateMemberSkeleton.InvalidMemberIdFaultException,com.example.cis.UpdateMemberSkeleton.InvalidMemberIdFaultException{
> 2) Only one fault exception class is generated in the skeleton, when there
> should be three.
> I'm attaching my wsdl, as well as the generated skeleton.
> My wsdl call is:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[AXIS2] [Sandesha2] Saving the message context
Hi all, I have posted this note to both the AXIS2 and SANDESHA developer discussion lists, so I apologize in advance to those folks who get multiple copies of this note. I am investigating how to save and restore the message context in AXIS2. This is functionality that would be used by other quality-of-service layers, for example, by a WS-ReliableMessaging implementation - particularly one that is composed with WS-Security, to save the message in persistent storage and later resume the message processing. The AXIS2 message context is very complex (it includes references to several complicated objects) and does not lend itself to the default java serialization mechanism (java.io.Serializable). In order to save the message context, the possible solutions include the following: (A) Internal Message Context option Do a customized serialization using java.io.Externalizable in the complex objects and use the default serialization mechanism (java.io.Serializable) in the simple objects. - - This keeps the knowledge of the object's internals in the object and keeps the responsibility in the object for persisting and resurrecting its own state. - - This lets an object have a plugpoint where needed to manage "user" data. This would apply to the situation where an object maintains a set of properties or attributes that are supplied by users of the object. The plugpoint would define an interface so that the users of the object could save their properties/attributes appropriately. (B) External Layer option Put in get/set methods in all of the objects related to the message context in order to allow another layer or quality of service (QoS) to extract sufficient information from the message context in order to save and resurrect the information. - - The simplest form of this technique is saving just the message (and the message attachments). However, this means that any processing on the message has to be re-done from the beginning. - - If there is a requirement to maintain the security context with the message, then the security layer would need to provide additional interfaces to allow that message's security context to be acquired by that other layer. (C) Core Plugpoint option Have a plugpoint in the AXIS2 core that would provide an interface to capture essential message context data for saving and restoring it. - - This solution would be a compromise between (A) and (B) - - This requires knowledge of message context object-related internals inside of the plugpoint implementation, which is not good object oriented design Any other suggestions or comments? I understand that there has been a previous attempt to do this in AXIS2 based on Sandesha requirements and that this attempt did not work. I was wondering if anyone remembers what problems were encountered and what issues ultimately blocked that solution? Thanks, Ann WebSphere Development, Web Services Engine IBM 11501 Burnet Rd IZip 9035G021 Austin, TX 78758 (512)838-9438TL 678-9438
[jira] Commented: (AXIS2-922) WSDL2Java generates incorrect code for multiple faults
[
http://issues.apache.org/jira/browse/AXIS2-922?page=comments#action_12423863 ]
Dave Cowing commented on AXIS2-922:
---
Should be closed - not an issue - bad WSDL. Works with section in bindings and
unique elements for the fault messages.
> WSDL2Java generates incorrect code for multiple faults
> --
>
> Key: AXIS2-922
> URL: http://issues.apache.org/jira/browse/AXIS2-922
> Project: Apache Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: Tools
>Reporter: Dave Cowing
> Attachments: Services.wsdl, Services.wsdl, UpdateMemberSkeleton.java
>
>
> When I run WSDL2Java on a wsdl that has 3 faults for a service, the generated
> skeleton is incorrect.
> 1) the service method declaration in the skeleton has the right number of
> faults in the throws portion, but they're all the same:
>throws
> com.example.cis.UpdateMemberSkeleton.InvalidMemberIdFaultException,com.example.cis.UpdateMemberSkeleton.InvalidMemberIdFaultException,com.example.cis.UpdateMemberSkeleton.InvalidMemberIdFaultException{
> 2) Only one fault exception class is generated in the skeleton, when there
> should be three.
> I'm attaching my wsdl, as well as the generated skeleton.
> My wsdl call is:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Could not convert org.apache.axis.attachments.AttachmentPart
Title: Could not convert org.apache.axis.attachments.AttachmentPart
Hello!
I have been struggeling with implementing an MMS receiver according to the MM7 specification.
3GPP's MM7 interface defines an MM7 XML schema (namespace is http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-6-MM7-1-0) that contains the following element:
content element including only href
This element contains a cid: URL that points to a MIME content in a SOAP with attachment message:
When importing this schema into a WSDL file and generating Java classes with WSDL2JAVA for the use on the server side, one gets the following Exception, when the service is called by a SOAP request containing an attachment:
[26.07.06 10:03:31:163 CEST] 3410b26 BeanPropertyT E org.apache.axis.encoding.ser.BeanPropertyTarget Could not convert org.apache.axis.attachments.AttachmentPart to bean field 'content', type at.mobilkom.asmp.mm7.wsdl.ContentReferenceType
[26.07.06 10:03:31:173 CEST] 3410b26 EXCEPTIONS I org.apache.axis.EXCEPTIONS AxisFault:
[26.07.06 10:03:31:273 CEST] 3410b26 EXCEPTIONS I org.apache.axis.EXCEPTIONS TRAS0014I: Die folgende Ausnahmebedingung wurde protokolliert: AxisFault
faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
faultSubcode:
faultString: java.lang.IllegalArgumentException: argument type mismatch
faultActor:
faultNode:
faultDetail:
{http://xml.apache.org/axis/}stackTrace:java.lang.IllegalArgumentException: argument type mismatch
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
at java.lang.reflect.Method.invoke(Method.java:391)
at org.apache.axis.utils.BeanPropertyDescriptor.set(BeanPropertyDescriptor.java:142)
at org.apache.axis.encoding.ser.BeanPropertyTarget.set(BeanPropertyTarget.java:75)
at org.apache.axis.encoding.DeserializerImpl.valueComplete(DeserializerImpl.java:249)
at org.apache.axis.encoding.DeserializerImpl.startElement(DeserializerImpl.java:388)
at org.apache.axis.encoding.DeserializationContext.startElement(DeserializationContext.java:1048)
at org.apache.axis.message.SAX2EventRecorder.replay(SAX2EventRecorder.java:165)
at org.apache.axis.message.MessageElement.publishToHandler(MessageElement.java:1141)
at org.apache.axis.message.RPCElement.deserialize(RPCElement.java:236)
at org.apache.axis.message.RPCElement.getParams(RPCElement.java:384)
at org.apache.axis.providers.java.RPCProvider.processMessage(RPCProvider.java:81)
at org.apache.axis.providers.java.JavaProvider.invoke(JavaProvider.java:323)
at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
at org.apache.axis.handlers.soap.SOAPService.invoke(SOAPService.java:453)
at org.apache.axis.server.AxisServer.invoke(AxisServer.java:281)
at org.apache.axis.transport.http.AxisServlet.doPost(AxisServlet.java:699)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:327)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at com.ibm.ws.webcontainer.servlet.StrictServletInstance.doService(StrictServletInstance.java:110)
at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet._service(StrictLifecycleServlet.java:174)
at com.ibm.ws.webcontainer.servlet.IdleServletState.service(StrictLifecycleServlet.java:313)
at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet.service(StrictLifecycleServlet.java:116)
at com.ibm.ws.webcontainer.servlet.ServletInstance.service(ServletInstance.java:283)
at com.ibm.ws.webcontainer.servlet.ValidServletReferenceState.dispatch(ValidServletReferenceState.java:42)
at com.ibm.ws.webcontainer.servlet.ServletInstanceReference.dispatch(ServletInstanceReference.java:40)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.handleWebAppDispatch(WebAppRequestDispatcher.java:1019)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.dispatch(WebAppRequestDispatcher.java:592)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.forward(WebAppRequestDispatcher.java:204)
at com.ibm.ws.webcontainer.srt.WebAppInvoker.doForward(WebAppInvoker.java:125)
at com.ibm.ws.webcontainer.srt.WebA
Re: Axis download links broken for versions 1.2.1 and 1.2RC3
Please see http://archive.apache.org/ On 7/27/06, Tom Sugden <[EMAIL PROTECTED]> wrote: Hello, I work on the OGSA-DAI project and our current release is compatible with Axis 1.2.1 and Axis 1.2RC3. In our installation guide we provide links to the Axis download pages, but unfortunately all the download links for these versions seem to be broken. See the links from these pages: http://www.apache.org/dyn/closer.cgi/ws/axis/1_2_1/ http://www.apache.org/dyn/closer.cgi/ws/axis/1_2RC3/ Is this a temporary problem or are these versions no longer distributed? Thank you, Tom Sugden - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Axis download links broken for versions 1.2.1 and 1.2RC3
Hello, I work on the OGSA-DAI project and our current release is compatible with Axis 1.2.1 and Axis 1.2RC3. In our installation guide we provide links to the Axis download pages, but unfortunately all the download links for these versions seem to be broken. See the links from these pages: http://www.apache.org/dyn/closer.cgi/ws/axis/1_2_1/ http://www.apache.org/dyn/closer.cgi/ws/axis/1_2RC3/ Is this a temporary problem or are these versions no longer distributed? Thank you, Tom Sugden - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (AXIS2-932) axis2 doesn't receive null values correctly
[ http://issues.apache.org/jira/browse/AXIS2-932?page=all ]
Deepal Jayasinghe reassigned AXIS2-932:
---
Assignee: Deepal Jayasinghe
> axis2 doesn't receive null values correctly
> ---
>
> Key: AXIS2-932
> URL: http://issues.apache.org/jira/browse/AXIS2-932
> Project: Apache Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: databinding
>Affects Versions: 1.0
> Environment: Java services (axis2) and .NET client.
>Reporter: Egor Samarkhanov
> Assigned To: Deepal Jayasinghe
>
> I created a simple service with the following method:
> public String[] testStringArrayWithNulls( String[] sarray )
> {
> return sarray;
> }
> Then I generated WSDL file (Java2WSDL) and got the following types in
> it:
>
>
>
>maxOccurs="unbounded"/>
>
>
>
>
>
>
>maxOccurs="unbounded"/>
>
>
>
> Then I added nillable="true" attribute manually to each item (to make .NET
> send
> nulls in SOAP), so the types are:
>
>
>
>maxOccurs="unbounded" nillable="true"/>
>
>
>
>
>
>
>maxOccurs="unbounded" nillable="true"/>
>
>
>
> Then I deployed this service and tested it with a simple .NET client
> that sends the following array (the operation is document/literal):
> [null, "str", null, "str", null]
> The SOAP message from .NET is as follows:
>
> http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";>
>
> http://org.apache.axis2/xsd";>
>
> str
>
> str
>
>
>
>
> But for some reason my service class gets:
> ["", "str", "", "str", ""]
> All null values in the array are replaced with empty strings :(
> =
> I also tried to return the same array (with nulls) form the method
> and axis made the following SOAP response:
>
> http://schemas.xmlsoap.org/soap/envelope/";>
>
>
> xmlns:ns="http://org.apache.axis2/xsd";>
>
>
> str
>
>
> str
>
>
>
>
>
> This response actually sends empty strings (and .NET client shows
> them). To me the correct SOAP response should be as follows:
>
> http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
>
>
> xmlns:ns="http://org.apache.axis2/xsd";>
>
> ssttrriinngg
>
> ssttrriinngg
>
>
>
>
> 1. Axis2 should correctly handle nulls in requests and responses (shouldn't
> replace them
>with empty strings).
> 2. Java2WSDL should add nillable="true" to Object array elements automatically
>(probably not only to Object[] but to any "nullable" type).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-936) Maven build fail for org.apache.axis2.jibx.Test
[ http://issues.apache.org/jira/browse/AXIS2-936?page=comments#action_12423820 ] Davanum Srinivas commented on AXIS2-936: it fails for me 100% of the time when i use JROCKIT 1.5. Basically i need to run it twice, first to compile the Customer/Person classes and then run maven again to run the tests. Otherwise it fails. It somehow picks up a undecorated (jibx uses BCEL to decorate the classes) Customer/Person in some jdk's. -- dims > Maven build fail for org.apache.axis2.jibx.Test > --- > > Key: AXIS2-936 > URL: http://issues.apache.org/jira/browse/AXIS2-936 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug > Components: samples, build,site & docs >Affects Versions: 1.0 > Environment: HP-UX B.11.11 U 9000/800; JDK 1.5.0.02 >Reporter: lo ti > > test:test: > [junit] Running org.apache.axis2.jibx.Test > [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 1.178 sec > [junit] [ERROR] TEST org.apache.axis2.jibx.Test FAILED > BUILD FAILED > File.. /sis/.maven/cache/maven-multiproject-plugin-1.3.1/plugin.jelly > Element... maven:reactor > Line.. 217 > Column 9 > Unable to obtain goal [multiproject:install-callback] -- > /sis/.maven/cache/maven-test-plugin-1.6.2/plugin.jelly:181:54: There > were test failures. > Total time: 7 minutes 8 seconds > Finished at: Wed Jul 26 17:16:28 CDT 2006 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-789) A SOAPFault targeted at a service (e.g. using WS-Addressing FaultTo) is not passed to the service object
[ http://issues.apache.org/jira/browse/AXIS2-789?page=comments#action_12423819 ] Davanum Srinivas commented on AXIS2-789: Eran, +1 from me FWIW, there was push back from Sanjiva (http://marc.theaimsgroup.com/?l=axis-dev&m=114912344830552&w=2) that led to this check (and throwing of exception). Let's see if he wants to chime in. thanks, dims > A SOAPFault targeted at a service (e.g. using WS-Addressing FaultTo) is not > passed to the service object > > > Key: AXIS2-789 > URL: http://issues.apache.org/jira/browse/AXIS2-789 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug > Components: core >Reporter: David Illsley > Assigned To: Deepal Jayasinghe >Priority: Minor > Attachments: patch.txt, patch2.txt, patch3.txt > > > A SOAPFault targeted at a service (e.g. using WS-Addressing FaultTo) is not > passed to the service object. It currently passes the message through the > InFaultFlow and then processing stops. This prevents Axis2 from being used to > host a 'FaultTo' service which processes faults generated in other services. > I have copied the invocation code from AxisEngine.receive() to > AxisEngine.receiveFault() and all unit tests continue to pass as well as > allowing the fault to be propagated to the service object. > Patch to follow momentarily -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-789) A SOAPFault targeted at a service (e.g. using WS-Addressing FaultTo) is not passed to the service object
[ http://issues.apache.org/jira/browse/AXIS2-789?page=comments#action_12423803 ] Eran Chinthaka commented on AXIS2-789: -- Ok, let me back off a bit :). Since the spec doesn't say how to understand the relatesTo, I'd rather not fault even if I can not understand the relatesTo with relationship type reply. Basically this comes down to the following. Addressing Handler sees the relatesTo id, and it tries to search for a operation and/or service context with that ID. If it finds that, fine go ahead. If not, just proceed, just printing an info statement, with no fault at all. IMO, this should not special case any MEP. > A SOAPFault targeted at a service (e.g. using WS-Addressing FaultTo) is not > passed to the service object > > > Key: AXIS2-789 > URL: http://issues.apache.org/jira/browse/AXIS2-789 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug > Components: core >Reporter: David Illsley > Assigned To: Deepal Jayasinghe >Priority: Minor > Attachments: patch.txt, patch2.txt, patch3.txt > > > A SOAPFault targeted at a service (e.g. using WS-Addressing FaultTo) is not > passed to the service object. It currently passes the message through the > InFaultFlow and then processing stops. This prevents Axis2 from being used to > host a 'FaultTo' service which processes faults generated in other services. > I have copied the invocation code from AxisEngine.receive() to > AxisEngine.receiveFault() and all unit tests continue to pass as well as > allowing the fault to be propagated to the service object. > Patch to follow momentarily -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
HowTo SandeshaClient.waitUntilSequenceCompleted
Hi, After calling my service, instead of using Thread.sleep(1000), I'm trying to use SandeshaClient.waitUntilSequenceCompleted(serviceClient). At runtime, this exception is thrown : org.apache.axis2.AxisFault: Default Sandesha Property Bean is not available What does that mean ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-789) A SOAPFault targeted at a service (e.g. using WS-Addressing FaultTo) is not passed to the service object
[ http://issues.apache.org/jira/browse/AXIS2-789?page=comments#action_12423802 ] David Illsley commented on AXIS2-789: - Well that line is the important one I agree that most web services start from a WSDL, with operations and associated MEPs. What I disagree with is the idea the the MEPs implemented by Axis2 are the only possible MEPs or that they are the only possible way that they can be implemented. I agree that an inbound message with a RelatesTo may be part of a request-response MEP, it's just that it started outside of Axis2 and may be triggering (or be a part of) a new MEP too. I disagree that this in any way introduces statefulness beyond that which axis2 already has. It simply enables the same state to be managed differently. Instead of it being held in an in-memory AxisOperation object it canbe stored away and retrieved which is far preferable for very long-running exchanges. (In terms of introducing statefulness reference parameters are far more guilty anway WS-RF anyone?) Anyway, as you said this has been discussed on the list. If you want to continue the discussion I suggest we move back there. David > A SOAPFault targeted at a service (e.g. using WS-Addressing FaultTo) is not > passed to the service object > > > Key: AXIS2-789 > URL: http://issues.apache.org/jira/browse/AXIS2-789 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug > Components: core >Reporter: David Illsley > Assigned To: Deepal Jayasinghe >Priority: Minor > Attachments: patch.txt, patch2.txt, patch3.txt > > > A SOAPFault targeted at a service (e.g. using WS-Addressing FaultTo) is not > passed to the service object. It currently passes the message through the > InFaultFlow and then processing stops. This prevents Axis2 from being used to > host a 'FaultTo' service which processes faults generated in other services. > I have copied the invocation code from AxisEngine.receive() to > AxisEngine.receiveFault() and all unit tests continue to pass as well as > allowing the fault to be propagated to the service object. > Patch to follow momentarily -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-789) A SOAPFault targeted at a service (e.g. using WS-Addressing FaultTo) is not passed to the service object
[ http://issues.apache.org/jira/browse/AXIS2-789?page=comments#action_12423800 ] Eran Chinthaka commented on AXIS2-789: -- Hi, +1 for the patch, except for the if (null == msgContext.getRelatesTo() || !(this instanceof OutInAxisOperation)) part in AxisOperation.java. I think its incorrect if you do not throw an error here. I know there was a thread on this, but let me explain what I feel. Web services normally starts from a WSDL. It defines operations and operations have MEPs and messages. So messages have something to do with a MEP. Even though WS-A doesn't define anything about the content of the relatesTo, I feel its a hole in the spec itself. What I feel is, a message better not contain a relatesTo value which has a message id of a message which is not in the current MEP. One more point, web services. by definition are stateless. If we let this message to refer to a message outside the MEP, then I feel its an attempt to have some statefulness. -- Chinthaka > A SOAPFault targeted at a service (e.g. using WS-Addressing FaultTo) is not > passed to the service object > > > Key: AXIS2-789 > URL: http://issues.apache.org/jira/browse/AXIS2-789 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug > Components: core >Reporter: David Illsley > Assigned To: Deepal Jayasinghe >Priority: Minor > Attachments: patch.txt, patch2.txt, patch3.txt > > > A SOAPFault targeted at a service (e.g. using WS-Addressing FaultTo) is not > passed to the service object. It currently passes the message through the > InFaultFlow and then processing stops. This prevents Axis2 from being used to > host a 'FaultTo' service which processes faults generated in other services. > I have copied the invocation code from AxisEngine.receive() to > AxisEngine.receiveFault() and all unit tests continue to pass as well as > allowing the fault to be propagated to the service object. > Patch to follow momentarily -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-548) [Axis2] Documentation for Session Mgt
[ http://issues.apache.org/jira/browse/AXIS2-548?page=comments#action_12423798 ] Eran Chinthaka commented on AXIS2-548: -- This patch is for Axis2 0_95 folder which is not in the code base anymore. I do not see this in 1_0 folder. Rajith, is tihs document still valid. If yes, can you please add an up-to-date patch. > [Axis2] Documentation for Session Mgt > - > > Key: AXIS2-548 > URL: http://issues.apache.org/jira/browse/AXIS2-548 > Project: Apache Axis 2.0 (Axis2) > Issue Type: New Feature > Components: samples, build,site & docs >Affects Versions: 0.95 >Reporter: Rajith Attapattu > Attachments: session_doc.patch > > > Attached is the documentation for session mgt. > Please apply the from xdocs folder. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-936) Maven build fail for org.apache.axis2.jibx.Test
[ http://issues.apache.org/jira/browse/AXIS2-936?page=comments#action_12423797 ] Eran Chinthaka commented on AXIS2-936: -- I just test the build in JDK 1.4 and JDK 1.5. I got the build successful. Can u please re-check and comment on this? > Maven build fail for org.apache.axis2.jibx.Test > --- > > Key: AXIS2-936 > URL: http://issues.apache.org/jira/browse/AXIS2-936 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug > Components: samples, build,site & docs >Affects Versions: 1.0 > Environment: HP-UX B.11.11 U 9000/800; JDK 1.5.0.02 >Reporter: lo ti > > test:test: > [junit] Running org.apache.axis2.jibx.Test > [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 1.178 sec > [junit] [ERROR] TEST org.apache.axis2.jibx.Test FAILED > BUILD FAILED > File.. /sis/.maven/cache/maven-multiproject-plugin-1.3.1/plugin.jelly > Element... maven:reactor > Line.. 217 > Column 9 > Unable to obtain goal [multiproject:install-callback] -- > /sis/.maven/cache/maven-test-plugin-1.6.2/plugin.jelly:181:54: There > were test failures. > Total time: 7 minutes 8 seconds > Finished at: Wed Jul 26 17:16:28 CDT 2006 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-748) AARWSDLLocator incorrect logic - may load incorrect files under certain scenarios
[ http://issues.apache.org/jira/browse/AXIS2-748?page=all ]
Deepal Jayasinghe resolved AXIS2-748.
-
Resolution: Fixed
Fixed in current SVN
> AARWSDLLocator incorrect logic - may load incorrect files under certain
> scenarios
> -
>
> Key: AXIS2-748
> URL: http://issues.apache.org/jira/browse/AXIS2-748
> Project: Apache Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: deployment
>Affects Versions: 1.0
> Environment: win32_x86 (windows xp sp2), tomcat 5.1, eclipse 3.2 with
> tomcat plugin, axis 2.0 1.0, Intel P4 2.8Ghz, 2.00GB RAM
>Reporter: Dave MacLean
> Assigned To: Deepal Jayasinghe
>Priority: Minor
>
> The following code in AARWSDLLocator.java will fail in a certain scenario
> (described below):
> ...
> while ((entry = zin.getNextEntry()) != null) {
> String entryName = entry.getName();
> if
> ((entryName.startsWith(DeploymentConstants.META_INF.toLowerCase())
> || entryName.startsWith(DeploymentConstants.META_INF))
> && entryName.endsWith(importLocation)) {
> ...
> If I have a wsdl file that has an import like:
>
> And then, in my aar file, I have the files:
> META-INF/xsd/some_namespace.xsd
> META-INF/some_bad_other_xsd/some_namespace.xsd
> The locator seems to try and load both files. At the very least, the if
> condition is met, and later down the line, an XMLSchemaException is thrown as
> follows:
> Error: org.apache.axis2.deployment.DeploymentException:
> java.lang.RuntimeException: org.apache.ws.commons.schema.XmlSchemaException:
> No namespace found in given base simple content type
> If you remove the excess xsd file, the problem goes away. So...I think the
> if statement here needs to be fixed to not include directories that happen to
> end with the import location.
> Marking as minor since I can change my directory strutcure, but would be
> major for someone who was unable to change the stucture of their files.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2]: SimpleHTTPServer port
Hi, Thanks I will try this. Deepal Jayasinghe wrote: Hi Jean; The best way is - First create configuration context - Then create serviceClient / ServiceClients using that - And use the those serviceClient to invoke the service - In that case you wont get any exception PS: Try to share same configurationContext across all the service client Jean-Michel PATER wrote: When you are using dual transport with HTTP transport can you use this feature or the server port can't be specified ? Saminda Abeyruwan wrote: SimpleHTTPServer default port is set to 8080. If you want to open multiple SHTTPServers, then you have to provide the args with -p. Ex: SimpleHTTPServer -p9762 /tmp/repo to start SHTTPS on port 9762 with /tem/repo repository and default axis2.xml Saminda Jaliya Ekanayake wrote: Resending with [Axis2] prefix. - Original Message - From: "Jean-Michel PATER" <[EMAIL PROTECTED]> To: Sent: Wednesday, July 26, 2006 11:46 AM Subject: SimpleHTTPServer port Hi all, How can I dynamically modify the SimpleHTTPServer port number. I want to call simultaneously several web services but I get the following exception : org.apache.axis2.transport.http.SimpleHTTPServer - java.net.BindException: Address already in use For now, the port is define in webapps/axis2/WEB-INF/conf/axis2.xml. Can I modify this port at runtime in order to have several simpleHTTPServer at the same time ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jean-Michel PATER <[EMAIL PROTECTED]> Cogenit Tél : +33 (0) 1 40 20 08 43 53 rue Sainte Anne Fax : +33 (0) 1 40 20 08 45 75002 Paris -- Jean-Michel PATER <[EMAIL PROTECTED]> Cogenit Tél : +33 (0) 1 40 20 08 43 53 rue Sainte Anne Fax : +33 (0) 1 40 20 08 45 75002 Paris
Re: [Axis2]: SimpleHTTPServer port
Hi Jean; The best way is - First create configuration context - Then create serviceClient / ServiceClients using that - And use the those serviceClient to invoke the service - In that case you wont get any exception PS: Try to share same configurationContext across all the service client Jean-Michel PATER wrote: > When you are using dual transport with HTTP transport can you use this feature or the server port can't be specified ? > > Saminda Abeyruwan wrote: > > SimpleHTTPServer default port is set to 8080. If you want to open > multiple SHTTPServers, then you have to provide the args with -p. > > Ex: SimpleHTTPServer -p9762 /tmp/repo > > to start SHTTPS on port 9762 with /tem/repo repository and default > axis2.xml > > Saminda > > Jaliya Ekanayake wrote: > > > >Resending with [Axis2] prefix. > >- Original Message - From: "Jean-Michel PATER" <[EMAIL PROTECTED]> > >To: > >Sent: Wednesday, July 26, 2006 11:46 AM > >Subject: SimpleHTTPServer port > > > > > >>Hi all, > > >>How can I dynamically modify the SimpleHTTPServer port number. I want > >>to call simultaneously several web services but I get the following > >>exception : > > >> > > >>>org.apache.axis2.transport.http.SimpleHTTPServer - > >>>java.net.BindException: Address already in use > >>> > >>> > >>For now, the port is define in webapps/axis2/WEB-INF/conf/axis2.xml. > >>Can I modify this port at runtime in order to have several > >>simpleHTTPServer at the same time ? > > > >>- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > > >> > > >- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] >-- >Jean-Michel PATER <[EMAIL PROTECTED]> >Cogenit Tél : +33 (0) 1 40 20 08 43 >53 rue Sainte Anne Fax : +33 (0) 1 40 20 08 45 >75002 Paris http://www.cogenit.fr> -- Thanks, Deepal ~Future is Open~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2]: SimpleHTTPServer port
When you are using dual transport with HTTP transport can you use this feature or the server port can't be specified ? Saminda Abeyruwan wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 SimpleHTTPServer default port is set to 8080. If you want to open multiple SHTTPServers, then you have to provide the args with -p. Ex: SimpleHTTPServer -p9762 /tmp/repo to start SHTTPS on port 9762 with /tem/repo repository and default axis2.xml Saminda Jaliya Ekanayake wrote: Resending with [Axis2] prefix. - Original Message - From: "Jean-Michel PATER" <[EMAIL PROTECTED]> To: Sent: Wednesday, July 26, 2006 11:46 AM Subject: SimpleHTTPServer port Hi all, How can I dynamically modify the SimpleHTTPServer port number. I want to call simultaneously several web services but I get the following exception : org.apache.axis2.transport.http.SimpleHTTPServer - java.net.BindException: Address already in use For now, the port is define in webapps/axis2/WEB-INF/conf/axis2.xml. Can I modify this port at runtime in order to have several simpleHTTPServer at the same time ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEx6jYYmklbLuW6wYRAmxqAKDF6T3vys+gGjjVPRMnrPfkVrK5FwCcC8eX Al086jcqYR1I9hX/iTeJwJ4= =UzLy -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jean-Michel PATER <[EMAIL PROTECTED]> Cogenit Tél : +33 (0) 1 40 20 08 43 53 rue Sainte Anne Fax : +33 (0) 1 40 20 08 45 75002 Paris
