[jira] Commented: (AXIS2-3733) Autogenerated WSDL misses element if POJO function has no parameters
[
https://issues.apache.org/jira/browse/AXIS2-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12834356#action_12834356
]
nadir amra commented on AXIS2-3733:
---
I would like to fix this and was wondering if anyone can point me to the right
direction?
> Autogenerated WSDL misses element if POJO function has no parameters
>
>
> Key: AXIS2-3733
> URL: https://issues.apache.org/jira/browse/AXIS2-3733
> Project: Axis2
> Issue Type: Bug
> Components: wsdl
>Affects Versions: 1.3
> Environment: CentOS 5.1/i386
> Tomcat/6.0.16
> Sun JVM 1.6.0_05-b13
>Reporter: Felix J. Ogris
>Assignee: Deepal Jayasinghe
>
> Given this tiny service:
> package net.ogris.test;
> public class TestService {
> public String helloWorld() {
> return "hello, world";
> }
> }
> Results in this WSDL:
>
> http://schemas.xmlsoap.org/wsdl/";
> xmlns:ns1="http://org.apache.axis2/xsd";
> xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl";
> xmlns:http="http://schemas.xmlsoap.org/wsdl/http/";
> xmlns:ns0="http://test.ogris.net"; xmlns:xs="http://www.w3.org/2001/XMLSchema";
> xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/";
> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";
> xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/";
> targetNamespace="http://test.ogris.net";>
> TestService
>
> http://test.ogris.net";
> attributeFormDefault="qualified" elementFormDefault="qualified"
> targetNamespace="http://test.ogris.net";>
>
>
>
> nillable="true" type="xs:string"/>
>
>
>
>
>
>
>
>
>
>
>
> wsaw:Action="urn:helloWorld"/>
> wsaw:Action="urn:helloWorldResponse"/>
>
>
> type="ns0:TestServicePortType">
> http://schemas.xmlsoap.org/soap/http";
> style="document"/>
>
>
>
>
>
>
>
>
>
>
> type="ns0:TestServicePortType">
> http://schemas.xmlsoap.org/soap/http";
> style="document"/>
>
>
>
>
>
>
>
>
>
>
> type="ns0:TestServicePortType">
>
>
>
>
>
>
>
>
>
>
>
>
> binding="ns0:TestServiceSOAP11Binding">
> location="http://81.89.251.15:8080/axis2/services/TestService"/>
>
> binding="ns0:TestServiceSOAP12Binding">
> location="http://81.89.251.15:8080/axis2/services/TestService"/>
>
> binding="ns0:TestServiceHttpBinding">
> location="http://81.89.251.15:8080/axis2/services/TestService"/>
>
>
>
> Problem:
> There should be an empty element "helloWorldRequest", eg: name="helloWorldRequest" />. Otherwise name="helloWorldRequest"/> has no corresponding element as shown above.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (AXIS2-4440) excludeOperations with static WSDL does not work
[ https://issues.apache.org/jira/browse/AXIS2-4440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nadir amra reopened AXIS2-4440: --- That is fine...which means the operation cannot be invoked. The semantics of excluding operations from being invoked should also be done for static WSDL's. We will work on a fix for this to make it happen. To me it should not be a reach for us to look at the exclude operation list and see if the operation that is being invoked is in the list, in which case we should through an exception to prevent invocation. > excludeOperations with static WSDL does not work > > > Key: AXIS2-4440 > URL: https://issues.apache.org/jira/browse/AXIS2-4440 > Project: Axis 2.0 (Axis2) > Issue Type: Bug >Affects Versions: 1.5, 1.4, 1.3 >Reporter: nadir amra > > A have a static WSDL file for my service. When I use excludeOperations in > services.xml i am still able to invoke the operation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2-4440) excludeOperations with static WSDL does not work
excludeOperations with static WSDL does not work Key: AXIS2-4440 URL: https://issues.apache.org/jira/browse/AXIS2-4440 Project: Axis 2.0 (Axis2) Issue Type: Bug Affects Versions: 1.3, 1.4, 1.5 Reporter: nadir amra A have a static WSDL file for my service. When I use excludeOperations in services.xml i am still able to invoke the operation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AXIS2-3724) WSDL complex type elements do not comply to JAXB Java bean
[ https://issues.apache.org/jira/browse/AXIS2-3724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12713688#action_12713688 ] nadir amra commented on AXIS2-3724: --- So is this going to be fixed anytime soon? Or can someone describe the fix and point me to the files so I can take a look and possibly fix? > WSDL complex type elements do not comply to JAXB Java bean > -- > > Key: AXIS2-3724 > URL: https://issues.apache.org/jira/browse/AXIS2-3724 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: wsdl >Affects Versions: nightly > Environment: Win XP Pro, JDK6_04, Tomcat 5.5.26, JAXB 2.1.6 >Reporter: Glen Verran > Fix For: nightly > > > I created a web service which contains one method. It has one parameter of > type RetrieveConfigurationDataRequest and returns > RetrieveConfigurationDataResponse. > Focusing on RetrieveConfigurationDataRequest , the java bean was generated by > JAXB 2.1.6. Here are the variables from the java bean below > @XmlElement(required = true) > protected String echoData; > @XmlElement(required = true) > protected String identifierType; > @XmlElement(required = true) > protected String identifier; > @XmlElement(required = true) > protected String revision; > protected String vintage; > protected Long dataBlockSize; > protected Long dataBlockPosition; > @XmlElement(required = true) > protected DataEncodingType dataEncodingType; > The order of their "getters" and "setters" appear in the same order as the > variables. > The WSDL that gets generated contains this complexType which lools like this. > > > > > type="xs:long"/> > type="xs:long"/> > type="ax21:DataEncodingType"/> > type="xs:string"/> > type="xs:string"/> > type="xs:string"/> > type="xs:string"/> > type="xs:string"/> > > > > > I find that the WSDL does not comply with the JAXB 2.1.6 generated java bean > in the following ways: > 1) The elements are alphabetically sorted and do not appear in the same > order as in the java bean. > 2) Look at the "identifier" element and you'll see that it has a minOccurs > of 0. This is a required field by the java bean and so should not have a > minOccurs modifier in there. > 3) I also noticed that all the fields are set to nullable. I don't know > what the criteria is for this, but I assume it is because these are referring > to java objects and not primitives. I also think that if an object is > required, that it should not be nullable. > At the end of the day, the WSDL must take JAXB and its annotations into > account and reflect the web service and its java beans 100% and it is not > doing that. > I know there is a workaround by inserting a modified wsdl into the aar file, > but I don't want to have to do that since AXIS2 was designed to generate the > WSDL itself when issuing ?WSDL in a browser. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (AXIS2-3920) Allow to disable HTTP binding at service level using a parameter in services.xml
[ https://issues.apache.org/jira/browse/AXIS2-3920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nadir amra closed AXIS2-3920. - Resolution: Duplicate Duplicate of AXIS2-3114 > Allow to disable HTTP binding at service level using a parameter in > services.xml > > > Key: AXIS2-3920 > URL: https://issues.apache.org/jira/browse/AXIS2-3920 > Project: Axis 2.0 (Axis2) > Issue Type: Bug >Affects Versions: 1.4 >Reporter: Nandana Mihindukulasooriya > Fix For: 1.4.1 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (AXIS2-3279) Axis2-1.3: BeanUtil: wrong xsi:type handling
[
https://issues.apache.org/jira/browse/AXIS2-3279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nadir amra closed AXIS2-3279.
-
Resolution: Fixed
Fix Version/s: nightly
I believe this is fixed in committed revision 652990
> Axis2-1.3: BeanUtil: wrong xsi:type handling
>
>
> Key: AXIS2-3279
> URL: https://issues.apache.org/jira/browse/AXIS2-3279
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: adb
>Affects Versions: 1.3
>Reporter: Jabber W
>Assignee: Deepal Jayasinghe
> Fix For: nightly
>
>
> In the deserialize(Class beanClass,
> OMElement beanElement,
> ObjectSupplier objectSupplier,
> String arrayLocalName)
> 1. there is a bug in the xsi:type hadnling (line 295) :
> String instanceTypeName = beanElement.getAttributeValue(new
> QName("type"))
>-- which returns null when attribute supplied instead
> of --
> String instanceTypeName =
>
> beanElement.getAttributeValue(QName.valueOf("{http://www.w3.org/2001/XMLSchema-instance}type";))
> As a result the supplied xsi:type is missed.
> BUT !!
> 2. Though the attribute value was collected properly it's still buggish :
>the assumption that the xsi:type contains the java name is not justified
> (line 298):
> beanClass = Loader.loadClass(beanClass.getClassLoader(),
> instanceTypeName)
> The xsi:type of course may be translated to appropriate class, but it
> shoudn't be the same.
> All mentioned is highly important issue when the extender types are used.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (AXIS2-3281) xmlns:xsi="http://www.w3.org/2001/XMLSchema- missing from code gen pojo response
[ https://issues.apache.org/jira/browse/AXIS2-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nadir amra closed AXIS2-3281. - Resolution: Fixed Fix Version/s: nightly I believe this is fixed in committed revision 652990 > xmlns:xsi="http://www.w3.org/2001/XMLSchema- missing from code gen pojo > response > - > > Key: AXIS2-3281 > URL: https://issues.apache.org/jira/browse/AXIS2-3281 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: codegen >Affects Versions: 1.3 > Environment: Ubuntu Fiesty Fawn, Caucho Resin 3.1.2 >Reporter: Ryan Vanderwerf > Fix For: nightly > > Attachments: wsdl.txt > > > I am using the POJO interaction I used and found an error in the XML that is > returned. For the server side I won't appear to have any control for this. > The elements of the code reference xsi:nil="true",, however that namespace > is defined nowhere. Since everything is auto-generated from my POJOs, I > assume this is a bug: > from SOAP Monitor: > request: > > http://schemas.xmlsoap.org/soap/envelope/";> > http://schemas.xmlsoap.org/soap/envelope/";> > xmlns:ns2="http://services.webservices.blueberry.mifflin.com";> >xmlns:ns2="http://services.webservices.blueberry.mifflin.com";>x >xmlns:ns2="http://services.webservices.blueberry.mifflin.com";> > > > > response: > > http://schemas.xmlsoap.org/soap/envelope/";> > http://schemas.xmlsoap.org/soap/envelope/";> > xmlns:ns="http://services.webservices.blueberry.mifflin.com";> >xmlns:ns="http://services.webservices.blueberry.mifflin.com"; > xmlns:ax22="http://webservices.blueberry.mifflin.com/xsd";> > xmlns:ax22="http://webservices.blueberry.mifflin.com/xsd";> > > xmlns:ax22="http://webservices.blueberry.mifflin.com/xsd";> > > xmlns:ax22="http://webservices.blueberry.mifflin.com/xsd";> > > xmlns:ax22="http://webservices.blueberry.mifflin.com/xsd";> > > xmlns:ax22="http://webservices.blueberry.mifflin.com/xsd";> > > xmlns:ax22="http://webservices.blueberry.mifflin.com/xsd";>[EMAIL > PROTECTED] > xmlns:ax22="http://webservices.blueberry.mifflin.com/xsd";>blah > xmlns:ax22="http://webservices.blueberry.mifflin.com/xsd";> > > xmlns:ax22="http://webservices.blueberry.mifflin.com/xsd";> > > xmlns:ax22="http://webservices.blueberry.mifflin.com/xsd";> > > xmlns:ax22="http://webservices.blueberry.mifflin.com/xsd";> > > xmlns:ax22="http://webservices.blueberry.mifflin.com/xsd";>hello > xmlns:ax22="http://webservices.blueberry.mifflin.com/xsd";> > > xmlns:ax22="http://webservices.blueberry.mifflin.com/xsd";> > > xmlns:ax22="http://webservices.blueberry.mifflin.com/xsd";> > > xmlns:ax22="http://webservices.blueberry.mifflin.com/xsd";>super > guy > xmlns:ax22="http://webservices.blueberry.mifflin.com/xsd";> > > xmlns:ax22="http://webservices.blueberry.mifflin.com/xsd";>username > > > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (AXIS2-3656) Missing namespace in SOAP response
[ https://issues.apache.org/jira/browse/AXIS2-3656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nadir amra closed AXIS2-3656. - Resolution: Fixed Fix Version/s: nightly Fixed in committed revision 652990 > Missing namespace in SOAP response > -- > > Key: AXIS2-3656 > URL: https://issues.apache.org/jira/browse/AXIS2-3656 > Project: Axis 2.0 (Axis2) > Issue Type: Bug >Affects Versions: 1.3 > Environment: Axis2 v1.3 on JBossAS v4.0.5 running on Java 1.6.0_03. > Windows XP. >Reporter: Nate Roe >Assignee: nadir amra > Fix For: nightly > > Attachments: PersonExpample.zip > > > When my POJO service responds with a List, the SOAP response > serializes a Person as follows: > > > Las Vegas > 12345 Pecos Road > > Jeff Doe 0 > > Notice that for both and , the "type" attribute has > no namespace. > This should look like: > > > Las Vegas > 12345 Pecos Road > > Jeff Doe 0 > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-3651) BeanUtil class should try and fill the xsi:type attribute with value from type table before defaulting to class name
[
https://issues.apache.org/jira/browse/AXIS2-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nadir amra resolved AXIS2-3651.
---
Resolution: Fixed
Fix Version/s: nightly
Fixed in committed revision 652990
> BeanUtil class should try and fill the xsi:type attribute with value from
> type table before defaulting to class name
>
>
> Key: AXIS2-3651
> URL: https://issues.apache.org/jira/browse/AXIS2-3651
> Project: Axis 2.0 (Axis2)
> Issue Type: Improvement
> Components: databinding
>Affects Versions: 1.4, 1.3
> Environment: Windows XP SP2, Java 6
>Reporter: Aaron Gourley
>Assignee: nadir amra
>Priority: Minor
> Fix For: nightly
>
>
> Using the type table to fill the xsi:type attribute would help make it
> possible to successfully validate SOAP response messages against the WSDL.
> Although the class name approach may be sufficient for POJO services, it
> provides meaningless information when other approaches are used.
> I suggest replacing the following lines of BeanUtil.java
> // Added objectAttributes as a fix for issues AXIS2-2055 and
> AXIS2-1899 to
> // support polymorphism in POJO approach.
> // For some reason, using QName(Constants.XSI_NAMESPACE, "type",
> "xsi") does not generate
> // an xsi:type attribtue properly for inner objects. So just
> using a simple QName("type").
> ArrayList objectAttributes = new ArrayList();
> objectAttributes.add(new QName("type"));
> objectAttributes.add(beanObject.getClass().getName());
> With this (or similar ... not sure if qualified check should be there):
> ArrayList objectAttributes = new ArrayList();
> objectAttributes.add(new QName(Constants.XSI_NAMESPACE, "type",
> "xsi"));
> if( typeTable != null && qualified )
> {
> QName qNamefortheType =
>
> typeTable.getQNamefortheType(beanObject.getClass().getName());
> if (qNamefortheType == null) {
> // Added objectAttributes as a fix for issues AXIS2-2055
> and AXIS2-1899 to
> // support polymorphism in POJO approach.
> objectAttributes.add(beanObject.getClass().getName());
> }
> else
> {
> objectAttributes.add(qNamefortheType);
> }
> }
> else
> {
> objectAttributes.add(beanObject.getClass().getName());
> }
> Note that I had no issues with generating the xsi:type attribute for inner
> elements in my testing (as was mentioned by the existing comment).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-3651) BeanUtil class should try and fill the xsi:type attribute with value from type table before defaulting to class name
[
https://issues.apache.org/jira/browse/AXIS2-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593365#action_12593365
]
nadir amra commented on AXIS2-3651:
---
I agree with Aaron...if there is a problem on the client side then it needs to
be fixed on the client side (i.e. open a new JIRA). Currently the reponse that
is returned is not valid and the fix documented here corrects that problem.
> BeanUtil class should try and fill the xsi:type attribute with value from
> type table before defaulting to class name
>
>
> Key: AXIS2-3651
> URL: https://issues.apache.org/jira/browse/AXIS2-3651
> Project: Axis 2.0 (Axis2)
> Issue Type: Improvement
> Components: databinding
>Affects Versions: 1.4, 1.3
> Environment: Windows XP SP2, Java 6
>Reporter: Aaron Gourley
>Assignee: nadir amra
>Priority: Minor
>
> Using the type table to fill the xsi:type attribute would help make it
> possible to successfully validate SOAP response messages against the WSDL.
> Although the class name approach may be sufficient for POJO services, it
> provides meaningless information when other approaches are used.
> I suggest replacing the following lines of BeanUtil.java
> // Added objectAttributes as a fix for issues AXIS2-2055 and
> AXIS2-1899 to
> // support polymorphism in POJO approach.
> // For some reason, using QName(Constants.XSI_NAMESPACE, "type",
> "xsi") does not generate
> // an xsi:type attribtue properly for inner objects. So just
> using a simple QName("type").
> ArrayList objectAttributes = new ArrayList();
> objectAttributes.add(new QName("type"));
> objectAttributes.add(beanObject.getClass().getName());
> With this (or similar ... not sure if qualified check should be there):
> ArrayList objectAttributes = new ArrayList();
> objectAttributes.add(new QName(Constants.XSI_NAMESPACE, "type",
> "xsi"));
> if( typeTable != null && qualified )
> {
> QName qNamefortheType =
>
> typeTable.getQNamefortheType(beanObject.getClass().getName());
> if (qNamefortheType == null) {
> // Added objectAttributes as a fix for issues AXIS2-2055
> and AXIS2-1899 to
> // support polymorphism in POJO approach.
> objectAttributes.add(beanObject.getClass().getName());
> }
> else
> {
> objectAttributes.add(qNamefortheType);
> }
> }
> else
> {
> objectAttributes.add(beanObject.getClass().getName());
> }
> Note that I had no issues with generating the xsi:type attribute for inner
> elements in my testing (as was mentioned by the existing comment).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (AXIS2-3656) Missing namespace in SOAP response
[ https://issues.apache.org/jira/browse/AXIS2-3656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nadir amra reassigned AXIS2-3656: - Assignee: nadir amra > Missing namespace in SOAP response > -- > > Key: AXIS2-3656 > URL: https://issues.apache.org/jira/browse/AXIS2-3656 > Project: Axis 2.0 (Axis2) > Issue Type: Bug >Affects Versions: 1.3 > Environment: Axis2 v1.3 on JBossAS v4.0.5 running on Java 1.6.0_03. > Windows XP. >Reporter: Nate Roe >Assignee: nadir amra > Attachments: PersonExpample.zip > > > When my POJO service responds with a List, the SOAP response > serializes a Person as follows: > > > Las Vegas > 12345 Pecos Road > > Jeff Doe 0 > > Notice that for both and , the "type" attribute has > no namespace. > This should look like: > > > Las Vegas > 12345 Pecos Road > > Jeff Doe 0 > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-3651) BeanUtil class should try and fill the xsi:type attribute with value from type table before defaulting to class name
[
https://issues.apache.org/jira/browse/AXIS2-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12592251#action_12592251
]
nadir amra commented on AXIS2-3651:
---
This seems like a reasonable fix and I want to do further testing but my
initial tests look good. Anyone have any feedback on this? Just to
summarize, if a simple POJO service such as
public class WeatherService{
Weather weather = new Weather();
public void setWeather(Weather weather){
this.weather = weather;
}
public Weather getWeather(){
return this.weather;
}
}
was deployed, the SOAP response that would be returned by the Axis 2 engine
would be something like the following:
=
http://service.pojo.sample";>
http://data.pojo.sample/xsd";
type="sample.pojo.data.Weather">
Sunny
1.0
true
9.5
==
The above response has 2 problems:
(1) "type" is missing xsi qualifier and namespace declaration for xsi
(2) "sample.pojo.data.Weather" is used instead of "ax21:Weather"
With the fix the response now looks like the following:
==
http://service.pojo.sample";>
http://data.pojo.sample/xsd";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:type="ax21:Weather">
Sunny
1.0
true
9.5
===
I think it would have been beneficial to incude this in 1.4, but oh well...:-(
This fix should also knock some several related JIRAs
> BeanUtil class should try and fill the xsi:type attribute with value from
> type table before defaulting to class name
>
>
> Key: AXIS2-3651
> URL: https://issues.apache.org/jira/browse/AXIS2-3651
> Project: Axis 2.0 (Axis2)
> Issue Type: Improvement
> Components: databinding
>Affects Versions: 1.4, 1.3
> Environment: Windows XP SP2, Java 6
>Reporter: Aaron Gourley
>Assignee: nadir amra
>Priority: Minor
>
> Using the type table to fill the xsi:type attribute would help make it
> possible to successfully validate SOAP response messages against the WSDL.
> Although the class name approach may be sufficient for POJO services, it
> provides meaningless information when other approaches are used.
> I suggest replacing the following lines of BeanUtil.java
> // Added objectAttributes as a fix for issues AXIS2-2055 and
> AXIS2-1899 to
> // support polymorphism in POJO approach.
> // For some reason, using QName(Constants.XSI_NAMESPACE, "type",
> "xsi") does not generate
> // an xsi:type attribtue properly for inner objects. So just
> using a simple QName("type").
> ArrayList objectAttributes = new ArrayList();
> objectAttributes.add(new QName("type"));
> objectAttributes.add(beanObject.getClass().getName());
> With this (or similar ... not sure if qualified check should be there):
> ArrayList objectAttributes = new ArrayList();
> objectAttributes.add(new QName(Constants.XSI_NAMESPACE, "type",
> "xsi"));
> if( typeTable != null && qualified )
> {
> QName qNamefortheType =
>
> typeTable.getQNamefortheType(beanObject.getClass().getName());
> if (qNamefortheType == null) {
> // Added objectAttributes as a fix for issues AXIS2-2055
> and AXIS2-1899 to
> // support polymorphism in POJO approach.
> objectAttributes.add(beanObject.getClass().getName());
> }
> else
> {
> objectAttributes.add(qNamefortheType);
> }
> }
> else
> {
> objectAttributes.add(beanObject.getClass().getName());
> }
> Note that I had no issues with generating the xsi:type attribute for inner
> elements in my testing (as was mentioned by the existing comment).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (AXIS2-3651) BeanUtil class should try and fill the xsi:type attribute with value from type table before defaulting to class name
[
https://issues.apache.org/jira/browse/AXIS2-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nadir amra reassigned AXIS2-3651:
-
Assignee: nadir amra
> BeanUtil class should try and fill the xsi:type attribute with value from
> type table before defaulting to class name
>
>
> Key: AXIS2-3651
> URL: https://issues.apache.org/jira/browse/AXIS2-3651
> Project: Axis 2.0 (Axis2)
> Issue Type: Improvement
> Components: databinding
>Affects Versions: 1.4, 1.3
> Environment: Windows XP SP2, Java 6
>Reporter: Aaron Gourley
>Assignee: nadir amra
>Priority: Minor
>
> Using the type table to fill the xsi:type attribute would help make it
> possible to successfully validate SOAP response messages against the WSDL.
> Although the class name approach may be sufficient for POJO services, it
> provides meaningless information when other approaches are used.
> I suggest replacing the following lines of BeanUtil.java
> // Added objectAttributes as a fix for issues AXIS2-2055 and
> AXIS2-1899 to
> // support polymorphism in POJO approach.
> // For some reason, using QName(Constants.XSI_NAMESPACE, "type",
> "xsi") does not generate
> // an xsi:type attribtue properly for inner objects. So just
> using a simple QName("type").
> ArrayList objectAttributes = new ArrayList();
> objectAttributes.add(new QName("type"));
> objectAttributes.add(beanObject.getClass().getName());
> With this (or similar ... not sure if qualified check should be there):
> ArrayList objectAttributes = new ArrayList();
> objectAttributes.add(new QName(Constants.XSI_NAMESPACE, "type",
> "xsi"));
> if( typeTable != null && qualified )
> {
> QName qNamefortheType =
>
> typeTable.getQNamefortheType(beanObject.getClass().getName());
> if (qNamefortheType == null) {
> // Added objectAttributes as a fix for issues AXIS2-2055
> and AXIS2-1899 to
> // support polymorphism in POJO approach.
> objectAttributes.add(beanObject.getClass().getName());
> }
> else
> {
> objectAttributes.add(qNamefortheType);
> }
> }
> else
> {
> objectAttributes.add(beanObject.getClass().getName());
> }
> Note that I had no issues with generating the xsi:type attribute for inner
> elements in my testing (as was mentioned by the existing comment).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Issue Comment Edited: (AXIS2-3746) File setLastModified() in deployment code causes problems
[
https://issues.apache.org/jira/browse/AXIS2-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590251#action_12590251
]
nadiramra edited comment on AXIS2-3746 at 4/17/08 5:28 PM:
Fixed. Much cleaner and correct now.
I will be putting this in the 1.4 release also. The trunk fix is in SVN
649334. The 1.4 branch fix is in SVN 649335.
was (Author: nadiramra):
Fixed. Much cleaner and correct now.
I will be putting this in the 1.4 release also. The trunk fix is in SVN 649334
> File setLastModified() in deployment code causes problems
> -
>
> Key: AXIS2-3746
> URL: https://issues.apache.org/jira/browse/AXIS2-3746
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: deployment
>Reporter: nadir amra
>Assignee: nadir amra
>Priority: Critical
> Fix For: 1.4, nightly
>
>
> I question the usage of the the File class's method setLastModified() in
> WSInfoList.java:
> private void setLastModifiedDate(File file, WSInfo wsInfo) {
> if (file.isDirectory()) {
> File files [] = file.listFiles();
> for (int i = 0; i < files.length; i++) {
> File fileItem = files[i];
> if (fileItem.isDirectory()) {
> setLastModifiedDate(fileItem, wsInfo);
> } else {
> fileItem.setLastModified(wsInfo.getLastModifiedDate());
> }
> }
> } else {
> file.setLastModified(wsInfo.getLastModifiedDate());
> }
> }
> I do not understand why we are actually modifying the last-modified-date of
> the file objects?
> The main reason is that this causes problems when the user ID that AXIS2 is
> running under does not have authority to update the files. So the attempt to
> modify the files will not result on anything be done (we apparently do not
> check if operation failed), but more importantly, if system auditing is
> enabled you will see authority-failure auditing records for each attempt to
> modify the time-stamp for a file. And if hot-update is deployed, this will
> result in 1000's of these records.
> Possible solution: Why do we need to test for equality when looking at
> time-stamps? We can save the newest last-modified time-stamp, and then when
> we want to detect if something has changed, we simply see if the saved
> time-stamp is greater or equal to the file time-stamp. And if this is true,
> then the file has not changed. Otherwise, the file has changed.the added
> benefit is we do not have to update files.
> I will be fixing this ASAP and hopefully will be getting this into Axis 1.4.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Issue Comment Edited: (AXIS2-3746) File setLastModified() in deployment code causes problems
[
https://issues.apache.org/jira/browse/AXIS2-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590251#action_12590251
]
nadiramra edited comment on AXIS2-3746 at 4/17/08 5:12 PM:
Fixed. Much cleaner and correct now.
I will be putting this in the 1.4 release also. The trunk fix is in SVN 649334
was (Author: nadiramra):
Fixed. Much cleaner and correct now.
I will be putting this in the 1.4 release also.
> File setLastModified() in deployment code causes problems
> -
>
> Key: AXIS2-3746
> URL: https://issues.apache.org/jira/browse/AXIS2-3746
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: deployment
>Reporter: nadir amra
>Assignee: nadir amra
>Priority: Critical
> Fix For: 1.4, nightly
>
>
> I question the usage of the the File class's method setLastModified() in
> WSInfoList.java:
> private void setLastModifiedDate(File file, WSInfo wsInfo) {
> if (file.isDirectory()) {
> File files [] = file.listFiles();
> for (int i = 0; i < files.length; i++) {
> File fileItem = files[i];
> if (fileItem.isDirectory()) {
> setLastModifiedDate(fileItem, wsInfo);
> } else {
> fileItem.setLastModified(wsInfo.getLastModifiedDate());
> }
> }
> } else {
> file.setLastModified(wsInfo.getLastModifiedDate());
> }
> }
> I do not understand why we are actually modifying the last-modified-date of
> the file objects?
> The main reason is that this causes problems when the user ID that AXIS2 is
> running under does not have authority to update the files. So the attempt to
> modify the files will not result on anything be done (we apparently do not
> check if operation failed), but more importantly, if system auditing is
> enabled you will see authority-failure auditing records for each attempt to
> modify the time-stamp for a file. And if hot-update is deployed, this will
> result in 1000's of these records.
> Possible solution: Why do we need to test for equality when looking at
> time-stamps? We can save the newest last-modified time-stamp, and then when
> we want to detect if something has changed, we simply see if the saved
> time-stamp is greater or equal to the file time-stamp. And if this is true,
> then the file has not changed. Otherwise, the file has changed.the added
> benefit is we do not have to update files.
> I will be fixing this ASAP and hopefully will be getting this into Axis 1.4.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (AXIS2-3746) File setLastModified() in deployment code causes problems
[
https://issues.apache.org/jira/browse/AXIS2-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nadir amra closed AXIS2-3746.
-
Resolution: Fixed
Fix Version/s: 1.4
Fixed. Much cleaner and correct now.
I will be putting this in the 1.4 release also.
> File setLastModified() in deployment code causes problems
> -
>
> Key: AXIS2-3746
> URL: https://issues.apache.org/jira/browse/AXIS2-3746
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: deployment
>Reporter: nadir amra
>Assignee: nadir amra
>Priority: Critical
> Fix For: 1.4, nightly
>
>
> I question the usage of the the File class's method setLastModified() in
> WSInfoList.java:
> private void setLastModifiedDate(File file, WSInfo wsInfo) {
> if (file.isDirectory()) {
> File files [] = file.listFiles();
> for (int i = 0; i < files.length; i++) {
> File fileItem = files[i];
> if (fileItem.isDirectory()) {
> setLastModifiedDate(fileItem, wsInfo);
> } else {
> fileItem.setLastModified(wsInfo.getLastModifiedDate());
> }
> }
> } else {
> file.setLastModified(wsInfo.getLastModifiedDate());
> }
> }
> I do not understand why we are actually modifying the last-modified-date of
> the file objects?
> The main reason is that this causes problems when the user ID that AXIS2 is
> running under does not have authority to update the files. So the attempt to
> modify the files will not result on anything be done (we apparently do not
> check if operation failed), but more importantly, if system auditing is
> enabled you will see authority-failure auditing records for each attempt to
> modify the time-stamp for a file. And if hot-update is deployed, this will
> result in 1000's of these records.
> Possible solution: Why do we need to test for equality when looking at
> time-stamps? We can save the newest last-modified time-stamp, and then when
> we want to detect if something has changed, we simply see if the saved
> time-stamp is greater or equal to the file time-stamp. And if this is true,
> then the file has not changed. Otherwise, the file has changed.the added
> benefit is we do not have to update files.
> I will be fixing this ASAP and hopefully will be getting this into Axis 1.4.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-3746) File setLastModified() in deployment code causes problems
File setLastModified() in deployment code causes problems
-
Key: AXIS2-3746
URL: https://issues.apache.org/jira/browse/AXIS2-3746
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Components: deployment
Reporter: nadir amra
Assignee: nadir amra
Priority: Critical
Fix For: nightly
I question the usage of the the File class's method setLastModified() in
WSInfoList.java:
private void setLastModifiedDate(File file, WSInfo wsInfo) {
if (file.isDirectory()) {
File files [] = file.listFiles();
for (int i = 0; i < files.length; i++) {
File fileItem = files[i];
if (fileItem.isDirectory()) {
setLastModifiedDate(fileItem, wsInfo);
} else {
fileItem.setLastModified(wsInfo.getLastModifiedDate());
}
}
} else {
file.setLastModified(wsInfo.getLastModifiedDate());
}
}
I do not understand why we are actually modifying the last-modified-date of the
file objects?
The main reason is that this causes problems when the user ID that AXIS2 is
running under does not have authority to update the files. So the attempt to
modify the files will not result on anything be done (we apparently do not
check if operation failed), but more importantly, if system auditing is enabled
you will see authority-failure auditing records for each attempt to modify the
time-stamp for a file. And if hot-update is deployed, this will result in
1000's of these records.
Possible solution: Why do we need to test for equality when looking at
time-stamps? We can save the newest last-modified time-stamp, and then when we
want to detect if something has changed, we simply see if the saved time-stamp
is greater or equal to the file time-stamp. And if this is true, then the file
has not changed. Otherwise, the file has changed.the added benefit is we
do not have to update files.
I will be fixing this ASAP and hopefully will be getting this into Axis 1.4.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-3656) Missing namespace in SOAP response
[ https://issues.apache.org/jira/browse/AXIS2-3656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12588087#action_12588087 ] nadir amra commented on AXIS2-3656: --- Does anyone know whether this is fixed in the nightly builds? This seems to be a show-stopper, no? > Missing namespace in SOAP response > -- > > Key: AXIS2-3656 > URL: https://issues.apache.org/jira/browse/AXIS2-3656 > Project: Axis 2.0 (Axis2) > Issue Type: Bug >Affects Versions: 1.3 > Environment: Axis2 v1.3 on JBossAS v4.0.5 running on Java 1.6.0_03. > Windows XP. >Reporter: Nate Roe > Attachments: PersonExpample.zip > > > When my POJO service responds with a List, the SOAP response > serializes a Person as follows: > > > Las Vegas > 12345 Pecos Road > > Jeff Doe 0 > > Notice that for both and , the "type" attribute has > no namespace. > This should look like: > > > Las Vegas > 12345 Pecos Road > > Jeff Doe 0 > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-3316) Control whether a WSDL is returned when ?wsdl comes in - both at service level and global level
[ https://issues.apache.org/jira/browse/AXIS2-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12569299#action_12569299 ] nadir amra commented on AXIS2-3316: --- I would like to start working on this and was wondering where would be the place to look? I am thinking that the object representing the service will have a flag that can be interrogated by whatever component to determine whether the wsdl should be returned. Please give me a pointer and I can take it from there. > Control whether a WSDL is returned when ?wsdl comes in - both at service > level and global level > > > Key: AXIS2-3316 > URL: https://issues.apache.org/jira/browse/AXIS2-3316 > Project: Axis 2.0 (Axis2) > Issue Type: Improvement > Components: kernel, wsdl >Affects Versions: nightly >Reporter: nadir amra >Assignee: Deepal Jayasinghe > > Need the ability to suppress the returning of WSDL document when a ?wsdl or > ?wsdl2 URL comes into the Axis2 engine. Mainly for security grounds. > The proposal would be to have the ability to do this globally (i.e. via the > axis2.xml file) and at the service level (i.e. in services.xml file), where > the services.xml file overrides the global switch. > I do not see a problem with naming the property the same in both > configuration files, something like "exposeWSDLDocument", with the value > being "true" or "false". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-3301) Generated WSDL has validation errors when methods launch exceptions
[
https://issues.apache.org/jira/browse/AXIS2-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548109
]
nadir amra commented on AXIS2-3301:
---
I think this is a major problem so it needs some focus since tools like eclipse
indicate that the generated the WSDL is not valid and affects the generation of
client stub code. So here are the various artifacts to recreate (we are using
Axis 1.3):
A POJO, ConvertTemp3Services() is deployed that returns an object of type
CONVERTTEMPResult . The java classes are very simple:
===
package iseries.wsbeans.converttemp3;
public class ConvertTemp3Services
{
public ConvertTemp3Services()
{
super();
}
public CONVERTTEMPResult converttemp()
{
CONVERTTEMPResult resultData = new CONVERTTEMPResult();
resultData.set_TEMPOUT("99");
return resultData;
}
}
==
package iseries.wsbeans.converttemp3;
import java.io.Serializable;
public class CONVERTTEMPResult implements Serializable
{
private static final long serialVersionUID = -6046540633483862560L;
private String TEMPOUT = "";
public CONVERTTEMPResult() { super(); }
public void set_TEMPOUT(String value) { TEMPOUT = value; }
public String get_TEMPOUT() { return TEMPOUT; }
}
===
The services.xml file is as follows:
===
http://www.w3.org/2004/08/wsdl/in-only"/>
http://www.w3.org/2004/08/wsdl/in-out"/>
iseries.wsbeans.converttemp3.ConvertTemp3Services
false
===
The Axis 3 automatically generates the following WSDL:
===
http://schemas.xmlsoap.org/wsdl/";
xmlns:ns1="http://converttemp3.wsbeans.iseries/xsd";
xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl";
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/";
xmlns:ns0="http://converttemp3.wsbeans.iseries";
xmlns:xs="http://www.w3.org/2001/XMLSchema";
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/";
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/";
targetNamespace="http://converttemp3.wsbeans.iseries";>
ConvertTemp3
http://converttemp3.wsbeans.iseries";
attributeFormDefault="qualified"
elementFormDefault="qualified"
targetNamespace="http://converttemp3.wsbeans.iseries";>
http://converttemp3.wsbeans.iseries/xsd";
attributeFormDefault="qualified"
elementFormDefault="qualified"
targetNamespace="http://converttemp3.wsbeans.iseries/xsd";>
http://schemas.xmlsoap.org/soap/http";
style="document" />
http://lp01ut10.rchland.ibm.com:10010/web/services/ConvertTemp3"; />
===
The problem is the namespace ns1 in "ns1:CONVERTTEMPResult" in the
"converttempResponse" element. Bascially the WSDL validator in eclipse
indicates the following errors:
IWAB0380E Errors were encountered while validating XML schemas.
XSD: Type reference
'http://converttemp3.wsbeans.iseries/xsd#CONVERTTEMPResult' is unresolved
In axis 1.1 (not sure about 1.2), everything use to be in 1 schema. Not sure
why this was changed. Please fix or give me some clues on where I should take
a look and I can fix. Thanks.
> Generated WSDL has validation errors when methods launch exceptions
> ---
>
> Key: AXIS2-3301
> URL: https://issues.apache.org/jira/browse/AXIS2-3301
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: Tools
>Affects Versions: 1.3
>Reporter: Mauro Molinari
>Assignee: Deepal Jayasinghe
>Priority: C
[jira] Created: (AXIS2-3316) Control whether a WSDL is returned when ?wsdl comes in - both at service level and global level
Control whether a WSDL is returned when ?wsdl comes in - both at service level and global level Key: AXIS2-3316 URL: https://issues.apache.org/jira/browse/AXIS2-3316 Project: Axis 2.0 (Axis2) Issue Type: Improvement Components: kernel, wsdl Affects Versions: nightly Reporter: nadir amra Need the ability to suppress the returning of WSDL document when a ?wsdl or ?wsdl2 URL comes into the Axis2 engine. Mainly for security grounds. The proposal would be to have the ability to do this globally (i.e. via the axis2.xml file) and at the service level (i.e. in services.xml file), where the services.xml file overrides the global switch. I do not see a problem with naming the property the same in both configuration files, something like "exposeWSDLDocument", with the value being "true" or "false". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-3090) Make SOAP 1.2 bindings optional, as they break older Axis 1 clients
[ https://issues.apache.org/jira/browse/AXIS2-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nadir amra resolved AXIS2-3090. --- Resolution: Fixed I hope I am not stepping on any toes, but I have resolved this issue. Deepal, please accept my apologies if I am not doing this according to some process due to my handling the issue that is not assigned to me. Basically added following in axis2.xml: false If set to true, not SOAP 1.2 bindings will be generated, for both wsdl and wsdl2. Of course this issue supplements issue AXIS2-3114. That is, AXIS2-3114 still needs to be implemented to give more flexibility. > Make SOAP 1.2 bindings optional, as they break older Axis 1 clients > --- > > Key: AXIS2-3090 > URL: https://issues.apache.org/jira/browse/AXIS2-3090 > Project: Axis 2.0 (Axis2) > Issue Type: Improvement > Components: kernel >Affects Versions: 1.2 >Reporter: Thomas Leonard >Assignee: Deepal Jayasinghe > Fix For: nightly > > Attachments: disable-soap-1.1.patch > > > We're trying to create some Axis 2 services which are usable by other clients > (including .NET and Axis 1). At first, we had problems due to AXIS2-2294, but > upgrading to Axis 2 1.3-RC2 fixed that. However, the WSDL is still unreadable > to the Axis 1 client because of the SOAP 1.2 bindings which are also present > in the file: > java.io.IOException: ERROR: Missing element inFault > "XMLStreamException" in operation "XMLStreamException", in binding sayHello > The attached patch (disable-soap-1.1.patch) adds a configuration option to > disable generation of these bindings. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-3090) Make SOAP 1.2 bindings optional, as they break older Axis 1 clients
[ https://issues.apache.org/jira/browse/AXIS2-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534478 ] nadir amra commented on AXIS2-3090: --- Deepal, you plan on working on this? I can look into this and provide a configuration switch similar to disableRest in axis2.xml config file > Make SOAP 1.2 bindings optional, as they break older Axis 1 clients > --- > > Key: AXIS2-3090 > URL: https://issues.apache.org/jira/browse/AXIS2-3090 > Project: Axis 2.0 (Axis2) > Issue Type: Improvement > Components: kernel >Affects Versions: 1.2 >Reporter: Thomas Leonard >Assignee: Deepal Jayasinghe > Fix For: nightly > > Attachments: disable-soap-1.1.patch > > > We're trying to create some Axis 2 services which are usable by other clients > (including .NET and Axis 1). At first, we had problems due to AXIS2-2294, but > upgrading to Axis 2 1.3-RC2 fixed that. However, the WSDL is still unreadable > to the Axis 1 client because of the SOAP 1.2 bindings which are also present > in the file: > java.io.IOException: ERROR: Missing element inFault > "XMLStreamException" in operation "XMLStreamException", in binding sayHello > The attached patch (disable-soap-1.1.patch) adds a configuration option to > disable generation of these bindings. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-3114) Control what wsdl bindings returned via services.xml
[ https://issues.apache.org/jira/browse/AXIS2-3114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531807 ] nadir amra commented on AXIS2-3114: --- Related to this issue is that Axis2 would throw a fault depending on what bindings are advertised in the WSDL. For example, if one SOAP 1.1 is the only advertised binding, then any requests that come in as SOAP 1.2 or REST would result in a fault. > Control what wsdl bindings returned via services.xml > > > Key: AXIS2-3114 > URL: https://issues.apache.org/jira/browse/AXIS2-3114 > Project: Axis 2.0 (Axis2) > Issue Type: New Feature > Components: kernel, wsdl >Reporter: nadir amra > > I believe that it would be a very useful feature if we controlled the > generation of what WSDL bindings is returned in a WSDL document by AXIS 2 > (when one does not exist) from within the services.xml file. One can > indicate through a parameter whether SOAP11, SOAP12, HTTP, ALL, etc. binding > are to be returned. > Keith Chapman responded with the following that may be help in showing how > this could be done: > I guess the better solution might be to use the AxisBinding hierarchy > introduced while integrating WSDL 2.0 changes. Currently the services.xml > does not populate the Binding hierarchy but keeps all the details in the > AxisService. It might be a better solution to populate 3 bindings by default > (namely SOAP 1.1, SOAP 1.2 and HTTP) and customize it based on properties in > the services.xml. > When ?wsdl or ?wsdl2 is called we look for binding hierarchy, and if its > present we serialize them. If its not present we generate 3 default bindings. > So if the above is incorporated we would automatically get a WSDL that the > user desires. > Using the binding hierarchy has other benefits, such as been able to > customize a particular binding without affecting the others. I certainly > think that we should be using the Binding hierarchy when building services > from the services.xml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-3017) WSDL generation error - lowercasing 1st char in element names
[
https://issues.apache.org/jira/browse/AXIS2-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519187
]
nadir amra commented on AXIS2-3017:
---
Davanum,
See attachments in this jira. There is a simple example.
> WSDL generation error - lowercasing 1st char in element names
> -
>
> Key: AXIS2-3017
> URL: https://issues.apache.org/jira/browse/AXIS2-3017
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: wsdl
>Reporter: nadir amra
>Assignee: Deepal Jayasinghe
>Priority: Critical
> Attachments: ConvertTemp.zip
>
>
> Here is the problem. I deploy a POJO and when AXIS2 (using nightly build
> 2007/07/25) automatically generated WSDL via ?wsdl it produces a WSDL file
> the includes the following:
>
>
> type="xs:string"/>
> type="xs:string"/>
>
>
>
>
> type="xs:string"/>
> type="xs:string"/>
>
>
> The problem is with the element names. It seems that AXIS2 is lowercasing
> the "t" in TEMPIN and TEMPOUT, which makes the service unusable. The
> CONVERTTEMPInput class is as follows:
> public class CONVERTTEMPInput implements Serializable
> {
> private static final long serialVersionUID = -884605419035002637L;
> public CONVERTTEMPInput() { }
> public void setTEMPIN( String TEMPIN )
> {
> _TEMPIN = TEMPIN;
> }
> public String getTEMPIN( )
> {
>return _TEMPIN;
> }
> public void setTEMPOUT( String TEMPOUT )
> {
> _TEMPOUT = TEMPOUT;
> }
> public String getTEMPOUT( )
> {
>return _TEMPOUT;
> }
>private String _TEMPIN = "";
>private String _TEMPOUT = "";
> }
> If I add an underscore prior to TEMPIN and TEMPOUT in the method names,
> things start to work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-3114) Control what wsdl bindings returned via services.xml
Control what wsdl bindings returned via services.xml Key: AXIS2-3114 URL: https://issues.apache.org/jira/browse/AXIS2-3114 Project: Axis 2.0 (Axis2) Issue Type: New Feature Components: kernel, wsdl Reporter: nadir amra I believe that it would be a very useful feature if we controlled the generation of what WSDL bindings is returned in a WSDL document by AXIS 2 (when one does not exist) from within the services.xml file. One can indicate through a parameter whether SOAP11, SOAP12, HTTP, ALL, etc. binding are to be returned. Keith Chapman responded with the following that may be help in showing how this could be done: I guess the better solution might be to use the AxisBinding hierarchy introduced while integrating WSDL 2.0 changes. Currently the services.xml does not populate the Binding hierarchy but keeps all the details in the AxisService. It might be a better solution to populate 3 bindings by default (namely SOAP 1.1, SOAP 1.2 and HTTP) and customize it based on properties in the services.xml. When ?wsdl or ?wsdl2 is called we look for binding hierarchy, and if its present we serialize them. If its not present we generate 3 default bindings. So if the above is incorporated we would automatically get a WSDL that the user desires. Using the binding hierarchy has other benefits, such as been able to customize a particular binding without affecting the others. I certainly think that we should be using the Binding hierarchy when building services from the services.xml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-3017) WSDL generation error - lowercasing 1st char in element names
[
https://issues.apache.org/jira/browse/AXIS2-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516309
]
nadir amra commented on AXIS2-3017:
---
Deepal,
Just wondering whether Annongen is the one that invokes the methods or is it
Axis 2? And if it is Axis 2, why can it not be fixed?
Sorry if the question is simplistic, I do not know much about how Axis 2 uses
annogen, etc and just want to get an idea how things work.
> WSDL generation error - lowercasing 1st char in element names
> -
>
> Key: AXIS2-3017
> URL: https://issues.apache.org/jira/browse/AXIS2-3017
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: wsdl
>Reporter: nadir amra
>Assignee: Deepal Jayasinghe
>Priority: Critical
> Attachments: ConvertTemp.zip
>
>
> Here is the problem. I deploy a POJO and when AXIS2 (using nightly build
> 2007/07/25) automatically generated WSDL via ?wsdl it produces a WSDL file
> the includes the following:
>
>
> type="xs:string"/>
> type="xs:string"/>
>
>
>
>
> type="xs:string"/>
> type="xs:string"/>
>
>
> The problem is with the element names. It seems that AXIS2 is lowercasing
> the "t" in TEMPIN and TEMPOUT, which makes the service unusable. The
> CONVERTTEMPInput class is as follows:
> public class CONVERTTEMPInput implements Serializable
> {
> private static final long serialVersionUID = -884605419035002637L;
> public CONVERTTEMPInput() { }
> public void setTEMPIN( String TEMPIN )
> {
> _TEMPIN = TEMPIN;
> }
> public String getTEMPIN( )
> {
>return _TEMPIN;
> }
> public void setTEMPOUT( String TEMPOUT )
> {
> _TEMPOUT = TEMPOUT;
> }
> public String getTEMPOUT( )
> {
>return _TEMPOUT;
> }
>private String _TEMPIN = "";
>private String _TEMPOUT = "";
> }
> If I add an underscore prior to TEMPIN and TEMPOUT in the method names,
> things start to work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-3017) WSDL generation error - lowercasing 1st char in element names
[
https://issues.apache.org/jira/browse/AXIS2-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516025
]
nadir amra commented on AXIS2-3017:
---
Dims, thanks. But the problem should be fixed. This has nothing to with what
the property is. This has simply to do with how we resolve to the getter and
setter methods, which I think is a bug.
> WSDL generation error - lowercasing 1st char in element names
> -
>
> Key: AXIS2-3017
> URL: https://issues.apache.org/jira/browse/AXIS2-3017
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: wsdl
>Reporter: nadir amra
>Assignee: Deepal Jayasinghe
>Priority: Critical
> Attachments: ConvertTemp.zip
>
>
> Here is the problem. I deploy a POJO and when AXIS2 (using nightly build
> 2007/07/25) automatically generated WSDL via ?wsdl it produces a WSDL file
> the includes the following:
>
>
> type="xs:string"/>
> type="xs:string"/>
>
>
>
>
> type="xs:string"/>
> type="xs:string"/>
>
>
> The problem is with the element names. It seems that AXIS2 is lowercasing
> the "t" in TEMPIN and TEMPOUT, which makes the service unusable. The
> CONVERTTEMPInput class is as follows:
> public class CONVERTTEMPInput implements Serializable
> {
> private static final long serialVersionUID = -884605419035002637L;
> public CONVERTTEMPInput() { }
> public void setTEMPIN( String TEMPIN )
> {
> _TEMPIN = TEMPIN;
> }
> public String getTEMPIN( )
> {
>return _TEMPIN;
> }
> public void setTEMPOUT( String TEMPOUT )
> {
> _TEMPOUT = TEMPOUT;
> }
> public String getTEMPOUT( )
> {
>return _TEMPOUT;
> }
>private String _TEMPIN = "";
>private String _TEMPOUT = "";
> }
> If I add an underscore prior to TEMPIN and TEMPOUT in the method names,
> things start to work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (AXIS2-3017) WSDL generation error - lowercasing 1st char in element names
[
https://issues.apache.org/jira/browse/AXIS2-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nadir amra reopened AXIS2-3017:
---
I guess I want to discuss before closing issue.
>From my point of view, this is an AXIS 2 bug if you want to state that POJOs
>are supported as a service.
I am OK with stating that element names have to be lowercasebut I do not
understand when a request coming in why AXIS2 is looking for settEMPIN since
this is not a java convention. It should ensure the first character in the
element name is uppercased, no?
I really disagree with you about not fixing this since I do not see what the
alternative is?
> WSDL generation error - lowercasing 1st char in element names
> -
>
> Key: AXIS2-3017
> URL: https://issues.apache.org/jira/browse/AXIS2-3017
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: wsdl
>Reporter: nadir amra
>Assignee: Deepal Jayasinghe
>Priority: Blocker
> Attachments: ConvertTemp.zip
>
>
> Here is the problem. I deploy a POJO and when AXIS2 (using nightly build
> 2007/07/25) automatically generated WSDL via ?wsdl it produces a WSDL file
> the includes the following:
>
>
> type="xs:string"/>
> type="xs:string"/>
>
>
>
>
> type="xs:string"/>
> type="xs:string"/>
>
>
> The problem is with the element names. It seems that AXIS2 is lowercasing
> the "t" in TEMPIN and TEMPOUT, which makes the service unusable. The
> CONVERTTEMPInput class is as follows:
> public class CONVERTTEMPInput implements Serializable
> {
> private static final long serialVersionUID = -884605419035002637L;
> public CONVERTTEMPInput() { }
> public void setTEMPIN( String TEMPIN )
> {
> _TEMPIN = TEMPIN;
> }
> public String getTEMPIN( )
> {
>return _TEMPIN;
> }
> public void setTEMPOUT( String TEMPOUT )
> {
> _TEMPOUT = TEMPOUT;
> }
> public String getTEMPOUT( )
> {
>return _TEMPOUT;
> }
>private String _TEMPIN = "";
>private String _TEMPOUT = "";
> }
> If I add an underscore prior to TEMPIN and TEMPOUT in the method names,
> things start to work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-3017) WSDL generation error - lowercasing 1st char in element names
[
https://issues.apache.org/jira/browse/AXIS2-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nadir amra updated AXIS2-3017:
--
Attachment: ConvertTemp.zip
I hava attached a very simple POJO service to illustrate the problem. When a
client tried to invoke the service, the response returned is simply:
http://schemas.xmlsoap.org/soap/envelope/";>
http://generate.com";>
http://generate.com/xsd";
type="com.generate.CONVERTTEMPResult" />
However, if I change the methods to settEMPIN and gettEMPIN and settEMPOUT and
gettEMPOUT, a valid response is returned.
So when a WSDL is generated by AXIS2, I suspect that AXIS2 calls
JavaUtils.xmlNameToJavaIdentifier, which lowercases the first character.
However, when AXIS2 receives the response, it attempts to look for settEMPIN,
etc.
I do not know what the proper fix would be. We can either NOT lowercase the
character for POJO, or most likely attempt to look for settEMPIN and if not
found, look for setTEMPIN.
I hope this gets in 1.3, because I believe this is critical.
> WSDL generation error - lowercasing 1st char in element names
> -
>
> Key: AXIS2-3017
> URL: https://issues.apache.org/jira/browse/AXIS2-3017
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: wsdl
>Reporter: nadir amra
> Attachments: ConvertTemp.zip
>
>
> Here is the problem. I deploy a POJO and when AXIS2 (using nightly build
> 2007/07/25) automatically generated WSDL via ?wsdl it produces a WSDL file
> the includes the following:
>
>
> type="xs:string"/>
> type="xs:string"/>
>
>
>
>
> type="xs:string"/>
> type="xs:string"/>
>
>
> The problem is with the element names. It seems that AXIS2 is lowercasing
> the "t" in TEMPIN and TEMPOUT, which makes the service unusable. The
> CONVERTTEMPInput class is as follows:
> public class CONVERTTEMPInput implements Serializable
> {
> private static final long serialVersionUID = -884605419035002637L;
> public CONVERTTEMPInput() { }
> public void setTEMPIN( String TEMPIN )
> {
> _TEMPIN = TEMPIN;
> }
> public String getTEMPIN( )
> {
>return _TEMPIN;
> }
> public void setTEMPOUT( String TEMPOUT )
> {
> _TEMPOUT = TEMPOUT;
> }
> public String getTEMPOUT( )
> {
>return _TEMPOUT;
> }
>private String _TEMPIN = "";
>private String _TEMPOUT = "";
> }
> If I add an underscore prior to TEMPIN and TEMPOUT in the method names,
> things start to work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-3017) WSDL generation error - lowercasing 1st char in element names
[
https://issues.apache.org/jira/browse/AXIS2-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nadir amra updated AXIS2-3017:
--
Component/s: wsdl
> WSDL generation error - lowercasing 1st char in element names
> -
>
> Key: AXIS2-3017
> URL: https://issues.apache.org/jira/browse/AXIS2-3017
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: wsdl
>Reporter: nadir amra
>
> Here is the problem. I deploy a POJO and when AXIS2 (using nightly build
> 2007/07/25) automatically generated WSDL via ?wsdl it produces a WSDL file
> the includes the following:
>
>
> type="xs:string"/>
> type="xs:string"/>
>
>
>
>
> type="xs:string"/>
> type="xs:string"/>
>
>
> The problem is with the element names. It seems that AXIS2 is lowercasing
> the "t" in TEMPIN and TEMPOUT, which makes the service unusable. The
> CONVERTTEMPInput class is as follows:
> public class CONVERTTEMPInput implements Serializable
> {
> private static final long serialVersionUID = -884605419035002637L;
> public CONVERTTEMPInput() { }
> public void setTEMPIN( String TEMPIN )
> {
> _TEMPIN = TEMPIN;
> }
> public String getTEMPIN( )
> {
>return _TEMPIN;
> }
> public void setTEMPOUT( String TEMPOUT )
> {
> _TEMPOUT = TEMPOUT;
> }
> public String getTEMPOUT( )
> {
>return _TEMPOUT;
> }
>private String _TEMPIN = "";
>private String _TEMPOUT = "";
> }
> If I add an underscore prior to TEMPIN and TEMPOUT in the method names,
> things start to work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-3017) WSDL generation error - lowercasing 1st char in element names
WSDL generation error - lowercasing 1st char in element names
-
Key: AXIS2-3017
URL: https://issues.apache.org/jira/browse/AXIS2-3017
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Reporter: nadir amra
Here is the problem. I deploy a POJO and when AXIS2 (using nightly build
2007/07/25) automatically generated WSDL via ?wsdl it produces a WSDL file
the includes the following:
The problem is with the element names. It seems that AXIS2 is lowercasing the
"t" in TEMPIN and TEMPOUT, which makes the service unusable. The
CONVERTTEMPInput class is as follows:
public class CONVERTTEMPInput implements Serializable
{
private static final long serialVersionUID = -884605419035002637L;
public CONVERTTEMPInput() { }
public void setTEMPIN( String TEMPIN )
{
_TEMPIN = TEMPIN;
}
public String getTEMPIN( )
{
return _TEMPIN;
}
public void setTEMPOUT( String TEMPOUT )
{
_TEMPOUT = TEMPOUT;
}
public String getTEMPOUT( )
{
return _TEMPOUT;
}
private String _TEMPIN = "";
private String _TEMPOUT = "";
}
If I add an underscore prior to TEMPIN and TEMPOUT in the method names, things
start to work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-3002) Axis 1.3RC2 does not work properly on websphere
[ https://issues.apache.org/jira/browse/AXIS2-3002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515330 ] nadir amra commented on AXIS2-3002: --- Dustin, I too am seeing this problem in RC2even when one specified useOriginalwsdl to be set in the services.xml as has been previously stated. Not sure what the class loader has to do with this particular problem. > Axis 1.3RC2 does not work properly on websphere > --- > > Key: AXIS2-3002 > URL: https://issues.apache.org/jira/browse/AXIS2-3002 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: kernel >Affects Versions: 1.3 > Environment: Websphere 6.0.2 >Reporter: Kent Watanabe >Assignee: Charitha Kankanamge > Attachments: Websphere-axis2.JPG > > > The new axis2.war does not work properly on websphere. There are problems > with the wsdl2 generation, and the wsdl 1.1 genaration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-1916) jars, mars and aars are locked in the file system even after undeployment of the axis2 webapp
[ https://issues.apache.org/jira/browse/AXIS2-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nadir amra updated AXIS2-1916: -- Comment: was deleted > jars, mars and aars are locked in the file system even after undeployment of > the axis2 webapp > - > > Key: AXIS2-1916 > URL: https://issues.apache.org/jira/browse/AXIS2-1916 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: deployment >Affects Versions: 1.1 > Environment: WinXP, Tomcat 4.1, Tomcat 5.5, WebSphere 6.0 >Reporter: Dejan Milosevic >Assignee: Deepal Jayasinghe > > Webapp containing axis2 servlet cannot be succesfuly undeployed because some > of the files (jar, mar, aar) are locked and cannot be deleted until the > servlet container is stopped. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-1916) jars, mars and aars are locked in the file system even after undeployment of the axis2 webapp
[ https://issues.apache.org/jira/browse/AXIS2-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508244 ] nadir amra commented on AXIS2-1916: --- Deepal, do you know what revision this was done under? And whether putting the fix in 1.1 code-base would be too much work? > jars, mars and aars are locked in the file system even after undeployment of > the axis2 webapp > - > > Key: AXIS2-1916 > URL: https://issues.apache.org/jira/browse/AXIS2-1916 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: deployment >Affects Versions: 1.1 > Environment: WinXP, Tomcat 4.1, Tomcat 5.5, WebSphere 6.0 >Reporter: Dejan Milosevic >Assignee: Deepal Jayasinghe > > Webapp containing axis2 servlet cannot be succesfuly undeployed because some > of the files (jar, mar, aar) are locked and cannot be deleted until the > servlet container is stopped. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-2504) Have indication of active/inactive service in services.xml
[ https://issues.apache.org/jira/browse/AXIS2-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490670 ] nadir amra commented on AXIS2-2504: --- I also want to update the services.xsd file so that this entry is added: However, I am unsure where to update the file. I have updated it in the 1.2 branch: xdocs/@axis2_version_dir@/resources/schemas/services.xsd But I am unsure if I need to update something in the trunk. Please let me know if I do and which directory. > Have indication of active/inactive service in services.xml > -- > > Key: AXIS2-2504 > URL: https://issues.apache.org/jira/browse/AXIS2-2504 > Project: Axis 2.0 (Axis2) > Issue Type: Improvement > Components: deployment >Affects Versions: 1.1.1 >Reporter: nadir amra > Assigned To: nadir amra > Fix For: 1.2, nightly > > > The idea is to add an "activate" attribute in services.xml to the "service" > element that indicates whether the service should be activated or not - i.e. > a persistent property that will allow the AXIS2 engine to determine whether > the service should be activated on startup. In addition, if management APIs > come to fruition that updates the services.xml file so that the state is > changed from active to inactive and vice-versa, the AXIS2 engine can pick > this up and activate/deactivate the service. Again, in a persistent way. > The code needed to do this affects two Java files: > DeploymentConstants.java -- simply to add attribute name "activate" and > possible values for "true" and "false" > ServiceBuilder.java -- a few lines to get the attribute and set the active > flag via AxisService::setActive() for the service depending on the "state" > attribute. > An example of what the service element would look like: > targetNamespace="http://quickstart.samples/";> > Before I make the changes and test it out, wondering if there are anything I > am overlooking? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-2504) Have indication of active/inactive service in services.xml
[ https://issues.apache.org/jira/browse/AXIS2-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nadir amra resolved AXIS2-2504. --- Resolution: Fixed Fix Version/s: nightly 1.2 Marking this as resolved. I also copied the changes into 1.2 release. I think it is critical that there is a persistent way to ensure a deployed service is not activated during startup if it is so desired. > Have indication of active/inactive service in services.xml > -- > > Key: AXIS2-2504 > URL: https://issues.apache.org/jira/browse/AXIS2-2504 > Project: Axis 2.0 (Axis2) > Issue Type: Improvement > Components: deployment >Affects Versions: 1.1.1 >Reporter: nadir amra > Assigned To: nadir amra > Fix For: 1.2, nightly > > > The idea is to add an "activate" attribute in services.xml to the "service" > element that indicates whether the service should be activated or not - i.e. > a persistent property that will allow the AXIS2 engine to determine whether > the service should be activated on startup. In addition, if management APIs > come to fruition that updates the services.xml file so that the state is > changed from active to inactive and vice-versa, the AXIS2 engine can pick > this up and activate/deactivate the service. Again, in a persistent way. > The code needed to do this affects two Java files: > DeploymentConstants.java -- simply to add attribute name "activate" and > possible values for "true" and "false" > ServiceBuilder.java -- a few lines to get the attribute and set the active > flag via AxisService::setActive() for the service depending on the "state" > attribute. > An example of what the service element would look like: > targetNamespace="http://quickstart.samples/";> > Before I make the changes and test it out, wondering if there are anything I > am overlooking? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-2567) Service activation with hotupdate not correct
[ https://issues.apache.org/jira/browse/AXIS2-2567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nadir amra updated AXIS2-2567: -- Summary: Service activation with hotupdate not correct (was: Exploded POJO service always activated even if deactivated from ADMIN console) > Service activation with hotupdate not correct > - > > Key: AXIS2-2567 > URL: https://issues.apache.org/jira/browse/AXIS2-2567 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: deployment >Affects Versions: nightly >Reporter: nadir amra > > Running with latest build. hotupdate set to "true" in axis2.xml. An > exploded POJO service is deployed and AXIS2 engine activates the service. > From the ADMIN console, deactivate the service. If you click on the > "Available Services" link you will find the service still active. > For aar files, this seems to work fine. However, if the aar file is updated, > the state goes to active. I would think in this case it should still be > inactive. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-2567) Exploded POJO service always activated even if deactivated from ADMIN console
[ https://issues.apache.org/jira/browse/AXIS2-2567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nadir amra updated AXIS2-2567: -- Description: Running with latest build. hotupdate set to "true" in axis2.xml. An exploded POJO service is deployed and AXIS2 engine activates the service. From the ADMIN console, deactivate the service. If you click on the "Available Services" link you will find the service still active. For aar files, this seems to work fine. However, if the aar file is updated, the state goes to active. I would think in this case it should still be inactive. was:Running with latest build. hotupdate set to "true" in axis2.xml. An exploded POJO service is deployed and AXIS2 engine activates the service. From the ADMIN console, deactivate the service. If you click on the "Available Services" link you will find the service still active. > Exploded POJO service always activated even if deactivated from ADMIN console > - > > Key: AXIS2-2567 > URL: https://issues.apache.org/jira/browse/AXIS2-2567 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: deployment >Affects Versions: nightly >Reporter: nadir amra > > Running with latest build. hotupdate set to "true" in axis2.xml. An > exploded POJO service is deployed and AXIS2 engine activates the service. > From the ADMIN console, deactivate the service. If you click on the > "Available Services" link you will find the service still active. > For aar files, this seems to work fine. However, if the aar file is updated, > the state goes to active. I would think in this case it should still be > inactive. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-2567) Exploded POJO service always activated even if deactivated from ADMIN console
Exploded POJO service always activated even if deactivated from ADMIN console - Key: AXIS2-2567 URL: https://issues.apache.org/jira/browse/AXIS2-2567 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: deployment Affects Versions: nightly Reporter: nadir amra Running with latest build. hotupdate set to "true" in axis2.xml. An exploded POJO service is deployed and AXIS2 engine activates the service. From the ADMIN console, deactivate the service. If you click on the "Available Services" link you will find the service still active. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-2504) Have indication of active/inactive service in services.xml
[ https://issues.apache.org/jira/browse/AXIS2-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489296 ] nadir amra commented on AXIS2-2504: --- I added code in ServiceBuilder::populateService() to check for the attribute and set the active flag via AxisService::setActive(). Things look good. If the activate attribute is "false", the service is not activated on AXIS2 startup. However, when I try to active the service from the AXIS2 admin page, the service goes to activate and then back to deactivate state. From what I can tell, this has to do with the fact that the periodic loading of the service results in the service being deactivated because of the activate="false" attribute that is in the service.xml. So I am wondering how I can rectify this? Even without my changes, I am wondering how does AXIS2 know when a service is active/inactive? A pointer where I can look would be helpful. > Have indication of active/inactive service in services.xml > -- > > Key: AXIS2-2504 > URL: https://issues.apache.org/jira/browse/AXIS2-2504 > Project: Axis 2.0 (Axis2) > Issue Type: Improvement > Components: deployment >Affects Versions: 1.1.1 >Reporter: nadir amra > Assigned To: nadir amra > > The idea is to add an "activate" attribute in services.xml to the "service" > element that indicates whether the service should be activated or not - i.e. > a persistent property that will allow the AXIS2 engine to determine whether > the service should be activated on startup. In addition, if management APIs > come to fruition that updates the services.xml file so that the state is > changed from active to inactive and vice-versa, the AXIS2 engine can pick > this up and activate/deactivate the service. Again, in a persistent way. > The code needed to do this affects two Java files: > DeploymentConstants.java -- simply to add attribute name "activate" and > possible values for "true" and "false" > ServiceBuilder.java -- a few lines to get the attribute and set the active > flag via AxisService::setActive() for the service depending on the "state" > attribute. > An example of what the service element would look like: > targetNamespace="http://quickstart.samples/";> > Before I make the changes and test it out, wondering if there are anything I > am overlooking? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-2504) Have indication of active/inactive service in services.xml
[ https://issues.apache.org/jira/browse/AXIS2-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487989 ] nadir amra commented on AXIS2-2504: --- Forgot to add that if the attribute is missing, the default would be to activate the service. > Have indication of active/inactive service in services.xml > -- > > Key: AXIS2-2504 > URL: https://issues.apache.org/jira/browse/AXIS2-2504 > Project: Axis 2.0 (Axis2) > Issue Type: Improvement > Components: deployment >Affects Versions: 1.1.1 >Reporter: nadir amra > Assigned To: nadir amra > > The idea is to add an "activate" attribute in services.xml to the "service" > element that indicates whether the service should be activated or not - i.e. > a persistent property that will allow the AXIS2 engine to determine whether > the service should be activated on startup. In addition, if management APIs > come to fruition that updates the services.xml file so that the state is > changed from active to inactive and vice-versa, the AXIS2 engine can pick > this up and activate/deactivate the service. Again, in a persistent way. > The code needed to do this affects two Java files: > DeploymentConstants.java -- simply to add attribute name "activate" and > possible values for "true" and "false" > ServiceBuilder.java -- a few lines to get the attribute and set the active > flag via AxisService::setActive() for the service depending on the "state" > attribute. > An example of what the service element would look like: > targetNamespace="http://quickstart.samples/";> > Before I make the changes and test it out, wondering if there are anything I > am overlooking? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-2504) Have indication of active/inactive service in services.xml
Have indication of active/inactive service in services.xml -- Key: AXIS2-2504 URL: https://issues.apache.org/jira/browse/AXIS2-2504 Project: Axis 2.0 (Axis2) Issue Type: Improvement Components: deployment Affects Versions: 1.1.1 Reporter: nadir amra Assigned To: nadir amra The idea is to add an "activate" attribute in services.xml to the "service" element that indicates whether the service should be activated or not - i.e. a persistent property that will allow the AXIS2 engine to determine whether the service should be activated on startup. In addition, if management APIs come to fruition that updates the services.xml file so that the state is changed from active to inactive and vice-versa, the AXIS2 engine can pick this up and activate/deactivate the service. Again, in a persistent way. The code needed to do this affects two Java files: DeploymentConstants.java -- simply to add attribute name "activate" and possible values for "true" and "false" ServiceBuilder.java -- a few lines to get the attribute and set the active flag via AxisService::setActive() for the service depending on the "state" attribute. An example of what the service element would look like: http://quickstart.samples/";> Before I make the changes and test it out, wondering if there are anything I am overlooking? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
