[jira] Commented: (AXIS2-1252) java2wsdl generates unknown namespace
[ http://issues.apache.org/jira/browse/AXIS2-1252?page=comments#action_12441357 ] Venkatakrishnan commented on AXIS2-1252: Hi Dims, My understanding of the 'stn' option is that it is to be used as the namespace for the schema definitions of the wsdl types i.e. the types that are generated for the message parts. It so happened earlier that all data types would get pushed into this namespace i.e. even the ones that represented the arguments and return types in the service methods. My personal opinion of this is that it is not clean but just about convenient. However I am not sure how acceptable this has become in practice in the webservices world so much so this is getting to be absorbed as the right thing to do. I would just about prefer the following: - - the 'stn' be left alone as it is to specify the namespace for the wsdl types. We don't try to mix this mix this option up. - support the following for namespace generation for all other types - if there is a 'package to namespace' mapping that is provided (or input) then use that mapping for the relevant packages. The format for this can be either -nsMap[pkg1=ns1, pk2=ns2] OR -nsMap pkg1=ns1 -nsMap pkg2=ns2 and so on. I am open to also any other way of doing this. - wherever there is no package to namespace mapping specified then the namespace will be generated based on the package name. For this we can probably provide little more flexibility by allowing users to overide the way a package name is converted to a namespace. i.e a user who'd want to generate namespaces from package names using some other scheme may simply implement an interface and provide that implementation class as input. The generator will then call this implementation for namespace generation. I am not at all comfortable with have all types in a single namespace by default. If we had a scheme by which we assign types to namespaces then we have a consistent way getting back whatever we started from if we did a wsdl2java. If you are taken aback by this perspective of mine, then I am surely missing something here... please help me get that :) Thanks. - Venkat > java2wsdl generates unknown namespace > - > > Key: AXIS2-1252 > URL: http://issues.apache.org/jira/browse/AXIS2-1252 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Improvement > Components: wsdl >Reporter: Kinichiro Inoguchi >Priority: Blocker > > This issue comes from user mailing list. > http://marc.theaimsgroup.com/?t=11593771594&r=1&w=2 > java2wsdl generates unknown namespace, "http://test/xsd";. > I'm using current nightly. > My service class has method "sayHello", > and returns array of simple java beans "HelloBean". > Then I run java2wsdl, sayHello and sayHelloResponse > are in namespace "http://aaa.bbb/types";. > But, HelloBean is in unknown namespace "http://test/xsd";. > Is this a bug ? > C:\axis2-std-SNAPSHOT-bin\bin\java2wsdl.bat > -cn test.TestService1 -cp . > -tn http://aaa.bbb -tp xxx > -stn http://aaa.bbb/types -stp yyy > -sn TestService1 -of TestService1.wsdl > generated WSDL is like this; > http://schemas.xmlsoap.org/wsdl/soap12/"; > xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"; > xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"; > xmlns:ns1="http://aaa.bbb/types"; xmlns:xxx="http://aaa.bbb"; > xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"; > xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"; > targetNamespace="http://aaa.bbb";> > > http://www.w3.org/2001/XMLSchema"; > xmlns:ax22="http://test/xsd"; targetNamespace="http://test/xsd"; > attributeFormDefault="qualified" elementFormDefault="qualified"> > > > > > > > > > > > > > > http://www.w3.org/2001/XMLSchema"; > xmlns:gen798="http://test/xsd"; xmlns:ax21="http://aaa.bbb/types"; > targetNamespace="http://aaa.bbb/types"; attributeFormDefault="qualified" > elementFormDefault="qualified"> > > > > > > > > > > > > > > > > >type="gen798:HelloBean" nillable="true" /> > > > > > > ... -- 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 PRO
RE: WS Addressing :: Issue with setting ReplyTo :: Axis2-1.1-SNAPSHOT
Hi, Thanks for the prompt reply Eran, this issue was resolved yesterday after a suggestion by Brian, that in such a scenario we should use fireandforget instead of sendrecievenonblocking and this worked for meand that comes out to be the same tht you have suggested :-) thanks newayz. Regards, Vaibhav -Original Message- From: Eran Chinthaka [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 11, 2006 12:35 AM To: axis-dev@ws.apache.org Subject: Re: WS Addressing :: Issue with setting ReplyTo :: Axis2-1.1-SNAPSHOT I answered this question couple of time, but let me try again. If you invoke send-receive from your client then your response *must* come to it and Axis2 engine helps you to do that by starting up the proper listeners. What you could have done was invoke one way and put your replyTo. Even if you are invoking an IN-OUT service, for your clients it is just IN-Only as it won't receive a response. But there was a valid scenario, actually pointed out by Chamikara, that some might want to get his replies through a proxy like tcp-mon. Yes in that case, you might want to override the replyTo value. I can remember Chamikara was talking about this but not sure whether he implemented it. Chamikara, you wanna add something here? -- Chinthaka Vaibhav Pandey wrote: > Hi All, > I am trying to explore WS Addressing by creating a flow in which i call a WS > (INOUT-with NonBlockingDual client) and then i want the response to be > directed to another WS on a different port and server. I have explicitly set > the To/ReplyTo in my client. In the resluting SOAP request the wsa:To > parmeter gets set based on what i mentioned but somehow the wsa:ReplyTo is > set to the default listener address !! > > I have also set:: > options.setProperty(AddressingConstants.REPLACE_ADDRESSING_HEADERS, > Boolean.TRUE) > and then am setting replyto as :: options.setTo(targetEPR); > > options.setReplyTo(targetReplyEPR); > > options.setTransportInProtocol(Constants.TRANSPORT_HTTP); > > i also tried :: > options.setProperty(AddressingConstants.WSA_REPLY_TO, targetReplyEPR); > > but what i found after looking at the source code was that in the message > context itself the replyTo address is set to default whereas the To address > is set based on what i mentioned. > > Kindly guide me as to what am i supposed to do. > > > Regards, > Vaibhav > > > > - > 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] Created: (AXIS2-1341) Cannot disengage a globally engaged module
Cannot disengage a globally engaged module -- Key: AXIS2-1341 URL: http://issues.apache.org/jira/browse/AXIS2-1341 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Affects Versions: 1.1 Environment: Windows XP, jdk1.5.0_08, Mozilla Firefox 1.5.0.6, Apache Tomcat 5.5.16 Reporter: Charitha Kankanamge Priority: Critical Globally engaged module cannot be disengaged from a service. A blank screen appears when clicking on 'Disengage' link and module is not disengaged. Steps to reproduce: === 1. Log in to Axis2 admin console 2. Check globally engaged modules by clicking on 'Globally Engaged Modules' hyperlink 3. Click on 'Available Services' in the left pane 4. Click on 'Disengage' link to disengage a module from the service Issue: = A blank screen appears. Module is not disengaged from the service -- 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-1336) Code Generation Exception occurred when Generating stubs
[ http://issues.apache.org/jira/browse/AXIS2-1336?page=all ] Evanthika Amarasiri updated AXIS2-1336: --- Attachment: CommodityQuote.wsdl Wsdl File used to generate the stub > Code Generation Exception occurred when Generating stubs > > > Key: AXIS2-1336 > URL: http://issues.apache.org/jira/browse/AXIS2-1336 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug >Affects Versions: 1.1 > Environment: Windows XP, jdk1.5.0_08, Maven 1.0.2, Mozilla Firefox > 1.5.0.6 >Reporter: Evanthika Amarasiri >Priority: Critical > Attachments: CommodityQuote.wsdl > > > 1. Tried to create a stub using the following command > wsdl2java.bat -uri \wsdl\CommodityQuote.wsdl -p com.wso2.tungsten.client -d > adb -u true -t -uw true > 2. The following exception occured > Exception in thread "main" > org.apache.axis2.wsdl.codegen.CodeGenerationException: > org.apache.axis2.wsdl.codegen.CodeGenerationException: Unsupported S > chema format for unwrapping! found unknown but expected sequence > at > org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224) > at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:32) > at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:21) > Caused by: org.apache.axis2.wsdl.codegen.CodeGenerationException: Unsupported > Schema format for unwrapping! found unknown but expected sequence > at > org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.processXMLSchemaSequence(SchemaUnwrapperExtension.java:287) > at > org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.handleAllCasesOfComplexTypes(SchemaUnwrapperExtension.java:164) > at > org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.walkSchema(SchemaUnwrapperExtension.java:122) > at > org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.engage(SchemaUnwrapperExtension.java:87) > at > org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:177) > ... 2 more -- 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-1333) InvocationTargetException thrown when accessing 'Engage Module For a Service' page in Axis2 admin console
[ http://issues.apache.org/jira/browse/AXIS2-1333?page=all ] Davanum Srinivas resolved AXIS2-1333. - Resolution: Fixed Charitha, fixed in r462694 (branch 1.1). Can u please try this? thanks, dims PS: Make sure your completely remove the work directory under tomcat before you start tomcat (each time!) for better testing. It caches the generated files (from jsp) in that directory. > InvocationTargetException thrown when accessing 'Engage Module For a Service' > page in Axis2 admin console > - > > Key: AXIS2-1333 > URL: http://issues.apache.org/jira/browse/AXIS2-1333 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug >Affects Versions: 1.1 > Environment: Windows XP, jdk1.5.0_08, Mozilla Firefox 1.5.0.6, > Apache Tomcat 5.5.16 >Reporter: Charitha Kankanamge > Attachments: stacktrace.txt > > > System returns HTTP 500 error with the follwoing exception in the logs when > accessing 'Engage Module For a Service' page in Axis2 admin console. > Oct 10, 2006 12:47:36 PM org.apache.axis2.transport.http.AbstractAgent handle > WARNING: Error dispatching request /axis2/axis2-admin/engageToService > java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. > java:39) > > Please note that this issue exists in Windows XP environment only. > Steps to reproduce: > > 1. Deploy Axis2.war from the axis2-std-1.1-RC1 distribution > 2. Access the admin console > 3. Click on 'For a Service' link under the 'Engage Module' in the left pane > Issue: > == > HTTP 500 error is shown to the user. > Complete stack trace is attached here with. -- 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-2541) Deserializing dates in attributes
[
http://issues.apache.org/jira/browse/AXIS-2541?page=comments#action_12441342 ]
Christian Phan-Trong commented on AXIS-2541:
I have exactly the same issue. I Took a look at similar issues in Jira, and it
seems like this one is a recurrent one. The same problem is reported in
AXIS-2115 and some very intersting comments can also be found in AXIS-1050. I
still didn't solve the issue though.
> Deserializing dates in attributes
> -
>
> Key: AXIS-2541
> URL: http://issues.apache.org/jira/browse/AXIS-2541
> Project: Apache Axis
> Issue Type: Bug
>Affects Versions: 1.2.1, 1.4
> Environment: JDK1.5, Windows, Axis 1.2.1 and 1.4
>Reporter: Michael Becke
>
> Dates are not correctly deserialized when used as in the following WSDL:
>
>xmlns="http://schemas.xmlsoap.org/wsdl/";
> xmlns:xs="http://www.w3.org/2001/XMLSchema";
> targetNamespace="http://ws.apache.org/test";
> xmlns:tns="http://ws.apache.org/test";
> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";
> >
>
> targetNamespace="http://ws.apache.org/test";
> xmlns:tns="http://ws.apache.org/test";
> xmlns:xs="http://www.w3.org/2001/XMLSchema";
> elementFormDefault="qualified">
>
>
>
>type="tns:DateValueType" minOccurs="1" maxOccurs="1" />
>
>
>
>
>
>
>
>
>
>
>minOccurs="1" maxOccurs="1" />
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> transport="http://schemas.xmlsoap.org/soap/http"/>
>
>http://ws.apache.org"/>
>
>
>
>
>
>
>
>
>
>
>
>http://localhost/axis/ws/TestService"/>
>
>
>
> I am using WSDL2Java to gerate the client/server for this service. Once
> generated and installed, calling the service produces the following exception:
> AxisFault
> faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
> faultSubcode:
> faultString: java.lang.NumberFormatException: For input string:
> "2006-08-16"
> faultActor:
> faultNode:
> faultDetail:
> {http://xml.apache.org/axis/}hostname:mbecke
> java.lang.NumberFormatException: For input string: "2006-08-16"
> at
> org.apache.axis.message.SOAPFaultBuilder.createFault(SOAPFaultBuilder.java:222)
> at
> org.apache.axis.message.SOAPFaultBuilder.endElement(SOAPFaultBuilder.java:129)
> at
> org.apache.axis.encoding.DeserializationContext.endElement(DeserializationContext.java:1087)
> at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> at javax.xml.parsers.SAXParser.parse(SAXParser.java:375)
> at
> org.apache.axis.encoding.DeserializationContext.parse(DeserializationContext.java:227)
> at org.apache.axis.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:696)
> at org.apache.axis.Message.getSOAPEnvelope(Message.java:435)
> at
> org.apache.axis.handlers.soap.MustUnderstandChecker.invoke(MustUnderstandChecker.java:62)
> at org.apache.axis.client.AxisClient.invoke(AxisClient.java:206)
> at org.apache.axis.client.Call.invokeEngine(Call.java:2784)
> at org.apache.axis.client.Call.invoke(Call.java:2767)
> at org.apache.axis.client.Call.invoke(Call.java:2443)
> at org.apache.axis.client.Call.invoke(Call.java:2366)
> at org.apache.axis.client.Call.invoke(Call.java:1812)
> at axis.test.TestSoapBindingStub.testDates(TestSoapBindingStub.java:171)
> at info.ppr.compass.AxisTest.testSendDates(AxisTest.java:93)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcc
[jira] Assigned: (AXIS2-1163) replace service endpoint when serving original wsdl using useOriginalwsdl param
[ http://issues.apache.org/jira/browse/AXIS2-1163?page=all ] Davanum Srinivas reassigned AXIS2-1163: --- Assignee: Eran Chinthaka > replace service endpoint when serving original wsdl using useOriginalwsdl > param > --- > > Key: AXIS2-1163 > URL: http://issues.apache.org/jira/browse/AXIS2-1163 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Improvement >Affects Versions: 1.0 >Reporter: rajesh > Assigned To: Eran Chinthaka >Priority: Blocker > > I've used the recently added useOriginalwsdl attribute to services.xml to > serve the wsdl from META-INF (and thanks for the fix). It would be nice to > just replace the endpoint address using the request url and context when > serving the original wsdl. -- 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-1340) Axis2Util.toOM() needs to work w/o XML-Security jar
[ http://issues.apache.org/jira/browse/AXIS2-1340?page=all ] Davanum Srinivas resolved AXIS2-1340. - Resolution: Fixed Looks like this is fixed: http://marc.theaimsgroup.com/?l=axis-cvs&m=116052397203244&w=2 http://svn.apache.org/viewvc?view=rev&rev=462640 > Axis2Util.toOM() needs to work w/o XML-Security jar > --- > > Key: AXIS2-1340 > URL: http://issues.apache.org/jira/browse/AXIS2-1340 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Improvement > Components: om > Environment: Any >Reporter: Sathija Pavuluri >Priority: Minor > > When converting a DOM element to OMElement, the process is not > straightforward. > We first need to use the org.apache.rampart.util.Axis2Utils.toOM() from > axis2-security-SNAPSHOT.jar. > The toOM() method references the org.apache.xml.security.utils.XMLUtils class > from xml-security jar file. > So one needs to include that jar in the classpath. > And then this error is seen: > > org.apache.xml.security.c14n.InvalidCanonicalizerException: You must > > initialize the xml-security library correctly before you use it. Call the > > static method "org.apache.xml.security.Init.init();" to do that before you > > use any functionality from that library. > > at org.apache.xml.security.c14n.Canonicalizer.(Unknown Source) > > at org.apache.xml.security.c14n.Canonicalizer.getInstance(Unknown > > Source) > > at org.apache.xml.security.utils.XMLUtils.outputDOM(Unknown Source) > > at org.apache.rampart.util.Axis2Util.toOM(Axis2Util.java:176) > To fix this, I have had to call org.apache.xml.security.Init.init(); in my > class before invoking Axis2Utils.toOM(). > This is rather cumbersome. It would be nice if the axis2-security was > packaged so that the xml-security jar need not be imported. > Or the toOM() method needs to correctly initialize the xml-security jar. -- 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: svn commit: r462672 - in /webservices/axis2/branches/java/1_1/modules: integration/maven.xml kernel/conf/axis2.xml
I dont' remember that. I do remember this:
http://marc.theaimsgroup.com/?l=axis-dev&m=115869598518264&w=2
which was, that If mtom enabled is on, then we always use mime stuff
whether there is an attachment or not.
-- dims
On 10/10/06, Thilina Gunarathne <[EMAIL PROTECTED]> wrote:
Ahh... My bad.. I thought I removed all the references to
kernel/conf/axis2.xml...
Regarding the MIME issue, i thought we came to a decision to switch
"on" MTOM by default... Anyway I'm fine with either...
~Thilina
On 10/11/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Author: dims
> Date: Tue Oct 10 19:53:17 2006
> New Revision: 462672
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=462672
> Log:
> Fix for Problem mentioned here:
> http://marc.theaimsgroup.com/?l=axis-dev&m=116052679312513&w=2
>
> We should not be generating MIME stuff for non-mtom requests, fails miserably
for non-Axis2 clients. Also removed references to kernel/conf/axis2.xml from the
maven.xml in integration.
>
> Thilina, Could you please review and verify this change?
>
>
> Modified:
> webservices/axis2/branches/java/1_1/modules/integration/maven.xml
> webservices/axis2/branches/java/1_1/modules/kernel/conf/axis2.xml
>
> Modified: webservices/axis2/branches/java/1_1/modules/integration/maven.xml
> URL:
http://svn.apache.org/viewvc/webservices/axis2/branches/java/1_1/modules/integration/maven.xml?view=diff&rev=462672&r1=462671&r2=462672
> ==
> --- webservices/axis2/branches/java/1_1/modules/integration/maven.xml
(original)
> +++ webservices/axis2/branches/java/1_1/modules/integration/maven.xml Tue Oct
10 19:53:17 2006
> @@ -1030,22 +1030,22 @@
>
>
tofile="target/Repository/modules/addressing-${addressing_version}.mar"/>
> - +tofile="target/Repository/conf/axis2.xml"/>
>
>
>
>
> -+ tofile="target/perf2/build/repo/conf/axis2.xml"/>
> - + tofile="target/perf/build/repo/conf/axis2.xml"/>
>
> -
> +
>
tofile="target/perf2/build/repo/modules/addressing-${addressing_version}.mar"/>
>
> -
> +
>
tofile="target/perf/build/repo/modules/addressing-${addressing_version}.mar"/>
>
>
> Modified: webservices/axis2/branches/java/1_1/modules/kernel/conf/axis2.xml
> URL:
http://svn.apache.org/viewvc/webservices/axis2/branches/java/1_1/modules/kernel/conf/axis2.xml?view=diff&rev=462672&r1=462671&r2=462672
> ==
> --- webservices/axis2/branches/java/1_1/modules/kernel/conf/axis2.xml
(original)
> +++ webservices/axis2/branches/java/1_1/modules/kernel/conf/axis2.xml Tue Oct
10 19:53:17 2006
> @@ -4,7 +4,7 @@
>
> true
> false
> -true
> +false
> false
>
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
http://webservices.apache.org/~thilina/
http://thilinag.blogspot.com/
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [axis2] Spring support broken ?????
Its late here so I'll take a look tomorrow. In the meantime, the
reason why this wasn't caught is because I'm not sure how to get a
ServletContext from our testing environment or if its even possible.
There are tests for the non-servlet container config. If someone knows
how to test the former case please post to the list. I've been mostly
focused on the latter lately, ie, non-servletContext config inside the
AAR.
Thanks for catching that Rajith.
Robert
On 10/10/06, Rajith Attapattu <[EMAIL PROTECTED]> wrote:
Forwarding with the axis2 prefix.
-- Forwarded message --
From: Rajith Attapattu <[EMAIL PROTECTED] >
Date: Oct 10, 2006 10:17 PM
Subject: Re: Spring support broken ?
To: axis-dev@ws.apache.org
Cc: [EMAIL PROTECTED]
Hi All,
The current spring support fails with the following exception possibly due
to the new code change of obtaining the servlet config from the
AxisConfiguration instead from the Message Context.
Caused by: org.apache.axis2.AxisFault: Axis2 Can't find ServletConfig;
nested exception is:
java.lang.Exception: Axis2 Can't find ServletConfig
at
org.apache.axis2.AxisFault.makeFault(AxisFault.java:318)
at
org.apache.axis2.extensions.spring.receivers.SpringServletContextObjectSupplier.getServiceObject(SpringServletContextObjectSupplier.java:70)
... 43 more
Caused by: java.lang.Exception: Axis2 Can't find ServletConfig
at
org.apache.axis2.extensions.spring.receivers.SpringServletContextObjectSupplier.getServiceObject(SpringServletContextObjectSupplier.java:53)
... 43 more
Now when I look at the code I see that at revesion 426884 the code was
obtaining the servlet config from the msgContext.
servletContext servletContext = (ServletContext) msgContext.getOptions().
getProperty(HTTPConstants.MC_HTTP_SERVLETCONTEXT);
However the head revision was obtaining the servlet config via the
AxisConfiguration.
ServletConfig servletConfig = (ServletConfig)
axisService.getAxisConfiguration()
.getParameter(HTTPConstants.HTTP_SERVLETCONFIG);
if (servletConfig == null) {
throw new Exception("Axis2 Can't find ServletConfig");
}
Why did we make the change ??? If we did so are we making sure that we
populate the AxisConfiguration with the servlet config ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Summery of todays Hackathon
SanjivaI also agree on your comments regarding the operation client.Now about the whole session/clustering thing. You mention that outside of Axis2 the concept of Service Group does not exist !!!So a client would expect to interact with Services from two Service Groups in a single session.
Thats the reason why I proposed a WS-Addressing or WS-Context
based approach which has a notion of session outside the context
heirachy and spans ServiceGroups. It's a lot more simple than ServiceGroupContext.getEPRForService
("serviceName") to propogate information.Why
can't we have a single lightweight mechanism to share "application
data" among services without all the hassel of being tied down to
the context heirachy.
However we still need to replicate Service Context and
ServiceGroupContext as there maybe axis2 specific operational data that
needs to available to service the client properly.I hear your argument about isolation at Service and Service Group level. But I think it should be limited to operational data.
For business data we should be able to share across Services that spans serveral Service Groups if the user chooses to do so.Comments are welcomed !!Regards,Rajith
On 10/10/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:
On Tue, 2006-10-10 at 17:54 -0500, Deepal Jayasinghe wrote:> Why do we need operation client ???? You gotta be kidding.We have it because that's the client API for a generic MEP.> As Dennis suggested , having annon name as public static seems not that
> good , so we need to remove them I mean we need to make the private.Sorry I don't understand what you're referring to. If its the constantswe used to make the simple API work then I don't agree there's any
problem.> Rather than giving two client API to client cant we have one API , we> can have all the methods in serviceClient then no one need to know about> the operationClient (service client will use that internally ). So our
> proposal is to add few more methods into ServiceCleint;>> public MessageContext sendReceive(MessageContext req){}> public void sendReceiveNonBlocking(MessageContext req){}> public fireAndForget(MessageContext req){}
> public sendRobust(MessageContext req){}This only works for the 4 built-in MEPs. Have we decided to narrow Axis2down to the built in MEPs? If so half of the machinery in Axis2 can beremoved.
> if we introduce these methods into ServiceClient then we do not too much> worry about how to create operationClient etc...>> I am +1 on adding these four methods in to serviceClient.Sorry, I'm -1 to this change. No way. It fundamentally breaks the client
APIIf you want to do this then in the minimum it has to be after 1.1. Noway we're going to change the client API after RC1 has been cut!> ===> How do we reflect service group concept in to client , and manage
> session using that. Well I do understand if we use Axis2 client <->> Axis2 service this will work , but what if we use .Net client <-> Axis2> Service. Is there any kind of specification sending session related data
> in SOAP message ? , if there is such a thing then we need to use them.You're forgetting a design decision we made a while ago: to make theservice group concept not visible to the outside. That's why we said
services withing group become top level services. I was against it butthat's what we decided. As such there's no need to expose it to theclient.What will be useful is for one service in a group to be able to get the
EPR of another service in a group. Something likeServiceGroupContext.getEPRForService ("serviceName"). That can propagatethe contextID etc. so that they share the same interaction session.Sanjiva.
-To unsubscribe, e-mail: [EMAIL PROTECTED]For additional commands, e-mail:
[EMAIL PROTECTED]
Re: [Axis2] Summery of todays Hackathon
On Tue, 2006-10-10 at 17:54 -0500, Deepal Jayasinghe wrote:
> Why do we need operation client ?
??? You gotta be kidding.
We have it because that's the client API for a generic MEP.
> As Dennis suggested , having annon name as public static seems not that
> good , so we need to remove them I mean we need to make the private.
Sorry I don't understand what you're referring to. If its the constants
we used to make the simple API work then I don't agree there's any
problem.
> Rather than giving two client API to client cant we have one API , we
> can have all the methods in serviceClient then no one need to know about
> the operationClient (service client will use that internally ). So our
> proposal is to add few more methods into ServiceCleint;
>
> public MessageContext sendReceive(MessageContext req){}
> public void sendReceiveNonBlocking(MessageContext req){}
> public fireAndForget(MessageContext req){}
> public sendRobust(MessageContext req){}
This only works for the 4 built-in MEPs. Have we decided to narrow Axis2
down to the built in MEPs? If so half of the machinery in Axis2 can be
removed.
> if we introduce these methods into ServiceClient then we do not too much
> worry about how to create operationClient etc...
>
> I am +1 on adding these four methods in to serviceClient.
Sorry, I'm -1 to this change. No way. It fundamentally breaks the client
API
If you want to do this then in the minimum it has to be after 1.1. No
way we're going to change the client API after RC1 has been cut!
> ===
> How do we reflect service group concept in to client , and manage
> session using that. Well I do understand if we use Axis2 client <->
> Axis2 service this will work , but what if we use .Net client <-> Axis2
> Service. Is there any kind of specification sending session related data
> in SOAP message ? , if there is such a thing then we need to use them.
You're forgetting a design decision we made a while ago: to make the
service group concept not visible to the outside. That's why we said
services withing group become top level services. I was against it but
that's what we decided. As such there's no need to expose it to the
client.
What will be useful is for one service in a group to be able to get the
EPR of another service in a group. Something like
ServiceGroupContext.getEPRForService ("serviceName"). That can propagate
the contextID etc. so that they share the same interaction session.
Sanjiva.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[axis2] Spring support broken ?????
Forwarding with the axis2 prefix.-- Forwarded message --From: Rajith Attapattu <[EMAIL PROTECTED]
>Date: Oct 10, 2006 10:17 PMSubject: Re: Spring support broken ?To: axis-dev@ws.apache.orgCc: [EMAIL PROTECTED]
Hi All,The current spring support fails with the following exception possibly due to the new code change of obtaining the servlet config from the AxisConfiguration instead from the Message Context.
Caused by:
org.apache.axis2.AxisFault: Axis2 Can't find ServletConfig; nested exception is:java.lang.Exception: Axis2 Can't find ServletConfigat org.apache.axis2.AxisFault.makeFault(AxisFault.java:318)at
org.apache.axis2.extensions.spring.receivers.SpringServletContextObjectSupplier.getServiceObject(SpringServletContextObjectSupplier.java:70)... 43 moreCaused by: java.lang.Exception: Axis2 Can't find ServletConfig
at org.apache.axis2.extensions.spring.receivers.SpringServletContextObjectSupplier.getServiceObject(SpringServletContextObjectSupplier.java:53)... 43 moreNow when I look at the code I see that at revesion 426884 the code was obtaining the servlet config from the msgContext.
servletContext servletContext = (ServletContext) msgContext.getOptions(). getProperty(HTTPConstants.MC_HTTP_SERVLETCONTEXT);However the head revision was obtaining the servlet config via the AxisConfiguration.
ServletConfig servletConfig = (ServletConfig) axisService.getAxisConfiguration().getParameter(HTTPConstants.HTTP_SERVLETCONFIG);if (servletConfig == null) {throw new Exception("Axis2 Can't find ServletConfig");
}Why did we make the change ??? If we did so are we making sure that we populate the AxisConfiguration with the servlet config ?
Re: Spring support broken ?????
Hi All,The current spring support fails with the following exception possibly due to the new code change of obtaining the servlet config from the AxisConfiguration instead from the Message Context.Caused by:
org.apache.axis2.AxisFault: Axis2 Can't find ServletConfig; nested exception is:java.lang.Exception: Axis2 Can't find ServletConfigat org.apache.axis2.AxisFault.makeFault(AxisFault.java:318)at
org.apache.axis2.extensions.spring.receivers.SpringServletContextObjectSupplier.getServiceObject(SpringServletContextObjectSupplier.java:70)... 43 moreCaused by: java.lang.Exception: Axis2 Can't find ServletConfig
at org.apache.axis2.extensions.spring.receivers.SpringServletContextObjectSupplier.getServiceObject(SpringServletContextObjectSupplier.java:53)... 43 moreNow when I look at the code I see that at revesion 426884 the code was obtaining the servlet config from the msgContext.
servletContext servletContext = (ServletContext) msgContext.getOptions(). getProperty(HTTPConstants.MC_HTTP_SERVLETCONTEXT);However the head revision was obtaining the servlet config via the AxisConfiguration.
ServletConfig servletConfig = (ServletConfig) axisService.getAxisConfiguration().getParameter(HTTPConstants.HTTP_SERVLETCONFIG);if (servletConfig == null) {throw new Exception("Axis2 Can't find ServletConfig");
}Why did we make the change ??? If we did so are we making sure that we populate the AxisConfiguration with the servlet config ?
Re: [Axis2] Proposal to add return type to Handler.invoke(...)
Hi Sanjiva,
The problem isn't that both people are modifying MessageContext.paused,
so synchronizing that isn't going to work, the problem is that if the RM
handler, for instance, pauses the message and returns, but the RM thread
picks up the message and resumes it (thereby unpausing the message)
before control returns to the logic in the Phase/AxisEngine, the
Phase/AxisEngine are going to proceed as if the message was never
paused.
I was trying to avoid the overhead of synchronization when we have
another solution that works just as well (i.e. the return value) without
the overhead (and is more logically correct IMO.)
Using the return code also allows us to capture whether or not a message
was 'paused' vs 'aborted' -- this is important in the handler unwinding,
as no unwinding needs to occur in the 'paused' case while it does in the
'aborted' case.
I prefer an enumeration object because it's clear from the method
signature what is being returned (InvocationProcessingInstruction vs.
int in this case,) but if that's all that is holding you up, I'll switch
it to constants.
-Bill
On Tue, 2006-10-10 at 18:13 +0530, Sanjiva Weerawarana wrote:
> On Mon, 2006-10-09 at 19:51 -0700, Bill Nagy wrote:
> > There is currently a race condition between code that pauses the message
> > flow within a handler and resumes it on another thread (e.g. Sandesha)
> > and the message flow processing chain (Phase.invoke(...),
> > AxisEngine.invoke(...), etc.)
> > (http://issues.apache.org/jira/browse/SANDESHA2-32) This is caused
> > because the control of processing is keyed off of MessageContext.paused
> > and not through some other mechanism (return code, semaphore, etc.). If
> > a handler pauses a message and returns, handing the message off to
> > another thread for execution, there is the possibility that the new
> > execution thread will resume processing of the message, unsetting
> > MessageContext.paused, before control returns to one of the invoke
> > methods. If this happens, the logic in the invoke method, which looks
> > at the MessageContext.paused flag, will believe that it should continue
> > execution instead of halting.
>
> Can't this be solved by synchronizing access to MessageContext.paused()?
> Sorry I looked at the sandesha issue but didn't see it.
>
> Alternatively,
>
> synchronized {
> h.invoke();
> h.getPaused();
> }
>
> I must be missing something obvious as to why this doesn't work.
>
> > Since the problem revolves around flow control logic, I suggest that we
> > use the return code from the method invocation to deal with it. I would
> > like to add a return code to the Handler.invoke(...) which would
> > identify how processing of the message should proceed, e.g. :
>
> How does this solve the problem as other thread could go get the MC and
> do stuff while still in this method?
>
> > /**
> > * This type encapsulates an enumeration of possible message processing
> > * instruction values that may be returned by a handler/phase within the
> > * runtime.
> > */
> > public class InvocationProcessingInstruction
> > {
> > public static InvocationProcessingInstruction CONTINUE_PROCESSING =
> > new InvocationProcessingInstruction(0);
> > public static InvocationProcessingInstruction SUSPEND_PROCESSING = new
> > InvocationProcessingInstruction(1);
> > public static InvocationProcessingInstruction ABORT_PROCESSING = new
> > InvocationProcessingInstruction(2);
> >
> > private int instructionID;
> >
> > private InvocationProcessingInstruction(int instructionID)
> > {
> > this.instructionID = instructionID;
> > }
> >
> > public boolean equals(InvocationProcessingInstruction instruction)
> > {
> > return this.instructionID == instruction.instructionID;
> > }
> >
> > public int hashCode()
> > {
> > return instructionID;
> > }
> > }
> >
> > Most handlers will return
> > InvocationProcessingInstruction.CONTINUE_PROCESSING; the RM handler may
> > return that, SUSPEND_PROCESSING (for a pause), or ABORT_PROCESSING (for
> > a duplicate msg.)
>
> I must be really jetlagged (traveling again): do we need all this or
> just use an int to return the status?? (some consts basically).
>
> 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]
Re: [Axis2] Summery of todays Hackathon
Hi,
public MessageContext sendReceive(MessageContext req){}
public void sendReceiveNonBlocking(MessageContext req){}
public fireAndForget(MessageContext req){}
public sendRobust(MessageContext req){}
Huge +1.
Currently we provide SwA support only in the OperationClient level,
cause we need to access the message context... This will solve that
issue..
~Thilina
if we introduce these methods into ServiceClient then we do not too much
worry about how to create operationClient etc...
I am +1 on adding these four methods in to serviceClient.
===
How do we reflect service group concept in to client , and manage
session using that. Well I do understand if we use Axis2 client <->
Axis2 service this will work , but what if we use .Net client <-> Axis2
Service. Is there any kind of specification sending session related data
in SOAP message ? , if there is such a thing then we need to use them.
Thanks
Deepal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
http://webservices.apache.org/~thilina/
http://thilinag.blogspot.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2][RC-1.1] problem with HTTP/BOM content before SOAP response
Hi, I'm having a problem with the Axis2 1.1 RC on the client side. My services still work as normal when I upgrade them to 1.1, but my non-Axis2 clients fail when trying to parse the response message. I get the following error message from the JAXP DocumentBuilder (Xerces): [Fatal Error] :1:1: Content is not allowed in prolog. I initially thought this was related to an old bug in the processing of byte-order marks at the beginning of XML documents: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4508058 However, when I look at the SOAP response in my TCP/IP monitor, I see the following: --MIMEBoundaryurn_uuid_D29F76E66EC97F738911605255931147 content-type: application/xop+xml; charset=UTF-8; type="application/soap+xml"; content-transfer-encoding: binary content-id: <0.urn:uuid:[EMAIL PROTECTED]> http://www.w3.org/2005/08/addressing"; xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope";> http://www.w3.org/2005/08/addressing/anonymous http://www.w3.org/2005/08/addressing/none urn:uuid:26F070AB96AC17B8D811605255931048 http://ws.apache.org/muse/test/http-server/Stop http://www.w3.org/2005/08/addressing/reply";>uuid:80882292-b452-7e92-919d-01ed1f001f17 http://ws.apache.org/axis2"; xmlns:muse-op="http://ws.apache.org/muse/test/http-server"; /> --MIMEBoundaryurn_uuid_D29F76E66EC97F738911605255931147-- Can anyone comment on why the MIMEBoundary wrapper and some HTTP headers seem to be in the POST data? I think this is what's causing Xerces to fail when parsing the POST content into a DOM Document. This may be a significant issue since most web services clients assume that the only POST data in a SOAP response is the SOAP XML document. Thanks, Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Summery of todays Hackathon
Deepal,
Please create JIRA issue(s) and let's work on them.
thanks,
dims
On 10/10/06, Deepal Jayasinghe <[EMAIL PROTECTED]> wrote:
Hi All;
Few note from todays Hackathon we had at ApacheCon US.
We are having very ugly name called finalizeInvoke() in service client
with restriction, so we (Glen and I agreed) to remove that method and
move the code into cleanup (well I am doing the changes in current
codebase).
Why do we need operation client ?
As Dennis suggested , having annon name as public static seems not that
good , so we need to remove them I mean we need to make the private.
Rather than giving two client API to client cant we have one API , we
can have all the methods in serviceClient then no one need to know about
the operationClient (service client will use that internally ). So our
proposal is to add few more methods into ServiceCleint;
public MessageContext sendReceive(MessageContext req){}
public void sendReceiveNonBlocking(MessageContext req){}
public fireAndForget(MessageContext req){}
public sendRobust(MessageContext req){}
if we introduce these methods into ServiceClient then we do not too much
worry about how to create operationClient etc...
I am +1 on adding these four methods in to serviceClient.
===
How do we reflect service group concept in to client , and manage
session using that. Well I do understand if we use Axis2 client <->
Axis2 service this will work , but what if we use .Net client <-> Axis2
Service. Is there any kind of specification sending session related data
in SOAP message ? , if there is such a thing then we need to use them.
Thanks
Deepal
-
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]
[Axis2] Summery of todays Hackathon
Hi All;
Few note from todays Hackathon we had at ApacheCon US.
We are having very ugly name called finalizeInvoke() in service client
with restriction, so we (Glen and I agreed) to remove that method and
move the code into cleanup (well I am doing the changes in current
codebase).
Why do we need operation client ?
As Dennis suggested , having annon name as public static seems not that
good , so we need to remove them I mean we need to make the private.
Rather than giving two client API to client cant we have one API , we
can have all the methods in serviceClient then no one need to know about
the operationClient (service client will use that internally ). So our
proposal is to add few more methods into ServiceCleint;
public MessageContext sendReceive(MessageContext req){}
public void sendReceiveNonBlocking(MessageContext req){}
public fireAndForget(MessageContext req){}
public sendRobust(MessageContext req){}
if we introduce these methods into ServiceClient then we do not too much
worry about how to create operationClient etc...
I am +1 on adding these four methods in to serviceClient.
===
How do we reflect service group concept in to client , and manage
session using that. Well I do understand if we use Axis2 client <->
Axis2 service this will work , but what if we use .Net client <-> Axis2
Service. Is there any kind of specification sending session related data
in SOAP message ? , if there is such a thing then we need to use them.
Thanks
Deepal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [axis2] Improvements to Service life cycle in handling -setOperationContext not thread-safe??!!
Hi Sanjiva Weerawarana wrote: >On Tue, 2006-10-10 at 20:21 +0100, David Illsley wrote: > > >>In terms of setting up TLS info, I'm interested by the comment that it >>would be set in the AxisEngine. When we had the conversation about the >>ThreadContextMigrator interface (which does now exist) I understood >>that there wasn't any guarantee that there is a single thread in use >>through the handler chain. >> >> > >I believe it'll be set in the message receiver just before invoking the >method right guys? I can't see why it needs to be set earlier. > > Yes that was the final conclusion. FYI: Deepal: hi dims [15:07]Deepal: u there [15:08]Deepal: I dont think we can move saveTCCL(messageCtx); in AxisEngine [15:23]GlenD: dims? [15:23]GlenD: u there? [15:26]dims: ping [15:26]GlenD: hey [15:26]GlenD: so Deepal and I were chatting about the context stuff [15:26]dims: yes [15:26]GlenD: and ended up coming up with a very interesting idea which we wanted to run past you [15:26]dims: sure [15:26]GlenD: I think it's too big a change for now, but it's pretty cool for a future release [15:27]dims: we need to make a list of those :) [15:28]GlenD: the issue is that there's a lot of code duplication amongst MessageReceivers [15:28]dims: ah. that one :) [15:28]GlenD: if we want this setTCCL stuff and the setCurrentContext stuff to live in the MRs, it's hard to figure out where to put it so it isn't dup'ed everywhere [15:29]dims: call back to engine? [15:29]dims: sorry...go ahead. [15:29]GlenD: so we're wondering if you could maybe factor it out into a single AbstractMessageReceiver [15:29]GlenD: which would do the TCCL/Context stuff, then call invokeBusinessLogic() but pass only the OperationContext [15:29]dims: we have one of those [15:30]dims: AbstractMessageReceiver [15:30]GlenD: not have separate ones that pass either (inContext) or (inContext, outContext) [15:30]GlenD: we do? [15:30]dims: we need to structure it better [15:30]Deepal: we have 4 of them :) [15:30]GlenD: right [15:30]GlenD: we have 4 [15:30]dims: org.apache.axis2.receivers.AbstractMessageReceiver [15:31]dims: ah. i see [15:31]Deepal: and we are thinking of chaning invokeBusinessLogic signature [15:31]GlenD: only the lower level ones (AbstractInOnlyMR, etc) actually have receive() [15:31]GlenD: the top level one doesn't do anything [15:31]GlenD: except hold utility methods [15:31]dims: any cleanup is very welcome! sorely needed in this area. [15:31]dims: +1 [15:31]GlenD: so the interesting part is that SOMEONE needs to know to take the outMessageContext from the operationContext and send it [15:31]dims: please make sure you handle the spring scenario [15:31]Deepal: invokeBusinessLogice will take OperationContext as it argument [15:32]GlenD: that's the real difference between in and inout [15:32]dims: and then check isinstanceof? [15:32]GlenD: we're wondering if there's a way to genericize that by calling invokeBusinessLogic() and then something like complete() or doNext() [15:32]GlenD: but we need to think about it a little more I think :) [15:33]dims: yep... [15:33]dims: pre and post? [15:34]GlenD: (thinking here) [15:34]dims: first step is to collapse all 4 into 1 AbstractMessageReceiver? [15:34]dims: somehow [15:34]GlenD: that was the thought yes but we're seeing if it can work [15:35]dims: then adjust the calls to invokeBusinessLogic and maybe call something before it and something after it for special processing for different MEP's? [15:36]dims: are we looking for clean code or new feature here? [15:36]Deepal: I think both :) [15:37]dims: and the new Feature is?.. [15:37]GlenD: its really mostly clean code [15:37]GlenD: and a good place to put the common stuff for tls [15:38]dims: :) ok. [15:53]GlenD: ok never mind :) [15:53]GlenD: I think we just came to the conclusion that it's actually useful to have different abstract Receiver types [15:54]GlenD: because they're the ones that know the logic for message processing [15:54]GlenD: if you had an in/in/out MR, for instance, it could have processMessage1() and processMessage2() abstract operations [15:54]GlenD: that's nicer than just relying on a single invokeBusinessLogic(OperationContext), I think [15:56]GlenD: So the idea is to coalesce the TCCL stuff and the CurrentContext stuff into a setupThreadContext() and removeThreadContext() on AbstractMessageReceiver [15:57]GlenD: so developers of new MRs that want TLS functionality would need to k
Re: [axis2] Improvements to Service life cycle in handling -setOperationContext not thread-safe??!!
On 10/10/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote: On Tue, 2006-10-10 at 20:21 +0100, David Illsley wrote: > In terms of setting up TLS info, I'm interested by the comment that it > would be set in the AxisEngine. When we had the conversation about the > ThreadContextMigrator interface (which does now exist) I understood > that there wasn't any guarantee that there is a single thread in use > through the handler chain. I believe it'll be set in the message receiver just before invoking the method right guys? I can't see why it needs to be set earlier. I agree it doesn't need to be earlier. From Deepal earlier in this thread: Deepal41: hi dims [12:06]GlenD: [11:59] so we're now talking about setting a TLS OperationContext.getCurrentContext() into the AxisEngine, right before it calls the MessageReceiver [12:06]GlenD: [11:59] and putting the thread ClassLoader stuff right in the same place [12:06]GlenD: [11:59] so it's factored out of the individual MRs [12:06]dims: +1 [12:07]ruchith: +1 [12:07]ruchith: we don't have to duplicate code this way [12:07]Deepal41: in the mean time shall we move ... David -- David Illsley - IBM Web Services Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [axis2] Improvements to Service life cycle in handling -setOperationContext not thread-safe??!!
On Tue, 2006-10-10 at 20:21 +0100, David Illsley wrote: > In terms of setting up TLS info, I'm interested by the comment that it > would be set in the AxisEngine. When we had the conversation about the > ThreadContextMigrator interface (which does now exist) I understood > that there wasn't any guarantee that there is a single thread in use > through the handler chain. I believe it'll be set in the message receiver just before invoking the method right guys? I can't see why it needs to be set earlier. Sanjiva. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-1339) WSDL2Java client side stub code does not work with AXIS2 TCP Server
[
http://issues.apache.org/jira/browse/AXIS2-1339?page=comments#action_12441284 ]
yogen commented on AXIS2-1339:
--
This is further information on this issue
One difference I debugged is ...
In TCP Server impl the MessageContext.Options.to value is never set. Therefore
none of the org.apache.axis2.engine.xxxDispatcher classes find the service
implementation.
Whereas in HTTP Server implementation HttpTransportUtils.processHTTPPostRequest
calls MessageContext.setTo to set it value to
"/axis2/services/Axis2SampleDocLitService".
> WSDL2Java client side stub code does not work with AXIS2 TCP Server
> ---
>
> Key: AXIS2-1339
> URL: http://issues.apache.org/jira/browse/AXIS2-1339
> Project: Apache Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: core
>Affects Versions: 1.1
> Environment: Sun JVM 1.5, Axis2 1.1, WinXP
>Reporter: yogen
>Priority: Critical
>
> The sample service axis2-rc1\samples\userguide\MyService.aar and client
> \axis2-rc1\samples\userguide\src\userguide\clients\TCPClient.java *works*
> with AXIS2 TCP Server.
> But the code generated using wsdl2java for
> \axis2-rc1\samples\wsdl\Axis2SampleDocLit.wsdl and service
> Axis2SampleDocLitService.aar *does not work* with AXIS2 TCP Server (works
> with HTTP Server).
> 1. the code is generated like this: >wsdl2java -d xmlbeans -p com.sample -ss
> -sd -g -uri Axis2SampleDocLit.wsdl -pn Axis2SampleDocLitPort
> 2. the service runs on port 6060.
> 3. Running the client code throws this exception stack trace:
> Oct 10, 2006 12:06:02 PM org.apache.axis2.deployment.DeploymentEngine doDeploy
> INFO: Deploying module : addressing-1.09
> org.apache.axis2.AxisFault: Service not found operation terminated !!
> at
> org.apache.axis2.description.OutInAxisOperationClient.execute(OutInAxisOperation.java:294)
> at
> com.sample.Axis2SampleDocLitServiceStub.echoString(Axis2SampleDocLitServiceStub.java:505)
> at TCP1Client.echoString(TCP1Client.java:28)
> at TCP1Client.main(TCP1Client.java:17)
> The client code is attached:
> import javax.xml.namespace.QName;
> import org.apache.axis2.Constants;
> import org.apache.axis2.addressing.EndpointReference;
> import org.apache.axis2.userguide.xsd.*;
> import com.sample.*;
> public class TCP1Client{
> public static void main(java.lang.String args[]){
> Axis2SampleDocLitServiceStub stub = null;
> try{
> stub = new Axis2SampleDocLitServiceStub(null,
> "tcp://localhost:6060/axis2/services/Axis2SampleDocLitService");
> stub._getServiceClient().getOptions().setTo(new
> EndpointReference("tcp://localhost:6060/axis2/services/Axis2SampleDocLitService"));
>
> stub._getServiceClient().getOptions().setTransportInProtocol(Constants.TRANSPORT_TCP);
> stub._getServiceClient().engageModule(new
> QName(Constants.MODULE_ADDRESSING));
> System.out.println(echoString(stub));
> } catch(Exception e){
> e.printStackTrace();
> }
> }
> public static String echoString(Axis2SampleDocLitServiceStub stub){
> try{
> EchoStringParamDocument reqDoc00 =
> EchoStringParamDocument.Factory.newInstance();
> reqDoc00.setEchoStringParam("echo");
> EchoStringReturnDocument resDoc00 = stub.echoString(reqDoc00);
> return resDoc00.getEchoStringReturn();
> } catch(Exception e){
> e.printStackTrace();
> }
> return null;
> }
> }
--
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-1339) WSDL2Java client side stub code does not work with AXIS2 TCP Server
[
http://issues.apache.org/jira/browse/AXIS2-1339?page=comments#action_12441283 ]
yogen commented on AXIS2-1339:
--
This is further information on this issue
One difference I debugged is ...
In TCP Server impl the MessageContext.Options.to value is never set. Therefore
none of the org.apache.axis2.engine.xxxDispatcher classes find the service
implementation.
Whereas in HTTP Server implementation HttpTransportUtils.processHTTPPostRequest
calls MessageContext.setTo to set it value to
"/axis2/services/Axis2SampleDocLitServer".
> WSDL2Java client side stub code does not work with AXIS2 TCP Server
> ---
>
> Key: AXIS2-1339
> URL: http://issues.apache.org/jira/browse/AXIS2-1339
> Project: Apache Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: core
>Affects Versions: 1.1
> Environment: Sun JVM 1.5, Axis2 1.1, WinXP
>Reporter: yogen
>Priority: Critical
>
> The sample service axis2-rc1\samples\userguide\MyService.aar and client
> \axis2-rc1\samples\userguide\src\userguide\clients\TCPClient.java *works*
> with AXIS2 TCP Server.
> But the code generated using wsdl2java for
> \axis2-rc1\samples\wsdl\Axis2SampleDocLit.wsdl and service
> Axis2SampleDocLitService.aar *does not work* with AXIS2 TCP Server (works
> with HTTP Server).
> 1. the code is generated like this: >wsdl2java -d xmlbeans -p com.sample -ss
> -sd -g -uri Axis2SampleDocLit.wsdl -pn Axis2SampleDocLitPort
> 2. the service runs on port 6060.
> 3. Running the client code throws this exception stack trace:
> Oct 10, 2006 12:06:02 PM org.apache.axis2.deployment.DeploymentEngine doDeploy
> INFO: Deploying module : addressing-1.09
> org.apache.axis2.AxisFault: Service not found operation terminated !!
> at
> org.apache.axis2.description.OutInAxisOperationClient.execute(OutInAxisOperation.java:294)
> at
> com.sample.Axis2SampleDocLitServiceStub.echoString(Axis2SampleDocLitServiceStub.java:505)
> at TCP1Client.echoString(TCP1Client.java:28)
> at TCP1Client.main(TCP1Client.java:17)
> The client code is attached:
> import javax.xml.namespace.QName;
> import org.apache.axis2.Constants;
> import org.apache.axis2.addressing.EndpointReference;
> import org.apache.axis2.userguide.xsd.*;
> import com.sample.*;
> public class TCP1Client{
> public static void main(java.lang.String args[]){
> Axis2SampleDocLitServiceStub stub = null;
> try{
> stub = new Axis2SampleDocLitServiceStub(null,
> "tcp://localhost:6060/axis2/services/Axis2SampleDocLitService");
> stub._getServiceClient().getOptions().setTo(new
> EndpointReference("tcp://localhost:6060/axis2/services/Axis2SampleDocLitService"));
>
> stub._getServiceClient().getOptions().setTransportInProtocol(Constants.TRANSPORT_TCP);
> stub._getServiceClient().engageModule(new
> QName(Constants.MODULE_ADDRESSING));
> System.out.println(echoString(stub));
> } catch(Exception e){
> e.printStackTrace();
> }
> }
> public static String echoString(Axis2SampleDocLitServiceStub stub){
> try{
> EchoStringParamDocument reqDoc00 =
> EchoStringParamDocument.Factory.newInstance();
> reqDoc00.setEchoStringParam("echo");
> EchoStringReturnDocument resDoc00 = stub.echoString(reqDoc00);
> return resDoc00.getEchoStringReturn();
> } catch(Exception e){
> e.printStackTrace();
> }
> return null;
> }
> }
--
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] What should be included in Axis2 minimal distribution
Dennis Sosnoski wrote: > While we're looking into this, we should also check the war file > contents. It looks like the full set of jars are included, which is > certainly unnecessary. JiBX support only needs axis2-jibx-XXX.jar and > jibx-run-XXX.jar, not the much larger bcel-XXX.jar (.5 MB) and > jibx-bind-XXX.jar (.3 MB). I can strip these two unnecessary files out > of the war build if someone wants to point me at the appropriate magic > maven file, but I'm sure there's a lot more that can also be eliminated. > Done. Removed bcel-XXX.jar and jibx-bind-XXX.jar from the build. BTW, we have no way of knowing which jars are really required. What the maven scripts does is (in case if some one doesn't know), when we name some modules, it will pick up all the dependencies of those modules and add them to the war (refer cache-war-deps goal in maven.xml). How I overcome the above problem is deleting un-necessary files, after the above goal is invoked (see line 384 of maven.xml). I could have done the same thing by excluding the jars within the war ant task, but I opted the above. Those couple of lines were to reveal the magic behind maven logic :). -- Chinthaka signature.asc Description: OpenPGP digital signature
[jira] Closed: (AXIS2-1233) Handlers do not get a chance to undo work if a fault occurs or complete work when message processing finishes (this was split off from AXIS2-653)
[ http://issues.apache.org/jira/browse/AXIS2-1233?page=all ] Bill Nagy closed AXIS2-1233. Resolution: Fixed > Handlers do not get a chance to undo work if a fault occurs or complete work > when message processing finishes (this was split off from AXIS2-653) > - > > Key: AXIS2-1233 > URL: http://issues.apache.org/jira/browse/AXIS2-1233 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug > Components: core >Reporter: Bill Nagy > Assigned To: Bill Nagy > Attachments: qoslifecyclepatch.txt > > > I split this off of AXIS2-653, so that we could track this bit of work > separately. The basic gist of the matter is that the handlers do not have an > opportunity to clean up/complete their work after message processing has > completed (either due to a fault or to successful processing.) Here's some > of the original discussion: > http://marc.theaimsgroup.com/?l=axis-dev&m=114505970102143&w=2 . -- 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] Improvements to Service life cycle in handling -setOperationContext not thread-safe??!!
In terms of setting up TLS info, I'm interested by the comment that it would be set in the AxisEngine. When we had the conversation about the ThreadContextMigrator interface (which does now exist) I understood that there wasn't any guarantee that there is a single thread in use through the handler chain. Was this a misunderstanding or is this a change? David On 10/10/06, Tom Jordahl <[EMAIL PROTECTED]> wrote: While we may have had to work around some bugs in Thread Local Storage (TLS) on the whole I think the Axis 1.x MessageContext.getCurrentContext() works exceptionally well. Since JDK 1.4 is the minimum for Axis2, I believe we have all the TLS bugs behind us, no? -- Tom Jordahl Adobe ColdFusion Team -Original Message- From: Sanjiva Weerawarana [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 10, 2006 10:28 AM To: [EMAIL PROTECTED] Cc: axis-dev@ws.apache.org Subject: Re: [axis2] Improvements to Service life cycle in handling -setOperationContext not thread-safe??!! Other choices? The approach we used back in ApacheSOAP was to tell the user to add an additional first parameter to their methods if they wanted the context .. so the signature would have an additional param and that'd tell us to do the right thing. Very thread safe. Need to avoid reflection - but can be done by a codegen flag. For RPC case its reflective anyway so its not a big deal. Sanjiva. On Tue, 2006-10-10 at 09:40 -0400, Davanum Srinivas wrote: > Sanjiva, > > We had terrible problems with TLS in Axis1...let me recollect my > thougts and post. > > -- dims > > On 10/10/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote: > > I think I agree with you. How about we drop setOperationContext() and > > introduce Axis1-style MessageContext.getCurrentContext() which returns > > it for this thread? Have to be careful to put it in TLS and take it off! > > > > We must be careful to tell users that instance variables are not > > supported; you have to use MessageContext properties to store state (or > > wherever else). > > > > Sanjiva. > > > > On Sun, 2006-09-24 at 14:12 +0200, Christopher Sahnwaldt wrote: > > > Entered as http://issues.apache.org/jira/browse/AXIS2-1224 . > > > I set the priority to blocker as David suggested. > > > > > > IMHO it's probably best to drop the method. Many users will use it in an > > > intuitive but wrong way. The only way to store the data it provides is an > > > instance variable, and telling users to either use only request scope or use > > > a ThreadLocal to store the data does not seem to be compatible with the > > > rule of least surprise. Something like MessageContext.getCurrentContext() > > > in Axis 1 might be better. > > > > > > Bye, > > > Christopher. > > > > > > Davanum Srinivas wrote: > > > > Chris, > > > > > > > > Can you please raise a new issue in JIRA? > > > > > > > > thanks, > > > > dims > > > > > > > > On 9/23/06, Christopher Sahnwaldt <[EMAIL PROTECTED]> wrote: > > > >> Something worries me: > > > >> > > > >> > setOperationContext(OperationContext) - per call. The messageContext > > > >> > can be obtained to gain per call instance information. > > > >> > > > >> That doesn't seem to be thread-safe, does it? If I understand this > > > >> correctly, one service object is created per application (if the > > > >> service has application scope). When a request comes in, Axis calls > > > >> the setOperationContext method, and the service object may store the > > > >> OperationContext or the MessageContext. Then Axis calls the actual > > > >> service method, in which the service code can access the stored > > > >> OperationContext or MessageContext. But what if two requests come > > > >> in almost simultaneously? The following sequence of method calls > > > >> may occur: > > > >> > > > >> - Axis calls setOperationContext with context for request A, the > > > >> service object stores the context in an instance field. > > > >> - Axis calls setOperationContext with context for request B, the same > > > >> service object stores the context in the same instance field and > > > >> thus *overwrites* the context for call A. > > > >> - Axis calls the service method with the input parameters for request A. > > > >> - The service method processes the call, using data from the stored > > > >> context, and thus *mixes the input parameters for call A with the > > > >> context data for call B*. Anything can happen... > > > >> - Finally, Axis calls the service method with the input parameters > > > >> for call B, the service method processes the call, using data from > > > >> the stored context, and thus correctly uses the input parameters > > > >> for call B with the context data for call B. Probably ok, unless > > > >> the service method updated the context in some way during the call > > > >> for request A. > > > >> > > > >> But I hope I'm wrong or misunderstood or forgot something... ;-) > > > >> > > > >> Axis 1 avoided this problem by MessageContext.getCurrentContext(), > > > >
Re: [axis2] Improvements to Service life cycle in handling - setOperationContext not thread-safe??!!
Thilina,I understand your use case about having to create a new object for each invocation.But your use case is clearly in the minority. (meaning people will not do that often)So if you have a special requirment like that then why not use the concept of "ServiceObjectSupplier". So if u specify a custom service object supplier which creates a new service object irrespective of the scope then you are fine.We should not in my opinion change the general expectation of the users at large to implement special cases. As a user my understanding of "Application Scope" is that I have a Service that will live for the life of the application.And I may have (or choose to do so) instance variables that I maybe relying across multiple invocations. I may also want to init "expensive" resources in my init().All these assumptions which are based on the general idea about "application scope" are no longer valid if choose to create new objects each time. Regards,RajithOn 10/10/06, Thilina Gunarathne <[EMAIL PROTECTED]> wrote: Hi Deepal,>Deploying a service in application scope , user want to have once>service impl instance (im I were a user , I want that )Frankly I don't... Service impl class is a Axis2 bundled MR(eg: RawXMLInOut..) specific notion... Service impl is meaning less if theuser has written a custom MR.. One example would be a BPELEngine(which I did :) ), where we had our own Message Receiver and we storedall the state data in the service context.. See http://issues.apache.org/jira/browse/AXIS2-1133 this too..>so we're now talking about> setting a TLS OperationContext.getCurrentContext() into the AxisEngine, > right before it calls the MessageReceiverI'm not sure about the impact of this change... If this is not astraight forward change I doubt whether we should do this at thismoment... Don't want to take any chances towards 1.1 :(...> We should maintain both ,I mean> - should have only one serviceContext> - and only one service implany concrete use cases Use cases which cannot be implemented usingby storing the state data in the service context... > What if user want to keep local variable inside the impl class . I know> that is not the best practice bt ppl are using that .Then why we gonna encourage that ??Thanks,~Thilina >> > IMO anybody can use> > the ServiceContext to store whatever the state data needed to be> > shared across the life of the service...Are there any special cases> > where we can't do that.. If there aren't any reasons my suggestion is > > to create the service object per invocation.> >> > Also a user who uses the application scope might most probably be> > working in the messagereceiver(MR) level, since MR is known to be the > > ultimate message recipient in Axis2. One possible example is a BPEL> > engine.. In that case the concept of one service object for the life> > time of the service invalidates.. AFAIKS AXIS2-1133 is another > > implication of this design...> >> > Thanks,> > Thilina> >> > On 10/10/06, Sanjiva Weerawarana <[EMAIL PROTECTED] > wrote:> >> >> Other choices?> >>> >> The approach we used back in ApacheSOAP was to tell the user to add an> >> additional first parameter to their methods if they wanted the > >> context .. so the signature would have an additional param and that'd> >> tell us to do the right thing. Very thread safe.> >>> >> Need to avoid reflection - but can be done by a codegen flag. For RPC > >> case its reflective anyway so its not a big deal.> >>> >> Sanjiva.> >>> >> On Tue, 2006-10-10 at 09:40 -0400, Davanum Srinivas wrote:> >> > Sanjiva, > >> >> >> > We had terrible problems with TLS in Axis1...let me recollect my> >> > thougts and post.> >> >> >> > -- dims> >> > > >> > On 10/10/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:> >> > > I think I agree with you. How about we drop setOperationContext() > >> and> >> > > introduce Axis1-style MessageContext.getCurrentContext() which> >> returns> >> > > it for this thread? Have to be careful to put it in TLS and take > >> it off!> >> > >> >> > > We must be careful to tell users that instance variables are not> >> > > supported; you have to use MessageContext properties to store > >> state (or> >> > > wherever else).> >> > >> >> > > Sanjiva.> >> > >> >> > > On Sun, 2006-09-24 at 14:12 +0200, Christopher Sahnwaldt wrote: > >> > > > Entered as http://issues.apache.org/jira/browse/AXIS2-1224 .> >> > > > I set the priority to blocker as David suggested. > >> > > >> >> > > > IMHO it's probably best to drop the method. Many users will use> >> it in an> >> > > > intuitive but wrong way. The only way to store the data it > >> provides is an> >> > > > instance variable, and telling users to either use only request> >> scope or use> >> > > > a ThreadLocal to store the data does not seem to be compatible > >> with the> >> > > > rule of least surprise. Something like> >> MessageContext.getCurrentContext()> >> > > > in Axis 1 might be better.> >> > > > > >> > > > Bye,> >> > > > Christopher.> >> > > >> >> > > > Davanum
RE: [axis2] Improvements to Service life cycle in handling -setOperationContext not thread-safe??!!
While we may have had to work around some bugs in Thread Local Storage (TLS) on the whole I think the Axis 1.x MessageContext.getCurrentContext() works exceptionally well. Since JDK 1.4 is the minimum for Axis2, I believe we have all the TLS bugs behind us, no? -- Tom Jordahl Adobe ColdFusion Team -Original Message- From: Sanjiva Weerawarana [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 10, 2006 10:28 AM To: [EMAIL PROTECTED] Cc: axis-dev@ws.apache.org Subject: Re: [axis2] Improvements to Service life cycle in handling -setOperationContext not thread-safe??!! Other choices? The approach we used back in ApacheSOAP was to tell the user to add an additional first parameter to their methods if they wanted the context .. so the signature would have an additional param and that'd tell us to do the right thing. Very thread safe. Need to avoid reflection - but can be done by a codegen flag. For RPC case its reflective anyway so its not a big deal. Sanjiva. On Tue, 2006-10-10 at 09:40 -0400, Davanum Srinivas wrote: > Sanjiva, > > We had terrible problems with TLS in Axis1...let me recollect my > thougts and post. > > -- dims > > On 10/10/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote: > > I think I agree with you. How about we drop setOperationContext() and > > introduce Axis1-style MessageContext.getCurrentContext() which returns > > it for this thread? Have to be careful to put it in TLS and take it off! > > > > We must be careful to tell users that instance variables are not > > supported; you have to use MessageContext properties to store state (or > > wherever else). > > > > Sanjiva. > > > > On Sun, 2006-09-24 at 14:12 +0200, Christopher Sahnwaldt wrote: > > > Entered as http://issues.apache.org/jira/browse/AXIS2-1224 . > > > I set the priority to blocker as David suggested. > > > > > > IMHO it's probably best to drop the method. Many users will use it in an > > > intuitive but wrong way. The only way to store the data it provides is an > > > instance variable, and telling users to either use only request scope or use > > > a ThreadLocal to store the data does not seem to be compatible with the > > > rule of least surprise. Something like MessageContext.getCurrentContext() > > > in Axis 1 might be better. > > > > > > Bye, > > > Christopher. > > > > > > Davanum Srinivas wrote: > > > > Chris, > > > > > > > > Can you please raise a new issue in JIRA? > > > > > > > > thanks, > > > > dims > > > > > > > > On 9/23/06, Christopher Sahnwaldt <[EMAIL PROTECTED]> wrote: > > > >> Something worries me: > > > >> > > > >> > setOperationContext(OperationContext) - per call. The messageContext > > > >> > can be obtained to gain per call instance information. > > > >> > > > >> That doesn't seem to be thread-safe, does it? If I understand this > > > >> correctly, one service object is created per application (if the > > > >> service has application scope). When a request comes in, Axis calls > > > >> the setOperationContext method, and the service object may store the > > > >> OperationContext or the MessageContext. Then Axis calls the actual > > > >> service method, in which the service code can access the stored > > > >> OperationContext or MessageContext. But what if two requests come > > > >> in almost simultaneously? The following sequence of method calls > > > >> may occur: > > > >> > > > >> - Axis calls setOperationContext with context for request A, the > > > >> service object stores the context in an instance field. > > > >> - Axis calls setOperationContext with context for request B, the same > > > >> service object stores the context in the same instance field and > > > >> thus *overwrites* the context for call A. > > > >> - Axis calls the service method with the input parameters for request A. > > > >> - The service method processes the call, using data from the stored > > > >> context, and thus *mixes the input parameters for call A with the > > > >> context data for call B*. Anything can happen... > > > >> - Finally, Axis calls the service method with the input parameters > > > >> for call B, the service method processes the call, using data from > > > >> the stored context, and thus correctly uses the input parameters > > > >> for call B with the context data for call B. Probably ok, unless > > > >> the service method updated the context in some way during the call > > > >> for request A. > > > >> > > > >> But I hope I'm wrong or misunderstood or forgot something... ;-) > > > >> > > > >> Axis 1 avoided this problem by MessageContext.getCurrentContext(), > > > >> which gives access to the MessageContext *for the current thread* > > > >> from within any service method, without the need for a > > > >> setMessageContext (or setOperationContext) method on the service > > > >> object. > > > >> > > > >> Bye, > > > >> Christopher. > > > >> > > > >> > > > >> Tony Dean wrote: > > > >> > > > >> > Can we fully document the logical semantics behind each method? > > > >> > > > >
Re: [axis2] Improvements to Service life cycle in handling - setOperationContext not thread-safe??!!
Hi Deepal, >> Deploying a service in application scope , user want to have once >> service impl instance (im I were a user , I want that ) > > > Frankly I don't... :) > Service impl class is a Axis2 bundled MR(eg: > RawXMLInOut..) specific notion... Service impl is meaning less if the > user has written a custom MR.. yes , I agree. btw we use all those concept in code gen as well , I mean all the generated MR support all those. > One example would be a BPELEngine > (which I did :) ), where we had our own Message Receiver and we stored > all the state data in the service context.. yes , as I told you earlier thats the perfect way , but there are users how want to store values in service impl. (And for me I think that is not that bad when you deploy a service in application scope) > See > http://issues.apache.org/jira/browse/AXIS2-1133 this too.. > >> so we're now talking about >> setting a TLS OperationContext.getCurrentContext() into the AxisEngine, >> right before it calls the MessageReceiver > > > I'm not sure about the impact of this change... If this is not a > straight forward change I doubt whether we should do this at this > moment... Don't want to take any chances towards 1.1 :(... no , if we are going to make this change we have to do that before 1.1 , and I dont think the change we are planing to do will affect that much :) > >> We should maintain both ,I mean >> - should have only one serviceContext >> - and only one service impl > > > any concrete use cases Use cases which cannot be implemented using > by storing the state data in the service context... > > >> What if user want to keep local variable inside the impl class . I know >> that is not the best practice bt ppl are using that . > > Then why we gonna encourage that ?? > > Thanks, > ~Thilina > >> >> > IMO anybody can use >> > the ServiceContext to store whatever the state data needed to be >> > shared across the life of the service...Are there any special cases >> > where we can't do that.. If there aren't any reasons my suggestion is >> > to create the service object per invocation. >> > >> > Also a user who uses the application scope might most probably be >> > working in the messagereceiver(MR) level, since MR is known to be the >> > ultimate message recipient in Axis2. One possible example is a BPEL >> > engine.. In that case the concept of one service object for the life >> > time of the service invalidates.. AFAIKS AXIS2-1133 is another >> > implication of this design... >> > >> > Thanks, >> > Thilina >> > >> > On 10/10/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote: >> > >> >> Other choices? >> >> >> >> The approach we used back in ApacheSOAP was to tell the user to >> add an >> >> additional first parameter to their methods if they wanted the >> >> context .. so the signature would have an additional param and that'd >> >> tell us to do the right thing. Very thread safe. >> >> >> >> Need to avoid reflection - but can be done by a codegen flag. For RPC >> >> case its reflective anyway so its not a big deal. >> >> >> >> Sanjiva. >> >> >> >> On Tue, 2006-10-10 at 09:40 -0400, Davanum Srinivas wrote: >> >> > Sanjiva, >> >> > >> >> > We had terrible problems with TLS in Axis1...let me recollect my >> >> > thougts and post. >> >> > >> >> > -- dims >> >> > >> >> > On 10/10/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote: >> >> > > I think I agree with you. How about we drop setOperationContext() >> >> and >> >> > > introduce Axis1-style MessageContext.getCurrentContext() which >> >> returns >> >> > > it for this thread? Have to be careful to put it in TLS and take >> >> it off! >> >> > > >> >> > > We must be careful to tell users that instance variables are not >> >> > > supported; you have to use MessageContext properties to store >> >> state (or >> >> > > wherever else). >> >> > > >> >> > > Sanjiva. >> >> > > >> >> > > On Sun, 2006-09-24 at 14:12 +0200, Christopher Sahnwaldt wrote: >> >> > > > Entered as http://issues.apache.org/jira/browse/AXIS2-1224 . >> >> > > > I set the priority to blocker as David suggested. >> >> > > > >> >> > > > IMHO it's probably best to drop the method. Many users will use >> >> it in an >> >> > > > intuitive but wrong way. The only way to store the data it >> >> provides is an >> >> > > > instance variable, and telling users to either use only request >> >> scope or use >> >> > > > a ThreadLocal to store the data does not seem to be compatible >> >> with the >> >> > > > rule of least surprise. Something like >> >> MessageContext.getCurrentContext() >> >> > > > in Axis 1 might be better. >> >> > > > >> >> > > > Bye, >> >> > > > Christopher. >> >> > > > >> >> > > > Davanum Srinivas wrote: >> >> > > > > Chris, >> >> > > > > >> >> > > > > Can you please raise a new issue in JIRA? >> >> > > > > >> >> > > > > thanks, >> >> > > > > dims >> >> > > > > >> >> > > > > On 9/23/06, Christopher Sahnwaldt <[EMAIL PROTECTED]> wrote: >> >> > > > >> Something worries me: >> >> > > > >> >> >> > > > >>
[jira] Commented: (AXIS2-1274) WSDL2Java does not create Stub class for PortType
[ http://issues.apache.org/jira/browse/AXIS2-1274?page=comments#action_12441261 ] Tom Jordahl commented on AXIS2-1274: So I have to parse the XML of the WSDL to figure out how to request all of the code be generated? Is their at least an "all" switch? > WSDL2Java does not create Stub class for PortType > - > > Key: AXIS2-1274 > URL: http://issues.apache.org/jira/browse/AXIS2-1274 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug > Components: wsdl >Affects Versions: 1.0 > Environment: WinXP, Sun JVM 1.5 >Reporter: yogen > > I am using AXIS2 1.0. I ran wsdl2java on samples/wsdl/Axis2SampleDocLit.wsdl > like this: wsdl2java -d xmlbeans -uri Axis2SampleDocLit.wsdl -p com.sample > -ss -sd -g; it does not > generate Axis2SampleDocLitPortTypeStub.java. > > when I tried this wsdl2java -d xmlbeans -uri Axis2SampleDocLit.wsdl -p > com.sample -ss -sd -g -pn Axis2SampleDocLitPortType > it complains that Axis2SampleDocLitPortType not found in WSDL. > The problem is in nightly build as well. -- 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]Embdeding Jetty to Axis2
-0 from me. While Jetty is super sweet, Axis2 has a serious jar file dependency problem. I think its going to have to go in to a detox program soon! -- Tom Jordahl Adobe ColdFusion Team -Original Message- From: Sanjiva Weerawarana [mailto:[EMAIL PROTECTED] Sent: Monday, October 09, 2006 5:17 PM To: axis-dev@ws.apache.org Subject: Re: [Axis2]Embdeding Jetty to Axis2 +1 from me too! Sanjiva. On Mon, 2006-10-09 at 10:36 -0400, Rajith Attapattu wrote: > Srinath, I personally think it's a good move. > > Regards, > > Rajith > > On 10/9/06, Brian De Pradine <[EMAIL PROTECTED]> wrote: > > +1 from me. > > Cheers > > Brian DePradine > Web Services Development > IBM Hursley > External +44 (0) 1962 816319 Internal 246319 > > If you can't find the time to do it right the first time, > where will you find the time to do it again? > > > "Jaliya Ekanayake" <[EMAIL PROTECTED]> wrote on 08/10/2006 > 15:20:49: > > > > Hi All, > > > > One other advantage is that we can simply give an Axis2 > server for the user > > as well. > > All they want is to start the Axis2 server which is based on > Jetty. > > > > Thanks, > > -Jaliya > > > > > > - Original Message - > > From: "Srinath Perera" <[EMAIL PROTECTED]> > > To: > > Cc: "Thilina Gunarathne" <[EMAIL PROTECTED]>; "Jaliya > Ekanayake" > > <[EMAIL PROTECTED]> > > Sent: Sunday, October 08, 2006 7:56 AM > > Subject: [Axis2]Embdeding Jetty to Axis2 > > > > > > > Hi All; > > > Myself and jaliya were talking about trying to do lot of > async > > > requests using Axis2 client .. it falis at about 40-50 > requests and we > > > belive that is becouse ..simple HTTP server can't handle > the load. > > > > > > I was looking at the jetty and found out that Jetty6 allow > you to > > > embed it to the application tightly. For an example > > > > > > Server server = new Server(8080); > > > Context root = new Context(server,"/",Context.SESSIONS); > > > root.addServlet(new ServletHolder(new > HelloServlet(serviceMap)), "/*"); > > > server.start(); > > > > > > Will create a new server and add a servlet. > > > > > > I belive if we embdeded Jetty to Axis2 > > > 1) Axis2 can use jetty as the listener for async messages > > > 2) Axis2 can started up standalone using jetty > > > > > > I belive I could port our Axis2 servlet to jetty pretty > easily. > > > > > > If people agree I think we should have it as a module and > if it is > > > sucessful I think we should switch to it as our default > container some > > > day > > > > > > thoughts? > > > Srinath > > > > > > > > > > > > -- > > > > > > Srinath Perera: > > > http://www.cs.indiana.edu/~hperera/ > > > http://www.bloglines.com/blog/hemapani > > > > > > > - > > > 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Axis2]WSDL2Java Code generation option
+1 for Sanjiva's suggestions: -c client side -s server side -t test case generation. I think -a should be for "all", but I assume it is in use already? -- Tom Jordahl Adobe ColdFusion Team -Original Message- From: Sanjiva Weerawarana [mailto:[EMAIL PROTECTED] Sent: Monday, October 09, 2006 5:13 PM To: axis-dev@ws.apache.org Cc: Thilina Gunarathne Subject: Re: [Axis2]WSDL2Java Code generation option On Mon, 2006-10-09 at 07:54 -0400, Srinath Perera wrote: > Hi AJith,All; > As far as I understand > > 1) no options client side only > 2) -s server side > 3) -sd -ss service side discriptions, this only work with -ss > 4) -g all, but no service.xml .. So I put -g -sd ..still none becouse > -sd only works with -ss .. so -g -ss and -sd Ouch. > Sorry but I feel this is far too complex. shall we change the options > for 1.1? for example (Or do we need to me backward compatible with the > tool options?) > > -GClient or nothing for Client > -GServer for server with service.xml > -GAll for everything > -GTest all with test case How about: - -c or nothing for client - -s for service side with services.xml - -g for both client and server (both the above basically) - -g -t for all and test case That is, introduce a -t argument for test case generation. By test case we mean what exactly .. a stub?? In that case its only meaningful for a server side case anyway. > Do we have use case for generating server side code without a service.xml file ? > Do we have use case for generating service.xml without server side > code? (we could at least assume -ss given -sd) +1. So basically same as your proposal except use option names that are closer to what we have now. 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]
[jira] Commented: (AXIS2-1274) WSDL2Java does not create Stub class for PortType
[ http://issues.apache.org/jira/browse/AXIS2-1274?page=comments#action_12441258 ] Davanum Srinivas commented on AXIS2-1274: - Yep :( I tried... > WSDL2Java does not create Stub class for PortType > - > > Key: AXIS2-1274 > URL: http://issues.apache.org/jira/browse/AXIS2-1274 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug > Components: wsdl >Affects Versions: 1.0 > Environment: WinXP, Sun JVM 1.5 >Reporter: yogen > > I am using AXIS2 1.0. I ran wsdl2java on samples/wsdl/Axis2SampleDocLit.wsdl > like this: wsdl2java -d xmlbeans -uri Axis2SampleDocLit.wsdl -p com.sample > -ss -sd -g; it does not > generate Axis2SampleDocLitPortTypeStub.java. > > when I tried this wsdl2java -d xmlbeans -uri Axis2SampleDocLit.wsdl -p > com.sample -ss -sd -g -pn Axis2SampleDocLitPortType > it complains that Axis2SampleDocLitPortType not found in WSDL. > The problem is in nightly build as well. -- 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-1274) WSDL2Java does not create Stub class for PortType
[ http://issues.apache.org/jira/browse/AXIS2-1274?page=comments#action_12441255 ] Tom Jordahl commented on AXIS2-1274: Dims, Does this mean that by default wsdl2java does not emit code for all the ports in a WSDL? That seems bad to me. > WSDL2Java does not create Stub class for PortType > - > > Key: AXIS2-1274 > URL: http://issues.apache.org/jira/browse/AXIS2-1274 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug > Components: wsdl >Affects Versions: 1.0 > Environment: WinXP, Sun JVM 1.5 >Reporter: yogen > > I am using AXIS2 1.0. I ran wsdl2java on samples/wsdl/Axis2SampleDocLit.wsdl > like this: wsdl2java -d xmlbeans -uri Axis2SampleDocLit.wsdl -p com.sample > -ss -sd -g; it does not > generate Axis2SampleDocLitPortTypeStub.java. > > when I tried this wsdl2java -d xmlbeans -uri Axis2SampleDocLit.wsdl -p > com.sample -ss -sd -g -pn Axis2SampleDocLitPortType > it complains that Axis2SampleDocLitPortType not found in WSDL. > The problem is in nightly build as well. -- 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-1272) Cannot differentiate between an int sent as 0 and an int sent as nil
[ http://issues.apache.org/jira/browse/AXIS2-1272?page=comments#action_12441253 ] Tom Jordahl commented on AXIS2-1272: (Commented on AXIS2-1247 also) Note that an Axis 1.x, any integer type that is nillable has to become a Java Integer. Otherwise you can not tell if 0 is sent or it was omitted. Axsi 2 should follow the same convention. Any nillable type must be converted in to the Java wrapper type. > Cannot differentiate between an int sent as 0 and an int sent as nil > > > Key: AXIS2-1272 > URL: http://issues.apache.org/jira/browse/AXIS2-1272 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug > Components: databinding >Affects Versions: nightly > Environment: Axis 2 nightly, Java 1.4.2, Tomcat 4 >Reporter: Todd Doolittle > > The service I deal with often sends back values a nil (or NULL). For most > datatypes, such as String and Date the value of the object is NULL (using > client code generated by WSDL2JAVA). However for anything that is an > integer, it is set to 0. This makes it impossible to tell if the value in > the message was really a 0, or if it was nil="true". > For example, the type in the wsdl is defined as... > > > > > > > > > The server returns this response... > >0 > > > In the client code, response.getFirstNumber() would return 0, and > response.getSecondNumber() would also return 0. > To get around this could we do one of the following... > **When an int is returned from a service as nil="true" set the value to > Integer.MIN_VALUE. > or > **In the generated classes using java.lang.Integer instead of int and in the > case of a nil="true" response, set the Integer object to null. > or > **In the generated classes, for each int value include a isNull() method that > would return a boolean. > Thanks! > Todd -- 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-1247) wsdl2java generated client throws NumberFormatException on nil integer
[ http://issues.apache.org/jira/browse/AXIS2-1247?page=comments#action_12441249 ] Tom Jordahl commented on AXIS2-1247: Note that an Axis 1.x, any integer type that is nillable has to become a Java Integer. Otherwise you can not tell if 0 is sent or it was omitted. Axsi 2 should follow the same convention. Any nillable type must be converted in to the Java wrapper type. > wsdl2java generated client throws NumberFormatException on nil integer > -- > > Key: AXIS2-1247 > URL: http://issues.apache.org/jira/browse/AXIS2-1247 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug >Affects Versions: nightly > Environment: Java 1.4.2, Tomcat 4, Axis 2 Nightly Build >Reporter: Todd Doolittle >Priority: Blocker > > I used wsdl2java to create a client based on wsdl from a non-java service. > The wsdl specifies that one of the returned values is an integer and is > nillable like this... > > When the service returns a null/nill value it looks like this in the SOAP > body: > > The client code throws a number format exception while processing this... > Caused by: java.lang.NumberFormatException: For input string: "" > at java.lang.NumberFormatException.forInputString(Unknown Source) > at java.lang.Integer.parseInt(Unknown Source) > at java.lang.Integer.parseInt(Unknown Source) > at > org.apache.axis2.databinding.utils.ConverterUtil.convertToInt(ConverterUtil.java:210) > at org.tempuri.POCStub$Item_type0$Factory.parse(POCStub.java:2149) > at org.tempuri.POCStub$Items_type1$Factory.parse(POCStub.java:1157) > at org.tempuri.POCStub$GetinfoResponse$Factory.parse(POCStub.java:1593) > at org.tempuri.POCStub.fromOM(POCStub.java:2330) > ... 3 more > Here is the SOAP message my client sent (which looks fine): > POST /ws/r/poc?WSDL > HTTP/1.1 > SOAPAction: getinfo > User-Agent: Axis2 > Host: localhost:8090 > Transfer-Encoding: chunked > Content-Type: text/xml; charset=UTF-8 > 160 > >xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";> > > > http://tempuri.org/"; count="1"> > 200910 >xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; nil="true" /> > > > > 0 > Here is the non-java service's reply: > HTTP/1.1 200 OK > Date: Wed, 27 Sep 2006 15:23:37 GMT > Server: Four J's Server (Build 369) > Content-Type: text/xml; charset="UTF-8" > Content-Length: 532 > >xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";> > > http://tempuri.org/"; count="1" > xmlns:xsd="http://www.w3.org/2001/XMLSchema"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> > > > > 200910 > > > > > > > > Here is the WSDL from the service... > > http://schemas.xmlsoap.org/wsdl/"; > name="POC" targetNamespace="http://tempuri.org/"; > xmlns:fjs="http://tempuri.org/"; > xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"; > xmlns:xsd="http://www.w3.org/2001/XMLSchema";> > >targetNamespace="http://tempuri.org/"; > xmlns:s1="http://tempuri.org/";> > > > >name="upc" nillable="true" type="xsd:string" /> > >use="required" /> > > > > > > > > >minOccurs="0" name="item" nillable="true"> > > >nillable="true" type="xsd:int" /> >nillable="true" type="xsd:string" /> >name="maintdt" nillable="true" type="xsd:date" /> >nillable="true" type="xsd:int" /> > > > > > > > >use="required" /> > > > > > > > > > > > > > >name="GetinfoResponse" /> > > > > http://schemas.xmlsoap.org/soap/http"; /> > > > > > > > > > > > > > http://localhost:8090/POC/POC"; /> > > > -- 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 P
Re: WS Addressing :: Issue with setting ReplyTo :: Axis2-1.1-SNAPSHOT
I answered this question couple of time, but let me try again. If you invoke send-receive from your client then your response *must* come to it and Axis2 engine helps you to do that by starting up the proper listeners. What you could have done was invoke one way and put your replyTo. Even if you are invoking an IN-OUT service, for your clients it is just IN-Only as it won't receive a response. But there was a valid scenario, actually pointed out by Chamikara, that some might want to get his replies through a proxy like tcp-mon. Yes in that case, you might want to override the replyTo value. I can remember Chamikara was talking about this but not sure whether he implemented it. Chamikara, you wanna add something here? -- Chinthaka Vaibhav Pandey wrote: > Hi All, > I am trying to explore WS Addressing by creating a flow in which i call a WS > (INOUT-with NonBlockingDual client) and then i want the response to be > directed to another WS on a different port and server. I have explicitly set > the To/ReplyTo in my client. In the resluting SOAP request the wsa:To > parmeter gets set based on what i mentioned but somehow the wsa:ReplyTo is > set to the default listener address !! > > I have also set:: > options.setProperty(AddressingConstants.REPLACE_ADDRESSING_HEADERS, > Boolean.TRUE) > and then am setting replyto as :: options.setTo(targetEPR); > > options.setReplyTo(targetReplyEPR); > > options.setTransportInProtocol(Constants.TRANSPORT_HTTP); > > i also tried :: > options.setProperty(AddressingConstants.WSA_REPLY_TO, targetReplyEPR); > > but what i found after looking at the source code was that in the message > context itself the replyTo address is set to default whereas the To address > is set based on what i mentioned. > > Kindly guide me as to what am i supposed to do. > > > Regards, > Vaibhav > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > signature.asc Description: OpenPGP digital signature
Re: [Axis2] What should be included in Axis2 minimal distribution
yep On 10/10/06, Eran Chinthaka <[EMAIL PROTECTED]> wrote: Does this mean, now we can happily ship the minimal distro with kernel, adb and java2wsdl in it? Agreed? -- Chinthaka Davanum Srinivas wrote: > Yes i did :) > > -- dims > > On 10/10/06, Thilina Gunarathne <[EMAIL PROTECTED]> wrote: >> +1... Seeems like you have already migrated it to ADB :).. >> >> ~Thilina >> >> On 10/10/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote: >> > Folks, >> > >> > lets move rpc* out of coden. it does not belong there. >> > >> > -- dims >> > >> > On 10/10/06, Thilina Gunarathne <[EMAIL PROTECTED]> wrote: >> > > Hi, >> > > AFAIK ADB is there because we need the RPCMessageReceiver to work in >> > > the minimal distro... >> > > Just now I figured out that RPCMessageReceiver resides in the codegen >> > > module..Which means we have to include codegen module to the minimal >> > > distro.. >> > > >> > > I'm not sure why we are putting the adb-codegen in to the minimal >> distro... >> > > >> > > ~Thilina >> > > >> > > On 10/10/06, Eran Chinthaka <[EMAIL PROTECTED]> wrote: >> > > > Hi, >> > > > >> > > > Can we please re-visit the modules that should be included in Axis2 >> > > > minimal distribution. Currently kernel, adb and java2wsdl >> modules are >> > > > included, but I saw even adb-codegen was added recently. >> > > > >> > > > What do you think? >> > > > >> > > > Thanks, >> > > > Chinthaka >> > > > >> > > > >> > > > >> > > > >> > > >> > > >> > > -- >> > > http://webservices.apache.org/~thilina/ >> > > http://thilinag.blogspot.com/ >> > > >> > > - >> > > 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] >> > >> > >> >> >> -- >> http://webservices.apache.org/~thilina/ >> http://thilinag.blogspot.com/ >> >> - >> 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]
Re: [Axis2] What should be included in Axis2 minimal distribution
Does this mean, now we can happily ship the minimal distro with kernel, adb and java2wsdl in it? Agreed? -- Chinthaka Davanum Srinivas wrote: > Yes i did :) > > -- dims > > On 10/10/06, Thilina Gunarathne <[EMAIL PROTECTED]> wrote: >> +1... Seeems like you have already migrated it to ADB :).. >> >> ~Thilina >> >> On 10/10/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote: >> > Folks, >> > >> > lets move rpc* out of coden. it does not belong there. >> > >> > -- dims >> > >> > On 10/10/06, Thilina Gunarathne <[EMAIL PROTECTED]> wrote: >> > > Hi, >> > > AFAIK ADB is there because we need the RPCMessageReceiver to work in >> > > the minimal distro... >> > > Just now I figured out that RPCMessageReceiver resides in the codegen >> > > module..Which means we have to include codegen module to the minimal >> > > distro.. >> > > >> > > I'm not sure why we are putting the adb-codegen in to the minimal >> distro... >> > > >> > > ~Thilina >> > > >> > > On 10/10/06, Eran Chinthaka <[EMAIL PROTECTED]> wrote: >> > > > Hi, >> > > > >> > > > Can we please re-visit the modules that should be included in Axis2 >> > > > minimal distribution. Currently kernel, adb and java2wsdl >> modules are >> > > > included, but I saw even adb-codegen was added recently. >> > > > >> > > > What do you think? >> > > > >> > > > Thanks, >> > > > Chinthaka >> > > > >> > > > >> > > > >> > > > >> > > >> > > >> > > -- >> > > http://webservices.apache.org/~thilina/ >> > > http://thilinag.blogspot.com/ >> > > >> > > - >> > > 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] >> > >> > >> >> >> -- >> http://webservices.apache.org/~thilina/ >> http://thilinag.blogspot.com/ >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > signature.asc Description: OpenPGP digital signature
[jira] Created: (AXIS2-1340) Axis2Util.toOM() needs to work w/o XML-Security jar
Axis2Util.toOM() needs to work w/o XML-Security jar --- Key: AXIS2-1340 URL: http://issues.apache.org/jira/browse/AXIS2-1340 Project: Apache Axis 2.0 (Axis2) Issue Type: Improvement Components: om Environment: Any Reporter: Sathija Pavuluri Priority: Minor When converting a DOM element to OMElement, the process is not straightforward. We first need to use the org.apache.rampart.util.Axis2Utils.toOM() from axis2-security-SNAPSHOT.jar. The toOM() method references the org.apache.xml.security.utils.XMLUtils class from xml-security jar file. So one needs to include that jar in the classpath. And then this error is seen: > org.apache.xml.security.c14n.InvalidCanonicalizerException: You must > initialize the xml-security library correctly before you use it. Call the > static method "org.apache.xml.security.Init.init();" to do that before you > use any functionality from that library. > at org.apache.xml.security.c14n.Canonicalizer.(Unknown Source) > at org.apache.xml.security.c14n.Canonicalizer.getInstance(Unknown > Source) > at org.apache.xml.security.utils.XMLUtils.outputDOM(Unknown Source) > at org.apache.rampart.util.Axis2Util.toOM(Axis2Util.java:176) To fix this, I have had to call org.apache.xml.security.Init.init(); in my class before invoking Axis2Utils.toOM(). This is rather cumbersome. It would be nice if the axis2-security was packaged so that the xml-security jar need not be imported. Or the toOM() method needs to correctly initialize the xml-security jar. -- 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] Improvements to Service life cycle in handling - setOperationContext not thread-safe??!!
Hi Deepal, Deploying a service in application scope , user want to have once service impl instance (im I were a user , I want that ) Frankly I don't... Service impl class is a Axis2 bundled MR(eg: RawXMLInOut..) specific notion... Service impl is meaning less if the user has written a custom MR.. One example would be a BPELEngine (which I did :) ), where we had our own Message Receiver and we stored all the state data in the service context.. See http://issues.apache.org/jira/browse/AXIS2-1133 this too.. so we're now talking about setting a TLS OperationContext.getCurrentContext() into the AxisEngine, right before it calls the MessageReceiver I'm not sure about the impact of this change... If this is not a straight forward change I doubt whether we should do this at this moment... Don't want to take any chances towards 1.1 :(... We should maintain both ,I mean - should have only one serviceContext - and only one service impl any concrete use cases Use cases which cannot be implemented using by storing the state data in the service context... What if user want to keep local variable inside the impl class . I know that is not the best practice bt ppl are using that . Then why we gonna encourage that ?? Thanks, ~Thilina > IMO anybody can use > the ServiceContext to store whatever the state data needed to be > shared across the life of the service...Are there any special cases > where we can't do that.. If there aren't any reasons my suggestion is > to create the service object per invocation. > > Also a user who uses the application scope might most probably be > working in the messagereceiver(MR) level, since MR is known to be the > ultimate message recipient in Axis2. One possible example is a BPEL > engine.. In that case the concept of one service object for the life > time of the service invalidates.. AFAIKS AXIS2-1133 is another > implication of this design... > > Thanks, > Thilina > > On 10/10/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote: > >> Other choices? >> >> The approach we used back in ApacheSOAP was to tell the user to add an >> additional first parameter to their methods if they wanted the >> context .. so the signature would have an additional param and that'd >> tell us to do the right thing. Very thread safe. >> >> Need to avoid reflection - but can be done by a codegen flag. For RPC >> case its reflective anyway so its not a big deal. >> >> Sanjiva. >> >> On Tue, 2006-10-10 at 09:40 -0400, Davanum Srinivas wrote: >> > Sanjiva, >> > >> > We had terrible problems with TLS in Axis1...let me recollect my >> > thougts and post. >> > >> > -- dims >> > >> > On 10/10/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote: >> > > I think I agree with you. How about we drop setOperationContext() >> and >> > > introduce Axis1-style MessageContext.getCurrentContext() which >> returns >> > > it for this thread? Have to be careful to put it in TLS and take >> it off! >> > > >> > > We must be careful to tell users that instance variables are not >> > > supported; you have to use MessageContext properties to store >> state (or >> > > wherever else). >> > > >> > > Sanjiva. >> > > >> > > On Sun, 2006-09-24 at 14:12 +0200, Christopher Sahnwaldt wrote: >> > > > Entered as http://issues.apache.org/jira/browse/AXIS2-1224 . >> > > > I set the priority to blocker as David suggested. >> > > > >> > > > IMHO it's probably best to drop the method. Many users will use >> it in an >> > > > intuitive but wrong way. The only way to store the data it >> provides is an >> > > > instance variable, and telling users to either use only request >> scope or use >> > > > a ThreadLocal to store the data does not seem to be compatible >> with the >> > > > rule of least surprise. Something like >> MessageContext.getCurrentContext() >> > > > in Axis 1 might be better. >> > > > >> > > > Bye, >> > > > Christopher. >> > > > >> > > > Davanum Srinivas wrote: >> > > > > Chris, >> > > > > >> > > > > Can you please raise a new issue in JIRA? >> > > > > >> > > > > thanks, >> > > > > dims >> > > > > >> > > > > On 9/23/06, Christopher Sahnwaldt <[EMAIL PROTECTED]> wrote: >> > > > >> Something worries me: >> > > > >> >> > > > >> > setOperationContext(OperationContext) - per call. The >> messageContext >> > > > >> > can be obtained to gain per call instance information. >> > > > >> >> > > > >> That doesn't seem to be thread-safe, does it? If I >> understand this >> > > > >> correctly, one service object is created per application (if >> the >> > > > >> service has application scope). When a request comes in, >> Axis calls >> > > > >> the setOperationContext method, and the service object may >> store the >> > > > >> OperationContext or the MessageContext. Then Axis calls the >> actual >> > > > >> service method, in which the service code can access the stored >> > > > >> OperationContext or MessageContext. But what if two requests >> come >> > > > >> in almost simultaneously? The following sequence of method >> calls >
Re: [axis2] Improvements to Service life cycle in handling - setOperationContext not thread-safe??!!
Thilina,Here is my concern. If you have application scope the expectation is that we have a single instance throught the life of the app.So I could be initializing very expensive stuff in my init() and thats ok bcos the expectation is that you do that only once. Imagine if we have to do this for every invocation bocs we choose to create a new object for every invocation?This could be a severe performance hit as I maybe doing very expensive object creations.So in my opinion we have to look at a different stratergy from a performance POV. Regards,RajithOn 10/10/06, Thilina Gunarathne <[EMAIL PROTECTED]> wrote: Ok... Here's my suggestion.. Let's create new service objects per invocation..AFAIK two things happen when we deploy a service in application scope.One is that Axis2 will maintain a single service context throughout the life of the service.. Other thing is Axis2 maintains one serviceclass object throughout the life of the service, serving for all therequests..Maintaining of the service context is really important and useful.. Users can use it to store whatever the state data that needs to sharedthroughout the life of the service. IIRC this is one of the use caseswe came up with for the Axis2 context hierarchy- to make the engine stateless..On the other hand, i don't see any reason for maintaining a singleservice object throughout the life of the service. IMO anybody can usethe ServiceContext to store whatever the state data needed to be shared across the life of the service...Are there any special caseswhere we can't do that.. If there aren't any reasons my suggestion isto create the service object per invocation.Also a user who uses the application scope might most probably be working in the messagereceiver(MR) level, since MR is known to be theultimate message recipient in Axis2. One possible example is a BPELengine.. In that case the concept of one service object for the lifetime of the service invalidates.. AFAIKS AXIS2-1133 is another implication of this design...Thanks,ThilinaOn 10/10/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:> Other choices?>> The approach we used back in ApacheSOAP was to tell the user to add an > additional first parameter to their methods if they wanted the> context .. so the signature would have an additional param and that'd> tell us to do the right thing. Very thread safe.>> Need to avoid reflection - but can be done by a codegen flag. For RPC > case its reflective anyway so its not a big deal.>> Sanjiva.>> On Tue, 2006-10-10 at 09:40 -0400, Davanum Srinivas wrote:> > Sanjiva,> >> > We had terrible problems with TLS in Axis1...let me recollect my > > thougts and post.> >> > -- dims> >> > On 10/10/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:> > > I think I agree with you. How about we drop setOperationContext() and > > > introduce Axis1-style MessageContext.getCurrentContext() which returns> > > it for this thread? Have to be careful to put it in TLS and take it off!> > >> > > We must be careful to tell users that instance variables are not > > > supported; you have to use MessageContext properties to store state (or> > > wherever else).> > >> > > Sanjiva.> > >> > > On Sun, 2006-09-24 at 14:12 +0200, Christopher Sahnwaldt wrote: > > > > Entered as http://issues.apache.org/jira/browse/AXIS2-1224 .> > > > I set the priority to blocker as David suggested. > > > >> > > > IMHO it's probably best to drop the method. Many users will use it in an> > > > intuitive but wrong way. The only way to store the data it provides is an> > > > instance variable, and telling users to either use only request scope or use > > > > a ThreadLocal to store the data does not seem to be compatible with the> > > > rule of least surprise. Something like MessageContext.getCurrentContext()> > > > in Axis 1 might be better. > > > >> > > > Bye,> > > > Christopher.> > > >> > > > Davanum Srinivas wrote:> > > > > Chris,> > > > > > > > > > Can you please raise a new issue in JIRA?> > > > >> > > > > thanks,> > > > > dims> > > > >> > > > > On 9/23/06, Christopher Sahnwaldt < [EMAIL PROTECTED]> wrote:> > > > >> Something worries me:> > > > >>> > > > >> > setOperationContext(OperationContext) - per call. The messageContext > > > > >> > can be obtained to gain per call instance information.> > > > >>> > > > >> That doesn't seem to be thread-safe, does it? If I understand this > > > > >> correctly, one service object is created per application (if the> > > > >> service has application scope). When a request comes in, Axis calls> > > > >> the setOperationContext method, and the service object may store the > > > > >> OperationContext or the MessageContext. Then Axis calls the actual> > > > >> service method, in which the service code can access the stored> > > > >> OperationContext or MessageContext. But what if two requests come > > > > >> in almost simultaneously? The following sequence of method calls> > > > >> may occur:> > > > >>> > > > >> - Axis calls setOperationContext with context for request
Re: [axis2] Improvements to Service life cycle in handling - setOperationContext not thread-safe??!!
Hi Thilina Thilina Gunarathne wrote: > Ok... Here's my suggestion.. Let's create new service objects per > invocation.. I do not agree with this approach :) , with this if some one deploy a service with application scope then there will be multiple instance of same service impl class. Deploying a service in application scope , user want to have once service impl instance (im I were a user , I want that ) btw : there was a JIRA issues on this couple of month ago. Here in ApacheCon US , we are discussed abt the this issue deeper ,and we agreed to use Sanjiva's suggestion. MessageContext.getCurrentContext(). P.S : Deepal41: hi dims [12:06]GlenD: [11:59] so we're now talking about setting a TLS OperationContext.getCurrentContext() into the AxisEngine, right before it calls the MessageReceiver [12:06]GlenD: [11:59] and putting the thread ClassLoader stuff right in the same place [12:06]GlenD: [11:59] so it's factored out of the individual MRs [12:06]dims: +1 [12:07]ruchith: +1 [12:07]ruchith: we don't have to duplicate code this way [12:07]Deepal41: in the mean time shall we move saveTCCL(messageCtx); [12:07]Deepal41: into AxisEnine too [12:07]Deepal41: what do u think dims ? [12:07]dims: ok [12:08]dims: sounds good [12:08]dims: need to get Ali to test his ejb stuff and get Robert to test spring support again after that change [12:09]GlenD: +1 [12:09]sanka has joined [12:10]Deepal41: +1 [12:12]Deepal41: one more q [12:13]Deepal41: is that OperationContext.getCurrentConetct(); [12:13]GlenD: getCurrentContext() [12:13]Deepal41: or MessageContext..getCurrentContext(); [12:14]GlenD: Personally, I prefer MC.getCurrentContext() [12:14]GlenD: but I'm fine with OC.getCurrentContext() too [12:14]Deepal41: how abt others [12:14]dims: Let's write it up and post to the list (with both options) [12:14]GlenD: I just think you don't lose anything by doing it in the MC, and it allows you to get the current MC properties without having to know which one to ask for from the OC [12:14]GlenD: sure, dims [12:15]Deepal41: ok , then let's go with MC.getCurrentContext(); [12:15]dims: was just reading email from incubator folks about not taking decisions on the irc :) [12:15]Deepal41: :) [12:16]Deepal41: hmm , I am +1 on MC.getCurrentContext(); [12:17]GlenD: hee hee [12:17]GlenD: we were just talking about IRC vs email a bit ago [12:17]dims: guys read the email from thilina as well [12:17]GlenD: k > > AFAIK two things happen when we deploy a service in application scope. > One is that Axis2 will maintain a single service context throughout > the life of the service.. Other thing is Axis2 maintains one service > class object throughout the life of the service, serving for all the > requests.. We should maintain both ,I mean - should have only one serviceContext - and only one service impl > Maintaining of the service context is really important and useful.. > Users can use it to store whatever the state data that needs to shared > throughout the life of the service. IIRC this is one of the use cases > we came up with for the Axis2 context hierarchy- to make the engine > stateless.. Totallly agrred. > > On the other hand, i don't see any reason for maintaining a single > service object throughout the life of the service. What if user want to keep local variable inside the impl class . I know that is not the best practice bt ppl are using that . > IMO anybody can use > the ServiceContext to store whatever the state data needed to be > shared across the life of the service...Are there any special cases > where we can't do that.. If there aren't any reasons my suggestion is > to create the service object per invocation. > > Also a user who uses the application scope might most probably be > working in the messagereceiver(MR) level, since MR is known to be the > ultimate message recipient in Axis2. One possible example is a BPEL > engine.. In that case the concept of one service object for the life > time of the service invalidates.. AFAIKS AXIS2-1133 is another > implication of this design... > > Thanks, > Thilina > > On 10/10/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote: > >> Other choices? >> >> The approach we used back in ApacheSOAP was to tell the user to add an >> additional first parameter to their methods if they wanted the >> context .. so the signature would have an additional param and that'd >> tell us to do the right thing. Very thread safe. >> >> Need to avoid reflection - but can be done by a codegen flag. For RPC >> case its reflective anyway so its not a big deal. >> >> Sanjiva. >> >> On Tue, 2006-10-10 at 09:40 -0400, Davanum Srinivas wrote: >> > Sanjiva, >> > >> > We had terrible problems with TLS in Axis1
Re: [Axis2] What should be included in Axis2 minimal distribution
Yes i did :) -- dims On 10/10/06, Thilina Gunarathne <[EMAIL PROTECTED]> wrote: +1... Seeems like you have already migrated it to ADB :).. ~Thilina On 10/10/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote: > Folks, > > lets move rpc* out of coden. it does not belong there. > > -- dims > > On 10/10/06, Thilina Gunarathne <[EMAIL PROTECTED]> wrote: > > Hi, > > AFAIK ADB is there because we need the RPCMessageReceiver to work in > > the minimal distro... > > Just now I figured out that RPCMessageReceiver resides in the codegen > > module..Which means we have to include codegen module to the minimal > > distro.. > > > > I'm not sure why we are putting the adb-codegen in to the minimal distro... > > > > ~Thilina > > > > On 10/10/06, Eran Chinthaka <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > Can we please re-visit the modules that should be included in Axis2 > > > minimal distribution. Currently kernel, adb and java2wsdl modules are > > > included, but I saw even adb-codegen was added recently. > > > > > > What do you think? > > > > > > Thanks, > > > Chinthaka > > > > > > > > > > > > > > > > > > -- > > http://webservices.apache.org/~thilina/ > > http://thilinag.blogspot.com/ > > > > - > > 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] > > -- http://webservices.apache.org/~thilina/ http://thilinag.blogspot.com/ - 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]
Re: [Axis2] What should be included in Axis2 minimal distribution
+1... Seeems like you have already migrated it to ADB :).. ~Thilina On 10/10/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote: Folks, lets move rpc* out of coden. it does not belong there. -- dims On 10/10/06, Thilina Gunarathne <[EMAIL PROTECTED]> wrote: > Hi, > AFAIK ADB is there because we need the RPCMessageReceiver to work in > the minimal distro... > Just now I figured out that RPCMessageReceiver resides in the codegen > module..Which means we have to include codegen module to the minimal > distro.. > > I'm not sure why we are putting the adb-codegen in to the minimal distro... > > ~Thilina > > On 10/10/06, Eran Chinthaka <[EMAIL PROTECTED]> wrote: > > Hi, > > > > Can we please re-visit the modules that should be included in Axis2 > > minimal distribution. Currently kernel, adb and java2wsdl modules are > > included, but I saw even adb-codegen was added recently. > > > > What do you think? > > > > Thanks, > > Chinthaka > > > > > > > > > > > -- > http://webservices.apache.org/~thilina/ > http://thilinag.blogspot.com/ > > - > 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] -- http://webservices.apache.org/~thilina/ http://thilinag.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [axis2] Improvements to Service life cycle in handling - setOperationContext not thread-safe??!!
Ok... Here's my suggestion.. Let's create new service objects per invocation.. AFAIK two things happen when we deploy a service in application scope. One is that Axis2 will maintain a single service context throughout the life of the service.. Other thing is Axis2 maintains one service class object throughout the life of the service, serving for all the requests.. Maintaining of the service context is really important and useful.. Users can use it to store whatever the state data that needs to shared throughout the life of the service. IIRC this is one of the use cases we came up with for the Axis2 context hierarchy- to make the engine stateless.. On the other hand, i don't see any reason for maintaining a single service object throughout the life of the service. IMO anybody can use the ServiceContext to store whatever the state data needed to be shared across the life of the service...Are there any special cases where we can't do that.. If there aren't any reasons my suggestion is to create the service object per invocation. Also a user who uses the application scope might most probably be working in the messagereceiver(MR) level, since MR is known to be the ultimate message recipient in Axis2. One possible example is a BPEL engine.. In that case the concept of one service object for the life time of the service invalidates.. AFAIKS AXIS2-1133 is another implication of this design... Thanks, Thilina On 10/10/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote: Other choices? The approach we used back in ApacheSOAP was to tell the user to add an additional first parameter to their methods if they wanted the context .. so the signature would have an additional param and that'd tell us to do the right thing. Very thread safe. Need to avoid reflection - but can be done by a codegen flag. For RPC case its reflective anyway so its not a big deal. Sanjiva. On Tue, 2006-10-10 at 09:40 -0400, Davanum Srinivas wrote: > Sanjiva, > > We had terrible problems with TLS in Axis1...let me recollect my > thougts and post. > > -- dims > > On 10/10/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote: > > I think I agree with you. How about we drop setOperationContext() and > > introduce Axis1-style MessageContext.getCurrentContext() which returns > > it for this thread? Have to be careful to put it in TLS and take it off! > > > > We must be careful to tell users that instance variables are not > > supported; you have to use MessageContext properties to store state (or > > wherever else). > > > > Sanjiva. > > > > On Sun, 2006-09-24 at 14:12 +0200, Christopher Sahnwaldt wrote: > > > Entered as http://issues.apache.org/jira/browse/AXIS2-1224 . > > > I set the priority to blocker as David suggested. > > > > > > IMHO it's probably best to drop the method. Many users will use it in an > > > intuitive but wrong way. The only way to store the data it provides is an > > > instance variable, and telling users to either use only request scope or use > > > a ThreadLocal to store the data does not seem to be compatible with the > > > rule of least surprise. Something like MessageContext.getCurrentContext() > > > in Axis 1 might be better. > > > > > > Bye, > > > Christopher. > > > > > > Davanum Srinivas wrote: > > > > Chris, > > > > > > > > Can you please raise a new issue in JIRA? > > > > > > > > thanks, > > > > dims > > > > > > > > On 9/23/06, Christopher Sahnwaldt <[EMAIL PROTECTED]> wrote: > > > >> Something worries me: > > > >> > > > >> > setOperationContext(OperationContext) - per call. The messageContext > > > >> > can be obtained to gain per call instance information. > > > >> > > > >> That doesn't seem to be thread-safe, does it? If I understand this > > > >> correctly, one service object is created per application (if the > > > >> service has application scope). When a request comes in, Axis calls > > > >> the setOperationContext method, and the service object may store the > > > >> OperationContext or the MessageContext. Then Axis calls the actual > > > >> service method, in which the service code can access the stored > > > >> OperationContext or MessageContext. But what if two requests come > > > >> in almost simultaneously? The following sequence of method calls > > > >> may occur: > > > >> > > > >> - Axis calls setOperationContext with context for request A, the > > > >> service object stores the context in an instance field. > > > >> - Axis calls setOperationContext with context for request B, the same > > > >> service object stores the context in the same instance field and > > > >> thus *overwrites* the context for call A. > > > >> - Axis calls the service method with the input parameters for request A. > > > >> - The service method processes the call, using data from the stored > > > >> context, and thus *mixes the input parameters for call A with the > > > >> context data for call B*. Anything can happen... > > > >> - Finally, Axis calls the service method with the input parameters > > > >> for
[jira] Commented: (AXIS2-1319) Redeployment of service with '.' in aar name fails
[ http://issues.apache.org/jira/browse/AXIS2-1319?page=comments#action_12441209 ] Jeff Peterson commented on AXIS2-1319: -- I need to try and reproduce this issue in a clean environment. There were a lot of things going wrong with that app server when I reported the bug. > Redeployment of service with '.' in aar name fails > -- > > Key: AXIS2-1319 > URL: http://issues.apache.org/jira/browse/AXIS2-1319 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug > Components: deployment >Affects Versions: 1.0 >Reporter: Jeff Peterson > > There seems to be a problem with service archives having names like > "service-2.0.aar". I presume its an issue with the additional "." in the > archive name not being handled correctly. It seems that the service group > name is being set to "service-2" instead of "service-2.0". > My services.xml looks like the following: > > > > > > Here's what I did and the accompanying error message: > 1. Deploy service "service-1.0.aar" by dropping it in the > "axis2/WEB-INF/services" directory > 2. Make change to service, and repackage. > 3. Redeploy service "service-1.0.aar" by dropping it in the > "axis2/WEB-INF/services" directory > 4. Notice the following errors in server log > ... > 06 Oct 2006 16:52:34,330 DEBUG ProjectResourceBundle []: > org.apache.axis2.i18n.resource::handleGetObject(invalidservicegroupname) > 06 Oct 2006 16:52:34,330 DEBUG ProjectResourceBundle []: > org.apache.axis2.i18n.resource::handleGetObject(invalidservicegroupname) > 06 Oct 2006 16:52:34,331 INFO DeploymentEngine []: > org.apache.axis2.AxisFault: invalid service group name : service-2 > 06 Oct 2006 16:52:34,331 INFO DeploymentEngine []: > org.apache.axis2.AxisFault: invalid service group name : service-2 > 06 Oct 2006 17:02:17,944 DEBUG ProjectResourceBundle []: > org.apache.axis2.i18n.resource::handleGetObject(twoservicecannothavesamename) > 06 Oct 2006 17:02:17,945 ERROR DeploymentEngine []: Invalid service > service-2.0.aar due to Two services can not have same name, a service with > TestWebService already exists in the system org.apache.axis2.AxisFault: Two > services can not have same name, a service with TestWebService already exists > in the system > at > org.apache.axis2.engine.AxisConfiguration.addServiceGroup(AxisConfigu > ration.java:198) > at > org.apache.axis2.deployment.DeploymentEngine.addServiceGroup(Deployme > ntEngine.java:438) > e.java:624) > at > org.apache.axis2.deployment.repository.util.WSInfoList.update(WSInfoL > ist.java:195) > at > org.apache.axis2.deployment.RepositoryListener.update(RepositoryListe > ner.java:207) > ... -- 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][1.1-RC1] Security sample is not included
Hi Dims, What I did in the 1.1-RC1 was to version the modules as 1.09 to avoid this issue... Thanks, Thilina On 10/10/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote: On Tue, 2006-10-10 at 08:57 -0400, Davanum Srinivas wrote: > Will that load when dropped as-is into a repo? I remember we nixed the > SNAPSHOT off the name of the mar to prevent such problems. You'd have to engage as "rampart-SNAPSHOT" but otherwise should work fine. Deepal?? Sanjiva. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://webservices.apache.org/~thilina/ http://thilinag.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-749) Mixing compile time and runtime support in codegen jar
[ http://issues.apache.org/jira/browse/AXIS2-749?page=all ] Davanum Srinivas resolved AXIS2-749. Resolution: Fixed Fixed in r454806 (1.1 branch) -- dims > Mixing compile time and runtime support in codegen jar > -- > > Key: AXIS2-749 > URL: http://issues.apache.org/jira/browse/AXIS2-749 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug >Reporter: Davanum Srinivas > Assigned To: Deepal Jayasinghe > > org.apache.axis2.rpc.receivers.RPCMessageReceiver is currently in > axis2-codegen-SNAPSHOT.jar...why "codegen"? can we please have just the > compile/build time stuff in "codegen"? -- 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-749) Mixing compile time and runtime support in codegen jar
[ http://issues.apache.org/jira/browse/AXIS2-749?page=comments#action_12441185 ] Davanum Srinivas commented on AXIS2-749: Again, the idea is that you should be able to deploy rpc/pojo using just the min distro. -- dims > Mixing compile time and runtime support in codegen jar > -- > > Key: AXIS2-749 > URL: http://issues.apache.org/jira/browse/AXIS2-749 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug >Reporter: Davanum Srinivas > Assigned To: Deepal Jayasinghe > > org.apache.axis2.rpc.receivers.RPCMessageReceiver is currently in > axis2-codegen-SNAPSHOT.jar...why "codegen"? can we please have just the > compile/build time stuff in "codegen"? -- 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-749) Mixing compile time and runtime support in codegen jar
[ http://issues.apache.org/jira/browse/AXIS2-749?page=comments#action_12441182 ] Davanum Srinivas commented on AXIS2-749: Problem shows up in user environments. we need to to this... http://marc.theaimsgroup.com/?l=axis-dev&m=116047863220600&w=2 the code relies on adb. so the 2 choices are to create a new module/jar and make that depend on adb or just move the package as-is to ADB. I am going to try doing the latter as it is least problematic w.r.t build/release process. thanks, dims > Mixing compile time and runtime support in codegen jar > -- > > Key: AXIS2-749 > URL: http://issues.apache.org/jira/browse/AXIS2-749 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug >Reporter: Davanum Srinivas > Assigned To: Deepal Jayasinghe > > org.apache.axis2.rpc.receivers.RPCMessageReceiver is currently in > axis2-codegen-SNAPSHOT.jar...why "codegen"? can we please have just the > compile/build time stuff in "codegen"? -- 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-1339) WSDL2Java client side stub code does not work with AXIS2 TCP Server
WSDL2Java client side stub code does not work with AXIS2 TCP Server
---
Key: AXIS2-1339
URL: http://issues.apache.org/jira/browse/AXIS2-1339
Project: Apache Axis 2.0 (Axis2)
Issue Type: Bug
Components: core
Affects Versions: 1.1
Environment: Sun JVM 1.5, Axis2 1.1, WinXP
Reporter: yogen
Priority: Critical
The sample service axis2-rc1\samples\userguide\MyService.aar and client
\axis2-rc1\samples\userguide\src\userguide\clients\TCPClient.java *works* with
AXIS2 TCP Server.
But the code generated using wsdl2java for
\axis2-rc1\samples\wsdl\Axis2SampleDocLit.wsdl and service
Axis2SampleDocLitService.aar *does not work* with AXIS2 TCP Server (works with
HTTP Server).
1. the code is generated like this: >wsdl2java -d xmlbeans -p com.sample -ss
-sd -g -uri Axis2SampleDocLit.wsdl -pn Axis2SampleDocLitPort
2. the service runs on port 6060.
3. Running the client code throws this exception stack trace:
Oct 10, 2006 12:06:02 PM org.apache.axis2.deployment.DeploymentEngine doDeploy
INFO: Deploying module : addressing-1.09
org.apache.axis2.AxisFault: Service not found operation terminated !!
at
org.apache.axis2.description.OutInAxisOperationClient.execute(OutInAxisOperation.java:294)
at
com.sample.Axis2SampleDocLitServiceStub.echoString(Axis2SampleDocLitServiceStub.java:505)
at TCP1Client.echoString(TCP1Client.java:28)
at TCP1Client.main(TCP1Client.java:17)
The client code is attached:
import javax.xml.namespace.QName;
import org.apache.axis2.Constants;
import org.apache.axis2.addressing.EndpointReference;
import org.apache.axis2.userguide.xsd.*;
import com.sample.*;
public class TCP1Client{
public static void main(java.lang.String args[]){
Axis2SampleDocLitServiceStub stub = null;
try{
stub = new Axis2SampleDocLitServiceStub(null,
"tcp://localhost:6060/axis2/services/Axis2SampleDocLitService");
stub._getServiceClient().getOptions().setTo(new
EndpointReference("tcp://localhost:6060/axis2/services/Axis2SampleDocLitService"));
stub._getServiceClient().getOptions().setTransportInProtocol(Constants.TRANSPORT_TCP);
stub._getServiceClient().engageModule(new
QName(Constants.MODULE_ADDRESSING));
System.out.println(echoString(stub));
} catch(Exception e){
e.printStackTrace();
}
}
public static String echoString(Axis2SampleDocLitServiceStub stub){
try{
EchoStringParamDocument reqDoc00 =
EchoStringParamDocument.Factory.newInstance();
reqDoc00.setEchoStringParam("echo");
EchoStringReturnDocument resDoc00 = stub.echoString(reqDoc00);
return resDoc00.getEchoStringReturn();
} catch(Exception e){
e.printStackTrace();
}
return null;
}
}
--
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-586) CLONE -Axis2 does not deserialise abstract types correctly when receiving WSA messages
[ http://issues.apache.org/jira/browse/AXIS2-586?page=comments#action_12441169 ] Justin Schoeman commented on AXIS2-586: --- The client code is on: http://www.schoeman.org.za/axis2_test_client.tbz It is hard coded to call either of the test methods (ConfirmCustomerRequest or CreditVendRequest). Thanks, -justin > CLONE -Axis2 does not deserialise abstract types correctly when receiving WSA > messages > -- > > Key: AXIS2-586 > URL: http://issues.apache.org/jira/browse/AXIS2-586 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug >Affects Versions: 0.94 > Environment: Suse Linux 9.3 Server, Tomcat 5.0, Axis2 0.94 >Reporter: Justin Schoeman > Assigned To: Ajith Harshana Ranabahu > > When receiving WSA encoded messages containing abstract types, the created > objects are for the implementation of the abstract class, instead of the > actual type sent over the wire. > In the following example, DeviceID is an abstract type, and EANDeviceID is an > implementation of that type. The following information is obtained from the > deserialised DeviceID object (which is sent as an EANDeviceID object): > WSA: > getClass().getName(): > za.co.eskom.nrs.www.xmlvend.base._2_0.schema.impl.DeviceIDImpl > schemaType(): [EMAIL PROTECTED]://www.nrs.eskom.co.za/xmlvend/base/2.0/schema > toString(): xmlns:sch="http://www.nrs.eskom.co.za/xmlvend/base/2.0/schema"/> > XSI: > getClass().getName(): > za.co.eskom.nrs.www.xmlvend.base._2_0.schema.impl.GenericDeviceIDImpl > schemaType(): [EMAIL PROTECTED]://www.nrs.eskom.co.za/xmlvend/base/2.0/schema > toString(): xmlns:sch="http://www.nrs.eskom.co.za/xmlvend/base/2.0/schema"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/> > As you can see, in both cases, the correct information is contained in the > xmlbean, but for the WSA message it is deserialised incorrectly. > -justin -- 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-586) CLONE -Axis2 does not deserialise abstract types correctly when receiving WSA messages
[ http://issues.apache.org/jira/browse/AXIS2-586?page=comments#action_12441165 ] Davanum Srinivas commented on AXIS2-586: Justin, Could you please upload your java test code that you use to send the message? I am assuming you ran w2j on the wsdl's in the prev comment. thanks, dims > CLONE -Axis2 does not deserialise abstract types correctly when receiving WSA > messages > -- > > Key: AXIS2-586 > URL: http://issues.apache.org/jira/browse/AXIS2-586 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug >Affects Versions: 0.94 > Environment: Suse Linux 9.3 Server, Tomcat 5.0, Axis2 0.94 >Reporter: Justin Schoeman > Assigned To: Ajith Harshana Ranabahu > > When receiving WSA encoded messages containing abstract types, the created > objects are for the implementation of the abstract class, instead of the > actual type sent over the wire. > In the following example, DeviceID is an abstract type, and EANDeviceID is an > implementation of that type. The following information is obtained from the > deserialised DeviceID object (which is sent as an EANDeviceID object): > WSA: > getClass().getName(): > za.co.eskom.nrs.www.xmlvend.base._2_0.schema.impl.DeviceIDImpl > schemaType(): [EMAIL PROTECTED]://www.nrs.eskom.co.za/xmlvend/base/2.0/schema > toString(): xmlns:sch="http://www.nrs.eskom.co.za/xmlvend/base/2.0/schema"/> > XSI: > getClass().getName(): > za.co.eskom.nrs.www.xmlvend.base._2_0.schema.impl.GenericDeviceIDImpl > schemaType(): [EMAIL PROTECTED]://www.nrs.eskom.co.za/xmlvend/base/2.0/schema > toString(): xmlns:sch="http://www.nrs.eskom.co.za/xmlvend/base/2.0/schema"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/> > As you can see, in both cases, the correct information is contained in the > xmlbean, but for the WSA message it is deserialised incorrectly. > -justin -- 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-1252) java2wsdl generates unknown namespace
[ http://issues.apache.org/jira/browse/AXIS2-1252?page=comments#action_12441163 ] Kinichiro Inoguchi commented on AXIS2-1252: --- I see. I fully agreed with your algorithm. > java2wsdl generates unknown namespace > - > > Key: AXIS2-1252 > URL: http://issues.apache.org/jira/browse/AXIS2-1252 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Improvement > Components: wsdl >Reporter: Kinichiro Inoguchi >Priority: Blocker > > This issue comes from user mailing list. > http://marc.theaimsgroup.com/?t=11593771594&r=1&w=2 > java2wsdl generates unknown namespace, "http://test/xsd";. > I'm using current nightly. > My service class has method "sayHello", > and returns array of simple java beans "HelloBean". > Then I run java2wsdl, sayHello and sayHelloResponse > are in namespace "http://aaa.bbb/types";. > But, HelloBean is in unknown namespace "http://test/xsd";. > Is this a bug ? > C:\axis2-std-SNAPSHOT-bin\bin\java2wsdl.bat > -cn test.TestService1 -cp . > -tn http://aaa.bbb -tp xxx > -stn http://aaa.bbb/types -stp yyy > -sn TestService1 -of TestService1.wsdl > generated WSDL is like this; > http://schemas.xmlsoap.org/wsdl/soap12/"; > xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"; > xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"; > xmlns:ns1="http://aaa.bbb/types"; xmlns:xxx="http://aaa.bbb"; > xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"; > xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"; > targetNamespace="http://aaa.bbb";> > > http://www.w3.org/2001/XMLSchema"; > xmlns:ax22="http://test/xsd"; targetNamespace="http://test/xsd"; > attributeFormDefault="qualified" elementFormDefault="qualified"> > > > > > > > > > > > > > > http://www.w3.org/2001/XMLSchema"; > xmlns:gen798="http://test/xsd"; xmlns:ax21="http://aaa.bbb/types"; > targetNamespace="http://aaa.bbb/types"; attributeFormDefault="qualified" > elementFormDefault="qualified"> > > > > > > > > > > > > > > > > >type="gen798:HelloBean" nillable="true" /> > > > > > > ... -- 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-586) CLONE -Axis2 does not deserialise abstract types correctly when receiving WSA messages
[ http://issues.apache.org/jira/browse/AXIS2-586?page=comments#action_12441160 ] Justin Schoeman commented on AXIS2-586: --- Just finished testing with the 4 October nightly build. Results are the same as previous tests. The ID is still deserialised as DeviceIDImpl instead of GenericDeviceIDImpl. The only significant difference is that an empty setAction in the client stub now generates an: Operation Not found EPR is ... error, where this did work correctly in the last 1.0 RC that I tested. (Although I am not sure why this is not set in the wsdl file...) I will try test with ADB as well now, seeing as this seems to generate compilable code now. -justin > CLONE -Axis2 does not deserialise abstract types correctly when receiving WSA > messages > -- > > Key: AXIS2-586 > URL: http://issues.apache.org/jira/browse/AXIS2-586 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug >Affects Versions: 0.94 > Environment: Suse Linux 9.3 Server, Tomcat 5.0, Axis2 0.94 >Reporter: Justin Schoeman > Assigned To: Ajith Harshana Ranabahu > > When receiving WSA encoded messages containing abstract types, the created > objects are for the implementation of the abstract class, instead of the > actual type sent over the wire. > In the following example, DeviceID is an abstract type, and EANDeviceID is an > implementation of that type. The following information is obtained from the > deserialised DeviceID object (which is sent as an EANDeviceID object): > WSA: > getClass().getName(): > za.co.eskom.nrs.www.xmlvend.base._2_0.schema.impl.DeviceIDImpl > schemaType(): [EMAIL PROTECTED]://www.nrs.eskom.co.za/xmlvend/base/2.0/schema > toString(): xmlns:sch="http://www.nrs.eskom.co.za/xmlvend/base/2.0/schema"/> > XSI: > getClass().getName(): > za.co.eskom.nrs.www.xmlvend.base._2_0.schema.impl.GenericDeviceIDImpl > schemaType(): [EMAIL PROTECTED]://www.nrs.eskom.co.za/xmlvend/base/2.0/schema > toString(): xmlns:sch="http://www.nrs.eskom.co.za/xmlvend/base/2.0/schema"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/> > As you can see, in both cases, the correct information is contained in the > xmlbean, but for the WSA message it is deserialised incorrectly. > -justin -- 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-1252) java2wsdl generates unknown namespace
[ http://issues.apache.org/jira/browse/AXIS2-1252?page=comments#action_12441155 ] Davanum Srinivas commented on AXIS2-1252: - We use the following in w2j: -ns2p ns1=pkg1,ns2=pkg2 Specify a custom package name for each namespace specified in the wsdls schema. In Axis1, we could do it from the command line or pick it up from a properties file. -- dims > java2wsdl generates unknown namespace > - > > Key: AXIS2-1252 > URL: http://issues.apache.org/jira/browse/AXIS2-1252 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Improvement > Components: wsdl >Reporter: Kinichiro Inoguchi >Priority: Blocker > > This issue comes from user mailing list. > http://marc.theaimsgroup.com/?t=11593771594&r=1&w=2 > java2wsdl generates unknown namespace, "http://test/xsd";. > I'm using current nightly. > My service class has method "sayHello", > and returns array of simple java beans "HelloBean". > Then I run java2wsdl, sayHello and sayHelloResponse > are in namespace "http://aaa.bbb/types";. > But, HelloBean is in unknown namespace "http://test/xsd";. > Is this a bug ? > C:\axis2-std-SNAPSHOT-bin\bin\java2wsdl.bat > -cn test.TestService1 -cp . > -tn http://aaa.bbb -tp xxx > -stn http://aaa.bbb/types -stp yyy > -sn TestService1 -of TestService1.wsdl > generated WSDL is like this; > http://schemas.xmlsoap.org/wsdl/soap12/"; > xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"; > xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"; > xmlns:ns1="http://aaa.bbb/types"; xmlns:xxx="http://aaa.bbb"; > xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"; > xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"; > targetNamespace="http://aaa.bbb";> > > http://www.w3.org/2001/XMLSchema"; > xmlns:ax22="http://test/xsd"; targetNamespace="http://test/xsd"; > attributeFormDefault="qualified" elementFormDefault="qualified"> > > > > > > > > > > > > > > http://www.w3.org/2001/XMLSchema"; > xmlns:gen798="http://test/xsd"; xmlns:ax21="http://aaa.bbb/types"; > targetNamespace="http://aaa.bbb/types"; attributeFormDefault="qualified" > elementFormDefault="qualified"> > > > > > > > > > > > > > > > > >type="gen798:HelloBean" nillable="true" /> > > > > > > ... -- 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-1252) java2wsdl generates unknown namespace
[ http://issues.apache.org/jira/browse/AXIS2-1252?page=comments#action_12441152 ] Kinichiro Inoguchi commented on AXIS2-1252: --- dims, Venkat, Deepal, Thanks for your discussions. I agree with algorithm of dims, and I believe current SVN implements #1 and #3. But I think algorithm #2 seems difficult to use, because I can't imagine how to specify MANY schematargetnamespace. Do you mean like this ? command line option of java2wsdl java2wsdl -stn test1=http://aaa/ -stn test2=http://bbb/ ... services.xml http://aaa/"/> http://bbb/"/> This examples, test1 and test2 means package of class. > java2wsdl generates unknown namespace > - > > Key: AXIS2-1252 > URL: http://issues.apache.org/jira/browse/AXIS2-1252 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Improvement > Components: wsdl >Reporter: Kinichiro Inoguchi >Priority: Blocker > > This issue comes from user mailing list. > http://marc.theaimsgroup.com/?t=11593771594&r=1&w=2 > java2wsdl generates unknown namespace, "http://test/xsd";. > I'm using current nightly. > My service class has method "sayHello", > and returns array of simple java beans "HelloBean". > Then I run java2wsdl, sayHello and sayHelloResponse > are in namespace "http://aaa.bbb/types";. > But, HelloBean is in unknown namespace "http://test/xsd";. > Is this a bug ? > C:\axis2-std-SNAPSHOT-bin\bin\java2wsdl.bat > -cn test.TestService1 -cp . > -tn http://aaa.bbb -tp xxx > -stn http://aaa.bbb/types -stp yyy > -sn TestService1 -of TestService1.wsdl > generated WSDL is like this; > http://schemas.xmlsoap.org/wsdl/soap12/"; > xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"; > xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"; > xmlns:ns1="http://aaa.bbb/types"; xmlns:xxx="http://aaa.bbb"; > xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"; > xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"; > targetNamespace="http://aaa.bbb";> > > http://www.w3.org/2001/XMLSchema"; > xmlns:ax22="http://test/xsd"; targetNamespace="http://test/xsd"; > attributeFormDefault="qualified" elementFormDefault="qualified"> > > > > > > > > > > > > > > http://www.w3.org/2001/XMLSchema"; > xmlns:gen798="http://test/xsd"; xmlns:ax21="http://aaa.bbb/types"; > targetNamespace="http://aaa.bbb/types"; attributeFormDefault="qualified" > elementFormDefault="qualified"> > > > > > > > > > > > > > > > > >type="gen798:HelloBean" nillable="true" /> > > > > > > ... -- 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] Improvements to Service life cycle in handling - setOperationContext not thread-safe??!!
Other choices? The approach we used back in ApacheSOAP was to tell the user to add an additional first parameter to their methods if they wanted the context .. so the signature would have an additional param and that'd tell us to do the right thing. Very thread safe. Need to avoid reflection - but can be done by a codegen flag. For RPC case its reflective anyway so its not a big deal. Sanjiva. On Tue, 2006-10-10 at 09:40 -0400, Davanum Srinivas wrote: > Sanjiva, > > We had terrible problems with TLS in Axis1...let me recollect my > thougts and post. > > -- dims > > On 10/10/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote: > > I think I agree with you. How about we drop setOperationContext() and > > introduce Axis1-style MessageContext.getCurrentContext() which returns > > it for this thread? Have to be careful to put it in TLS and take it off! > > > > We must be careful to tell users that instance variables are not > > supported; you have to use MessageContext properties to store state (or > > wherever else). > > > > Sanjiva. > > > > On Sun, 2006-09-24 at 14:12 +0200, Christopher Sahnwaldt wrote: > > > Entered as http://issues.apache.org/jira/browse/AXIS2-1224 . > > > I set the priority to blocker as David suggested. > > > > > > IMHO it's probably best to drop the method. Many users will use it in an > > > intuitive but wrong way. The only way to store the data it provides is an > > > instance variable, and telling users to either use only request scope or > > > use > > > a ThreadLocal to store the data does not seem to be compatible with the > > > rule of least surprise. Something like MessageContext.getCurrentContext() > > > in Axis 1 might be better. > > > > > > Bye, > > > Christopher. > > > > > > Davanum Srinivas wrote: > > > > Chris, > > > > > > > > Can you please raise a new issue in JIRA? > > > > > > > > thanks, > > > > dims > > > > > > > > On 9/23/06, Christopher Sahnwaldt <[EMAIL PROTECTED]> wrote: > > > >> Something worries me: > > > >> > > > >> > setOperationContext(OperationContext) - per call. The messageContext > > > >> > can be obtained to gain per call instance information. > > > >> > > > >> That doesn't seem to be thread-safe, does it? If I understand this > > > >> correctly, one service object is created per application (if the > > > >> service has application scope). When a request comes in, Axis calls > > > >> the setOperationContext method, and the service object may store the > > > >> OperationContext or the MessageContext. Then Axis calls the actual > > > >> service method, in which the service code can access the stored > > > >> OperationContext or MessageContext. But what if two requests come > > > >> in almost simultaneously? The following sequence of method calls > > > >> may occur: > > > >> > > > >> - Axis calls setOperationContext with context for request A, the > > > >> service object stores the context in an instance field. > > > >> - Axis calls setOperationContext with context for request B, the same > > > >> service object stores the context in the same instance field and > > > >> thus *overwrites* the context for call A. > > > >> - Axis calls the service method with the input parameters for request > > > >> A. > > > >> - The service method processes the call, using data from the stored > > > >> context, and thus *mixes the input parameters for call A with the > > > >> context data for call B*. Anything can happen... > > > >> - Finally, Axis calls the service method with the input parameters > > > >> for call B, the service method processes the call, using data from > > > >> the stored context, and thus correctly uses the input parameters > > > >> for call B with the context data for call B. Probably ok, unless > > > >> the service method updated the context in some way during the call > > > >> for request A. > > > >> > > > >> But I hope I'm wrong or misunderstood or forgot something... ;-) > > > >> > > > >> Axis 1 avoided this problem by MessageContext.getCurrentContext(), > > > >> which gives access to the MessageContext *for the current thread* > > > >> from within any service method, without the need for a > > > >> setMessageContext (or setOperationContext) method on the service > > > >> object. > > > >> > > > >> Bye, > > > >> Christopher. > > > >> > > > >> > > > >> Tony Dean wrote: > > > >> > > > >> > Can we fully document the logical semantics behind each method? > > > >> > > > > >> > init(ServiceContext) - To me this use to mean application init. > > > >> Now it means session init. However, when running > > > >> scope="Application", it is analogous to application init since you > > > >> will only have one session; but, still probably not appropriate to > > > >> think in those terms. > > > >> > > > > >> > How should an application use this method? A session use-case > > > >> would be nice. > > > >> > > > > >> > destroy(ServiceContext) - inverse of init() > > > >> > Use-case? > > > >> > > > > >> > setOperationContext(OperationContext)
Re: [jira] Commented: (AXIS2-1334) Deployment of Sandesha2 causes exception in Axis2 Admin-Frontend
Hi Thilo, Yes. Sandesha2 1.0 release does not work with the Axis2 1.0 RC1 release. But we hope to do a Sandesha2 release compatible with Axis2 1.1 after it get release. For now you'll have to work with Sandesha2 SNAPSHOTs from http://people.apache.org/repository/sandesha2/ BTW the Sandesha2 releases and compatible Axis2 versions are given here http://ws.apache.org/sandesha/sandesha2/download.cgi Chamikara On 10/10/06, Thilo Frotscher (JIRA) <[EMAIL PROTECTED]> wrote: [ http://issues.apache.org/jira/browse/AXIS2-1334?page=comments#action_12441104 ]Thilo Frotscher commented on AXIS2-1334: I investigated further... Sandesha2 1.0 works fine with Axis2 1.0 but not with Axis2 1.1 RC1. But I don't know whether this is an issue with Axis2 1.1 or whether there is just a new Sandesha2 release needed. In the latter case, it should be documented in the Sandesha2 user guide which Sandesha release works with which Axis2 release.> Deployment of Sandesha2 causes exception in Axis2 Admin-Frontend> > > Key: AXIS2-1334> URL: http://issues.apache.org/jira/browse/AXIS2-1334> Project: Apache Axis 2.0 (Axis2)> Issue Type: Bug> Components: core >Affects Versions: 1.1> Environment: Axis2 1.1 RC1> Sandesha2 1.0>Reporter: Thilo Frotscher>Priority: Blocker>> - deploy a fresh Axis2 1.1 RC1 into Tomcat> - startup Tomcat> - check out Axis2 Web Admin Frontend with browser - works fine!> - shut down Tomcat> - copy sandesha2-1.0.mar into WEB-INF/modules> - add name of module archive to modules.list (not sure if this step is needed, but bug occurs with or without this step!)> - add RMPhase to all four flows, according to Sandesha2 user guide: http://ws.apache.org/sandesha/sandesha2/userGuide.html> - start up Tomcat> - check out Axis2 Web Admin Frontend with browser - Exception!> TOMCAT's LOG FILE> => java.lang.NoSuchMethodError : org.apache.axis2.description.PolicyInclude.getEffectivePolicy()Lorg/apache/ws/policy/Policy;> at org.apache.sandesha2.util.PropertyManager.loadPropertiesFromModuleDescPolicy(PropertyManager.java:158)> at org.apache.sandesha2.SandeshaModule.init(SandeshaModule.java:50)> at org.apache.axis2.context.ConfigurationContextFactory.initModules(ConfigurationContextFactory.java:217)> at org.apache.axis2.context.ConfigurationContextFactory.init (ConfigurationContextFactory.java:193)> at org.apache.axis2.context.ConfigurationContextFactory.createConfigurationContext(ConfigurationContextFactory.java:70)> at org.apache.axis2.transport.http.AxisServlet.initConfigContext (AxisServlet.java:366)> at org.apache.axis2.transport.http.AxisServlet.init(AxisServlet.java:304)> at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1105)> at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:932)> at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3917)> at org.apache.catalina.core.StandardContext.start (StandardContext.java:4197)> at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)> at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)> at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)> at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:809)> at org.apache.catalina.startup.HostConfig.deployWARs (HostConfig.java:698)> at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:472)> at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1112)> at org.apache.catalina.startup.HostConfig.lifecycleEvent (HostConfig.java:310)> at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)> at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1021)> at org.apache.catalina.core.StandardHost.start(StandardHost.java:718)> at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013)> at org.apache.catalina.core.StandardEngine.start(StandardEngine.java :442)> at org.apache.catalina.core.StandardService.start(StandardService.java:450)> at org.apache.catalina.core.StandardServer.start(StandardServer.java:709)> at org.apache.catalina.startup.Catalina.start (Catalina.java:551)> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)> at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25)> at java.lang.reflect.Method.invoke(Method.java:585)> at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:275)> at org.apache.catalina.startup.Bootstrap.main (Bootstrap.java:413)> BROW
[jira] Updated: (AXIS2-1102) schema generation for .aar when ServiceObjectSupplier and SpringBeanName given with *RPCMessagaReceiver
[ http://issues.apache.org/jira/browse/AXIS2-1102?page=all ] Davanum Srinivas updated AXIS2-1102: Component/s: rpc (was: core) > schema generation for .aar when ServiceObjectSupplier and SpringBeanName > given with *RPCMessagaReceiver > --- > > Key: AXIS2-1102 > URL: http://issues.apache.org/jira/browse/AXIS2-1102 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Improvement > Components: rpc > Environment: Any >Reporter: Saminda Wishwajith Abeyruwan > Assigned To: Deepal Jayasinghe > > An .aar can hold either "ServiceClass" or "ServiceObjectSupplier and > SpringBeanName" to get the service object. In the first case with > RPCMessageReceiver schema to this service will be generated. In the later > case if the MR is RPCMR the generation of schema has not been implemented. -- 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-1285) Invalid namespace in response by RPCMessagaReceiver
[ http://issues.apache.org/jira/browse/AXIS2-1285?page=all ] Davanum Srinivas updated AXIS2-1285: Component/s: rpc (was: core) > Invalid namespace in response by RPCMessagaReceiver > --- > > Key: AXIS2-1285 > URL: http://issues.apache.org/jira/browse/AXIS2-1285 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug > Components: rpc >Reporter: Kinichiro Inoguchi > Attachments: WsdlTest2.aar > > > I found this issue when I fight with AXIS2-805 and AXIS2-1252. > With my service, I defined namespace like these; > - definitions namespace = none (default to http://ws.apache.org/axis2) > - schema namespace = http://ws.aaa.bbb/types > - HelloBean = http://test/xsd (comes from package 'test') > You can call this by REST, > http://localhost:8080/axis2/rest/WsdlTest2/sayHello?var1=xyz&var2=123&var3=9&var4=123.456&var5=4.0&var6=789&var7=true > And you can get response like this, > http://ws.aaa.bbb/types";> > > xyz > 123 > 9 > 123.456 > 4.0 > 789 > true > > > xyzxyz > 246 > 18 > 246.912 > 8.0 > 789 > true > > > Response has namespace "http://ws.aaa.bbb/types"; only. > I think some part should have "http://test/xsd";. > Thanks. -- 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-1226) [RPC] Can't deserialize a nil parameter to null
[ http://issues.apache.org/jira/browse/AXIS2-1226?page=all ]
Davanum Srinivas updated AXIS2-1226:
Component/s: rpc
(was: databinding)
> [RPC] Can't deserialize a nil parameter to null
> ---
>
> Key: AXIS2-1226
> URL: http://issues.apache.org/jira/browse/AXIS2-1226
> Project: Apache Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: rpc
>Affects Versions: 1.1
>Reporter: takanori
>
> When I use RPCMessageReciver, can't deserialize a nil parameter to null.
> Send data
> --
> http://schemas.xmlsoap.org/soap/envelope/";>
>
>
> http://examples/xsd";>
> http://www.w3.org/2001/XMLSchema-instance";
> nil:nil="true" />
>
>
>
> --
> I hope that "strParam" is deserialized to null, but it is empty("").
> I think that there is a problem in
> org.apache.axis2.databinding.typemapping.SimpleTypeMapper#getSimpleTypeObject
> The method don't judge nil.
--
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-1227) [RPC] Deserializing a array parameter is invalid
[ http://issues.apache.org/jira/browse/AXIS2-1227?page=all ]
Davanum Srinivas updated AXIS2-1227:
Component/s: rpc
> [RPC] Deserializing a array parameter is invalid
>
>
> Key: AXIS2-1227
> URL: http://issues.apache.org/jira/browse/AXIS2-1227
> Project: Apache Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: rpc
>Affects Versions: 1.1
>Reporter: takanori
>
> When I use RPCMessageReciver, fail to deserializie a array parameter.
> Service
> ---
> public SampleDto echo(SampleDto dto) {
> // do something.
> }
> ---
> SampleDto
> ---
> public class SampleDto {
> private StringstrParam= "echo";
> private short shortParam = 1;
> private int intParam= 2;
> private long longParam = 3L;
> private float floatParam = 1.0f;
> private doubledoubleParam = 1.1;
> private boolean boolParam = true;
> private String[] stringArray = null;
> // setter/getter
> }
> ---
> If I send the array ["a", "b", "c"](stringArray ),
> it is deserializied to [true, 1.1, 1.0, 2, 3, 1, "echo", "a", "b", "c"].
> Sending data is:
> ---
> http://schemas.xmlsoap.org/soap/envelope/";>
>
>
> http://examples/xsd";>
>
> true
> 1.1
> 1.0
> 2
> 3
> 1
> echo
>
> abc
>
>
>
>
> ---
--
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]
NPE trying to send from an InOutAsyncMessageReceiver
I am getting the NPE below trying to send from an InOutAsyncMessageReceiver. It is possible that the envelope may not be correctly put together, but without any more clues, it's not clear what may be causing the NPE, which seems to happen inside Axiom. One thing to notice is that the code that invokes AxisEngine.send catches Throwable in addition to AxisFault, and nothing gets caught, so is also seems like the NPE is being swallowed somewhere and not being thrown back. Any help is appreciated. Thanks Thread [pool-2-thread-2] (Suspended (exception NullPointerException)) InternalOutputBuffer.realWriteBytes(byte[], int, int) line: 746 ByteChunk.flushBuffer () line: 433 InternalOutputBuffer.flush() line: 304 Http11Processor.action(ActionCode, Object) line: 991 Response.action(ActionCode, Object) line: 182 OutputBuffer.doFlush(boolean) line: 322 OutputBuffer.flush() line: 293 CoyoteOutputStream.flush() line: 97 StreamEncoder$ConverterSE.implFlush() line: 290 StreamEncoder$ConverterSE(StreamEncoder).flush() line: 200 OutputStreamWriter.flush() line: 236 BufferedWriter.flush() line: 257 BufferingXmlWriter.flush() line: 184 SimpleNsStreamWriter(BaseStreamWriter).flush() line: 269 MTOMXMLStreamWriter.flush() line: 119 SOAPEnvelopeImpl(OMNodeImpl).serializeAndConsume(OutputStream, OMOutputFormat) line: 412 CommonsHTTPTransportSender.sendUsingOutputStream (MessageContext, OMOutputFormat, OMElement) line: 276 CommonsHTTPTransportSender.invoke(MessageContext) line: 210 AxisEngine.send(MessageContext) line: 642 Axis2ServiceCallbackTargetInvoker.invokeTarget (Object) line: 76 Axis2ServiceCallbackTargetInvoker.invoke(Message) line: 90 InvokerInterceptor.invoke(Message) line: 44 SynchronousBridgingInterceptor.invoke(Message) line: 41 DataBindingInteceptor.invoke(Message) line: 71 JDKCallbackInvocationHandler(AbstractOutboundInvocationHandler).invoke(OutboundInvocationChain, TargetInvoker, Object[]) line: 60 JDKCallbackInvocationHandler.invoke(Object, Method, Object[]) line: 71 $Proxy31.getGreetingsCallback(String) line: not available HelloWorldImpl.getGreetings(String) line: 50 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 64 DelegatingMethodAccessorImpl.invoke (Object, Object[]) line: 43 Method.invoke(Object, Object...) line: 615 AsyncJavaTargetInvoker(PojoTargetInvoker).invokeTarget(Object
Re: [axis2] Improvements to Service life cycle in handling - setOperationContext not thread-safe??!!
Sanjiva, We had terrible problems with TLS in Axis1...let me recollect my thougts and post. -- dims On 10/10/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote: I think I agree with you. How about we drop setOperationContext() and introduce Axis1-style MessageContext.getCurrentContext() which returns it for this thread? Have to be careful to put it in TLS and take it off! We must be careful to tell users that instance variables are not supported; you have to use MessageContext properties to store state (or wherever else). Sanjiva. On Sun, 2006-09-24 at 14:12 +0200, Christopher Sahnwaldt wrote: > Entered as http://issues.apache.org/jira/browse/AXIS2-1224 . > I set the priority to blocker as David suggested. > > IMHO it's probably best to drop the method. Many users will use it in an > intuitive but wrong way. The only way to store the data it provides is an > instance variable, and telling users to either use only request scope or use > a ThreadLocal to store the data does not seem to be compatible with the > rule of least surprise. Something like MessageContext.getCurrentContext() > in Axis 1 might be better. > > Bye, > Christopher. > > Davanum Srinivas wrote: > > Chris, > > > > Can you please raise a new issue in JIRA? > > > > thanks, > > dims > > > > On 9/23/06, Christopher Sahnwaldt <[EMAIL PROTECTED]> wrote: > >> Something worries me: > >> > >> > setOperationContext(OperationContext) - per call. The messageContext > >> > can be obtained to gain per call instance information. > >> > >> That doesn't seem to be thread-safe, does it? If I understand this > >> correctly, one service object is created per application (if the > >> service has application scope). When a request comes in, Axis calls > >> the setOperationContext method, and the service object may store the > >> OperationContext or the MessageContext. Then Axis calls the actual > >> service method, in which the service code can access the stored > >> OperationContext or MessageContext. But what if two requests come > >> in almost simultaneously? The following sequence of method calls > >> may occur: > >> > >> - Axis calls setOperationContext with context for request A, the > >> service object stores the context in an instance field. > >> - Axis calls setOperationContext with context for request B, the same > >> service object stores the context in the same instance field and > >> thus *overwrites* the context for call A. > >> - Axis calls the service method with the input parameters for request A. > >> - The service method processes the call, using data from the stored > >> context, and thus *mixes the input parameters for call A with the > >> context data for call B*. Anything can happen... > >> - Finally, Axis calls the service method with the input parameters > >> for call B, the service method processes the call, using data from > >> the stored context, and thus correctly uses the input parameters > >> for call B with the context data for call B. Probably ok, unless > >> the service method updated the context in some way during the call > >> for request A. > >> > >> But I hope I'm wrong or misunderstood or forgot something... ;-) > >> > >> Axis 1 avoided this problem by MessageContext.getCurrentContext(), > >> which gives access to the MessageContext *for the current thread* > >> from within any service method, without the need for a > >> setMessageContext (or setOperationContext) method on the service > >> object. > >> > >> Bye, > >> Christopher. > >> > >> > >> Tony Dean wrote: > >> > >> > Can we fully document the logical semantics behind each method? > >> > > >> > init(ServiceContext) - To me this use to mean application init. > >> Now it means session init. However, when running > >> scope="Application", it is analogous to application init since you > >> will only have one session; but, still probably not appropriate to > >> think in those terms. > >> > > >> > How should an application use this method? A session use-case > >> would be nice. > >> > > >> > destroy(ServiceContext) - inverse of init() > >> > Use-case? > >> > > >> > setOperationContext(OperationContext) - per call. The > >> messageContext can be obtained to gain per call instance information. > >> > > >> > StartUp() - one time initialization... DB connections etc... > >> > Shutdown() - inverse of StartUp() > >> > > >> > Any more insight or corrections to pattern usage would be grateful... > >> > > >> > Thanks. > >> > > >> > -Original Message- > >> > From: robert lazarski [mailto:[EMAIL PROTECTED] > >> > Sent: Friday, September 15, 2006 8:49 AM > >> > To: axis-dev@ws.apache.org > >> > Subject: Re: Improvements to Service life cycle in handling > >> > > >> > That makes sense to me. I've been using startUp() and it doesn't > >> really fit with the other methods of the interface in its current > >> form. +1 for 1.1 since its interface changes and it'd be better to do > >> it now. > >> > > >> > One question: Currently you need this in service
Re: [axis2] Improvements to Service life cycle in handling - setOperationContext not thread-safe??!!
I think I agree with you. How about we drop setOperationContext() and introduce Axis1-style MessageContext.getCurrentContext() which returns it for this thread? Have to be careful to put it in TLS and take it off! We must be careful to tell users that instance variables are not supported; you have to use MessageContext properties to store state (or wherever else). Sanjiva. On Sun, 2006-09-24 at 14:12 +0200, Christopher Sahnwaldt wrote: > Entered as http://issues.apache.org/jira/browse/AXIS2-1224 . > I set the priority to blocker as David suggested. > > IMHO it's probably best to drop the method. Many users will use it in an > intuitive but wrong way. The only way to store the data it provides is an > instance variable, and telling users to either use only request scope or use > a ThreadLocal to store the data does not seem to be compatible with the > rule of least surprise. Something like MessageContext.getCurrentContext() > in Axis 1 might be better. > > Bye, > Christopher. > > Davanum Srinivas wrote: > > Chris, > > > > Can you please raise a new issue in JIRA? > > > > thanks, > > dims > > > > On 9/23/06, Christopher Sahnwaldt <[EMAIL PROTECTED]> wrote: > >> Something worries me: > >> > >> > setOperationContext(OperationContext) - per call. The messageContext > >> > can be obtained to gain per call instance information. > >> > >> That doesn't seem to be thread-safe, does it? If I understand this > >> correctly, one service object is created per application (if the > >> service has application scope). When a request comes in, Axis calls > >> the setOperationContext method, and the service object may store the > >> OperationContext or the MessageContext. Then Axis calls the actual > >> service method, in which the service code can access the stored > >> OperationContext or MessageContext. But what if two requests come > >> in almost simultaneously? The following sequence of method calls > >> may occur: > >> > >> - Axis calls setOperationContext with context for request A, the > >> service object stores the context in an instance field. > >> - Axis calls setOperationContext with context for request B, the same > >> service object stores the context in the same instance field and > >> thus *overwrites* the context for call A. > >> - Axis calls the service method with the input parameters for request A. > >> - The service method processes the call, using data from the stored > >> context, and thus *mixes the input parameters for call A with the > >> context data for call B*. Anything can happen... > >> - Finally, Axis calls the service method with the input parameters > >> for call B, the service method processes the call, using data from > >> the stored context, and thus correctly uses the input parameters > >> for call B with the context data for call B. Probably ok, unless > >> the service method updated the context in some way during the call > >> for request A. > >> > >> But I hope I'm wrong or misunderstood or forgot something... ;-) > >> > >> Axis 1 avoided this problem by MessageContext.getCurrentContext(), > >> which gives access to the MessageContext *for the current thread* > >> from within any service method, without the need for a > >> setMessageContext (or setOperationContext) method on the service > >> object. > >> > >> Bye, > >> Christopher. > >> > >> > >> Tony Dean wrote: > >> > >> > Can we fully document the logical semantics behind each method? > >> > > >> > init(ServiceContext) - To me this use to mean application init. > >> Now it means session init. However, when running > >> scope="Application", it is analogous to application init since you > >> will only have one session; but, still probably not appropriate to > >> think in those terms. > >> > > >> > How should an application use this method? A session use-case > >> would be nice. > >> > > >> > destroy(ServiceContext) - inverse of init() > >> > Use-case? > >> > > >> > setOperationContext(OperationContext) - per call. The > >> messageContext can be obtained to gain per call instance information. > >> > > >> > StartUp() - one time initialization... DB connections etc... > >> > Shutdown() - inverse of StartUp() > >> > > >> > Any more insight or corrections to pattern usage would be grateful... > >> > > >> > Thanks. > >> > > >> > -Original Message- > >> > From: robert lazarski [mailto:[EMAIL PROTECTED] > >> > Sent: Friday, September 15, 2006 8:49 AM > >> > To: axis-dev@ws.apache.org > >> > Subject: Re: Improvements to Service life cycle in handling > >> > > >> > That makes sense to me. I've been using startUp() and it doesn't > >> really fit with the other methods of the interface in its current > >> form. +1 for 1.1 since its interface changes and it'd be better to do > >> it now. > >> > > >> > One question: Currently you need this in services.xml to get > >> startUp() to invoke: > >> > > >> > true > >> > > >> > I plan on testing this when its ready ... since the spring tutorial > >> depen
[jira] Commented: (AXIS2-1252) java2wsdl generates unknown namespace
[ http://issues.apache.org/jira/browse/AXIS2-1252?page=comments#action_12441139 ] Davanum Srinivas commented on AXIS2-1252: - Venkat, Kinichiro, Deepal, I think we need the ability to specify a namespace/pakage mapping to fully control the schema generation. What do you think about the following algorithm: #1: If ONE schematargetnamespace is specified then push all types to that namespace. Throw an error and exit on collision. #2: If MANY schematargetnamespace/package name mappings are specified, then push types to specified namespaces. Again, Throw an error on collision. #3: If NO schematargetnamespace or mappings specified, then auto generate namespaces from packages. Hopefully there will be no collisions. We need full control over this from both java2wsdl command line and from services.xml. Please note that there is runtime support we need to enhance too when we change to this model/algo. Specifically when we serialize/deserialize we need to take into account the schema namespaces as the user has specified. Will this solve all issues? Did i miss anything? Thanks, dims > java2wsdl generates unknown namespace > - > > Key: AXIS2-1252 > URL: http://issues.apache.org/jira/browse/AXIS2-1252 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Improvement > Components: wsdl >Reporter: Kinichiro Inoguchi >Priority: Blocker > > This issue comes from user mailing list. > http://marc.theaimsgroup.com/?t=11593771594&r=1&w=2 > java2wsdl generates unknown namespace, "http://test/xsd";. > I'm using current nightly. > My service class has method "sayHello", > and returns array of simple java beans "HelloBean". > Then I run java2wsdl, sayHello and sayHelloResponse > are in namespace "http://aaa.bbb/types";. > But, HelloBean is in unknown namespace "http://test/xsd";. > Is this a bug ? > C:\axis2-std-SNAPSHOT-bin\bin\java2wsdl.bat > -cn test.TestService1 -cp . > -tn http://aaa.bbb -tp xxx > -stn http://aaa.bbb/types -stp yyy > -sn TestService1 -of TestService1.wsdl > generated WSDL is like this; > http://schemas.xmlsoap.org/wsdl/soap12/"; > xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"; > xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"; > xmlns:ns1="http://aaa.bbb/types"; xmlns:xxx="http://aaa.bbb"; > xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"; > xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"; > targetNamespace="http://aaa.bbb";> > > http://www.w3.org/2001/XMLSchema"; > xmlns:ax22="http://test/xsd"; targetNamespace="http://test/xsd"; > attributeFormDefault="qualified" elementFormDefault="qualified"> > > > > > > > > > > > > > > http://www.w3.org/2001/XMLSchema"; > xmlns:gen798="http://test/xsd"; xmlns:ax21="http://aaa.bbb/types"; > targetNamespace="http://aaa.bbb/types"; attributeFormDefault="qualified" > elementFormDefault="qualified"> > > > > > > > > > > > > > > > > >type="gen798:HelloBean" nillable="true" /> > > > > > > ... -- 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][1.1-RC1] Security sample is not included
On Tue, 2006-10-10 at 08:57 -0400, Davanum Srinivas wrote: > Will that load when dropped as-is into a repo? I remember we nixed the > SNAPSHOT off the name of the mar to prevent such problems. You'd have to engage as "rampart-SNAPSHOT" but otherwise should work fine. Deepal?? Sanjiva. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-1334) Deployment of Sandesha2 causes exception in Axis2 Admin-Frontend
[ http://issues.apache.org/jira/browse/AXIS2-1334?page=all ] Davanum Srinivas updated AXIS2-1334: Priority: Critical (was: Blocker) Not a blocker. -- dims > Deployment of Sandesha2 causes exception in Axis2 Admin-Frontend > > > Key: AXIS2-1334 > URL: http://issues.apache.org/jira/browse/AXIS2-1334 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug > Components: core >Affects Versions: 1.1 > Environment: Axis2 1.1 RC1 > Sandesha2 1.0 >Reporter: Thilo Frotscher >Priority: Critical > > - deploy a fresh Axis2 1.1 RC1 into Tomcat > - startup Tomcat > - check out Axis2 Web Admin Frontend with browser - works fine! > - shut down Tomcat > - copy sandesha2-1.0.mar into WEB-INF/modules > - add name of module archive to modules.list (not sure if this step is > needed, but bug occurs with or without this step!) > - add RMPhase to all four flows, according to Sandesha2 user guide: > http://ws.apache.org/sandesha/sandesha2/userGuide.html > - start up Tomcat > - check out Axis2 Web Admin Frontend with browser - Exception! > TOMCAT's LOG FILE > = > java.lang.NoSuchMethodError: > org.apache.axis2.description.PolicyInclude.getEffectivePolicy()Lorg/apache/ws/policy/Policy; > at > org.apache.sandesha2.util.PropertyManager.loadPropertiesFromModuleDescPolicy(PropertyManager.java:158) > at org.apache.sandesha2.SandeshaModule.init(SandeshaModule.java:50) > at > org.apache.axis2.context.ConfigurationContextFactory.initModules(ConfigurationContextFactory.java:217) > at > org.apache.axis2.context.ConfigurationContextFactory.init(ConfigurationContextFactory.java:193) > at > org.apache.axis2.context.ConfigurationContextFactory.createConfigurationContext(ConfigurationContextFactory.java:70) > at > org.apache.axis2.transport.http.AxisServlet.initConfigContext(AxisServlet.java:366) > at > org.apache.axis2.transport.http.AxisServlet.init(AxisServlet.java:304) > at > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1105) > at > org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:932) > at > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3917) > at > org.apache.catalina.core.StandardContext.start(StandardContext.java:4197) > at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759) > at > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) > at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) > at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:809) > at > org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:698) > at > org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:472) > at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1112) > at > org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310) > at > org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) > at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1021) > at org.apache.catalina.core.StandardHost.start(StandardHost.java:718) > at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013) > at > org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442) > at > org.apache.catalina.core.StandardService.start(StandardService.java:450) > at > org.apache.catalina.core.StandardServer.start(StandardServer.java:709) > at org.apache.catalina.startup.Catalina.start(Catalina.java:551) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:275) > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) > BROWSER > === > org.apache.jasper.JasperException > > org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:510) > > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:375) > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) > javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > root cause > org.apache.jasper.JasperException > > org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:510) > > org.apache.jasper.serv
Re: [Axis2][1.1-RC1] Security sample is not included
Will that load when dropped as-is into a repo? I remember we nixed the SNAPSHOT off the name of the mar to prevent such problems. -- dims On 10/10/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote: On Tue, 2006-10-10 at 07:15 -0400, Davanum Srinivas wrote: > Thilina, > > if i add snapshots to the name, the mar wont load :( > > -- dims > > On 10/10/06, Thilina Gunarathne <[EMAIL PROTECTED]> wrote: > > I would not recommend you to try mixing the stuff between 1.0 and > > 1.1... You can try the snapshots together with 1.1-RC1... > > http://people.apache.org/repository/org.apache.axis2/mars/rampart-1.1.mar > > > > IMO this version number is wrong.. Should be 1.1-snapshots.. s/rampart-1.1.mar/rampart-SNAPSHOT-1.1.mar/g ?? Sanjiva. -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Proposal to add return type to Handler.invoke(...)
On Mon, 2006-10-09 at 19:51 -0700, Bill Nagy wrote:
> There is currently a race condition between code that pauses the message
> flow within a handler and resumes it on another thread (e.g. Sandesha)
> and the message flow processing chain (Phase.invoke(...),
> AxisEngine.invoke(...), etc.)
> (http://issues.apache.org/jira/browse/SANDESHA2-32) This is caused
> because the control of processing is keyed off of MessageContext.paused
> and not through some other mechanism (return code, semaphore, etc.). If
> a handler pauses a message and returns, handing the message off to
> another thread for execution, there is the possibility that the new
> execution thread will resume processing of the message, unsetting
> MessageContext.paused, before control returns to one of the invoke
> methods. If this happens, the logic in the invoke method, which looks
> at the MessageContext.paused flag, will believe that it should continue
> execution instead of halting.
Can't this be solved by synchronizing access to MessageContext.paused()?
Sorry I looked at the sandesha issue but didn't see it.
Alternatively,
synchronized {
h.invoke();
h.getPaused();
}
I must be missing something obvious as to why this doesn't work.
> Since the problem revolves around flow control logic, I suggest that we
> use the return code from the method invocation to deal with it. I would
> like to add a return code to the Handler.invoke(...) which would
> identify how processing of the message should proceed, e.g. :
How does this solve the problem as other thread could go get the MC and
do stuff while still in this method?
> /**
> * This type encapsulates an enumeration of possible message processing
> * instruction values that may be returned by a handler/phase within the
> * runtime.
> */
> public class InvocationProcessingInstruction
> {
> public static InvocationProcessingInstruction CONTINUE_PROCESSING =
> new InvocationProcessingInstruction(0);
> public static InvocationProcessingInstruction SUSPEND_PROCESSING = new
> InvocationProcessingInstruction(1);
> public static InvocationProcessingInstruction ABORT_PROCESSING = new
> InvocationProcessingInstruction(2);
>
> private int instructionID;
>
> private InvocationProcessingInstruction(int instructionID)
> {
> this.instructionID = instructionID;
> }
>
> public boolean equals(InvocationProcessingInstruction instruction)
> {
> return this.instructionID == instruction.instructionID;
> }
>
> public int hashCode()
> {
> return instructionID;
> }
> }
>
> Most handlers will return
> InvocationProcessingInstruction.CONTINUE_PROCESSING; the RM handler may
> return that, SUSPEND_PROCESSING (for a pause), or ABORT_PROCESSING (for
> a duplicate msg.)
I must be really jetlagged (traveling again): do we need all this or
just use an int to return the status?? (some consts basically).
Sanjiva.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Deleted: (AXIS2-1335) Code Generation Exception occurred when Generating Clients
Franz, I asked the reporter (a colleague) to open an issue using just the WSDL2Java bat file and not using a product/gui. Here's the new issue: http://issues.apache.org/jira/browse/AXIS2-1336 thanks, dims On 10/10/06, Franz Fehringer <[EMAIL PROTECTED]> wrote: And what was wrong with this issue i.e. why got it deleted? Franz Davanum Srinivas schrieb: > Franz, > > the delete button in JIRA does not allow us to add comments as the > comments are part of the issue that is to be deleted :) > > -- dims > > On 10/10/06, Franz Fehringer <[EMAIL PROTECTED]> wrote: >> >> Out of curiosity why gets an issue deleted without comment? >> >> Greetings >> >> Franz >> >> >> Davanum Srinivas (JIRA) schrieb: >> [ http://issues.apache.org/jira/browse/AXIS2-1335?page=all >> ] >> >> Davanum Srinivas deleted AXIS2-1335: >> >> >> >> >> >> Code Generation Exception occurred when Generating Clients >> -- >> >> Key: AXIS2-1335 >> URL: http://issues.apache.org/jira/browse/AXIS2-1335 >> Project: Apache Axis 2.0 (Axis2) >> Issue Type: Bug >> Environment: Windows XP, jdk1.5.0_08, Maven 1.0.2, Mozilla Firefox >> 1.5.0.6 >> Reporter: Evanthika Amarasiri >> Priority: Critical >> >> 1. Login to the Tungsten Management Console >> 2. Click on the link "Services" which is on the left pane of the page >> 3. Click on the link "Generate Client" >> 4. Select the following "Stub Generation options" to create the stub >> a) Port - CommodityQuoteSOAP11port_https >> b) Invocation Style - Both >> c) Databinding - ADB >> d) Unpack Classes - True >> e) Unwrap - True >> f) Generate Testcase - False >> 5. Select the above options and click on the button "Generate" (You can >> change the values of any other option but the value of the option >> "Unwrap" >> should be set to "True" and the port should be either >> CommodityQuoteSOAP11port_https or CommodityQuoteSOAP11port_http1) >> 6. A Code Generation Exception is thrown >> ERROR [2006-10-10 16:12:49,343] Error occurred during code generation. >> Unsupported Schema format fo >> r unwrapping! found unknown but expected sequence >> org.apache.axis2.wsdl.codegen.CodeGenerationException: >> org.apache.axis2.wsdl.codegen.CodeGenerationE >> xception: Unsupported Schema format for unwrapping! found unknown but >> expected sequence >> at >> org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224 >> >> ) >> at >> com.wso2.tungsten.admin.service.wsdl2code.WSDL2CodeService.generate(WSDL2CodeService.java >> >> :154) >> at >> com.wso2.tungsten.admin.service.wsdl2code.WSDL2CodeServiceMessageReceiverInOut.invokeBusi >> >> nessLogic(WSDL2CodeServiceMessageReceiverInOut.java:55) >> at >> org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.receive(AbstractInOutSyncMess >> >> ageReceiver.java:39) >> at >> org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:493) >> at >> org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUt >> >> ils.java:323) >> at >> org.apache.axis2.transport.http.util.SOAPUtil.processPostRequest(SOAPUtil.java:57) >> >> at >> com.wso2.tungsten.transport.jetty.Axis2SOAPHandler.processPostRequest(Axis2SOAPHandler.ja >> >> va:42) >> at >> com.wso2.tungsten.transport.jetty.Axis2Handler.dispatch(Axis2Handler.java:175) >> >> at >> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) >> at >> org.mortbay.http.HttpContext.handle(HttpContext.java:1530) >> at >> org.mortbay.http.HttpContext.handle(HttpContext.java:1482) >> at >> org.mortbay.http.HttpServer.service(HttpServer.java:909) >> at >> org.mortbay.http.HttpConnection.service(HttpConnection.java:816) >> at >> org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982) >> at >> org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) >> at >> org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) >> >> at >> org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) >> at >> org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) >> Caused by: >> org.apache.axis2.wsdl.codegen.CodeGenerationException: >> Unsupported Schema format for unwr >> apping! found unknown but expected sequence >> at >> org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.processXMLSchemaSequence >> >> (SchemaUnwrapperExtension.java:287) >> at >> org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.handleAllCasesOfComplexT >> >> ypes(SchemaUnwrapperExtension.java:164) >> at >> org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.walkSchema(SchemaUnwrapp >> >> erExtension.java:122) >> at >> org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.engage(SchemaUnwrapperEx >> >> tension.java:87) >> at >> org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:177 >> >> ) >> ... 18 more >> ERROR [2006-10-10 16:12:49
Re: [Axis2][1.1-RC1] Security sample is not included
On Tue, 2006-10-10 at 07:15 -0400, Davanum Srinivas wrote: > Thilina, > > if i add snapshots to the name, the mar wont load :( > > -- dims > > On 10/10/06, Thilina Gunarathne <[EMAIL PROTECTED]> wrote: > > I would not recommend you to try mixing the stuff between 1.0 and > > 1.1... You can try the snapshots together with 1.1-RC1... > > http://people.apache.org/repository/org.apache.axis2/mars/rampart-1.1.mar > > > > IMO this version number is wrong.. Should be 1.1-snapshots.. s/rampart-1.1.mar/rampart-SNAPSHOT-1.1.mar/g ?? Sanjiva. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Deleted: (AXIS2-1335) Code Generation Exception occurred when Generating Clients
And what was wrong with this issue i.e. why got it deleted? Franz Davanum Srinivas schrieb: Franz, the delete button in JIRA does not allow us to add comments as the comments are part of the issue that is to be deleted :) -- dims On 10/10/06, Franz Fehringer <[EMAIL PROTECTED]> wrote: Out of curiosity why gets an issue deleted without comment? Greetings Franz Davanum Srinivas (JIRA) schrieb: [ http://issues.apache.org/jira/browse/AXIS2-1335?page=all ] Davanum Srinivas deleted AXIS2-1335: Code Generation Exception occurred when Generating Clients -- Key: AXIS2-1335 URL: http://issues.apache.org/jira/browse/AXIS2-1335 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Environment: Windows XP, jdk1.5.0_08, Maven 1.0.2, Mozilla Firefox 1.5.0.6 Reporter: Evanthika Amarasiri Priority: Critical 1. Login to the Tungsten Management Console 2. Click on the link "Services" which is on the left pane of the page 3. Click on the link "Generate Client" 4. Select the following "Stub Generation options" to create the stub a) Port - CommodityQuoteSOAP11port_https b) Invocation Style - Both c) Databinding - ADB d) Unpack Classes - True e) Unwrap - True f) Generate Testcase - False 5. Select the above options and click on the button "Generate" (You can change the values of any other option but the value of the option "Unwrap" should be set to "True" and the port should be either CommodityQuoteSOAP11port_https or CommodityQuoteSOAP11port_http1) 6. A Code Generation Exception is thrown ERROR [2006-10-10 16:12:49,343] Error occurred during code generation. Unsupported Schema format fo r unwrapping! found unknown but expected sequence org.apache.axis2.wsdl.codegen.CodeGenerationException: org.apache.axis2.wsdl.codegen.CodeGenerationE xception: Unsupported Schema format for unwrapping! found unknown but expected sequence at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224 ) at com.wso2.tungsten.admin.service.wsdl2code.WSDL2CodeService.generate(WSDL2CodeService.java :154) at com.wso2.tungsten.admin.service.wsdl2code.WSDL2CodeServiceMessageReceiverInOut.invokeBusi nessLogic(WSDL2CodeServiceMessageReceiverInOut.java:55) at org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.receive(AbstractInOutSyncMess ageReceiver.java:39) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:493) at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUt ils.java:323) at org.apache.axis2.transport.http.util.SOAPUtil.processPostRequest(SOAPUtil.java:57) at com.wso2.tungsten.transport.jetty.Axis2SOAPHandler.processPostRequest(Axis2SOAPHandler.ja va:42) at com.wso2.tungsten.transport.jetty.Axis2Handler.dispatch(Axis2Handler.java:175) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) at org.mortbay.http.HttpServer.service(HttpServer.java:909) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) Caused by: org.apache.axis2.wsdl.codegen.CodeGenerationException: Unsupported Schema format for unwr apping! found unknown but expected sequence at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.processXMLSchemaSequence (SchemaUnwrapperExtension.java:287) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.handleAllCasesOfComplexT ypes(SchemaUnwrapperExtension.java:164) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.walkSchema(SchemaUnwrapp erExtension.java:122) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.engage(SchemaUnwrapperEx tension.java:87) at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:177 ) ... 18 more ERROR [2006-10-10 16:12:49,343] org.apache.axis2.AxisFault: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown but expected sequence; nested exception is: java.lang.RuntimeException: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown but expected sequence; nested exception is: org.apache.axis2.AxisFault: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown but expected sequence; nested exception is: java.lang.RuntimeException: Error occurred during code generation. Unsupported Schema format for unwrapping!
Re: [jira] Deleted: (AXIS2-1335) Code Generation Exception occurred when Generating Clients
Franz, the delete button in JIRA does not allow us to add comments as the comments are part of the issue that is to be deleted :) -- dims On 10/10/06, Franz Fehringer <[EMAIL PROTECTED]> wrote: Out of curiosity why gets an issue deleted without comment? Greetings Franz Davanum Srinivas (JIRA) schrieb: [ http://issues.apache.org/jira/browse/AXIS2-1335?page=all ] Davanum Srinivas deleted AXIS2-1335: Code Generation Exception occurred when Generating Clients -- Key: AXIS2-1335 URL: http://issues.apache.org/jira/browse/AXIS2-1335 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Environment: Windows XP, jdk1.5.0_08, Maven 1.0.2, Mozilla Firefox 1.5.0.6 Reporter: Evanthika Amarasiri Priority: Critical 1. Login to the Tungsten Management Console 2. Click on the link "Services" which is on the left pane of the page 3. Click on the link "Generate Client" 4. Select the following "Stub Generation options" to create the stub a) Port - CommodityQuoteSOAP11port_https b) Invocation Style - Both c) Databinding - ADB d) Unpack Classes - True e) Unwrap - True f) Generate Testcase - False 5. Select the above options and click on the button "Generate" (You can change the values of any other option but the value of the option "Unwrap" should be set to "True" and the port should be either CommodityQuoteSOAP11port_https or CommodityQuoteSOAP11port_http1) 6. A Code Generation Exception is thrown ERROR [2006-10-10 16:12:49,343] Error occurred during code generation. Unsupported Schema format fo r unwrapping! found unknown but expected sequence org.apache.axis2.wsdl.codegen.CodeGenerationException: org.apache.axis2.wsdl.codegen.CodeGenerationE xception: Unsupported Schema format for unwrapping! found unknown but expected sequence at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224 ) at com.wso2.tungsten.admin.service.wsdl2code.WSDL2CodeService.generate(WSDL2CodeService.java :154) at com.wso2.tungsten.admin.service.wsdl2code.WSDL2CodeServiceMessageReceiverInOut.invokeBusi nessLogic(WSDL2CodeServiceMessageReceiverInOut.java:55) at org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.receive(AbstractInOutSyncMess ageReceiver.java:39) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:493) at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUt ils.java:323) at org.apache.axis2.transport.http.util.SOAPUtil.processPostRequest(SOAPUtil.java:57) at com.wso2.tungsten.transport.jetty.Axis2SOAPHandler.processPostRequest(Axis2SOAPHandler.ja va:42) at com.wso2.tungsten.transport.jetty.Axis2Handler.dispatch(Axis2Handler.java:175) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) at org.mortbay.http.HttpServer.service(HttpServer.java:909) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) Caused by: org.apache.axis2.wsdl.codegen.CodeGenerationException: Unsupported Schema format for unwr apping! found unknown but expected sequence at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.processXMLSchemaSequence (SchemaUnwrapperExtension.java:287) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.handleAllCasesOfComplexT ypes(SchemaUnwrapperExtension.java:164) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.walkSchema(SchemaUnwrapp erExtension.java:122) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.engage(SchemaUnwrapperEx tension.java:87) at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:177 ) ... 18 more ERROR [2006-10-10 16:12:49,343] org.apache.axis2.AxisFault: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown but expected sequence; nested exception is: java.lang.RuntimeException: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown but expected sequence; nested exception is: org.apache.axis2.AxisFault: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown but expected sequence; nested exception is: java.lang.RuntimeException: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown but expected sequence ERROR [2006-10-10 16:12:49,343] Unable to handle request com.wso2.tungsten.TungstenException: org.apache.axis2.A
[jira] Updated: (AXIS2-1338) Code generation drops the element which holds an xsd:anyType element at both client and server sides
[ http://issues.apache.org/jira/browse/AXIS2-1338?page=all ] Asankha C. Perera updated AXIS2-1338: - Attachment: AbstractTestCase.java > Code generation drops the element which holds an xsd:anyType element at both > client and server sides > > > Key: AXIS2-1338 > URL: http://issues.apache.org/jira/browse/AXIS2-1338 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug > Components: adb > Environment: Axis2 1.1 RC-1 >Reporter: Asankha C. Perera > Attachments: AbstractTestCase.java, ComplexEchoServiceSkeleton.java, > ComplexEchoServiceTest.java, echo.wsdl > > > The following is a fragment from the WSDL used (attached to the JIRA). The > element "value" is of type xsd:anyType > > >type="xsd:string"/> >type="xsd:anyType"/> > > > > >type="xsd:string"/> >type="xsd:string"/> >type="tns1:NamedValue" maxOccurs="unbounded"/> >type="tns1:AttributeRequest" maxOccurs="unbounded"/> > > > Codegen using -o -s -t -ss -sd -g -uri echo.wsdl and use > attached client and server skeleton implementations to test. > On TCPMon the SOAP request sent is as follows: > >Request NV1 name > > > When a correct request of the form shown below is sent to the server: > >Request NV1 name > /> > > The server replies as: > http://types.echo.services"; > > > Response NV1 name > > > Again, thw WSDL defines the response as follows: > > > >type="tns1:NamedValue" maxOccurs="unbounded"/> > > > -- 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-1338) Code generation drops the element which holds an xsd:anyType element at both client and server sides
[ http://issues.apache.org/jira/browse/AXIS2-1338?page=all ] Asankha C. Perera updated AXIS2-1338: - Attachment: echo.wsdl ComplexEchoServiceSkeleton.java ComplexEchoServiceTest.java > Code generation drops the element which holds an xsd:anyType element at both > client and server sides > > > Key: AXIS2-1338 > URL: http://issues.apache.org/jira/browse/AXIS2-1338 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug > Components: adb > Environment: Axis2 1.1 RC-1 >Reporter: Asankha C. Perera > Attachments: AbstractTestCase.java, ComplexEchoServiceSkeleton.java, > ComplexEchoServiceTest.java, echo.wsdl > > > The following is a fragment from the WSDL used (attached to the JIRA). The > element "value" is of type xsd:anyType > > >type="xsd:string"/> >type="xsd:anyType"/> > > > > >type="xsd:string"/> >type="xsd:string"/> >type="tns1:NamedValue" maxOccurs="unbounded"/> >type="tns1:AttributeRequest" maxOccurs="unbounded"/> > > > Codegen using -o -s -t -ss -sd -g -uri echo.wsdl and use > attached client and server skeleton implementations to test. > On TCPMon the SOAP request sent is as follows: > >Request NV1 name > > > When a correct request of the form shown below is sent to the server: > >Request NV1 name > /> > > The server replies as: > http://types.echo.services"; > > > Response NV1 name > > > Again, thw WSDL defines the response as follows: > > > >type="tns1:NamedValue" maxOccurs="unbounded"/> > > > -- 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-1338) Code generation drops the element which holds an xsd:anyType element at both client and server sides
Code generation drops the element which holds an xsd:anyType element at both client and server sides Key: AXIS2-1338 URL: http://issues.apache.org/jira/browse/AXIS2-1338 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: adb Environment: Axis2 1.1 RC-1 Reporter: Asankha C. Perera The following is a fragment from the WSDL used (attached to the JIRA). The element "value" is of type xsd:anyType Codegen using -o -s -t -ss -sd -g -uri echo.wsdl and use attached client and server skeleton implementations to test. On TCPMon the SOAP request sent is as follows: Request NV1 name When a correct request of the form shown below is sent to the server: Request NV1 name The server replies as: http://types.echo.services"; > Response NV1 name Again, thw WSDL defines the response as follows: -- 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]
WS Addressing :: Issue with setting ReplyTo :: Axis2-1.1-SNAPSHOT
Hi All, I am trying to explore WS Addressing by creating a flow in which i call a WS (INOUT-with NonBlockingDual client) and then i want the response to be directed to another WS on a different port and server. I have explicitly set the To/ReplyTo in my client. In the resluting SOAP request the wsa:To parmeter gets set based on what i mentioned but somehow the wsa:ReplyTo is set to the default listener address !! I have also set:: options.setProperty(AddressingConstants.REPLACE_ADDRESSING_HEADERS, Boolean.TRUE) and then am setting replyto as :: options.setTo(targetEPR); options.setReplyTo(targetReplyEPR); options.setTransportInProtocol(Constants.TRANSPORT_HTTP); i also tried :: options.setProperty(AddressingConstants.WSA_REPLY_TO, targetReplyEPR); but what i found after looking at the source code was that in the message context itself the replyTo address is set to default whereas the To address is set based on what i mentioned. Kindly guide me as to what am i supposed to do. Regards, Vaibhav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-1337) Null value is returned when accessing the 'List Single Service' page of an available service group
[ http://issues.apache.org/jira/browse/AXIS2-1337?page=all ] Charitha Kankanamge updated AXIS2-1337: --- Attachment: listSingleService-FireFox.JPG listSingleService-IE.JPG Attached screen shots taken from the 'List Single Service' page through FireFox and IE browsers. > Null value is returned when accessing the 'List Single Service' page of an > available service group > -- > > Key: AXIS2-1337 > URL: http://issues.apache.org/jira/browse/AXIS2-1337 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug >Affects Versions: 1.1 > Environment: Axis2 1.1 RC1, Mozilla FireFox 1.5.0.7, Apach Tomcat > 5.5.16, JDK 1.5 >Reporter: Charitha Kankanamge > Attachments: listSingleService-FireFox.JPG, listSingleService-IE.JPG > > > Note that this issue occurs when accessing the 'List Single Service' page > through FireFox only. This will not occur with IE. > Steps to reproduce: > > 1. Deploy a service > 2. Navigate to the 'Available Service Group' page in the admin console > (Access through Mozilla FireFox 1.5.0.7) > 3. Click on a link of a deployed service > Actual Result: > == > Null value is returned and following text can be seen in the page. > 'List Single service > This Web axisService has deployment faults > null' > Expected Result: > > Service should be listed with available operations > Please check the screen shots taken from the same service accessed through > FireFox 1.5.0.7 and IE 6.0 -- 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-1337) Null value is returned when accessing the 'List Single Service' page of an available service group
Null value is returned when accessing the 'List Single Service' page of an available service group -- Key: AXIS2-1337 URL: http://issues.apache.org/jira/browse/AXIS2-1337 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Affects Versions: 1.1 Environment: Axis2 1.1 RC1, Mozilla FireFox 1.5.0.7, Apach Tomcat 5.5.16, JDK 1.5 Reporter: Charitha Kankanamge Note that this issue occurs when accessing the 'List Single Service' page through FireFox only. This will not occur with IE. Steps to reproduce: 1. Deploy a service 2. Navigate to the 'Available Service Group' page in the admin console (Access through Mozilla FireFox 1.5.0.7) 3. Click on a link of a deployed service Actual Result: == Null value is returned and following text can be seen in the page. 'List Single service This Web axisService has deployment faults null' Expected Result: Service should be listed with available operations Please check the screen shots taken from the same service accessed through FireFox 1.5.0.7 and IE 6.0 -- 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-1336) Code Generation Exception occurred when Generating stubs
Code Generation Exception occurred when Generating stubs Key: AXIS2-1336 URL: http://issues.apache.org/jira/browse/AXIS2-1336 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Affects Versions: 1.1 Environment: Windows XP, jdk1.5.0_08, Maven 1.0.2, Mozilla Firefox 1.5.0.6 Reporter: Evanthika Amarasiri Priority: Critical 1. Tried to create a stub using the following command wsdl2java.bat -uri \wsdl\CommodityQuote.wsdl -p com.wso2.tungsten.client -d adb -u true -t -uw true 2. The following exception occured Exception in thread "main" org.apache.axis2.wsdl.codegen.CodeGenerationException: org.apache.axis2.wsdl.codegen.CodeGenerationException: Unsupported S chema format for unwrapping! found unknown but expected sequence at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224) at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:32) at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:21) Caused by: org.apache.axis2.wsdl.codegen.CodeGenerationException: Unsupported Schema format for unwrapping! found unknown but expected sequence at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.processXMLSchemaSequence(SchemaUnwrapperExtension.java:287) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.handleAllCasesOfComplexTypes(SchemaUnwrapperExtension.java:164) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.walkSchema(SchemaUnwrapperExtension.java:122) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.engage(SchemaUnwrapperExtension.java:87) at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:177) ... 2 more -- 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: Apache Axis 1.6b
Wow ! Excellent - well done and thanks ! I suggest you create a JIRA and attach the files to that. "Haiping Zhao" <[EMAIL PROTECTED]> 09/10/2006 18:06 Please respond to axis-dev@ws.apache.org To cc Subject RE: Apache Axis 1.6b Hi, We have adopted Apache Axis C++ 1.6b since around Februry of this year, and we have made quite a few bug fixes and improvements. Where can I submit those? Here are some of them, 1. Fixed incorrect large packet handling in three transports: apache 2.0 transport, simple axis transport and axis client transport. 2. Fixed XML unrepresentable character handling on outbound. 3. Fixed a crash on apache shutdown from module unloading. 4. Fixed some bugs from code generation tool wsdl2ws: (1) incorrect parsing; (2) weak parsing; (3) missing required element checking; (4) bad header include when array is xsd__string_array; (5) wrong xsd__int enumeration code; (6) memory leaking code. 5. Fixed bugs in XMLParserXerces.cpp: (1) not throwing SAX parser exceptions; (2) incorrect end tag handling. 6. Supporting JSON and XML input and output, in addition to SOAP ones. 7. Supporting pretty print of SOAP/XML/JSON formats. 8. Supporting getting IP address and HTTP cookies from transport layer. Haiping Zhao Computer never make mistakes. 赵海平 Server Architect Plaxo, inc. tel: mobile: (650) 810-1093 (650) 248-4587 Add me to your address book... Want a signature like this?
Re: [jira] Deleted: (AXIS2-1335) Code Generation Exception occurred when Generating Clients
Out of curiosity why gets an issue deleted without comment? Greetings Franz Davanum Srinivas (JIRA) schrieb: [ http://issues.apache.org/jira/browse/AXIS2-1335?page=all ] Davanum Srinivas deleted AXIS2-1335: Code Generation Exception occurred when Generating Clients -- Key: AXIS2-1335 URL: http://issues.apache.org/jira/browse/AXIS2-1335 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Environment: Windows XP, jdk1.5.0_08, Maven 1.0.2, Mozilla Firefox 1.5.0.6 Reporter: Evanthika Amarasiri Priority: Critical 1. Login to the Tungsten Management Console 2. Click on the link "Services" which is on the left pane of the page 3. Click on the link "Generate Client" 4. Select the following "Stub Generation options" to create the stub a) Port - CommodityQuoteSOAP11port_https b) Invocation Style - Both c) Databinding - ADB d) Unpack Classes - True e) Unwrap - True f) Generate Testcase - False 5. Select the above options and click on the button "Generate" (You can change the values of any other option but the value of the option "Unwrap" should be set to "True" and the port should be either CommodityQuoteSOAP11port_https or CommodityQuoteSOAP11port_http1) 6. A Code Generation Exception is thrown ERROR [2006-10-10 16:12:49,343] Error occurred during code generation. Unsupported Schema format fo r unwrapping! found unknown but expected sequence org.apache.axis2.wsdl.codegen.CodeGenerationException: org.apache.axis2.wsdl.codegen.CodeGenerationE xception: Unsupported Schema format for unwrapping! found unknown but expected sequence at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224 ) at com.wso2.tungsten.admin.service.wsdl2code.WSDL2CodeService.generate(WSDL2CodeService.java :154) at com.wso2.tungsten.admin.service.wsdl2code.WSDL2CodeServiceMessageReceiverInOut.invokeBusi nessLogic(WSDL2CodeServiceMessageReceiverInOut.java:55) at org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.receive(AbstractInOutSyncMess ageReceiver.java:39) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:493) at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUt ils.java:323) at org.apache.axis2.transport.http.util.SOAPUtil.processPostRequest(SOAPUtil.java:57) at com.wso2.tungsten.transport.jetty.Axis2SOAPHandler.processPostRequest(Axis2SOAPHandler.ja va:42) at com.wso2.tungsten.transport.jetty.Axis2Handler.dispatch(Axis2Handler.java:175) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) at org.mortbay.http.HttpServer.service(HttpServer.java:909) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) Caused by: org.apache.axis2.wsdl.codegen.CodeGenerationException: Unsupported Schema format for unwr apping! found unknown but expected sequence at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.processXMLSchemaSequence (SchemaUnwrapperExtension.java:287) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.handleAllCasesOfComplexT ypes(SchemaUnwrapperExtension.java:164) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.walkSchema(SchemaUnwrapp erExtension.java:122) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.engage(SchemaUnwrapperEx tension.java:87) at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:177 ) ... 18 more ERROR [2006-10-10 16:12:49,343] org.apache.axis2.AxisFault: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown but expected sequence; nested exception is: java.lang.RuntimeException: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown but expected sequence; nested exception is: org.apache.axis2.AxisFault: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown but expected sequence; nested exception is: java.lang.RuntimeException: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown but
Re: [Axis2] Proposal to add return type to Handler.invoke(...)
+1 from me.
On 10/10/06, Srinath Perera <[EMAIL PROTECTED]> wrote:
+1
On 10/9/06, Bill Nagy <[EMAIL PROTECTED]> wrote:
> There is currently a race condition between code that pauses the message
> flow within a handler and resumes it on another thread (e.g. Sandesha)
> and the message flow processing chain (Phase.invoke(...),
> AxisEngine.invoke(...), etc.)
> (http://issues.apache.org/jira/browse/SANDESHA2-32) This is caused
> because the control of processing is keyed off of MessageContext.paused
> and not through some other mechanism (return code, semaphore, etc.). If
> a handler pauses a message and returns, handing the message off to
> another thread for execution, there is the possibility that the new
> execution thread will resume processing of the message, unsetting
> MessageContext.paused, before control returns to one of the invoke
> methods. If this happens, the logic in the invoke method, which looks
> at the MessageContext.paused flag, will believe that it should continue
> execution instead of halting.
>
> Since the problem revolves around flow control logic, I suggest that we
> use the return code from the method invocation to deal with it. I would
> like to add a return code to the Handler.invoke(...) which would
> identify how processing of the message should proceed, e.g. :
>
> /**
> * This type encapsulates an enumeration of possible message processing
> * instruction values that may be returned by a handler/phase within the
> * runtime.
> */
> public class InvocationProcessingInstruction
> {
> public static InvocationProcessingInstruction CONTINUE_PROCESSING =
> new InvocationProcessingInstruction(0);
> public static InvocationProcessingInstruction SUSPEND_PROCESSING = new
> InvocationProcessingInstruction(1);
> public static InvocationProcessingInstruction ABORT_PROCESSING = new
> InvocationProcessingInstruction(2);
>
> private int instructionID;
>
> private InvocationProcessingInstruction(int instructionID)
> {
> this.instructionID = instructionID;
> }
>
> public boolean equals(InvocationProcessingInstruction instruction)
> {
> return this.instructionID == instruction.instructionID;
> }
>
> public int hashCode()
> {
> return instructionID;
> }
> }
>
> Most handlers will return
> InvocationProcessingInstruction.CONTINUE_PROCESSING; the RM handler may
> return that, SUSPEND_PROCESSING (for a pause), or ABORT_PROCESSING (for
> a duplicate msg.)
>
> Comments?
>
> -Bill
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Srinath Perera:
Indiana University, Bloomington
http://www.cs.indiana.edu/~hperera/
http://www.bloglines.com/blog/hemapani
-
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]
Re: [Axis2][1.1-RC1] Security sample is not included
Thilina, if i add snapshots to the name, the mar wont load :( -- dims On 10/10/06, Thilina Gunarathne <[EMAIL PROTECTED]> wrote: I would not recommend you to try mixing the stuff between 1.0 and 1.1... You can try the snapshots together with 1.1-RC1... http://people.apache.org/repository/org.apache.axis2/mars/rampart-1.1.mar IMO this version number is wrong.. Should be 1.1-snapshots.. ~Thilina On 10/10/06, Ali Sadik Kumlali <[EMAIL PROTECTED]> wrote: > Thanks Thilina. Do I have a chance to test my codebase which uses Axis2 1.0(Rampart included) against Axis2 1.1 RC1(Rampart excluded) by adding Rampart externally somehow? Or am I required to wait till Axis2 1.1 and then Rampart has been released? > > Regards, > > Ali Sadik Kumlali > > - Original Message > From: Thilina Gunarathne <[EMAIL PROTECTED]> > To: axis-dev@ws.apache.org > Sent: Tuesday, October 10, 2006 2:24:38 AM > Subject: Re: [Axis2][1.1-RC1] Security sample is not included > > We will not be releasing the security stuff (Rampart,Rahas) with Axis2 > 1.1. They will be released separately after the Axis2 1.1 release.. > > ~Thilina > > On 10/10/06, Ali Sadik Kumlali <[EMAIL PROTECTED]> wrote: > > Hi devs, > > > > I haven't seen the security sample within the nightlies for a while. And it isn't included in the 1.1 RC1, either. > > > > Is it a known issue? > > > > Regards, > > > > Ali Sadik Kumlali > > > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > http://webservices.apache.org/~thilina/ > http://thilinag.blogspot.com/ > > - > 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] > > -- http://webservices.apache.org/~thilina/ http://thilinag.blogspot.com/ - 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]
Re: [Axis2] What should be included in Axis2 minimal distribution
Folks, lets move rpc* out of coden. it does not belong there. -- dims On 10/10/06, Thilina Gunarathne <[EMAIL PROTECTED]> wrote: Hi, AFAIK ADB is there because we need the RPCMessageReceiver to work in the minimal distro... Just now I figured out that RPCMessageReceiver resides in the codegen module..Which means we have to include codegen module to the minimal distro.. I'm not sure why we are putting the adb-codegen in to the minimal distro... ~Thilina On 10/10/06, Eran Chinthaka <[EMAIL PROTECTED]> wrote: > Hi, > > Can we please re-visit the modules that should be included in Axis2 > minimal distribution. Currently kernel, adb and java2wsdl modules are > included, but I saw even adb-codegen was added recently. > > What do you think? > > Thanks, > Chinthaka > > > > -- http://webservices.apache.org/~thilina/ http://thilinag.blogspot.com/ - 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]
[jira] Deleted: (AXIS2-1335) Code Generation Exception occurred when Generating Clients
[ http://issues.apache.org/jira/browse/AXIS2-1335?page=all ] Davanum Srinivas deleted AXIS2-1335: > Code Generation Exception occurred when Generating Clients > -- > > Key: AXIS2-1335 > URL: http://issues.apache.org/jira/browse/AXIS2-1335 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug > Environment: Windows XP, jdk1.5.0_08, Maven 1.0.2, Mozilla Firefox > 1.5.0.6 >Reporter: Evanthika Amarasiri >Priority: Critical > > 1. Login to the Tungsten Management Console > 2. Click on the link "Services" which is on the left pane of the page > 3. Click on the link "Generate Client" > 4. Select the following "Stub Generation options" to create the stub > a) Port - CommodityQuoteSOAP11port_https > b) Invocation Style - Both > c) Databinding - ADB > d) Unpack Classes - True > e) Unwrap - True > f) Generate Testcase - False > 5. Select the above options and click on the button "Generate" (You can > change the values of any other option but the value of the option "Unwrap" > should be set to "True" and the port should be either > CommodityQuoteSOAP11port_https or CommodityQuoteSOAP11port_http1) > 6. A Code Generation Exception is thrown > ERROR [2006-10-10 16:12:49,343] Error occurred during code generation. > Unsupported Schema format fo > r unwrapping! found unknown but expected sequence > org.apache.axis2.wsdl.codegen.CodeGenerationException: > org.apache.axis2.wsdl.codegen.CodeGenerationE > xception: Unsupported Schema format for unwrapping! found unknown but > expected sequence > at > org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224 > ) > at > com.wso2.tungsten.admin.service.wsdl2code.WSDL2CodeService.generate(WSDL2CodeService.java > :154) > at > com.wso2.tungsten.admin.service.wsdl2code.WSDL2CodeServiceMessageReceiverInOut.invokeBusi > nessLogic(WSDL2CodeServiceMessageReceiverInOut.java:55) > at > org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.receive(AbstractInOutSyncMess > ageReceiver.java:39) > at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:493) > at > org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUt > ils.java:323) > at > org.apache.axis2.transport.http.util.SOAPUtil.processPostRequest(SOAPUtil.java:57) > at > com.wso2.tungsten.transport.jetty.Axis2SOAPHandler.processPostRequest(Axis2SOAPHandler.ja > va:42) > at > com.wso2.tungsten.transport.jetty.Axis2Handler.dispatch(Axis2Handler.java:175) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) > at org.mortbay.http.HttpServer.service(HttpServer.java:909) > at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) > at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982) > at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) > at > org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) > at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) > at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) > Caused by: org.apache.axis2.wsdl.codegen.CodeGenerationException: Unsupported > Schema format for unwr > apping! found unknown but expected sequence > at > org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.processXMLSchemaSequence > (SchemaUnwrapperExtension.java:287) > at > org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.handleAllCasesOfComplexT > ypes(SchemaUnwrapperExtension.java:164) > at > org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.walkSchema(SchemaUnwrapp > erExtension.java:122) > at > org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.engage(SchemaUnwrapperEx > tension.java:87) > at > org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:177 > ) > ... 18 more > ERROR [2006-10-10 16:12:49,343] org.apache.axis2.AxisFault: Error occurred > during code generation. > Unsupported Schema format for unwrapping! found unknown but expected > sequence; nested exception is: > java.lang.RuntimeException: Error occurred during code generation. > Unsupported Schema format > for unwrapping! found unknown but expected sequence; nested exception is: > org.apache.axis2.AxisFault: Error occurred during code generation. > Unsupported Schema format > for unwrapping! found unknown but expected sequence; nested exception is: > java.lang.RuntimeException: Error o
[jira] Updated: (AXIS2-1335) Code Generation Exception occurred when Generating Clients
[ http://issues.apache.org/jira/browse/AXIS2-1335?page=all ] Evanthika Amarasiri updated AXIS2-1335: --- Attachment: Error 6.JPG > Code Generation Exception occurred when Generating Clients > -- > > Key: AXIS2-1335 > URL: http://issues.apache.org/jira/browse/AXIS2-1335 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug >Affects Versions: 1.1 > Environment: Windows XP, jdk1.5.0_08, Maven 1.0.2, Mozilla Firefox > 1.5.0.6 >Reporter: Evanthika Amarasiri >Priority: Critical > Attachments: Error 6.JPG > > > 1. Login to the Tungsten Management Console > 2. Click on the link "Services" which is on the left pane of the page > 3. Click on the link "Generate Client" > 4. Select the following "Stub Generation options" to create the stub > a) Port - CommodityQuoteSOAP11port_https > b) Invocation Style - Both > c) Databinding - ADB > d) Unpack Classes - True > e) Unwrap - True > f) Generate Testcase - False > 5. Select the above options and click on the button "Generate" (You can > change the values of any other option but the value of the option "Unwrap" > should be set to "True" and the port should be either > CommodityQuoteSOAP11port_https or CommodityQuoteSOAP11port_http1) > 6. A Code Generation Exception is thrown > ERROR [2006-10-10 16:12:49,343] Error occurred during code generation. > Unsupported Schema format fo > r unwrapping! found unknown but expected sequence > org.apache.axis2.wsdl.codegen.CodeGenerationException: > org.apache.axis2.wsdl.codegen.CodeGenerationE > xception: Unsupported Schema format for unwrapping! found unknown but > expected sequence > at > org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224 > ) > at > com.wso2.tungsten.admin.service.wsdl2code.WSDL2CodeService.generate(WSDL2CodeService.java > :154) > at > com.wso2.tungsten.admin.service.wsdl2code.WSDL2CodeServiceMessageReceiverInOut.invokeBusi > nessLogic(WSDL2CodeServiceMessageReceiverInOut.java:55) > at > org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.receive(AbstractInOutSyncMess > ageReceiver.java:39) > at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:493) > at > org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUt > ils.java:323) > at > org.apache.axis2.transport.http.util.SOAPUtil.processPostRequest(SOAPUtil.java:57) > at > com.wso2.tungsten.transport.jetty.Axis2SOAPHandler.processPostRequest(Axis2SOAPHandler.ja > va:42) > at > com.wso2.tungsten.transport.jetty.Axis2Handler.dispatch(Axis2Handler.java:175) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) > at org.mortbay.http.HttpServer.service(HttpServer.java:909) > at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) > at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982) > at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) > at > org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) > at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) > at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) > Caused by: org.apache.axis2.wsdl.codegen.CodeGenerationException: Unsupported > Schema format for unwr > apping! found unknown but expected sequence > at > org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.processXMLSchemaSequence > (SchemaUnwrapperExtension.java:287) > at > org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.handleAllCasesOfComplexT > ypes(SchemaUnwrapperExtension.java:164) > at > org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.walkSchema(SchemaUnwrapp > erExtension.java:122) > at > org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.engage(SchemaUnwrapperEx > tension.java:87) > at > org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:177 > ) > ... 18 more > ERROR [2006-10-10 16:12:49,343] org.apache.axis2.AxisFault: Error occurred > during code generation. > Unsupported Schema format for unwrapping! found unknown but expected > sequence; nested exception is: > java.lang.RuntimeException: Error occurred during code generation. > Unsupported Schema format > for unwrapping! found unknown but expected sequence; nested exception is: > org.apache.axis2.AxisFault: Error occurred during code generation. > Unsupported Schema format > for unwrapping! found
[jira] Created: (AXIS2-1335) Code Generation Exception occurred when Generating Clients
Code Generation Exception occurred when Generating Clients -- Key: AXIS2-1335 URL: http://issues.apache.org/jira/browse/AXIS2-1335 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Affects Versions: 1.1 Environment: Windows XP, jdk1.5.0_08, Maven 1.0.2, Mozilla Firefox 1.5.0.6 Reporter: Evanthika Amarasiri Priority: Critical 1. Login to the Tungsten Management Console 2. Click on the link "Services" which is on the left pane of the page 3. Click on the link "Generate Client" 4. Select the following "Stub Generation options" to create the stub a) Port - CommodityQuoteSOAP11port_https b) Invocation Style - Both c) Databinding - ADB d) Unpack Classes - True e) Unwrap - True f) Generate Testcase - False 5. Select the above options and click on the button "Generate" (You can change the values of any other option but the value of the option "Unwrap" should be set to "True" and the port should be either CommodityQuoteSOAP11port_https or CommodityQuoteSOAP11port_http1) 6. A Code Generation Exception is thrown ERROR [2006-10-10 16:12:49,343] Error occurred during code generation. Unsupported Schema format fo r unwrapping! found unknown but expected sequence org.apache.axis2.wsdl.codegen.CodeGenerationException: org.apache.axis2.wsdl.codegen.CodeGenerationE xception: Unsupported Schema format for unwrapping! found unknown but expected sequence at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224 ) at com.wso2.tungsten.admin.service.wsdl2code.WSDL2CodeService.generate(WSDL2CodeService.java :154) at com.wso2.tungsten.admin.service.wsdl2code.WSDL2CodeServiceMessageReceiverInOut.invokeBusi nessLogic(WSDL2CodeServiceMessageReceiverInOut.java:55) at org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.receive(AbstractInOutSyncMess ageReceiver.java:39) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:493) at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUt ils.java:323) at org.apache.axis2.transport.http.util.SOAPUtil.processPostRequest(SOAPUtil.java:57) at com.wso2.tungsten.transport.jetty.Axis2SOAPHandler.processPostRequest(Axis2SOAPHandler.ja va:42) at com.wso2.tungsten.transport.jetty.Axis2Handler.dispatch(Axis2Handler.java:175) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) at org.mortbay.http.HttpServer.service(HttpServer.java:909) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) Caused by: org.apache.axis2.wsdl.codegen.CodeGenerationException: Unsupported Schema format for unwr apping! found unknown but expected sequence at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.processXMLSchemaSequence (SchemaUnwrapperExtension.java:287) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.handleAllCasesOfComplexT ypes(SchemaUnwrapperExtension.java:164) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.walkSchema(SchemaUnwrapp erExtension.java:122) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.engage(SchemaUnwrapperEx tension.java:87) at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:177 ) ... 18 more ERROR [2006-10-10 16:12:49,343] org.apache.axis2.AxisFault: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown but expected sequence; nested exception is: java.lang.RuntimeException: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown but expected sequence; nested exception is: org.apache.axis2.AxisFault: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown but expected sequence; nested exception is: java.lang.RuntimeException: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown but expected sequence ERROR [2006-10-10 16:12:49,343] Unable to handle request com.wso2.tungsten.TungstenException: org.apache.axis2.AxisFault: Error occurred during code generati on. Unsupported Schema format f
Re: [Axis2] Proposal to add return type to Handler.invoke(...)
+1
On 10/9/06, Bill Nagy <[EMAIL PROTECTED]> wrote:
There is currently a race condition between code that pauses the message
flow within a handler and resumes it on another thread (e.g. Sandesha)
and the message flow processing chain (Phase.invoke(...),
AxisEngine.invoke(...), etc.)
(http://issues.apache.org/jira/browse/SANDESHA2-32) This is caused
because the control of processing is keyed off of MessageContext.paused
and not through some other mechanism (return code, semaphore, etc.). If
a handler pauses a message and returns, handing the message off to
another thread for execution, there is the possibility that the new
execution thread will resume processing of the message, unsetting
MessageContext.paused, before control returns to one of the invoke
methods. If this happens, the logic in the invoke method, which looks
at the MessageContext.paused flag, will believe that it should continue
execution instead of halting.
Since the problem revolves around flow control logic, I suggest that we
use the return code from the method invocation to deal with it. I would
like to add a return code to the Handler.invoke(...) which would
identify how processing of the message should proceed, e.g. :
/**
* This type encapsulates an enumeration of possible message processing
* instruction values that may be returned by a handler/phase within the
* runtime.
*/
public class InvocationProcessingInstruction
{
public static InvocationProcessingInstruction CONTINUE_PROCESSING =
new InvocationProcessingInstruction(0);
public static InvocationProcessingInstruction SUSPEND_PROCESSING = new
InvocationProcessingInstruction(1);
public static InvocationProcessingInstruction ABORT_PROCESSING = new
InvocationProcessingInstruction(2);
private int instructionID;
private InvocationProcessingInstruction(int instructionID)
{
this.instructionID = instructionID;
}
public boolean equals(InvocationProcessingInstruction instruction)
{
return this.instructionID == instruction.instructionID;
}
public int hashCode()
{
return instructionID;
}
}
Most handlers will return
InvocationProcessingInstruction.CONTINUE_PROCESSING; the RM handler may
return that, SUSPEND_PROCESSING (for a pause), or ABORT_PROCESSING (for
a duplicate msg.)
Comments?
-Bill
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Srinath Perera:
Indiana University, Bloomington
http://www.cs.indiana.edu/~hperera/
http://www.bloglines.com/blog/hemapani
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] What should be included in Axis2 minimal distribution
Hi Dennis, http://svn.apache.org/viewvc/webservices/axis2/branches/java/1_1/maven.xml This is it Have fun :) Thanks, ~Thilina On 10/10/06, Thilina Gunarathne <[EMAIL PROTECTED]> wrote: Yes.. We need to figure out the unnecessary jars... Good to know that we can get rid of bcel-xxx.jar and jibx bind... I'll set up a wiki page ot figure out what we need and what we don't need.. ~Thilina On 10/10/06, Dennis Sosnoski <[EMAIL PROTECTED]> wrote: > While we're looking into this, we should also check the war file > contents. It looks like the full set of jars are included, which is > certainly unnecessary. JiBX support only needs axis2-jibx-XXX.jar and > jibx-run-XXX.jar, not the much larger bcel-XXX.jar (.5 MB) and > jibx-bind-XXX.jar (.3 MB). I can strip these two unnecessary files out > of the war build if someone wants to point me at the appropriate magic > maven file, but I'm sure there's a lot more that can also be eliminated. > > - Dennis > > Dennis M. Sosnoski > SOA, Web Services, and XML > Training and Consulting > http://www.sosnoski.com - http://www.sosnoski.co.nz > Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117 > > > > Thilina Gunarathne wrote: > > Hi, > > AFAIK ADB is there because we need the RPCMessageReceiver to work in > > the minimal distro... > > Just now I figured out that RPCMessageReceiver resides in the codegen > > module..Which means we have to include codegen module to the minimal > > distro.. > > > > I'm not sure why we are putting the adb-codegen in to the minimal > > distro... > > > > ~Thilina > > > > On 10/10/06, Eran Chinthaka <[EMAIL PROTECTED]> wrote: > >> Hi, > >> > >> Can we please re-visit the modules that should be included in Axis2 > >> minimal distribution. Currently kernel, adb and java2wsdl modules are > >> included, but I saw even adb-codegen was added recently. > >> > >> What do you think? > >> > >> Thanks, > >> Chinthaka > >> > >> > >> > >> > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- http://webservices.apache.org/~thilina/ http://thilinag.blogspot.com/ -- http://webservices.apache.org/~thilina/ http://thilinag.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] What should be included in Axis2 minimal distribution
Yes.. We need to figure out the unnecessary jars... Good to know that we can get rid of bcel-xxx.jar and jibx bind... I'll set up a wiki page ot figure out what we need and what we don't need.. ~Thilina On 10/10/06, Dennis Sosnoski <[EMAIL PROTECTED]> wrote: While we're looking into this, we should also check the war file contents. It looks like the full set of jars are included, which is certainly unnecessary. JiBX support only needs axis2-jibx-XXX.jar and jibx-run-XXX.jar, not the much larger bcel-XXX.jar (.5 MB) and jibx-bind-XXX.jar (.3 MB). I can strip these two unnecessary files out of the war build if someone wants to point me at the appropriate magic maven file, but I'm sure there's a lot more that can also be eliminated. - Dennis Dennis M. Sosnoski SOA, Web Services, and XML Training and Consulting http://www.sosnoski.com - http://www.sosnoski.co.nz Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117 Thilina Gunarathne wrote: > Hi, > AFAIK ADB is there because we need the RPCMessageReceiver to work in > the minimal distro... > Just now I figured out that RPCMessageReceiver resides in the codegen > module..Which means we have to include codegen module to the minimal > distro.. > > I'm not sure why we are putting the adb-codegen in to the minimal > distro... > > ~Thilina > > On 10/10/06, Eran Chinthaka <[EMAIL PROTECTED]> wrote: >> Hi, >> >> Can we please re-visit the modules that should be included in Axis2 >> minimal distribution. Currently kernel, adb and java2wsdl modules are >> included, but I saw even adb-codegen was added recently. >> >> What do you think? >> >> Thanks, >> Chinthaka >> >> >> >> > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://webservices.apache.org/~thilina/ http://thilinag.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-729) 404 Not Found trying to access JiBX example page
[ http://issues.apache.org/jira/browse/AXIS2-729?page=all ] Dennis Sosnoski resolved AXIS2-729. --- Fix Version/s: nightly Resolution: Fixed Added more JiBX documentation, including details of wrapped and unwrapped examples. All links should now be good. http://svn.apache.org/viewvc?view=rev&rev=454672 > 404 Not Found trying to access JiBX example page > > > Key: AXIS2-729 > URL: http://issues.apache.org/jira/browse/AXIS2-729 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug > Components: samples, build,site & docs >Affects Versions: 1.0 >Reporter: Brent Ulbricht > Assigned To: Dennis Sosnoski >Priority: Minor > Fix For: nightly > > > The link for the "JiBX example" from > http://ws.apache.org/axis2/1_0/jibx/jibx-codegen-integration.html leads to > http://ws.apache.org/axis2/1_0/jibx/jibx-example.html, which gives a 404 Not > Found. -- 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] What should be included in Axis2 minimal distribution
While we're looking into this, we should also check the war file contents. It looks like the full set of jars are included, which is certainly unnecessary. JiBX support only needs axis2-jibx-XXX.jar and jibx-run-XXX.jar, not the much larger bcel-XXX.jar (.5 MB) and jibx-bind-XXX.jar (.3 MB). I can strip these two unnecessary files out of the war build if someone wants to point me at the appropriate magic maven file, but I'm sure there's a lot more that can also be eliminated. - Dennis Dennis M. Sosnoski SOA, Web Services, and XML Training and Consulting http://www.sosnoski.com - http://www.sosnoski.co.nz Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117 Thilina Gunarathne wrote: Hi, AFAIK ADB is there because we need the RPCMessageReceiver to work in the minimal distro... Just now I figured out that RPCMessageReceiver resides in the codegen module..Which means we have to include codegen module to the minimal distro.. I'm not sure why we are putting the adb-codegen in to the minimal distro... ~Thilina On 10/10/06, Eran Chinthaka <[EMAIL PROTECTED]> wrote: Hi, Can we please re-visit the modules that should be included in Axis2 minimal distribution. Currently kernel, adb and java2wsdl modules are included, but I saw even adb-codegen was added recently. What do you think? Thanks, Chinthaka - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] What should be included in Axis2 minimal distribution
Hi, AFAIK ADB is there because we need the RPCMessageReceiver to work in the minimal distro... Just now I figured out that RPCMessageReceiver resides in the codegen module..Which means we have to include codegen module to the minimal distro.. I'm not sure why we are putting the adb-codegen in to the minimal distro... ~Thilina On 10/10/06, Eran Chinthaka <[EMAIL PROTECTED]> wrote: Hi, Can we please re-visit the modules that should be included in Axis2 minimal distribution. Currently kernel, adb and java2wsdl modules are included, but I saw even adb-codegen was added recently. What do you think? Thanks, Chinthaka -- http://webservices.apache.org/~thilina/ http://thilinag.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-1334) Deployment of Sandesha2 causes exception in Axis2 Admin-Frontend
[ http://issues.apache.org/jira/browse/AXIS2-1334?page=comments#action_12441104 ] Thilo Frotscher commented on AXIS2-1334: I investigated further... Sandesha2 1.0 works fine with Axis2 1.0 but not with Axis2 1.1 RC1. But I don't know whether this is an issue with Axis2 1.1 or whether there is just a new Sandesha2 release needed. In the latter case, it should be documented in the Sandesha2 user guide which Sandesha release works with which Axis2 release. > Deployment of Sandesha2 causes exception in Axis2 Admin-Frontend > > > Key: AXIS2-1334 > URL: http://issues.apache.org/jira/browse/AXIS2-1334 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug > Components: core >Affects Versions: 1.1 > Environment: Axis2 1.1 RC1 > Sandesha2 1.0 >Reporter: Thilo Frotscher >Priority: Blocker > > - deploy a fresh Axis2 1.1 RC1 into Tomcat > - startup Tomcat > - check out Axis2 Web Admin Frontend with browser - works fine! > - shut down Tomcat > - copy sandesha2-1.0.mar into WEB-INF/modules > - add name of module archive to modules.list (not sure if this step is > needed, but bug occurs with or without this step!) > - add RMPhase to all four flows, according to Sandesha2 user guide: > http://ws.apache.org/sandesha/sandesha2/userGuide.html > - start up Tomcat > - check out Axis2 Web Admin Frontend with browser - Exception! > TOMCAT's LOG FILE > = > java.lang.NoSuchMethodError: > org.apache.axis2.description.PolicyInclude.getEffectivePolicy()Lorg/apache/ws/policy/Policy; > at > org.apache.sandesha2.util.PropertyManager.loadPropertiesFromModuleDescPolicy(PropertyManager.java:158) > at org.apache.sandesha2.SandeshaModule.init(SandeshaModule.java:50) > at > org.apache.axis2.context.ConfigurationContextFactory.initModules(ConfigurationContextFactory.java:217) > at > org.apache.axis2.context.ConfigurationContextFactory.init(ConfigurationContextFactory.java:193) > at > org.apache.axis2.context.ConfigurationContextFactory.createConfigurationContext(ConfigurationContextFactory.java:70) > at > org.apache.axis2.transport.http.AxisServlet.initConfigContext(AxisServlet.java:366) > at > org.apache.axis2.transport.http.AxisServlet.init(AxisServlet.java:304) > at > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1105) > at > org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:932) > at > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3917) > at > org.apache.catalina.core.StandardContext.start(StandardContext.java:4197) > at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759) > at > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) > at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) > at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:809) > at > org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:698) > at > org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:472) > at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1112) > at > org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310) > at > org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) > at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1021) > at org.apache.catalina.core.StandardHost.start(StandardHost.java:718) > at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013) > at > org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442) > at > org.apache.catalina.core.StandardService.start(StandardService.java:450) > at > org.apache.catalina.core.StandardServer.start(StandardServer.java:709) > at org.apache.catalina.startup.Catalina.start(Catalina.java:551) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:275) > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) > BROWSER > === > org.apache.jasper.JasperException > > org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:510) > > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:375) > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) > o
[jira] Created: (AXIS2-1334) Deployment of Sandesha2 causes exception in Axis2 Admin-Frontend
Deployment of Sandesha2 causes exception in Axis2 Admin-Frontend Key: AXIS2-1334 URL: http://issues.apache.org/jira/browse/AXIS2-1334 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: core Affects Versions: 1.1 Environment: Axis2 1.1 RC1 Sandesha2 1.0 Reporter: Thilo Frotscher Priority: Blocker - deploy a fresh Axis2 1.1 RC1 into Tomcat - startup Tomcat - check out Axis2 Web Admin Frontend with browser - works fine! - shut down Tomcat - copy sandesha2-1.0.mar into WEB-INF/modules - add name of module archive to modules.list (not sure if this step is needed, but bug occurs with or without this step!) - add RMPhase to all four flows, according to Sandesha2 user guide: http://ws.apache.org/sandesha/sandesha2/userGuide.html - start up Tomcat - check out Axis2 Web Admin Frontend with browser - Exception! TOMCAT's LOG FILE = java.lang.NoSuchMethodError: org.apache.axis2.description.PolicyInclude.getEffectivePolicy()Lorg/apache/ws/policy/Policy; at org.apache.sandesha2.util.PropertyManager.loadPropertiesFromModuleDescPolicy(PropertyManager.java:158) at org.apache.sandesha2.SandeshaModule.init(SandeshaModule.java:50) at org.apache.axis2.context.ConfigurationContextFactory.initModules(ConfigurationContextFactory.java:217) at org.apache.axis2.context.ConfigurationContextFactory.init(ConfigurationContextFactory.java:193) at org.apache.axis2.context.ConfigurationContextFactory.createConfigurationContext(ConfigurationContextFactory.java:70) at org.apache.axis2.transport.http.AxisServlet.initConfigContext(AxisServlet.java:366) at org.apache.axis2.transport.http.AxisServlet.init(AxisServlet.java:304) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1105) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:932) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3917) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4197) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:809) at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:698) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:472) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1112) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1021) at org.apache.catalina.core.StandardHost.start(StandardHost.java:718) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442) at org.apache.catalina.core.StandardService.start(StandardService.java:450) at org.apache.catalina.core.StandardServer.start(StandardServer.java:709) at org.apache.catalina.startup.Catalina.start(Catalina.java:551) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:275) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) BROWSER === org.apache.jasper.JasperException org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:510) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:375) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) root cause org.apache.jasper.JasperException org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:510) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:393) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.jaspe
