[GitHub] [ws-wss4j] coheigea merged pull request #67: Fix Build Status Icon in README.md
coheigea merged PR #67: URL: https://github.com/apache/ws-wss4j/pull/67 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[GitHub] [ws-wss4j] free2create opened a new pull request, #67: Fix Build Status Icon in README.md
free2create opened a new pull request, #67: URL: https://github.com/apache/ws-wss4j/pull/67 This fixes URL so build badge for master JDK11 is shown correctly. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
Fwd: Delivery Status Notification (Failure)
+1 (non-binding) to drop Java 5 (even drop 6 if you like). Gary On Thu, Sep 11, 2014 at 8:16 AM, Alexandr Klimov my-...@yandex.ru wrote: +1 09.09.2014, 12:04, Colm O hEigeartaigh cohei...@apache.org: +1 makes sense. Colm. On Mon, Sep 8, 2014 at 9:22 PM, Daniel Kulp dk...@apache.org wrote: We got a nice contribution from the Avro folks to add to XmlSchema. It's a whole new module with new functionality so not really something for a patch release. I'd like to go ahead and get it committed and prepare a 2.2.0 release. As part of this, I'd like to drop support for Java 5 for 2.2.0 on. The new module requires JAXB to be available which is much simpler with Java6 (built into the JDK). Otherwise, we have to add some profiles and conditional dependencies and such to the poms which kind of sucks. We can easily release a 2.1.1 if we need a specific fix for the 2.1.x series that would still run on Java 5. However, I'm not really sure that is necessary as the downstream projects that are actually needing this and are actually making releases have moved forward with Java6+. Thoughts? -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com //Best regards //Alexandr - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition - Message truncated - -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [XmlSchema 2.0] Project Status?
Hi, I'm happy to take on an active role in the project if no one else is - I'm currently trying to automatically generate an XML parser based on the XBRL schema http://www.xbrl.org/2003/xbrl-linkbase-2003-12-31.xsd. I've tried XMLBeans and I've tried JAXP, but so far only XmlSchema has been able to process all 11 schemas associated with reading an XBRL document. I'm currently trying to figure out how to automatically generate code to save the data in another format, like Avro. There are things I wished XmlSchema did better, like tell me which attributes and children are valid for a particular element (which includes processing substitution groups and complex content extensions restrictions). I'm happy to work on these items, as well as any bugs that others have filed, but I'm having a hard time of getting a hold of someone. Thanks, Mike On Wed, Jul 9, 2014 at 11:08 AM, Michael Pigott mpigott.subscripti...@gmail.com wrote: Hello Apache Web Services Developers, Last week I filed and provided a fix for https://issues.apache.org/jira/browse/XMLSCHEMA-33 (uploading the diff.zip yesterday). However, I haven't seen much traction on the JIRA ticket, and I am not sure who to reach out to. No lead developer is assigned to the JIRA project, and the project team list ( https://ws.apache.org/xmlschema/team-list.html ) is currently empty. I also, I tried signing into the #apache-ws IRC room yesterday (per https://ws.apache.org/irc.html ) and no one was there. Is it possible to contribute to the Apache XML Schema project? Thanks, Mike
[XmlSchema 2.0] Project Status?
Hello Apache Web Services Developers, Last week I filed and provided a fix for https://issues.apache.org/jira/browse/XMLSCHEMA-33 (uploading the diff.zip yesterday). However, I haven't seen much traction on the JIRA ticket, and I am not sure who to reach out to. No lead developer is assigned to the JIRA project, and the project team list ( https://ws.apache.org/xmlschema/team-list.html ) is currently empty. I also, I tried signing into the #apache-ws IRC room yesterday (per https://ws.apache.org/irc.html ) and no one was there. Is it possible to contribute to the Apache XML Schema project? Thanks, Mike
[jira] [Closed] (WSS-341) the FIRST step check in SignatureTrustValidator.verifyTrustInCert ignore the enableRevocation status
[
https://issues.apache.org/jira/browse/WSS-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed WSS-341.
---
the FIRST step check in SignatureTrustValidator.verifyTrustInCert ignore
the enableRevocation status
--
Key: WSS-341
URL: https://issues.apache.org/jira/browse/WSS-341
Project: WSS4J
Issue Type: Bug
Affects Versions: 1.6.4
Reporter: Freeman Fang
Assignee: Colm O hEigeartaigh
Fix For: 1.6.5
Attachments: WSS-341.patch
currently it's
if (isCertificateInKeyStore(crypto, cert)) {
return true;
}
However if the crypto here has keystore, then if cert is in it, it will
return true in this case, so it can't reach the
crypto.verifyTrust(x509certs, enableRevocation) later to check with the
revocation. This logic is wrong in case the cert is in keystore but already
get revoked.
The SignatureCRLTest can't cover this case because the CA Merlin crypto it
passed in only have truststore, we need check enableRevocation first before
we check isCertificateInKeyStore(crypto, cert)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Updated] (WSS-341) the FIRST step check in SignatureTrustValidator.verifyTrustInCert ignore the enableRevocation status
[
https://issues.apache.org/jira/browse/WSS-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh updated WSS-341:
Affects Version/s: 1.6.4
Fix Version/s: 1.6.5
the FIRST step check in SignatureTrustValidator.verifyTrustInCert ignore
the enableRevocation status
--
Key: WSS-341
URL: https://issues.apache.org/jira/browse/WSS-341
Project: WSS4J
Issue Type: Bug
Affects Versions: 1.6.4
Reporter: Freeman Fang
Assignee: Colm O hEigeartaigh
Fix For: 1.6.5
Attachments: WSS-341.patch
currently it's
if (isCertificateInKeyStore(crypto, cert)) {
return true;
}
However if the crypto here has keystore, then if cert is in it, it will
return true in this case, so it can't reach the
crypto.verifyTrust(x509certs, enableRevocation) later to check with the
revocation. This logic is wrong in case the cert is in keystore but already
get revoked.
The SignatureCRLTest can't cover this case because the CA Merlin crypto it
passed in only have truststore, we need check enableRevocation first before
we check isCertificateInKeyStore(crypto, cert)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Updated] (WSS-341) the FIRST step check in SignatureTrustValidator.verifyTrustInCert ignore the enableRevocation status
[
https://issues.apache.org/jira/browse/WSS-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang updated WSS-341:
-
Description:
currently it's
if (isCertificateInKeyStore(crypto, cert)) {
return true;
}
However if the crypto here has keystore, then if cert is in it, it will return
true in this case, so it can't reach the
crypto.verifyTrust(x509certs, enableRevocation) later to check with the
revocation. This logic is wrong in case the cert is in keystore but already get
revoked.
The SignatureCRLTest can't cover this case because the CA Merlin crypto it
passed in only have truststore, we need check enableRevocation first before we
check isCertificateInKeyStore(crypto, cert)
was:
currently it's
if (isCertificateInKeyStore(crypto, cert)) {
return true;
}
However if the crypto has keystore, then the cert must be in it, so it always
return true in this case, so it can't reach the
crypto.verifyTrust(x509certs, enableRevocation) to check with the revocation.
The SignatureCRLTest can't cover this case because the Merlin crypto it passed
in only have truststore, we need check enableRevocation first before we check
isCertificateInKeyStore(crypto, cert)
the FIRST step check in SignatureTrustValidator.verifyTrustInCert ignore
the enableRevocation status
--
Key: WSS-341
URL: https://issues.apache.org/jira/browse/WSS-341
Project: WSS4J
Issue Type: Bug
Reporter: Freeman Fang
Assignee: Colm O hEigeartaigh
currently it's
if (isCertificateInKeyStore(crypto, cert)) {
return true;
}
However if the crypto here has keystore, then if cert is in it, it will
return true in this case, so it can't reach the
crypto.verifyTrust(x509certs, enableRevocation) later to check with the
revocation. This logic is wrong in case the cert is in keystore but already
get revoked.
The SignatureCRLTest can't cover this case because the CA Merlin crypto it
passed in only have truststore, we need check enableRevocation first before
we check isCertificateInKeyStore(crypto, cert)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Updated] (WSS-341) the FIRST step check in SignatureTrustValidator.verifyTrustInCert ignore the enableRevocation status
[
https://issues.apache.org/jira/browse/WSS-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang updated WSS-341:
-
Attachment: WSS-341.patch
the FIRST step check in SignatureTrustValidator.verifyTrustInCert ignore
the enableRevocation status
--
Key: WSS-341
URL: https://issues.apache.org/jira/browse/WSS-341
Project: WSS4J
Issue Type: Bug
Reporter: Freeman Fang
Assignee: Colm O hEigeartaigh
Attachments: WSS-341.patch
currently it's
if (isCertificateInKeyStore(crypto, cert)) {
return true;
}
However if the crypto here has keystore, then if cert is in it, it will
return true in this case, so it can't reach the
crypto.verifyTrust(x509certs, enableRevocation) later to check with the
revocation. This logic is wrong in case the cert is in keystore but already
get revoked.
The SignatureCRLTest can't cover this case because the CA Merlin crypto it
passed in only have truststore, we need check enableRevocation first before
we check isCertificateInKeyStore(crypto, cert)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org
Status
I had some questions on using XML schema, but it seems that the project is dormant. I was wondering how to leverage XML Schema and a catalog file to tie together Springs auto WSDL generation and referencing imports with the XJC catalog mechanism. Thanks, Gregory Bonk Abercrombie Fitch gregory_b...@abercrombie.com 614.283.7887 d 614.302.9252 c 614.571.4734 c
Status of 1.6 branch.....
Colm, I asw just wondering what that status of the 1.6 branch is? Aka: how close to releasable is it? We're getting pretty close to CXF 2.3 and am trying to figure out if moving up to 1.6 will be a possibility or if we need to stay on 1.5.x. Let me know if there is anything that I can do to help get 1.6 ready. Thanks! -- Daniel Kulp dk...@apache.org http://dankulp.com/blog - To unsubscribe, e-mail: wss4j-dev-unsubscr...@ws.apache.org For additional commands, e-mail: wss4j-dev-h...@ws.apache.org
[jira] Resolved: (WSCOMMONS-417) Clarify the status of the JavaMail dependency
[ https://issues.apache.org/jira/browse/WSCOMMONS-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen resolved WSCOMMONS-417. --- Resolution: Fixed Axiom (including the tests) now works correctly with the Geronimo JARs. Therefore I'm going to close this issue. Note that Axis2 still overrides the dependency to use Sun's implementations. Clarify the status of the JavaMail dependency - Key: WSCOMMONS-417 URL: https://issues.apache.org/jira/browse/WSCOMMONS-417 Project: WS-Commons Issue Type: Improvement Components: AXIOM Reporter: Andreas Veithen Priority: Minor Fix For: Axiom 1.2.9 axiom-api depends on Geronimo's JavaMail implementation. On the other hand, in axiom-tests this dependency is excluded and replaced by Sun's JavaMail dependency (same situation in Axis2). If Axiom doesn't work properly with Geronimo's JavaMail implementation, we should either make sure that the bugs in Geronimo get fixed or change the dependencies of axiom-api. If Axiom works properly with Geronimo's JavaMail implementation, then it doesn't make sense to run the tests against a different JavaMail implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2C-1282) 1)reads all http headers from the request and adds them to the msg_ctx, they were missing. 2)Allows custumized http status and http headers for rest requests(don't affec
[
https://issues.apache.org/jira/browse/AXIS2C-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nandika Jayawardana resolved AXIS2C-1282.
-
Resolution: Fixed
patch applied
1)reads all http headers from the request and adds them to the msg_ctx, they
were missing. 2)Allows custumized http status and http headers for rest
requests(don't affect soap requests). 3) Adds missing http forbidden
definitions
-
Key: AXIS2C-1282
URL: https://issues.apache.org/jira/browse/AXIS2C-1282
Project: Axis2-C
Issue Type: Improvement
Components: httpd module
Affects Versions: 1.5.0
Reporter: Luis Bilo
Assignee: Nandika Jayawardana
Priority: Minor
Fix For: 1.7.0
Attachments: apache_http_headers_and_rest_enhancement.diff,
http_forbidden.diff
Original Estimate: 1h
Remaining Estimate: 1h
#1 Adds http headers to msg_ctx when using axis2/c module for apache
I noticed however this functionality were only implemented for the
standalone server. When using the axis module for apache http headers
were not added to the msg_ctx so they were not accessible @ the inflow
handlers level for instance.
#2 Adds forbidden definition tags for http forbidden code which is
missing in standard release
#define AXIS2_HTTP_RESPONSE_FORBIDDEN_CODE_VAL 403
#define AXIS2_HTTP_RESPONSE_HTTP_FORBIDDEN_CODE_NAME Forbidden
#define AXIS2_HTTP_RESPONSE_HTTP_FORBIDDEN 403 Forbidden
#3 Adds support to specify feedback for REST requests, when a module
failure occurs.
This issue is related to the difference between soap and rest
requests. When an inflow handler fails two things can happen depending
on the request type:
- For SOAP requests, the inflow handler chain is broken, and all the
outflow fault handlers are invoked. The response soap envelope
response containing a default fault is built by axis in between these
phases, so we can edit the fault accordingly @ the outflow fault
handlers.
- For REST requests, the inflow handler chain is also broken, but the
outflow fault handlers are not invoked. This is not a problem, and is
probably intended, since unlike soap there is no need to create a soap
envelope. The thing is when this happens it always returned 202
ACCEPTED, which is not enough to provide any feedback to the user who
made the request.
@ the inflow handler is now possible to set the desired status code
desired for the response, extra http headers, and/or http content. It
was already possible before, changes just weren't propagated to the
actual response.
inflow handler example with the patch:
..
// For REST requests
if (doing_rest AXIS2_FAILURE == result)
{
axis2_msg_ctx_set_status_code(msg_ctx, env,
AXIS2_HTTP_RESPONSE_HTTP_UNAUTHORIZED_CODE_VAL);
AXIS2_LOG_ERROR(env-log, AXIS2_LOG_SI,
[Inflow][authentication_in]
HTTP status code unauthorized);
axutil_stream_t *stream = axutil_stream_create_basic(env);
axis2_char_t *http_content = axutil_strcat(env,
AXIS2_HTTP_RESPONSE_HTTP_UNAUTHORIZED, \n, NULL);
axutil_stream_write(stream, env, http_content,
axutil_strlen(http_content));
axis2_msg_ctx_set_transport_out_stream(msg_ctx, env, stream);
}
return result;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Transports 1.0.0 release status
Folks, Tag has been created, and the artifacts are uploaded to the maven2 repository. I am having a bit of trouble on adding my public key into the KEYS file at [1], It says Permission denied :-( Any help will be much appreciated. [1] - http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/axis2/KEYS Thanks, Ruwan -- Ruwan Linton Technical Lead Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com
Transports 1.0.0 release status
Folks, Tag has been created, and the artifacts are uploaded to the maven2 repository. I am having a bit of trouble on adding my public key into the KEYS file at [1], It says Permission denied :-( Any help will be much appreciated. [1] - http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/axis2/KEYS Thanks, Ruwan -- Ruwan Linton Technical Lead Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com
[jira] Updated: (AXIS2C-1402) AXIS2_PARAM_CHECK overwrite previously set error status
[
https://issues.apache.org/jira/browse/AXIS2C-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
S.Uthaiyashankar updated AXIS2C-1402:
-
Component/s: core/engine
AXIS2_PARAM_CHECK overwrite previously set error status
---
Key: AXIS2C-1402
URL: https://issues.apache.org/jira/browse/AXIS2C-1402
Project: Axis2-C
Issue Type: Bug
Components: core/engine
Affects Versions: 1.6.0
Reporter: S.Uthaiyashankar
Assignee: S.Uthaiyashankar
Fix For: Next Version
Attachments: axis2_param_check.patch
When checking AXIS2_PARAM_CHECK, if it is success, it overwrites STATUS_CODE
by setting AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_SUCCESS);
check the macro definition:
#define AXIS2_PARAM_CHECK(error, object, error_return) \
if (!object)\
{ \
AXIS2_ERROR_SET_ERROR_NUMBER(error, AXIS2_ERROR_INVALID_NULL_PARAM); \
AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_FAILURE); \
return error_return;\
} \
else\
{ \
AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_SUCCESS); \
}
Ideally, if PARAM_CHECK is success, it should not touch error status code.
This macro is a problem when sending soap faults from generated code. To send
faults from generated code, we have to set the error status inside service
logic and it will be checked by the engine to create soap fault. However,
after setting error status, there are several generated codes doing
AXIS2_PARAM_CHECK and hence overwriting the status code.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1409) The AXIS2_PARAM_CHECK macro reset the env status when the param is OK
[ https://issues.apache.org/jira/browse/AXIS2C-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar updated AXIS2C-1409: - Component/s: core/engine The AXIS2_PARAM_CHECK macro reset the env status when the param is OK - Key: AXIS2C-1409 URL: https://issues.apache.org/jira/browse/AXIS2C-1409 Project: Axis2-C Issue Type: Bug Components: core/engine Reporter: Francois Mireaux In AXIS2_PARAM_CHECK macro, reseting the env status to OK when the tested parameter is OK seems not a good thing. Some days ago, the macro was modified to not reset the env status which leads me to track down some errors (see JIRA AXIS2C-1407 and AXIS2C-1408). This day (10/21/2009) the macro resets again the env status but this could conceal real errors. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2C-1409) The AXIS2_PARAM_CHECK macro reset the env status when the param is OK
[ https://issues.apache.org/jira/browse/AXIS2C-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar resolved AXIS2C-1409. -- Resolution: Duplicate Same issue as AXIS2C-1402 The AXIS2_PARAM_CHECK macro reset the env status when the param is OK - Key: AXIS2C-1409 URL: https://issues.apache.org/jira/browse/AXIS2C-1409 Project: Axis2-C Issue Type: Bug Components: core/engine Reporter: Francois Mireaux Assignee: S.Uthaiyashankar In AXIS2_PARAM_CHECK macro, reseting the env status to OK when the tested parameter is OK seems not a good thing. Some days ago, the macro was modified to not reset the env status which leads me to track down some errors (see JIRA AXIS2C-1407 and AXIS2C-1408). This day (10/21/2009) the macro resets again the env status but this could conceal real errors. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (AXIS2C-1409) The AXIS2_PARAM_CHECK macro reset the env status when the param is OK
[ https://issues.apache.org/jira/browse/AXIS2C-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S.Uthaiyashankar reassigned AXIS2C-1409: Assignee: S.Uthaiyashankar The AXIS2_PARAM_CHECK macro reset the env status when the param is OK - Key: AXIS2C-1409 URL: https://issues.apache.org/jira/browse/AXIS2C-1409 Project: Axis2-C Issue Type: Bug Components: core/engine Reporter: Francois Mireaux Assignee: S.Uthaiyashankar In AXIS2_PARAM_CHECK macro, reseting the env status to OK when the tested parameter is OK seems not a good thing. Some days ago, the macro was modified to not reset the env status which leads me to track down some errors (see JIRA AXIS2C-1407 and AXIS2C-1408). This day (10/21/2009) the macro resets again the env status but this could conceal real errors. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AXIS2C-1402) AXIS2_PARAM_CHECK overwrite previously set error status
[
https://issues.apache.org/jira/browse/AXIS2C-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12769231#action_12769231
]
Francois Mireaux commented on AXIS2C-1402:
--
Wanting to make some more testing, I look in Axis2c tests but :
- there are not many tests
- they are not automated like with JUnit in Java
- often, test says SUCCESS with env status to FAILURE
-
So It's seems we need a test framework which allows us to write more tests more
easily.
Which framework choose ? CUnit, Check , WSF_unit ... ? Does somebody has an
idea ?
AXIS2_PARAM_CHECK overwrite previously set error status
---
Key: AXIS2C-1402
URL: https://issues.apache.org/jira/browse/AXIS2C-1402
Project: Axis2-C
Issue Type: Bug
Affects Versions: 1.6.0
Reporter: S.Uthaiyashankar
Assignee: S.Uthaiyashankar
Fix For: Next Version
Attachments: axis2_param_check.patch
When checking AXIS2_PARAM_CHECK, if it is success, it overwrites STATUS_CODE
by setting AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_SUCCESS);
check the macro definition:
#define AXIS2_PARAM_CHECK(error, object, error_return) \
if (!object)\
{ \
AXIS2_ERROR_SET_ERROR_NUMBER(error, AXIS2_ERROR_INVALID_NULL_PARAM); \
AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_FAILURE); \
return error_return;\
} \
else\
{ \
AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_SUCCESS); \
}
Ideally, if PARAM_CHECK is success, it should not touch error status code.
This macro is a problem when sending soap faults from generated code. To send
faults from generated code, we have to set the error status inside service
logic and it will be checked by the engine to create soap fault. However,
after setting error status, there are several generated codes doing
AXIS2_PARAM_CHECK and hence overwriting the status code.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1402) AXIS2_PARAM_CHECK overwrite previously set error status
[
https://issues.apache.org/jira/browse/AXIS2C-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francois Mireaux updated AXIS2C-1402:
-
Attachment: axis2_param_check.patch
Content :
1 initialize env status to AXIS_SUCCESS
2 don't reset env status in AXIS2_PARAM_CHECK
3 exit from do loop when root_node is closed in om_stax_builder_next
4 don't set env status to failure when module parent is undefined in
axis2_module_desc_is_param_locked
5 force env status to AXIS2_SUCCESS at axis2_engine_send end (returned
status is AXIS2_SUCCESS)
All Axis2c samples which works without patch works with patch (google and
mtom_callback don't work out off the box) but it's more likely that there are
others problematic use cases.
Patch solve errors I have found in WSF-PHP context (only poor tests righrt now).
Which functionnality is known as broken by the AXIS2_PARAM_CHECK modification ?
AXIS2_PARAM_CHECK overwrite previously set error status
---
Key: AXIS2C-1402
URL: https://issues.apache.org/jira/browse/AXIS2C-1402
Project: Axis2-C
Issue Type: Bug
Affects Versions: 1.6.0
Reporter: S.Uthaiyashankar
Assignee: S.Uthaiyashankar
Fix For: Next Version
Attachments: axis2_param_check.patch
When checking AXIS2_PARAM_CHECK, if it is success, it overwrites STATUS_CODE
by setting AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_SUCCESS);
check the macro definition:
#define AXIS2_PARAM_CHECK(error, object, error_return) \
if (!object)\
{ \
AXIS2_ERROR_SET_ERROR_NUMBER(error, AXIS2_ERROR_INVALID_NULL_PARAM); \
AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_FAILURE); \
return error_return;\
} \
else\
{ \
AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_SUCCESS); \
}
Ideally, if PARAM_CHECK is success, it should not touch error status code.
This macro is a problem when sending soap faults from generated code. To send
faults from generated code, we have to set the error status inside service
logic and it will be checked by the engine to create soap fault. However,
after setting error status, there are several generated codes doing
AXIS2_PARAM_CHECK and hence overwriting the status code.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2C-1407) Loading an XML file always sets the env status to AXIS2FAILURE
Loading an XML file always sets the env status to AXIS2FAILURE -- Key: AXIS2C-1407 URL: https://issues.apache.org/jira/browse/AXIS2C-1407 Project: Axis2-C Issue Type: Bug Components: xml/om Reporter: Francois Mireaux In om_stax_builder.c, the loop condition in axiom_stax_builder_next is not correct, leading to exit of the function by the if om_builder-done which set the env status to AXIS2FAILURE. Instead of 'while(!node)', the condition should be 'while(!node !axiom_node_is_complete(om_builder-root_node, env))' to exit in error only in the root XML element is not closed. Problem is concealed notably because of the AXIS2_PARAM_CHECK macro which, usualy, resets the status to OK. But some days ago, the macro was temporaly modified to not reset the status (which seems the good way) and I track down the resulting error(s). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2C-1408) axis2_dep_engine_load_client exits with the env status to AXIS2FAILURE
axis2_dep_engine_load_client exits with the env status to AXIS2FAILURE --- Key: AXIS2C-1408 URL: https://issues.apache.org/jira/browse/AXIS2C-1408 Project: Axis2-C Issue Type: Bug Components: core/deployment Reporter: Francois Mireaux Function 'axis2_dep_engine_add_new_module' calls 'axis2_dep_engine_load_module_dll' which in turn calls 'axis2_module_desc_add_param'. This function calls 'axis2_module_desc_is_param_locked' which set the env status to AXIS2FAILURE if the module has no parent. But in that case the module parent is only set at the end of 'axis2_dep_engine_add_new_module' by the call of 'axis2_conf_add_module'. Is that clear ? Problem is usualy concealed by the AXIS2_PARAM_CHECK macro which reset the env status ! But some days ago the macro was temporaly modified to not reset the env status when param is OK (which seems the good way). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2C-1409) The AXIS2_PARAM_CHECK macro reset the env status when the param is OK
The AXIS2_PARAM_CHECK macro reset the env status when the param is OK - Key: AXIS2C-1409 URL: https://issues.apache.org/jira/browse/AXIS2C-1409 Project: Axis2-C Issue Type: Bug Reporter: Francois Mireaux In AXIS2_PARAM_CHECK macro, reseting the env status to OK when the tested parameter is OK seems not a good thing. Some days ago, the macro was modified to not reset the env status which leads me to track down some errors (see JIRA AXIS2C-1407 and AXIS2C-1408). This day (10/21/2009) the macro resets again the env status but this could conceal real errors. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AXIS2C-1409) The AXIS2_PARAM_CHECK macro reset the env status when the param is OK
[ https://issues.apache.org/jira/browse/AXIS2C-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12768224#action_12768224 ] Francois Mireaux commented on AXIS2C-1409: -- Sorry, I don't see the JIRA AXIS2C-1402. But is somebody works on the topic ? (I could carry on tracking problems with a correct AXIS2_PARAM_CHECK macro) The AXIS2_PARAM_CHECK macro reset the env status when the param is OK - Key: AXIS2C-1409 URL: https://issues.apache.org/jira/browse/AXIS2C-1409 Project: Axis2-C Issue Type: Bug Reporter: Francois Mireaux In AXIS2_PARAM_CHECK macro, reseting the env status to OK when the tested parameter is OK seems not a good thing. Some days ago, the macro was modified to not reset the env status which leads me to track down some errors (see JIRA AXIS2C-1407 and AXIS2C-1408). This day (10/21/2009) the macro resets again the env status but this could conceal real errors. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AXIS2C-1409) The AXIS2_PARAM_CHECK macro reset the env status when the param is OK
[ https://issues.apache.org/jira/browse/AXIS2C-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12768232#action_12768232 ] S.Uthaiyashankar commented on AXIS2C-1409: -- If you could track the problems, it will help us a lot. Please provide patch if you find the solutions to the problem. The AXIS2_PARAM_CHECK macro reset the env status when the param is OK - Key: AXIS2C-1409 URL: https://issues.apache.org/jira/browse/AXIS2C-1409 Project: Axis2-C Issue Type: Bug Reporter: Francois Mireaux In AXIS2_PARAM_CHECK macro, reseting the env status to OK when the tested parameter is OK seems not a good thing. Some days ago, the macro was modified to not reset the env status which leads me to track down some errors (see JIRA AXIS2C-1407 and AXIS2C-1408). This day (10/21/2009) the macro resets again the env status but this could conceal real errors. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AXIS2C-1409) The AXIS2_PARAM_CHECK macro reset the env status when the param is OK
[ https://issues.apache.org/jira/browse/AXIS2C-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12768231#action_12768231 ] S.Uthaiyashankar commented on AXIS2C-1409: -- Yes, I am working on this issue. Ideally, we should not set status if param is OK. However, when that is removed, there are some functionality broken. I'll fix them and then remove setting the status. The AXIS2_PARAM_CHECK macro reset the env status when the param is OK - Key: AXIS2C-1409 URL: https://issues.apache.org/jira/browse/AXIS2C-1409 Project: Axis2-C Issue Type: Bug Reporter: Francois Mireaux In AXIS2_PARAM_CHECK macro, reseting the env status to OK when the tested parameter is OK seems not a good thing. Some days ago, the macro was modified to not reset the env status which leads me to track down some errors (see JIRA AXIS2C-1407 and AXIS2C-1408). This day (10/21/2009) the macro resets again the env status but this could conceal real errors. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (AXIS2C-1402) AXIS2_PARAM_CHECK overwrite previously set error status
[
https://issues.apache.org/jira/browse/AXIS2C-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
S.Uthaiyashankar reopened AXIS2C-1402:
--
This fix break some of the functionality. Reverting the changes until all the
functionalities are fixed.
AXIS2_PARAM_CHECK overwrite previously set error status
---
Key: AXIS2C-1402
URL: https://issues.apache.org/jira/browse/AXIS2C-1402
Project: Axis2-C
Issue Type: Bug
Affects Versions: 1.6.0
Reporter: S.Uthaiyashankar
Assignee: S.Uthaiyashankar
Fix For: Next Version
When checking AXIS2_PARAM_CHECK, if it is success, it overwrites STATUS_CODE
by setting AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_SUCCESS);
check the macro definition:
#define AXIS2_PARAM_CHECK(error, object, error_return) \
if (!object)\
{ \
AXIS2_ERROR_SET_ERROR_NUMBER(error, AXIS2_ERROR_INVALID_NULL_PARAM); \
AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_FAILURE); \
return error_return;\
} \
else\
{ \
AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_SUCCESS); \
}
Ideally, if PARAM_CHECK is success, it should not touch error status code.
This macro is a problem when sending soap faults from generated code. To send
faults from generated code, we have to set the error status inside service
logic and it will be checked by the engine to create soap fault. However,
after setting error status, there are several generated codes doing
AXIS2_PARAM_CHECK and hence overwriting the status code.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2C-1402) AXIS2_PARAM_CHECK overwrite previously set error status
AXIS2_PARAM_CHECK overwrite previously set error status
---
Key: AXIS2C-1402
URL: https://issues.apache.org/jira/browse/AXIS2C-1402
Project: Axis2-C
Issue Type: Bug
Affects Versions: 1.6.0
Reporter: S.Uthaiyashankar
Assignee: S.Uthaiyashankar
Fix For: Next Version
When checking AXIS2_PARAM_CHECK, if it is success, it overwrites STATUS_CODE by
setting AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_SUCCESS);
check the macro definition:
#define AXIS2_PARAM_CHECK(error, object, error_return) \
if (!object)\
{ \
AXIS2_ERROR_SET_ERROR_NUMBER(error, AXIS2_ERROR_INVALID_NULL_PARAM); \
AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_FAILURE); \
return error_return;\
} \
else\
{ \
AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_SUCCESS); \
}
Ideally, if PARAM_CHECK is success, it should not touch error status code.
This macro is a problem when sending soap faults from generated code. To send
faults from generated code, we have to set the error status inside service
logic and it will be checked by the engine to create soap fault. However, after
setting error status, there are several generated codes doing AXIS2_PARAM_CHECK
and hence overwriting the status code.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AXIS2C-1402) AXIS2_PARAM_CHECK overwrite previously set error status
[
https://issues.apache.org/jira/browse/AXIS2C-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
S.Uthaiyashankar resolved AXIS2C-1402.
--
Resolution: Fixed
Fixed in revision 825395
AXIS2_PARAM_CHECK overwrite previously set error status
---
Key: AXIS2C-1402
URL: https://issues.apache.org/jira/browse/AXIS2C-1402
Project: Axis2-C
Issue Type: Bug
Affects Versions: 1.6.0
Reporter: S.Uthaiyashankar
Assignee: S.Uthaiyashankar
Fix For: Next Version
When checking AXIS2_PARAM_CHECK, if it is success, it overwrites STATUS_CODE
by setting AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_SUCCESS);
check the macro definition:
#define AXIS2_PARAM_CHECK(error, object, error_return) \
if (!object)\
{ \
AXIS2_ERROR_SET_ERROR_NUMBER(error, AXIS2_ERROR_INVALID_NULL_PARAM); \
AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_FAILURE); \
return error_return;\
} \
else\
{ \
AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_SUCCESS); \
}
Ideally, if PARAM_CHECK is success, it should not touch error status code.
This macro is a problem when sending soap faults from generated code. To send
faults from generated code, we have to set the error status inside service
logic and it will be checked by the engine to create soap fault. However,
after setting error status, there are several generated codes doing
AXIS2_PARAM_CHECK and hence overwriting the status code.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [axis2] Status on Axis2 1.5.1 and Rampart 1.5
+1 for re-spining the votes. Thanks, Ruwan On Tue, Oct 13, 2009 at 5:24 AM, Nandana Mihindukulasooriya nandana@gmail.com wrote: Hi Glen Nandana/all, can you check what I did in Rampart and let me know if you foresee any problems with it? I'm going to respin Axis2 1.5.1 with this and one other fix, and we should respin Rampart 1.5 as well. +1 for re-spining both Axis2 1.5.1 and Rampart 1.5. I checked the change in STSClient and it does't seem to have side effects on Rampart functionality. thanks, Nandana -- Ruwan Linton Technical Lead Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com
Re: [axis2] Status on Axis2 1.5.1 and Rampart 1.5
On Mon, Oct 12, 2009 at 16:08, Glen Daniels g...@thoughtcraft.com wrote: Hi folks! OK, so here are the results of my weekend investigations. The lockup when running the Rampart 1.5 tests with Axis2 1.5.1 was due to http connection starvation. I've fixed two issues and everything works now, but I'd like to respin both Axis2 1.5.1 and Rampart 1.5 as a result. Details below. First, a quick summary of a major change in Axis2 1.5.1 : we were formerly creating new MultithreadedHTTPConenctionManagers all the time in the HTTP sender code. In typical usage you'd never see connection pool starvation (since each new MHCM had a new pool), but two major problems occurred. 1) Connection reuse wasn't really possible, and 2) we would eventually (in high-volume situations) run into the OS limits for open sockets. So I fixed this so that 1.5.1 now re-uses a single MHCM for each ConfigurationContext, which allows for sharing connections across ServiceClient instances. The bigger problem *behind* the problem above is that users of the commons HTTPClient library (like Axis2) need to call releaseConnection() on each and every HTTPMethod after they are finished. The ServiceClient.cleanupTransport() call does this, but since we never told people to call that explicitly, Well, I did :-) See [1] and [2]. Andreas [1] http://markmail.org/message/c7wqfwzl23qrheic [2] http://svn.apache.org/viewvc?view=revrevision=748730 no one was in the habit of doing it. A number of bugs about connection starvation came up, and we put in the Options.setCallTransportCleanup() option, which automatically calls cleanupTransport() after each call, but at a cost - since we're releasing connection resources you need to make sure you've read everything, which means building the whole Axiom tree. Bye-bye, streaming. So I also added a different connection cleanup option which automatically cleans up the *last* operation as you're setting up the next one. So, to make the Rampart story very short, the problem was this: a new ServiceClient gets created to deal with SecureConversation interactions (see STSClient.getServiceClient()). This SC shares the same ConfigurationContext with the outer (i.e. user) SC, so it shares a MHCM and a connection pool. The problem is since the STS operations happen inside a user-level operation, the record of the last operation gets overwritten, and as a result my automatic cleanup mechanism can't catch both! So we lose one connection each time we go through the STS process, and that causes a hard lock. SOLUTION I did two things to fix this, both of which I think should be reflected in the released code. First, in Rampart, I added a call to setCallTransportCleanup(true) in STSClient - this means that the STS operations will be forced to build the complete Axiom tree (see above), but solves the connection starvation issue. Second, in Axis2, I added a default 30-second timeout while waiting for new connections - this doesn't change the functionality at all, but it does mean that we can no longer get into situations where the system just locks up forever. With that change, we'll now at least get an Exception if there's a starvation issue, which can then be debugged. Nandana/all, can you check what I did in Rampart and let me know if you foresee any problems with it? I'm going to respin Axis2 1.5.1 with this and one other fix, and we should respin Rampart 1.5 as well. Thoughts/comments? Thanks, --Glen
Re: Transport-1.0 release status
We are ready from the JIRA PoV to go for the release, I need to figure out the site and various other things together with a few code formatting. Once I am done with that will publish the RC. Thanks, Ruwan On Sun, Oct 11, 2009 at 10:04 PM, Ruwan Linton ruwan.lin...@gmail.comwrote: Folks, We have only 2 more issues to be fixed for the 1.0 release of the axis2 transports [1]. As soon as those issues are fixed I will pack an RC to test with synapse and axis2 1.5 and we will be able to get the release soon. [1] - https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310250fixfor=12313665resolution=-1sorter/field=prioritysorter/order=DESC Thanks, Ruwan -- Ruwan Linton Technical Lead Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com -- Ruwan Linton Technical Lead Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com
[axis2] Status on Axis2 1.5.1 and Rampart 1.5
Hi folks! OK, so here are the results of my weekend investigations. The lockup when running the Rampart 1.5 tests with Axis2 1.5.1 was due to http connection starvation. I've fixed two issues and everything works now, but I'd like to respin both Axis2 1.5.1 and Rampart 1.5 as a result. Details below. First, a quick summary of a major change in Axis2 1.5.1 : we were formerly creating new MultithreadedHTTPConenctionManagers all the time in the HTTP sender code. In typical usage you'd never see connection pool starvation (since each new MHCM had a new pool), but two major problems occurred. 1) Connection reuse wasn't really possible, and 2) we would eventually (in high-volume situations) run into the OS limits for open sockets. So I fixed this so that 1.5.1 now re-uses a single MHCM for each ConfigurationContext, which allows for sharing connections across ServiceClient instances. The bigger problem *behind* the problem above is that users of the commons HTTPClient library (like Axis2) need to call releaseConnection() on each and every HTTPMethod after they are finished. The ServiceClient.cleanupTransport() call does this, but since we never told people to call that explicitly, no one was in the habit of doing it. A number of bugs about connection starvation came up, and we put in the Options.setCallTransportCleanup() option, which automatically calls cleanupTransport() after each call, but at a cost - since we're releasing connection resources you need to make sure you've read everything, which means building the whole Axiom tree. Bye-bye, streaming. So I also added a different connection cleanup option which automatically cleans up the *last* operation as you're setting up the next one. So, to make the Rampart story very short, the problem was this: a new ServiceClient gets created to deal with SecureConversation interactions (see STSClient.getServiceClient()). This SC shares the same ConfigurationContext with the outer (i.e. user) SC, so it shares a MHCM and a connection pool. The problem is since the STS operations happen inside a user-level operation, the record of the last operation gets overwritten, and as a result my automatic cleanup mechanism can't catch both! So we lose one connection each time we go through the STS process, and that causes a hard lock. SOLUTION I did two things to fix this, both of which I think should be reflected in the released code. First, in Rampart, I added a call to setCallTransportCleanup(true) in STSClient - this means that the STS operations will be forced to build the complete Axiom tree (see above), but solves the connection starvation issue. Second, in Axis2, I added a default 30-second timeout while waiting for new connections - this doesn't change the functionality at all, but it does mean that we can no longer get into situations where the system just locks up forever. With that change, we'll now at least get an Exception if there's a starvation issue, which can then be debugged. Nandana/all, can you check what I did in Rampart and let me know if you foresee any problems with it? I'm going to respin Axis2 1.5.1 with this and one other fix, and we should respin Rampart 1.5 as well. Thoughts/comments? Thanks, --Glen
Re: [axis2] Status on Axis2 1.5.1 and Rampart 1.5
Hi Glen Nandana/all, can you check what I did in Rampart and let me know if you foresee any problems with it? I'm going to respin Axis2 1.5.1 with this and one other fix, and we should respin Rampart 1.5 as well. +1 for re-spining both Axis2 1.5.1 and Rampart 1.5. I checked the change in STSClient and it does't seem to have side effects on Rampart functionality. thanks, Nandana
[axis2] Status on Axis2 1.5.1 and Rampart 1.5
Hi folks! OK, so here are the results of my weekend investigations. The lockup when running the Rampart 1.5 tests with Axis2 1.5.1 was due to http connection starvation. I've fixed two issues and everything works now, but I'd like to respin both Axis2 1.5.1 and Rampart 1.5 as a result. Details below. First, a quick summary of a major change in Axis2 1.5.1 : we were formerly creating new MultithreadedHTTPConenctionManagers all the time in the HTTP sender code. In typical usage you'd never see connection pool starvation (since each new MHCM had a new pool), but two major problems occurred. 1) Connection reuse wasn't really possible, and 2) we would eventually (in high-volume situations) run into the OS limits for open sockets. So I fixed this so that 1.5.1 now re-uses a single MHCM for each ConfigurationContext, which allows for sharing connections across ServiceClient instances. The bigger problem *behind* the problem above is that users of the commons HTTPClient library (like Axis2) need to call releaseConnection() on each and every HTTPMethod after they are finished. The ServiceClient.cleanupTransport() call does this, but since we never told people to call that explicitly, no one was in the habit of doing it. A number of bugs about connection starvation came up, and we put in the Options.setCallTransportCleanup() option, which automatically calls cleanupTransport() after each call, but at a cost - since we're releasing connection resources you need to make sure you've read everything, which means building the whole Axiom tree. Bye-bye, streaming. So I also added a different connection cleanup option which automatically cleans up the *last* operation as you're setting up the next one. So, to make the Rampart story very short, the problem was this: a new ServiceClient gets created to deal with SecureConversation interactions (see STSClient.getServiceClient()). This SC shares the same ConfigurationContext with the outer (i.e. user) SC, so it shares a MHCM and a connection pool. The problem is since the STS operations happen inside a user-level operation, the record of the last operation gets overwritten, and as a result my automatic cleanup mechanism can't catch both! So we lose one connection each time we go through the STS process, and that causes a hard lock. SOLUTION I did two things to fix this, both of which I think should be reflected in the released code. First, in Rampart, I added a call to setCallTransportCleanup(true) in STSClient - this means that the STS operations will be forced to build the complete Axiom tree (see above), but solves the connection starvation issue. Second, in Axis2, I added a default 30-second timeout while waiting for new connections - this doesn't change the functionality at all, but it does mean that we can no longer get into situations where the system just locks up forever. With that change, we'll now at least get an Exception if there's a starvation issue, which can then be debugged. Nandana/all, can you check what I did in Rampart and let me know if you foresee any problems with it? I'm going to respin Axis2 1.5.1 with this and one other fix, and we should respin Rampart 1.5 as well. Thoughts/comments? Thanks, --Glen
Transport-1.0 release status
Folks, We have only 2 more issues to be fixed for the 1.0 release of the axis2 transports [1]. As soon as those issues are fixed I will pack an RC to test with synapse and axis2 1.5 and we will be able to get the release soon. [1] - https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310250fixfor=12313665resolution=-1sorter/field=prioritysorter/order=DESC Thanks, Ruwan -- Ruwan Linton Technical Lead Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com
[jira] Commented: (WSCOMMONS-417) Clarify the status of the JavaMail dependency
[ https://issues.apache.org/jira/browse/WSCOMMONS-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12761849#action_12761849 ] Andreas Veithen commented on WSCOMMONS-417: --- On a similar question in the context of CXF, Daniel Kulp gave some additional arguments in support of the Geronimo implementations. See [1]. [1] http://markmail.org/message/xanxtu2s4ukjhn3k Clarify the status of the JavaMail dependency - Key: WSCOMMONS-417 URL: https://issues.apache.org/jira/browse/WSCOMMONS-417 Project: WS-Commons Issue Type: Improvement Components: AXIOM Reporter: Andreas Veithen Priority: Minor Fix For: Axiom 1.2.9 axiom-api depends on Geronimo's JavaMail implementation. On the other hand, in axiom-tests this dependency is excluded and replaced by Sun's JavaMail dependency (same situation in Axis2). If Axiom doesn't work properly with Geronimo's JavaMail implementation, we should either make sure that the bugs in Geronimo get fixed or change the dependencies of axiom-api. If Axiom works properly with Geronimo's JavaMail implementation, then it doesn't make sense to run the tests against a different JavaMail implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: SMS transport status?
Hi Ruwan, SMS Transport is feature complete now.both the SMPP and and GSM implementations. I m currently working on a patch that will be useful with the SMPP implementation. Which i'll add in this week. thanks, Charith On Tue, Sep 22, 2009 at 10:32 AM, Ruwan Linton ruwan.lin...@gmail.comwrote: Hi Charith, What is the status of the SMS transport? Can we include that in the transports 1.0 release that we are planning to do? Thanks, Ruwan -- Ruwan Linton Technical Lead Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 http://wso2.org/esb%0AWSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com -- Charith Dhanushka Wickramarachchi http://charithwiki.blogspot.com/
Re: SMS transport status?
Cool, so I will get this included to the release as well. Thanks, Ruwan On Tue, Sep 22, 2009 at 12:36 PM, Charith Wickramarachchi charith.dhanus...@gmail.com wrote: Hi Ruwan, SMS Transport is feature complete now.both the SMPP and and GSM implementations. I m currently working on a patch that will be useful with the SMPP implementation. Which i'll add in this week. thanks, Charith On Tue, Sep 22, 2009 at 10:32 AM, Ruwan Linton ruwan.lin...@gmail.com wrote: Hi Charith, What is the status of the SMS transport? Can we include that in the transports 1.0 release that we are planning to do? Thanks, Ruwan -- Ruwan Linton Technical Lead Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 http://wso2.org/esb%0AWSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com -- Charith Dhanushka Wickramarachchi http://charithwiki.blogspot.com/ -- Ruwan Linton Technical Lead Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com
Re: SMS transport status?
Also, I assume that the udp and tcp transports are in good shape to go for the 1.0 release?? Am I correct Andreas? Thanks, Ruwan On Tue, Sep 22, 2009 at 10:32 AM, Ruwan Linton ruwan.lin...@gmail.comwrote: Hi Charith, What is the status of the SMS transport? Can we include that in the transports 1.0 release that we are planning to do? Thanks, Ruwan -- Ruwan Linton Technical Lead Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com -- Ruwan Linton Technical Lead Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com
Re: [VOTE] [axis2] Release Axis2 1.5.1 (status)
Glen, Dobri made some comments about the changes in the HTTP transport and I think we should take them into account. That is why I didn't vote yet. Andreas On Mon, Aug 17, 2009 at 16:48, Glen Danielsg...@thoughtcraft.com wrote: :-) So regarding this release - we don't seem to have many +1's yet. As such, my plan is to rejigger it as Dennis suggests and re-publish this content (with only minor tweaks) as 1.5RC later today. Hopefully we can get that out to the world ASAP while trying to quickly resolve the documentation, etc. --Glen Andreas Veithen wrote: Stop complaining and do something :-) Andreas On Mon, Aug 17, 2009 at 06:37, Dennis Sosnoskid...@sosnoski.com wrote: I'd think at least this Jira should be addressed before a 1.5.1 release: https://issues.apache.org/jira/browse/AXIS2-4434 Another documentation issue is that the documentation on transports is no longer accurate, and should either be corrected (presumably by pointing to the transports project location... if there is one) or deleted. My personal preference would also be to make Axis2 1.5.1 available as an RC rather than a full release until at least preliminary builds of transports and Rampart are available to work with 1.5.1. Otherwise, the Axis2 download page should warn users that the release has limited functionality until these other projects are available. - Dennis Glen Daniels wrote: (resend with corrected URL) Hi Axis Developers, I've put up what will hopefully be our 1.5.1 release, with a few key fixes as follows: * Fix for the dreaded CLOSE_WAIT problem (JIRA issues 935, 2883, etc). We now share an instance of HTTPClient across each ConfigurationContext (i.e. each Axis2 server or ServiceClient) - connection reuse is now automatic. This means the REUSE_HTTP_CLIENT flag is no longer necessary or useful, nor is creating your own MultithreadedHttpConnectionManager. * Transport deployer is now actually functional, and getListenerManager() in ConfigurationContext now creates a new LM if there isn't one already. * Fix for AXIS2-4034, module versions now support real versions like 1.5.1 * NPE problem (see AXIS2-4114) fixed in MessageContext while retrieving policy. This mail kicks off a VOTE for the release, with the usual 72-hour window for votes. You can find the distribution files in here: http://people.apache.org/~gdaniels/stagingRepo/org/apache/axis2/distribution/1.5.1/ And the M2 repository with everything is at: http://people.apache.org/~gdaniels/stagingRepo The SVN tag is: https://svn.apache.org/repos/asf/webservices/axis2/tags/java/v1.5.1RC ...and I'll add a proper v1.5.1 tag as soon as this release goes final. Please offer your VOTE(and indicate binding/non-binding). Here's my +1 (binding). Many thanks, --Glen
Re: [VOTE] [axis2] Release Axis2 1.5.1 (status)
:-) So regarding this release - we don't seem to have many +1's yet. As such, my plan is to rejigger it as Dennis suggests and re-publish this content (with only minor tweaks) as 1.5RC later today. Hopefully we can get that out to the world ASAP while trying to quickly resolve the documentation, etc. --Glen Andreas Veithen wrote: Stop complaining and do something :-) Andreas On Mon, Aug 17, 2009 at 06:37, Dennis Sosnoskid...@sosnoski.com wrote: I'd think at least this Jira should be addressed before a 1.5.1 release: https://issues.apache.org/jira/browse/AXIS2-4434 Another documentation issue is that the documentation on transports is no longer accurate, and should either be corrected (presumably by pointing to the transports project location... if there is one) or deleted. My personal preference would also be to make Axis2 1.5.1 available as an RC rather than a full release until at least preliminary builds of transports and Rampart are available to work with 1.5.1. Otherwise, the Axis2 download page should warn users that the release has limited functionality until these other projects are available. - Dennis Glen Daniels wrote: (resend with corrected URL) Hi Axis Developers, I've put up what will hopefully be our 1.5.1 release, with a few key fixes as follows: * Fix for the dreaded CLOSE_WAIT problem (JIRA issues 935, 2883, etc). We now share an instance of HTTPClient across each ConfigurationContext (i.e. each Axis2 server or ServiceClient) - connection reuse is now automatic. This means the REUSE_HTTP_CLIENT flag is no longer necessary or useful, nor is creating your own MultithreadedHttpConnectionManager. * Transport deployer is now actually functional, and getListenerManager() in ConfigurationContext now creates a new LM if there isn't one already. * Fix for AXIS2-4034, module versions now support real versions like 1.5.1 * NPE problem (see AXIS2-4114) fixed in MessageContext while retrieving policy. This mail kicks off a VOTE for the release, with the usual 72-hour window for votes. You can find the distribution files in here: http://people.apache.org/~gdaniels/stagingRepo/org/apache/axis2/distribution/1.5.1/ And the M2 repository with everything is at: http://people.apache.org/~gdaniels/stagingRepo The SVN tag is: https://svn.apache.org/repos/asf/webservices/axis2/tags/java/v1.5.1RC ...and I'll add a proper v1.5.1 tag as soon as this release goes final. Please offer your VOTE(and indicate binding/non-binding). Here's my +1 (binding). Many thanks, --Glen
Re: jUDDI status meeting tomorrow Friday 14
Works for me. Jeremi Kurt T Stam wrote: Hi guys, Let's meet up on IRC tomorrow 9am Chicago time/10 am Boston time / 4 pm Germany time (Jeremy does that work for you?). irc.freenode.net #juddi. Suggested Agenda: * Quick go around to see what everyone has been up to. * Check Jira to see what should go in the 3.0.0 release. * Introduction to load testing work by Jeremy - Link to test results, or publish on the apache site? - Check test scripts into the source tree? * Anything else that comes to mind. Hope you can make it! --Kurt
MEETING NOTES: jUDDI status meeting tomorrow Friday 14
KurtStam: k let's do a quick go around then; I think Jeremi last since I think we'll talk about the testing the longest [10:02am] KurtStam: who wants to go first? [10:03am] tcunning: i can go first [10:03am] tcunning: right now i'm working on getting scout working with juddi v3 [10:03am] tcunning: just finished off removing getContent [10:04am] tcunning: and i'll probably be working on the dist bundle next week [10:04am] tcunning: that's about it [10:05am] tcunning: np [10:06am] KurtStam: Jeff? [10:06am] KurtStam: Well I can go while Jeff is getting his coffee [10:06am] jfaath: working on the JIRAs assigned to me [10:06am] KurtStam: ah [10:07am] jfaath: which isn't much right now [10:07am] KurtStam: k [10:07am] KurtStam: I've been spending some time with scout and jUDDIv2 since that still ships with the AppServers (JBoss, Gerominimo etc) because of the TCK [10:08am] KurtStam: so that side tracked me from jUDDIv3 work a bit. [10:08am] KurtStam: but that is done now; so I've been working and on v3 the last week or so. [10:09am] KurtStam: It think things are looking pretty good. I have rearranged Jira a bit; I think we need to release 3.0 sooner rather then later [10:10am] KurtStam: I'm happy with the results from the load tests so far. I think some of the issues found will need to address for 3.0 and some can wait till 3.0.1 [10:10am] KurtStam: Rene want to jump in to introduce the load testing stuff and then jeremi can take us through some details? [10:11am] Natalie__ joined the chat room. [10:11am] ReneXceptance: Yes. [10:11am] KurtStam: Hi Natalie [10:11am] Natalie__: Hi there. Sorry to jump in late. [10:11am] tcunning: Natalie - we're doing a go around of what everyone is working on, i can send you a log of what's gone on so far [10:11am] ReneXceptance: So basically we are using our tool, that is capable of executing any kind of http/html reuqests. [10:12am] ReneXceptance: It was extended to support web services and you program it directly on the Java-API. [10:12am] Natalie__: Ok great, thanks [10:12am] ReneXceptance: Therefore the tests are as close as possible to the later usage scenarios. No tricks with recorded urls and so on. [10:13am] ReneXceptance: The juddi project has a full license and the scripts are yours... just have to find a nice place to store them. They are pure Java [10:13am] ReneXceptance: and you can, at the end, integrate the stuff as regression test into the build. [10:14am] ReneXceptance: If you have a way to get the server up during the build, so you can run performance regression. [10:14am] KurtStam: that's great; we definetly need to hook them up like that [10:14am] KurtStam: yup we do that now in the uddi-client module actually [10:14am] ReneXceptance: And I guess Jeremi can kick in with some stuff we did [10:14am] KurtStam: thx Rene [10:15am] jeremi: So I first did some juddi-out-of the -box testing [10:16am] jeremi: and got some benchmark values that can be seen in the last update I sent [10:16am] jeremi: found here, file:///home/jeremi/.gvfs/ftp%20as%20ftp1058375-jthebeau%20on%20www.xceptance.de/download/results/juddi/JuddiReports/RE:%20jUDDI%20load%20testing%20update:%20performance%20comparaison.html [10:17am] KurtStam: maybe you have an http link? [10:17am] ReneXceptance: maybe not the local file copy... [10:17am] jeremi: oops [10:18am] jeremi: http://xlt.xceptance.de/download/results/juddi/JuddiReports/RE: jUDDI load testing update: performance comparaison.html [10:19am] KurtStam: I think the link got cut off.. [10:19am] jeremi: then I compared that with juddi using MySQL as a DB instead of Derby [10:19am] KurtStam: so this is both using hibernate right? [10:20am] KurtStam: with OpenJPA we see a memory leak? [10:20am] jeremi: yes [10:20am] KurtStam: http://xlt.xceptance.de/download/results/juddi/20090812-124530-vs-20090812-134739/ [10:20am] KurtStam: is the comparison of dbs? [10:20am] jeremi: this was with the Snapshot that Kurt sent me [10:20am] KurtStam: cool; yeah that was a recent snapshot buil;d [10:21am] ReneXceptance: if i remember correctly the first build had memory issues [10:21am] KurtStam: the later builds not anymore? [10:21am] jeremi: the comparison is of juddi with these two different DBs [10:22am] ReneXceptance: Baseline Derby compared to MySQL [10:22am] ReneXceptance: green is good. check the requests section [10:22am] KurtStam: so mysql is quite a but faster [10:22am] KurtStam: bit [10:23am] jeremi: after that we ran some performance test to compare them under a load setting they could both take [10:24am] jeremi: In which juddi + MySQL responded faster on average [10:25am] KurtStam: Cool; yeah the snapshots run hibernate; so we prob still have an issue using openjpa. [10:25am] ReneXceptance: shall we run mysql and openJPA? [10:25am] jeremi: Finding a load profile that both could take was a bit difficult since juddi + Derby kept freezing up a loads that juddi+ MySQL could easily take [10:25am] KurtStam:
Re: Status of ADB SOAP encoding and helper mode
On Tue, Jun 30, 2009 at 07:05, Amila Suriarachchiamilasuriarach...@gmail.com wrote: On Sat, Jun 27, 2009 at 1:15 AM, Andreas Veithen andreas.veit...@gmail.com wrote: Hi devs, I would like to have more information about the status of two components of adb(-codegen): 1) SOAP encoding support for ADB (see [1]). Last status that I see is that it is incomplete [2] or unsupported [3]. Can somebody clarify this? Note that the code that implements this is largely based on generated code that has been modified by hand afterwards. There seems to be no information on how one would regenerate these classes, making them almost unmaintainable. yes. It is not complete. The generated code is for the data types in the soap encoding schema. I had to manually change some code since soap encoding does not necessarily follow the xml schemas. So it is not mean to regenerate. Amilas, Does not complete mean not usable, or are there people using it for some particular cases? In other words, is it something that we should maintain or is it a candidate for removal (in case the burden of maintaining it gets too high)? 2) Helper mode for ADB. In this mode, the schema compiler splits the bean and the parser/serializer code into different classes. While this is a nice feature, it seems to be obsolete [4] or deprecated [5]. At least the corresponding part of the template is not up to date. The specific problem here is that the test coverage of this feature is zero, again making it unmaintainable. So we should either update this feature and have an appropriate level of test coverage or scrap it. As I see no one currently use this feature and it is obsolete. Actually, I kind of like this feature (except for the fact that it has been implemented by copy paste...). I took some action to safeguard the current implementation, i.e. to avoid further degradation. Regards, Andreas thanks, Amila. Regards, Andreas [1] http://markmail.org/thread/htchm4nsbywlnzi4 [2] http://markmail.org/message/xkzefcaxrfio5zsm [3] http://markmail.org/message/vhayn365l6hrgvmo [4] http://markmail.org/message/wfoynhc6i6k5r76u [5] http://markmail.org/message/rcvtjvrelwncv7a6 -- Amila Suriarachchi WSO2 Inc. blog: http://amilachinthaka.blogspot.com/
Re: Status of ADB SOAP encoding and helper mode
On Mon, Jul 20, 2009 at 8:08 PM, Andreas Veithen andreas.veit...@gmail.comwrote: On Tue, Jun 30, 2009 at 07:05, Amila Suriarachchiamilasuriarach...@gmail.com wrote: On Sat, Jun 27, 2009 at 1:15 AM, Andreas Veithen andreas.veit...@gmail.com wrote: Hi devs, I would like to have more information about the status of two components of adb(-codegen): 1) SOAP encoding support for ADB (see [1]). Last status that I see is that it is incomplete [2] or unsupported [3]. Can somebody clarify this? Note that the code that implements this is largely based on generated code that has been modified by hand afterwards. There seems to be no information on how one would regenerate these classes, making them almost unmaintainable. yes. It is not complete. The generated code is for the data types in the soap encoding schema. I had to manually change some code since soap encoding does not necessarily follow the xml schemas. So it is not mean to regenerate. Amilas, Does not complete mean not usable, or are there people using it for some particular cases? I don't think anyone using it. In other words, is it something that we should maintain or is it a candidate for removal (in case the burden of maintaining it gets too high)? What the the maintaining cost you see? I think it is better to keep it unless you have a better idea to implement it and implements it. I can complete it whenever I get time (although not sure when it happens :)). thanks, Amila. 2) Helper mode for ADB. In this mode, the schema compiler splits the bean and the parser/serializer code into different classes. While this is a nice feature, it seems to be obsolete [4] or deprecated [5]. At least the corresponding part of the template is not up to date. The specific problem here is that the test coverage of this feature is zero, again making it unmaintainable. So we should either update this feature and have an appropriate level of test coverage or scrap it. As I see no one currently use this feature and it is obsolete. Actually, I kind of like this feature (except for the fact that it has been implemented by copy paste...). I took some action to safeguard the current implementation, i.e. to avoid further degradation. Regards, Andreas thanks, Amila. Regards, Andreas [1] http://markmail.org/thread/htchm4nsbywlnzi4 [2] http://markmail.org/message/xkzefcaxrfio5zsm [3] http://markmail.org/message/vhayn365l6hrgvmo [4] http://markmail.org/message/wfoynhc6i6k5r76u [5] http://markmail.org/message/rcvtjvrelwncv7a6 -- Amila Suriarachchi WSO2 Inc. blog: http://amilachinthaka.blogspot.com/ -- Amila Suriarachchi WSO2 Inc. blog: http://amilachinthaka.blogspot.com/
Re: how to get the http status code
Sorry, I replied to the wrong message, so try it again. Yes, I did some debugging, but this seems to be a bug in axis2/c library. Or maybe I need to do something like call some APIs so that the status will be set and so users can get the status? My question is this, does a user need to specifically do something in order for get_http_status_code to work? if yes, what needs to be done? There doesn't seem to any info in the documentation. Thanks! Vivian From: Rajika Kumarasiri rajika.kumaras...@gmail.com To: Apache AXIS C Developers List axis-c-dev@ws.apache.org Sent: Wednesday, July 15, 2009 7:37:50 PM Subject: Re: how to get the http status code May be some debugging will help? Rajika On Thu, Jul 16, 2009 at 5:45 AM, Vivian Wang vivianwan...@yahoo.com wrote: Hi There, I am using axis2/c to make web service client call, like this: axiom_node_t * node = axis2_svc_client_send_receive(_wsf_service_client, _env, payload); After this, I am trying to use the following API to get the http status code, AXIS2_EXTERN int AXIS2_CALL axis2_svc_client_get_http_status_code(axis2_svc_client_t * svc_client, const axutil_env_t * env); I am expecting 408 for time out, 200 for success. However, I am always getting 0. How do I get the proper status code? Thanks! Vivian
how to get the http status code
Hi There, I am using axis2/c to make web service client call, like this: axiom_node_t * node = axis2_svc_client_send_receive(_wsf_service_client, _env, payload); After this, I am trying to use the following API to get the http status code, AXIS2_EXTERN int AXIS2_CALL axis2_svc_client_get_http_status_code(axis2_svc_client_t * svc_client, const axutil_env_t * env); I am expecting 408 for time out, 200 for success. However, I am always getting 0. How do I get the proper status code? Thanks! Vivian
Re: how to get the http status code
May be some debugging will help? -Rajika On Thu, Jul 16, 2009 at 5:45 AM, Vivian Wang vivianwan...@yahoo.com wrote: Hi There, I am using axis2/c to make web service client call, like this: axiom_node_t * node = axis2_svc_client_send_receive(_wsf_service_client, _env, payload); After this, I am trying to use the following API to get the http status code, AXIS2_EXTERN int AXIS2_CALL axis2_svc_client_get_http_status_code(axis2_svc_client_t * svc_client, const axutil_env_t * env); I am expecting 408 for time out, 200 for success. However, I am always getting 0. How do I get the proper status code? Thanks! Vivian -- http://wso2.org http://llvm.org http://www.minix3.org
Re: [Axis2] Transports status?
Currently only snapshots are available. The following things need to be done before releasing 1.0: - Put together a Maven site for the project and make sure there is a minimum of documentation. - Fix some of the remaining open bugs. Andreas On Sat, Jul 11, 2009 at 02:08, Dennis Sosnoskid...@sosnoski.com wrote: What's the status of the transports code compatible with Axis 1.5? Thanks, - Dennis -- Dennis M. Sosnoski Java XML and Web Services Axis2 Training and Consulting http://www.sosnoski.com - http://www.sosnoski.co.nz Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117
Re: [Axis2] Transports status?
Thanks for the update, Andreas. Do you know if anyone is actively working on getting this done? It'd be great if we had a schedule for the 1.5.X release, including Rampart, transports, and any other essential components. The original schedule (http://www.mail-archive.com/axis-dev@ws.apache.org/msg44317.html) seems a bit outdated... It's questionable to recommend that users switch to 1.5 when so much is currently missing. - Dennis Andreas Veithen wrote: Currently only snapshots are available. The following things need to be done before releasing 1.0: - Put together a Maven site for the project and make sure there is a minimum of documentation. - Fix some of the remaining open bugs. Andreas On Sat, Jul 11, 2009 at 02:08, Dennis Sosnoskid...@sosnoski.com wrote: What's the status of the transports code compatible with Axis 1.5? Thanks, - Dennis -- Dennis M. Sosnoski Java XML and Web Services Axis2 Training and Consulting http://www.sosnoski.com - http://www.sosnoski.co.nz Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117
Re: Status of ADB SOAP encoding and helper mode
On Sat, Jun 27, 2009 at 1:15 AM, Andreas Veithen andreas.veit...@gmail.comwrote: Hi devs, I would like to have more information about the status of two components of adb(-codegen): 1) SOAP encoding support for ADB (see [1]). Last status that I see is that it is incomplete [2] or unsupported [3]. Can somebody clarify this? Note that the code that implements this is largely based on generated code that has been modified by hand afterwards. There seems to be no information on how one would regenerate these classes, making them almost unmaintainable. yes. It is not complete. The generated code is for the data types in the soap encoding schema. I had to manually change some code since soap encoding does not necessarily follow the xml schemas. So it is not mean to regenerate. 2) Helper mode for ADB. In this mode, the schema compiler splits the bean and the parser/serializer code into different classes. While this is a nice feature, it seems to be obsolete [4] or deprecated [5]. At least the corresponding part of the template is not up to date. The specific problem here is that the test coverage of this feature is zero, again making it unmaintainable. So we should either update this feature and have an appropriate level of test coverage or scrap it. As I see no one currently use this feature and it is obsolete. thanks, Amila. Regards, Andreas [1] http://markmail.org/thread/htchm4nsbywlnzi4 [2] http://markmail.org/message/xkzefcaxrfio5zsm [3] http://markmail.org/message/vhayn365l6hrgvmo [4] http://markmail.org/message/wfoynhc6i6k5r76u [5] http://markmail.org/message/rcvtjvrelwncv7a6 -- Amila Suriarachchi WSO2 Inc. blog: http://amilachinthaka.blogspot.com/
Status meeting June 10 2009
KurtStam: so beta is out [12:45pm] jfaath: yes [12:45pm] KurtStam: and we're getting some downloads and questions [12:45pm] KurtStam: which is good [12:46pm] tcunning: did it work in jboss? [12:46pm] KurtStam: hopefully we can learn from the issues [12:46pm] KurtStam: I got side tracked, but will try again this afternoon [12:46pm] KurtStam: so I guess we need to plan 3.0.0 [12:47pm] KurtStam: we have a nice list of tasks [12:47pm] KurtStam: and Tom was going to add some subtaks around the console [12:47pm] KurtStam: do you have the list? [12:47pm] tcunning: yup [12:47pm] tcunning: i'll start adding right now [12:47pm] KurtStam: just paste list here [12:48pm] tcunning: Add/Edit/Delete Tmodel [12:48pm] tcunning: Add/Edit/Delete Services [12:48pm] tcunning: Add/Edit/Delete Service Binding [12:48pm] tcunning: Add/Edit/Delete Subscription [12:48pm] tcunning: Add/Edit/Delete Category [12:48pm] tcunning: Add/Edit/Delete Business [12:48pm] tcunning: Business requires (Address, Contact, Email, etc) [12:48pm] tcunning: Add/Edit/Delete Publisher [12:48pm] tcunning: Add/Edit/Delete Overview Doc [12:48pm] tcunning: Finish Search [12:48pm] tcunning: Query Window [12:48pm] tcunning: Browse by Category [12:48pm] KurtStam: Jeff, do you think we missed anything? [12:48pm] KurtStam: this is what Tom and I came up with yesterday [12:49pm] jfaath: what is finish search [12:50pm] KurtStam: Add a portlet that supports writing and storing a query [12:50pm] jfaath: ok [12:50pm] KurtStam: not that we really started that... [12:50pm] tcunning: we have a placeholder in there [12:50pm] KurtStam: and displaying the results. [12:50pm] KurtStam: right we have a place holder [12:51pm] KurtStam: If I have to pick priorities for the console it'd be Publishing and Browsing [12:51pm] KurtStam: Search would be nice to have [12:52pm] tcunning: agreed [12:52pm] jfaath: yea, publishing perhaps first, because you can't search for something if it's not in there [12:53pm] KurtStam: right, so I'd be fine push some console tasks into a later 3.0.x release [12:53pm] KurtStam: if needed [12:53pm] KurtStam: Besides console, docs will be crucial [12:54pm] KurtStam: do we have any additional tasks besides the ones in jira? [12:54pm] KurtStam: anyone :)? [12:54pm] jfaath: not that I can think of offhand [12:54pm] jfaath: really, we just need to make juddi easy to use [12:55pm] tcunning: maybe more testing? i don't know. [12:55pm] KurtStam: yes, we need docs on how to deploy it to different environments/app servers [12:55pm] KurtStam: hopefully the users can help us with that [12:55pm] KurtStam: but in the end we will need to document it [12:55pm] KurtStam: want to do a pass over the jiras? [12:56pm] KurtStam: we can skip console ones i think [12:56pm] KurtStam: 161 [12:56pm] KurtStam: seems silly now [12:57pm] KurtStam: we might want to combine juddi-cxf and juddi-axis into one module with a profile [12:57pm] KurtStam: see 233 [12:57pm] tcunning: ugh [12:57pm] tcunning: i still think we keep them separate [12:57pm] KurtStam: but I'd like to a profile that may not pull in any ws stack? 'provided' [12:57pm] KurtStam: isn't it just a pom difference? [12:58pm] KurtStam: and maybe the beans.xml [12:58pm] KurtStam: ? [12:58pm] tcunning: and there's one other xml i think too [12:59pm] KurtStam: k anyway I think 161 can be closed [12:59pm] KurtStam: let's keep 233 [12:59pm] KurtStam: ? [12:59pm] KurtStam: WDYT? [1:00pm] tcunning: sure [1:00pm] tcunning: i'll take 245 unless you've started on it [1:02pm] KurtStam: k [1:02pm] KurtStam: 198 [1:02pm] KurtStam: Validation [1:03pm] KurtStam: any takers :)? [1:04pm] tcunning: jeff - 218 - is that just a delete of the whole tree? [1:04pm] jfaath: no, tmodels are lazily deleted by default [1:04pm] jfaath: this is about remvoving them completely [1:05pm] tcunning: ok [1:05pm] tcunning: is 243 necessary for 3.0? [1:05pm] jfaath: it's not huge, i just thought i'd stick it in JIRA while I saw it in the spec [1:06pm] KurtStam: 243 is half done [1:06pm] KurtStam: we support inVM [1:07pm] KurtStam: supporting RMI should be easy. I will do it. [1:08pm] KurtStam: 247 [1:08pm] KurtStam: which tomcat should we use? 5.5 or 6? [1:08pm] jfaath: i'd go with 6 [1:09pm] tcunning left the chat room. (Read error: 104 (Connection reset by peer)) [1:09pm] KurtStam: looks like tom's machine rebooted [1:09pm] jfaath: yea [1:10pm] KurtStam: he'll be back in a minite he says [1:10pm] KurtStam: so are there any tasks you like to take/give away? [1:10pm] jfaath: hmm [1:11pm] jfaath: well, I can say that I probably won't be able to devote the same time that I have been over the next couple months [1:12pm] KurtStam: k does that mean you want to stick with what you have now? [1:12pm] tcunning joined the chat room. [1:12pm] tcunning: sorry about that [1:12pm] jfaath: we'll see...i'll know more by the middle of next week [1:13pm] KurtStam: k [1:13pm] KurtStam: tom are there any tasks you want to take/give away? (I just asked the
1.5 release status
Hi folks. Just FYI - I haven't officially announced the 1.5 release yet because I'm doing a few changes to the site (and hopefully the process around the site as well). The artifacts are in Maven already, however, and the dist is where you'd expect. :) I'll do the actual announcement tonight or tomorrow. Thanks for your patience, --Glen
status meeting May 28, 2009
KurtStam: so it looks like our beta3 list is nice and clean. [11:12am] KurtStam: I know Tom is still working on an end2end test for subscriptions [11:12am] KurtStam: Tom want to jump in? [11:12am] tcunning: sure [11:13am] tcunning: i'm just finishing up a test which sets subscriptions, changes objects, and tests for output coming back from the notifier service [11:13am] tcunning: that's all i have left [11:14am] tcunning: is there anything else outstanding? [11:14am] KurtStam: no, but it'd be good to know things work before we declare victory on subscriptions [11:14am] tcunning: true [11:15am] tcunning: what else can we do to get there? [11:15am] KurtStam: Is there anything we need to document? [11:16am] tcunning: i'm sure there's a bunch of stuff to document [11:17am] KurtStam: what did you mean with what else can we do to get there?? [11:17am] tcunning: well is my test all we need to declare victory on subscriptions? [11:18am] KurtStam: well we are unit testing the components, this would be the integration test, and for beta that would be good enough for me. [11:19am] KurtStam: do you need help the test? [11:19am] tcunning: not right now [11:19am] KurtStam: k [11:19am] tcunning: just went through the user guide [11:19am] tcunning: there's nothing on subscriptions in there [11:19am] KurtStam: yeah we have to add some [11:19am] tcunning: are you going to add the clerks stuff? [11:19am] KurtStam: I can take a shot at it [11:20am] KurtStam: I will also make a run on openjpa [11:20am] KurtStam: maybe we can base this release on openjpa? [11:22am] KurtStam: anyway Jeff do you see anything besides docs and the integration test? [11:22am] jfaath: no, I think we're good [11:22am] KurtStam: cool, so maybe we aim for starting a vote over the weekend? [11:22am] jfaath: I've been working with it internally, and things seem to work pretty well [11:22am] KurtStam: cool [11:23am] KurtStam: have you used subscriptions? [11:23am] jfaath: no, the main apis only, inquiry, publishing [11:23am] KurtStam: k [11:23am] KurtStam: anything else on beta? Should be talk about 3.0? [11:24am] tcunning: sure [11:25am] KurtStam: k [11:25am] KurtStam: I add 2 taks for beta [11:25am] KurtStam: docs and integration test [11:25am] KurtStam: so let's talk 3.0 then [11:26am] KurtStam: in my mind it is a mostly stability and console work [11:27am] KurtStam: do we have to add tasks to what there is now? [11:27am] tcunning: i don't mind taking one of the portlets [11:28am] jfaath: well, in terms of apis, other than replication, there's the value set stuff [11:28am] tcunning: looks like we have axis support [11:28am] jfaath: which i think is small [11:28am] jfaath: but I see those are there [11:28am] KurtStam: I think we need to implement subscription on the server [11:28am] KurtStam: so that you can keep 2 servers in sync [11:29am] KurtStam: for certain services [11:29am] KurtStam: let me add that task [11:30am] jfaath: right, you might want to mention chapter 8 in the spec which talks about using subscription for stuff like that [11:30am] tcunning: i'd vote to close JUDDI-233 [11:30am] KurtStam: should be do it for beta? [11:31am] tcunning: no [11:31am] jfaath: are we still going to support axis? [11:31am] tcunning: i think so [11:31am] tcunning: i just don't think we should combine the modules [11:32am] KurtStam: what is the against using a profile? [11:32am] tcunning: i think separate modules is cleaner [11:32am] KurtStam: but that means we have jsp etc in 2 places [11:33am] tcunning: we'll have two giant profiles with mlutiple plugins [11:33am] KurtStam: it should only be a compile/package options? [11:33am] tcunning: if we want a shared war target that both inherit from that'd be fine for me [11:34am] KurtStam: k, let's do that, then we can always see if it's worth it to do a profile [11:34am] tcunning: plus if we add other implementations later it'd be easier if they are separate [11:34am] KurtStam: at least we have no duplication then [11:36am] KurtStam: should I create a 3.1 version so we can add stuff like replication? [11:36am] KurtStam: and track what we think about replication anyway [11:37am] jfaath: sounds fine [11:37am] tcunning: i thought we agreed not to do replication?is this just sort of as a cover? [11:38am] KurtStam: well I think we decided that for now we are not going to it. but we might offer an alternative down the road [11:39am] tcunning: sure, we can always boot on down to 3.2 or 3.3 [11:40am] jfaath: hopefully, juddi will gain some traction in the community and we can get some help [11:41am] KurtStam: right [11:41am] KurtStam: I added it [11:41am] KurtStam: feel free to add other stuff to 3.1 when you think of it [11:41am] KurtStam: so should we aim for 3.0 end of june? [11:42am] jfaath: that'd be cool [11:43am] KurtStam: cool [11:43am] KurtStam: question for you guys [11:44am] KurtStam: we register our InquiryService as an endpoint in jUDDI [11:44am] KurtStam: I think this is per
Re: [jira] Commented: (WSCOMMONS-417) Clarify the status of the JavaMail dependency
Andreas Do you know if its safe to exclude Geronimo JARs from Axiom-api .. its becoming a transitive dependency? thanks asankha
Re: JUDDI-206 status
Jeff, If you still want JUDDI-206, please take it. I'm still blocked by JUDDI-217 (I can't debug any tests). I logged a bunch of bugs - two tests are failing for me w/hibernate config, 18/19 tests fail for me w/openjpa, and Eclipse doesn't work debugging the tests - what we have in the DevGuide for this just doesn't work.The Eclipse thing might work for Kurt because of the maven plugin, but I installed the maven plugin and can't get it to work and I'm not real sure we should require people to use the Eclipse maven plugin. --Tom Jeff Faath wrote: Tom, not sure what that error could be. Most of the other tests need to get authInfo and they work fine. I would take a look at those. Also took a quick look at your code. I would focus more on making sure the input is correct before you try to put stuff in the database (ie. validation) - basically take a step-wise approach. Why try writing code to save to the database when you haven't got a grasp of exactly what you need to put in there? Additionally, per the spec, a non-blank key doesn't necessarily mean the user is renewing a subscription. They could be proposing their own key for the subscription therefore the same rules must be applied for keys as with saving the standard entities. A quick note, Kurt and I discussed a little bit and I posted a message last week I believe about saving the subscription filter as an XML blob. Fortunately, after reading the spec, I discovered that only one filter structure is allowed which makes life easier. Just giving you a heads up. I'm going to be tied up for a few days, but that should be ample time to finish this portion of the API, depending of course on how much time you can spend on it. Why don't you continue working on it and we can touch base a few days from now. -JF -Original Message- From: Tom Cunningham [mailto:tcunn...@redhat.com] Sent: Wednesday, March 25, 2009 1:00 AM To: juddi-dev@ws.apache.org Subject: Re: JUDDI-206 status I'm stuck on trying to run API_080_SubscriberSaveTest within eclipse. I'm getting the following : Initial entityManagerFactory creation failed:java.lang.NoSuchMethodError: org.hibernate.cfg.SecondPass.doSecondPass(Ljava/util/Map;Ljava/util/Map;)V seems like some sort of hibernate conflict and it happens as soon as I hit this line in TckSubscriber.saveSubscriber() : String authInfo = TckSecurity.getAuthToken(security, root, ); Any ideas? Jeff, I checked in what I have, it's not much, if you need to take this bug go ahead, I'll go fish for another. Jeff Faath wrote: Tom, Curious as to where you're at with saving subscriptions. I'm looking into the subscription results portion and I can only go so far without having saved subscriptions to work with. If you don't think you can get it done within a week, let me know. I may have to just get it done. Thanks, JF
[jira] Commented: (WSCOMMONS-417) Clarify the status of the JavaMail dependency
[ https://issues.apache.org/jira/browse/WSCOMMONS-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12689452#action_12689452 ] Asankha C. Perera commented on WSCOMMONS-417: - I think the problem occurred since earlier versions of Sun Javamail or Activation were not available on M2 repos probably due to some licensing issues. Now Axis2 poms have a dependency on both Geronimo and Sun Javamail, which creates problems [1], and confusion I would like the Axis2 mail transport to depend on Sun Javamail v1.4.2 (which is the latest as of now and available on M2 Repos), and exclude the use of geronimo JARs altogether for the Commons Transports 1.0 release [1] http://forums.sun.com/thread.jspa?messageID=10657165 Clarify the status of the JavaMail dependency - Key: WSCOMMONS-417 URL: https://issues.apache.org/jira/browse/WSCOMMONS-417 Project: WS-Commons Issue Type: Improvement Components: AXIOM Reporter: Andreas Veithen Priority: Minor Fix For: Axiom 1.2.9 axiom-api depends on Geronimo's JavaMail implementation. On the other hand, in axiom-tests this dependency is excluded and replaced by Sun's JavaMail dependency (same situation in Axis2). If Axiom doesn't work properly with Geronimo's JavaMail implementation, we should either make sure that the bugs in Geronimo get fixed or change the dependencies of axiom-api. If Axiom works properly with Geronimo's JavaMail implementation, then it doesn't make sense to run the tests against a different JavaMail implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: JUDDI-206 status
Tom, not sure what that error could be. Most of the other tests need to get authInfo and they work fine. I would take a look at those. Also took a quick look at your code. I would focus more on making sure the input is correct before you try to put stuff in the database (ie. validation) - basically take a step-wise approach. Why try writing code to save to the database when you haven't got a grasp of exactly what you need to put in there? Additionally, per the spec, a non-blank key doesn't necessarily mean the user is renewing a subscription. They could be proposing their own key for the subscription therefore the same rules must be applied for keys as with saving the standard entities. A quick note, Kurt and I discussed a little bit and I posted a message last week I believe about saving the subscription filter as an XML blob. Fortunately, after reading the spec, I discovered that only one filter structure is allowed which makes life easier. Just giving you a heads up. I'm going to be tied up for a few days, but that should be ample time to finish this portion of the API, depending of course on how much time you can spend on it. Why don't you continue working on it and we can touch base a few days from now. -JF -Original Message- From: Tom Cunningham [mailto:tcunn...@redhat.com] Sent: Wednesday, March 25, 2009 1:00 AM To: juddi-dev@ws.apache.org Subject: Re: JUDDI-206 status I'm stuck on trying to run API_080_SubscriberSaveTest within eclipse. I'm getting the following : Initial entityManagerFactory creation failed:java.lang.NoSuchMethodError: org.hibernate.cfg.SecondPass.doSecondPass(Ljava/util/Map;Ljava/util/Map;)V seems like some sort of hibernate conflict and it happens as soon as I hit this line in TckSubscriber.saveSubscriber() : String authInfo = TckSecurity.getAuthToken(security, root, ); Any ideas? Jeff, I checked in what I have, it's not much, if you need to take this bug go ahead, I'll go fish for another. Jeff Faath wrote: Tom, Curious as to where you're at with saving subscriptions. I'm looking into the subscription results portion and I can only go so far without having saved subscriptions to work with. If you don't think you can get it done within a week, let me know. I may have to just get it done. Thanks, JF
JUDDI-206 status
Tom, Curious as to where you're at with saving subscriptions. I'm looking into the subscription results portion and I can only go so far without having saved subscriptions to work with. If you don't think you can get it done within a week, let me know. I may have to just get it done. Thanks, JF
status meeting March 18, 2009
KurtStam_: hey guys [1:58pm] jfaath: howdy [1:58pm] tcunning: hiya [1:58pm] KurtStam_: Did my file upload work? [1:58pm] KurtStam_: just curious.. [1:58pm] jfaath: no [1:58pm] jfaath: failed connection [1:58pm] tcunning: yeah, failed for me too [2:00pm] KurtStam_: k emailed it now too [2:00pm] [1]Troy joined the chat room. [2:00pm] KurtStam_: it is a screenshot of a the UDDI Browser Portlet Proof of Concept [2:01pm] [1]Troy is now known as TroyHaaland. [2:01pm] tcunning: is it the one you sent around? [2:01pm] KurtStam_: anyway, want to go around for status update? [2:01pm] jfaath: cool [2:01pm] KurtStam_: yeah but now actually running in a portal [2:01pm] tcunning: cool [2:02pm] KurtStam_: so after alfa I worked on getting openjpa to work, which is working now [2:02pm] KurtStam_: the build machine is still failing, but I'll get to that.. [2:03pm] jfaath: who's been working on the portal? [2:03pm] KurtStam_: also I cleaned up some other small issues I can't remember now but the list of jiras got pretty short for 3.0 beta [2:03pm] jfaath: do we have a new resource? [2:03pm] KurtStam_: I have been working on it. I have a standing offer from a UI guy [2:03pm] KurtStam_: so I'm setting up the framework, so he can go to town [2:04pm] tcunning: nice! [2:04pm] KurtStam_: I picked GWT b/c it is simple, and b/c I don't need persistence, just UI [2:04pm] KurtStam_: GWT is apache2 licensed so we should be good there. [2:05pm] jfaath: gotcha [2:05pm] KurtStam_: I'm thinking of 3 portlets; browse, search and register [2:05pm] KurtStam_: and I just just for it to work end2end; [2:05pm] KurtStam_: browser - GTW tomcat - jUDDI tomcat WS [2:06pm] KurtStam_: browser looking at the Pluto Portal [2:06pm] KurtStam_: I'm thinking that portlets are nice so people can embed it in their apps [2:07pm] KurtStam_: also I looked at he 3 client side API that are remaining [2:07pm] KurtStam_: turns out all of them are optional [2:07pm] KurtStam_: but we prob want to implement the subscription client side. [2:07pm] jfaath: did you get a chance to read chapter 7? [2:07pm] KurtStam_: so we can test that subscriptions work [2:07pm] jfaath: i'd like a second opinion on my assessment [2:08pm] KurtStam_: no sorry, not yet. [2:08pm] KurtStam_: I'm kinda done woth my status want to jump in? [2:08pm] jfaath: sure [2:08pm] jfaath: I was ready to work on replication, until I read through chapter 7 [2:09pm] jfaath: than when searching for more information on the net, i found Anne's old post about it being an ugly rat's nest [2:09pm] jfaath: and i couldn't agree more [2:09pm] KurtStam_: yeah I remember that [2:09pm] jfaath: trying to do load balancing and failover with XML messaging is ugly, and that's putting it nicely [2:10pm] jfaath: chapter 8 talks about transferring data between registries in a different context [2:10pm] jfaath: with root and affiliates [2:10pm] KurtStam_: sounds like ESB type of functionality [2:10pm] jfaath: and it focuses on the subscription functionality to achieve this [2:11pm] jfaath: so, i think that should be our next api focus [2:11pm] jfaath: i'm ready to put a couple of weeks of hard labor into it [2:11pm] KurtStam_: cool. [2:11pm] KurtStam_: it seems to me that we need subscription more then anything else [2:11pm] tcunning: i am too.SCOUT-57 i should be checking in today and then i'm done there. [2:12pm] KurtStam_: so it'd be great to divide and conquor [2:12pm] TroyHaaland: so we are really no further with Subscription then we were in December? [2:12pm] jfaath: yea, i meant to go through and JIRA it up, but have been tied down with other things [2:13pm] KurtStam_: Hi Troy, how are you? [2:13pm] TroyHaaland: good, hopeful that we were going to be talking about the Beta release [2:14pm] jfaath: that's a good point, what are the milestones for beta? [2:14pm] KurtStam_: yeah I added tag in jira [2:14pm] jfaath: assuming that kurt reads chapter 7 and concludes the same thing [2:14pm] KurtStam_: and assigned taks [2:14pm] TroyHaaland: was also wondering about the Alpha release and any feedback that may have come back [2:14pm] KurtStam_: I will read chapter 7..soon [2:14pm] KurtStam_: but I'm thinking we can release beta without it, [2:15pm] KurtStam_: http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=10401fixfor=12313630 [2:15pm] KurtStam_: we have 9 tasks [2:15pm] KurtStam_: but subscription needs to be broken out [2:15pm] jfaath: yea, i'll get to that, perhaps today [2:15pm] tcunning: want to break them out now? [2:16pm] KurtStam_: sure [2:16pm] KurtStam_: got some suggestions? [2:16pm] tcunning: registration seems like a part [2:16pm] tcunning: notification seems like a part [2:17pm] tcunning: the subscription model itself (durations / point in time / coverage / etc) seems like something [2:17pm] tcunning: registration and notification probably could be drilled down further [2:18pm
Re: status meeting this wed?
Sounds fine to me. Let's shoot for 2 pm EST. irc.freenode.net #juddi. See you there. Jeff Faath wrote: I can do Wednesday, but I can only make it in the afternoon. I might be able to do 1pm EST, but 2pm EST is probably safer. -Original Message- From: Kurt T Stam [mailto:kurt.s...@gmail.com] Sent: Monday, March 16, 2009 10:19 AM To: juddi-dev@ws.apache.org Subject: status meeting this wed? Hey guys, Want to do a status meeting this Wednesday March 18? Does 11 am EST work for everyone? --Kurt
status meeting this wed?
Hey guys, Want to do a status meeting this Wednesday March 18? Does 11 am EST work for everyone? --Kurt
status update on jUDDI tomorrow wed 2/11 - 11 am
irc.freenode.org #juddi See you there! --Kurt
Status report on XmlSchema 2.0
So far, I've accomplished the following:
1) Consistent property names. 'name' is now always a name relative to
the containing schema. 'QName' is now always the name relative to the
schema collection: {tns}name. 'wiredName' is the name for use on the
wire, as influenced by 'form' and 'ref'.
2) Common classes to manage named items.
3) Removal of things that were never implemented at all, such as
'compilation' and Java types.
4) Removal of obsolete 'two-argument toStrings' that generated incorrect XML.
Next up is to change to using Java parameterized collections directly,
removing XmlSchemaObjectCollection.
I'll publish a snapshot when I have that done.
[jira] Assigned: (AXIS2C-1282) 1)reads all http headers from the request and adds them to the msg_ctx, they were missing. 2)Allows custumized http status and http headers for rest requests(don't affec
[
https://issues.apache.org/jira/browse/AXIS2C-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nandika Jayawardana reassigned AXIS2C-1282:
---
Assignee: Nandika Jayawardana
1)reads all http headers from the request and adds them to the msg_ctx, they
were missing. 2)Allows custumized http status and http headers for rest
requests(don't affect soap requests). 3) Adds missing http forbidden
definitions
-
Key: AXIS2C-1282
URL: https://issues.apache.org/jira/browse/AXIS2C-1282
Project: Axis2-C
Issue Type: Improvement
Components: httpd module
Affects Versions: 1.5.0
Reporter: Luis Bilo
Assignee: Nandika Jayawardana
Priority: Minor
Fix For: 1.6.0
Attachments: apache_http_headers_and_rest_enhancement.diff,
http_forbidden.diff
Original Estimate: 1h
Remaining Estimate: 1h
#1 Adds http headers to msg_ctx when using axis2/c module for apache
I noticed however this functionality were only implemented for the
standalone server. When using the axis module for apache http headers
were not added to the msg_ctx so they were not accessible @ the inflow
handlers level for instance.
#2 Adds forbidden definition tags for http forbidden code which is
missing in standard release
#define AXIS2_HTTP_RESPONSE_FORBIDDEN_CODE_VAL 403
#define AXIS2_HTTP_RESPONSE_HTTP_FORBIDDEN_CODE_NAME Forbidden
#define AXIS2_HTTP_RESPONSE_HTTP_FORBIDDEN 403 Forbidden
#3 Adds support to specify feedback for REST requests, when a module
failure occurs.
This issue is related to the difference between soap and rest
requests. When an inflow handler fails two things can happen depending
on the request type:
- For SOAP requests, the inflow handler chain is broken, and all the
outflow fault handlers are invoked. The response soap envelope
response containing a default fault is built by axis in between these
phases, so we can edit the fault accordingly @ the outflow fault
handlers.
- For REST requests, the inflow handler chain is also broken, but the
outflow fault handlers are not invoked. This is not a problem, and is
probably intended, since unlike soap there is no need to create a soap
envelope. The thing is when this happens it always returned 202
ACCEPTED, which is not enough to provide any feedback to the user who
made the request.
@ the inflow handler is now possible to set the desired status code
desired for the response, extra http headers, and/or http content. It
was already possible before, changes just weren't propagated to the
actual response.
inflow handler example with the patch:
..
// For REST requests
if (doing_rest AXIS2_FAILURE == result)
{
axis2_msg_ctx_set_status_code(msg_ctx, env,
AXIS2_HTTP_RESPONSE_HTTP_UNAUTHORIZED_CODE_VAL);
AXIS2_LOG_ERROR(env-log, AXIS2_LOG_SI,
[Inflow][authentication_in]
HTTP status code unauthorized);
axutil_stream_t *stream = axutil_stream_create_basic(env);
axis2_char_t *http_content = axutil_strcat(env,
AXIS2_HTTP_RESPONSE_HTTP_UNAUTHORIZED, \n, NULL);
axutil_stream_write(stream, env, http_content,
axutil_strlen(http_content));
axis2_msg_ctx_set_transport_out_stream(msg_ctx, env, stream);
}
return result;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AXIS2C-1282) 1)reads all http headers from the request and adds them to the msg_ctx, they were missing. 2)Allows custumized http status and http headers for rest requests(don't affect
[
https://issues.apache.org/jira/browse/AXIS2C-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manjula Peiris updated AXIS2C-1282:
---
Fix Version/s: (was: 1.5.0)
1.6.0
1)reads all http headers from the request and adds them to the msg_ctx, they
were missing. 2)Allows custumized http status and http headers for rest
requests(don't affect soap requests). 3) Adds missing http forbidden
definitions
-
Key: AXIS2C-1282
URL: https://issues.apache.org/jira/browse/AXIS2C-1282
Project: Axis2-C
Issue Type: Improvement
Components: httpd module
Affects Versions: 1.5.0
Reporter: Luis Bilo
Priority: Minor
Fix For: 1.6.0
Attachments: apache_http_headers_and_rest_enhancement.diff,
http_forbidden.diff
Original Estimate: 1h
Remaining Estimate: 1h
#1 Adds http headers to msg_ctx when using axis2/c module for apache
I noticed however this functionality were only implemented for the
standalone server. When using the axis module for apache http headers
were not added to the msg_ctx so they were not accessible @ the inflow
handlers level for instance.
#2 Adds forbidden definition tags for http forbidden code which is
missing in standard release
#define AXIS2_HTTP_RESPONSE_FORBIDDEN_CODE_VAL 403
#define AXIS2_HTTP_RESPONSE_HTTP_FORBIDDEN_CODE_NAME Forbidden
#define AXIS2_HTTP_RESPONSE_HTTP_FORBIDDEN 403 Forbidden
#3 Adds support to specify feedback for REST requests, when a module
failure occurs.
This issue is related to the difference between soap and rest
requests. When an inflow handler fails two things can happen depending
on the request type:
- For SOAP requests, the inflow handler chain is broken, and all the
outflow fault handlers are invoked. The response soap envelope
response containing a default fault is built by axis in between these
phases, so we can edit the fault accordingly @ the outflow fault
handlers.
- For REST requests, the inflow handler chain is also broken, but the
outflow fault handlers are not invoked. This is not a problem, and is
probably intended, since unlike soap there is no need to create a soap
envelope. The thing is when this happens it always returned 202
ACCEPTED, which is not enough to provide any feedback to the user who
made the request.
@ the inflow handler is now possible to set the desired status code
desired for the response, extra http headers, and/or http content. It
was already possible before, changes just weren't propagated to the
actual response.
inflow handler example with the patch:
..
// For REST requests
if (doing_rest AXIS2_FAILURE == result)
{
axis2_msg_ctx_set_status_code(msg_ctx, env,
AXIS2_HTTP_RESPONSE_HTTP_UNAUTHORIZED_CODE_VAL);
AXIS2_LOG_ERROR(env-log, AXIS2_LOG_SI,
[Inflow][authentication_in]
HTTP status code unauthorized);
axutil_stream_t *stream = axutil_stream_create_basic(env);
axis2_char_t *http_content = axutil_strcat(env,
AXIS2_HTTP_RESPONSE_HTTP_UNAUTHORIZED, \n, NULL);
axutil_stream_write(stream, env, http_content,
axutil_strlen(http_content));
axis2_msg_ctx_set_transport_out_stream(msg_ctx, env, stream);
}
return result;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (WSCOMMONS-417) Clarify the status of the JavaMail dependency
Clarify the status of the JavaMail dependency - Key: WSCOMMONS-417 URL: https://issues.apache.org/jira/browse/WSCOMMONS-417 Project: WS-Commons Issue Type: Improvement Components: AXIOM Reporter: Andreas Veithen Priority: Minor Fix For: Axiom 1.2.9 axiom-api depends on Geronimo's JavaMail implementation. On the other hand, in axiom-tests this dependency is excluded and replaced by Sun's JavaMail dependency (same situation in Axis2). If Axiom doesn't work properly with Geronimo's JavaMail implementation, we should either make sure that the bugs in Geronimo get fixed or change the dependencies of axiom-api. If Axiom works properly with Geronimo's JavaMail implementation, then it doesn't make sense to run the tests against a different JavaMail implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WSCOMMONS-417) Clarify the status of the JavaMail dependency
[ https://issues.apache.org/jira/browse/WSCOMMONS-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12657768#action_12657768 ] Thilina Gunarathne commented on WSCOMMONS-417: -- AFAIK Axis2 ships sun mail activation implementations. A quick look at Axis2 1.4.1 confirmed this. We got rid of the gerenimo-impl's when Sun changed mail activation to a favorable license terms. I do not know about the current situation, but back then Gerenimo impl's were not complete. IIRC it was mostly the activation, where they did not support some content-type bindings. +1 for switching completely to Sun mail+activation... Clarify the status of the JavaMail dependency - Key: WSCOMMONS-417 URL: https://issues.apache.org/jira/browse/WSCOMMONS-417 Project: WS-Commons Issue Type: Improvement Components: AXIOM Reporter: Andreas Veithen Priority: Minor Fix For: Axiom 1.2.9 axiom-api depends on Geronimo's JavaMail implementation. On the other hand, in axiom-tests this dependency is excluded and replaced by Sun's JavaMail dependency (same situation in Axis2). If Axiom doesn't work properly with Geronimo's JavaMail implementation, we should either make sure that the bugs in Geronimo get fixed or change the dependencies of axiom-api. If Axiom works properly with Geronimo's JavaMail implementation, then it doesn't make sense to run the tests against a different JavaMail implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WSCOMMONS-417) Clarify the status of the JavaMail dependency
[ https://issues.apache.org/jira/browse/WSCOMMONS-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12657796#action_12657796 ] Jarek Gawor commented on WSCOMMONS-417: --- (As a Geronimo person) I think it would be good to use Geronimo jars over Sun. The Geronimo JavaMail implementation is much better now and we are pretty good about fixing bugs in it. Clarify the status of the JavaMail dependency - Key: WSCOMMONS-417 URL: https://issues.apache.org/jira/browse/WSCOMMONS-417 Project: WS-Commons Issue Type: Improvement Components: AXIOM Reporter: Andreas Veithen Priority: Minor Fix For: Axiom 1.2.9 axiom-api depends on Geronimo's JavaMail implementation. On the other hand, in axiom-tests this dependency is excluded and replaced by Sun's JavaMail dependency (same situation in Axis2). If Axiom doesn't work properly with Geronimo's JavaMail implementation, we should either make sure that the bugs in Geronimo get fixed or change the dependencies of axiom-api. If Axiom works properly with Geronimo's JavaMail implementation, then it doesn't make sense to run the tests against a different JavaMail implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WSCOMMONS-417) Clarify the status of the JavaMail dependency
[ https://issues.apache.org/jira/browse/WSCOMMONS-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12657803#action_12657803 ] Andreas Veithen commented on WSCOMMONS-417: --- Jarek, I still have two open issues with Geronimo JavaMail: GERONIMO-4352 and GERONIMO-4421. The first one causes failures in the mail transport (if we move to Geronimo, we should make sure that the mail transport works reasonably well with it) and the second will potentially cause an issue for Axiom itself. Maybe you can push a bit so that they get solved? Clarify the status of the JavaMail dependency - Key: WSCOMMONS-417 URL: https://issues.apache.org/jira/browse/WSCOMMONS-417 Project: WS-Commons Issue Type: Improvement Components: AXIOM Reporter: Andreas Veithen Priority: Minor Fix For: Axiom 1.2.9 axiom-api depends on Geronimo's JavaMail implementation. On the other hand, in axiom-tests this dependency is excluded and replaced by Sun's JavaMail dependency (same situation in Axis2). If Axiom doesn't work properly with Geronimo's JavaMail implementation, we should either make sure that the bugs in Geronimo get fixed or change the dependencies of axiom-api. If Axiom works properly with Geronimo's JavaMail implementation, then it doesn't make sense to run the tests against a different JavaMail implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AXIS2-4146) HTTP status code 400 is changed to 500
HTTP status code 400 is changed to 500 -- Key: AXIS2-4146 URL: https://issues.apache.org/jira/browse/AXIS2-4146 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: transports Affects Versions: 1.4.1 Reporter: Markus Bussemer After the fix for AXIS2-3887 in CommonsHTTPTransportSender the HTTP status code is always set to 500 for a response with a fault, even if the status code has been explicitly set to 400 (or another value) before. -- 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]
Re: vote committer status Dave Parsons and Sara Mitchel
+1 Chamikara Paul Fremantle wrote: +1 Paul On Tue, Nov 11, 2008 at 6:56 PM, Andrew K Gatford [EMAIL PROTECTED] wrote: +1 Andrew Gatford Technical Project Lead Websphere ESB Foundation Technologies Hursley MP211 IBM United Kingdom Laboratories, Hursley Park, Winchester, SO21 2JN Telephone : Internal (7) 245743 External 01962 815743 Internet : [EMAIL PROTECTED] From: Thomas McKiernan/UK/[EMAIL PROTECTED] To: sandesha-dev@ws.apache.org Date: 11/11/2008 16:13 Subject: vote committer status Dave Parsons and Sara Mitchel Hi all, I would like to propose that David Parsons and Sara Mitchell get made apache committers for Sandesha2 Java. Between them they have raised and resolved many JIRA issues since the May time frame. Many thanks, Thomas -- Thomas McKiernan WebSphere Messaging Development, IBM United Kingdom Limited Internal Phone: 248241 External Phone: +44 (0)1962 818241 Mobile: +44 (0)789 1737497 Email: [EMAIL PROTECTED] Mail Point 211, IBM, Hursley Park, Winchester, Hampshire, England, SO21 2JN Caminante, no hay camino Se hace camino al andar. (Walker, there is no path; the path is made by walking.) Antonio Machado Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: vote committer status Dave Parsons and Sara Mitchel
+1 Amila. On 11/12/08, Paul Fremantle [EMAIL PROTECTED] wrote: +1 Paul On Tue, Nov 11, 2008 at 6:56 PM, Andrew K Gatford [EMAIL PROTECTED] wrote: +1 Andrew Gatford Technical Project Lead Websphere ESB Foundation Technologies Hursley MP211 IBM United Kingdom Laboratories, Hursley Park, Winchester, SO21 2JN Telephone : Internal (7) 245743 External 01962 815743 Internet : [EMAIL PROTECTED] From: Thomas McKiernan/UK/[EMAIL PROTECTED] To: sandesha-dev@ws.apache.org Date: 11/11/2008 16:13 Subject: vote committer status Dave Parsons and Sara Mitchel Hi all, I would like to propose that David Parsons and Sara Mitchell get made apache committers for Sandesha2 Java. Between them they have raised and resolved many JIRA issues since the May time frame. Many thanks, Thomas -- Thomas McKiernan WebSphere Messaging Development, IBM United Kingdom Limited Internal Phone: 248241 External Phone: +44 (0)1962 818241 Mobile: +44 (0)789 1737497 Email: [EMAIL PROTECTED] Mail Point 211, IBM, Hursley Park, Winchester, Hampshire, England, SO21 2JN Caminante, no hay camino Se hace camino al andar. (Walker, there is no path; the path is made by walking.) Antonio Machado Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paul Fremantle Co-Founder and CTO, WSO2 Apache Synapse PMC Chair OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] Oxygenating the Web Service Platform, www.wso2.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Amila Suriarachchi WSO2 Inc. blog: http://amilachinthaka.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
vote committer status Dave Parsons and Sara Mitchel
Hi all, I would like to propose that David Parsons and Sara Mitchell get made apache committers for Sandesha2 Java. Between them they have raised and resolved many JIRA issues since the May time frame. Many thanks, Thomas -- Thomas McKiernan WebSphere Messaging Development, IBM United Kingdom Limited Internal Phone: 248241 External Phone: +44 (0)1962 818241 Mobile: +44 (0)789 1737497 Email: [EMAIL PROTECTED] Mail Point 211, IBM, Hursley Park, Winchester, Hampshire, England, SO21 2JN Caminante, no hay camino Se hace camino al andar. (Walker, there is no path; the path is made by walking.) Antonio Machado Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: vote committer status Dave Parsons and Sara Mitchel
+1 Andrew Gatford Technical Project Lead Websphere ESB Foundation Technologies Hursley MP211 IBM United Kingdom Laboratories, Hursley Park, Winchester, SO21 2JN Telephone : Internal (7) 245743 External 01962 815743 Internet : [EMAIL PROTECTED] From: Thomas McKiernan/UK/[EMAIL PROTECTED] To: sandesha-dev@ws.apache.org Date: 11/11/2008 16:13 Subject: vote committer status Dave Parsons and Sara Mitchel Hi all, I would like to propose that David Parsons and Sara Mitchell get made apache committers for Sandesha2 Java. Between them they have raised and resolved many JIRA issues since the May time frame. Many thanks, Thomas -- Thomas McKiernan WebSphere Messaging Development, IBM United Kingdom Limited Internal Phone: 248241 External Phone: +44 (0)1962 818241 Mobile: +44 (0)789 1737497 Email: [EMAIL PROTECTED] Mail Point 211, IBM, Hursley Park, Winchester, Hampshire, England, SO21 2JN Caminante, no hay camino Se hace camino al andar. (Walker, there is no path; the path is made by walking.) Antonio Machado Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: vote committer status Dave Parsons and Sara Mitchel
+1 Paul On Tue, Nov 11, 2008 at 6:56 PM, Andrew K Gatford [EMAIL PROTECTED] wrote: +1 Andrew Gatford Technical Project Lead Websphere ESB Foundation Technologies Hursley MP211 IBM United Kingdom Laboratories, Hursley Park, Winchester, SO21 2JN Telephone : Internal (7) 245743 External 01962 815743 Internet : [EMAIL PROTECTED] From: Thomas McKiernan/UK/[EMAIL PROTECTED] To: sandesha-dev@ws.apache.org Date: 11/11/2008 16:13 Subject: vote committer status Dave Parsons and Sara Mitchel Hi all, I would like to propose that David Parsons and Sara Mitchell get made apache committers for Sandesha2 Java. Between them they have raised and resolved many JIRA issues since the May time frame. Many thanks, Thomas -- Thomas McKiernan WebSphere Messaging Development, IBM United Kingdom Limited Internal Phone: 248241 External Phone: +44 (0)1962 818241 Mobile: +44 (0)789 1737497 Email: [EMAIL PROTECTED] Mail Point 211, IBM, Hursley Park, Winchester, Hampshire, England, SO21 2JN Caminante, no hay camino Se hace camino al andar. (Walker, there is no path; the path is made by walking.) Antonio Machado Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paul Fremantle Co-Founder and CTO, WSO2 Apache Synapse PMC Chair OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] Oxygenating the Web Service Platform, www.wso2.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-1282) 1)reads all http headers from the request and adds them to the msg_ctx, they were missing. 2)Allows custumized http status and http headers for rest requests(don't affect
1)reads all http headers from the request and adds them to the msg_ctx, they
were missing. 2)Allows custumized http status and http headers for rest
requests(don't affect soap requests). 3) Adds missing http forbidden definitions
-
Key: AXIS2C-1282
URL: https://issues.apache.org/jira/browse/AXIS2C-1282
Project: Axis2-C
Issue Type: Improvement
Components: httpd module
Affects Versions: 1.5.0
Reporter: Luis Bilo
Priority: Minor
Fix For: 1.5.0
#1 Adds http headers to msg_ctx when using axis2/c module for apache
I noticed however this functionality were only implemented for the
standalone server. When using the axis module for apache http headers
were not added to the msg_ctx so they were not accessible @ the inflow
handlers level for instance.
#2 Adds forbidden definition tags for http forbidden code which is
missing in standard release
#define AXIS2_HTTP_RESPONSE_FORBIDDEN_CODE_VAL 403
#define AXIS2_HTTP_RESPONSE_HTTP_FORBIDDEN_CODE_NAME Forbidden
#define AXIS2_HTTP_RESPONSE_HTTP_FORBIDDEN 403 Forbidden
#3 Adds support to specify feedback for REST requests, when a module
failure occurs.
This issue is related to the difference between soap and rest
requests. When an inflow handler fails two things can happen depending
on the request type:
- For SOAP requests, the inflow handler chain is broken, and all the
outflow fault handlers are invoked. The response soap envelope
response containing a default fault is built by axis in between these
phases, so we can edit the fault accordingly @ the outflow fault
handlers.
- For REST requests, the inflow handler chain is also broken, but the
outflow fault handlers are not invoked. This is not a problem, and is
probably intended, since unlike soap there is no need to create a soap
envelope. The thing is when this happens it always returned 202
ACCEPTED, which is not enough to provide any feedback to the user who
made the request.
@ the inflow handler is now possible to set the desired status code
desired for the response, extra http headers, and/or http content. It
was already possible before, changes just weren't propagated to the
actual response.
inflow handler example with the patch:
..
// For REST requests
if (doing_rest AXIS2_FAILURE == result)
{
axis2_msg_ctx_set_status_code(msg_ctx, env,
AXIS2_HTTP_RESPONSE_HTTP_UNAUTHORIZED_CODE_VAL);
AXIS2_LOG_ERROR(env-log, AXIS2_LOG_SI,
[Inflow][authentication_in]
HTTP status code unauthorized);
axutil_stream_t *stream = axutil_stream_create_basic(env);
axis2_char_t *http_content = axutil_strcat(env,
AXIS2_HTTP_RESPONSE_HTTP_UNAUTHORIZED, \n, NULL);
axutil_stream_write(stream, env, http_content,
axutil_strlen(http_content));
axis2_msg_ctx_set_transport_out_stream(msg_ctx, env, stream);
}
return result;
}
--
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: (AXIS2C-1282) 1)reads all http headers from the request and adds them to the msg_ctx, they were missing. 2)Allows custumized http status and http headers for rest requests(don't affect
[
https://issues.apache.org/jira/browse/AXIS2C-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luis Bilo updated AXIS2C-1282:
--
Attachment: http_forbidden.diff
apache_http_headers_and_rest_enhancement.diff
Proposed patches.
1)reads all http headers from the request and adds them to the msg_ctx, they
were missing. 2)Allows custumized http status and http headers for rest
requests(don't affect soap requests). 3) Adds missing http forbidden
definitions
-
Key: AXIS2C-1282
URL: https://issues.apache.org/jira/browse/AXIS2C-1282
Project: Axis2-C
Issue Type: Improvement
Components: httpd module
Affects Versions: 1.5.0
Reporter: Luis Bilo
Priority: Minor
Fix For: 1.5.0
Attachments: apache_http_headers_and_rest_enhancement.diff,
http_forbidden.diff
Original Estimate: 1h
Remaining Estimate: 1h
#1 Adds http headers to msg_ctx when using axis2/c module for apache
I noticed however this functionality were only implemented for the
standalone server. When using the axis module for apache http headers
were not added to the msg_ctx so they were not accessible @ the inflow
handlers level for instance.
#2 Adds forbidden definition tags for http forbidden code which is
missing in standard release
#define AXIS2_HTTP_RESPONSE_FORBIDDEN_CODE_VAL 403
#define AXIS2_HTTP_RESPONSE_HTTP_FORBIDDEN_CODE_NAME Forbidden
#define AXIS2_HTTP_RESPONSE_HTTP_FORBIDDEN 403 Forbidden
#3 Adds support to specify feedback for REST requests, when a module
failure occurs.
This issue is related to the difference between soap and rest
requests. When an inflow handler fails two things can happen depending
on the request type:
- For SOAP requests, the inflow handler chain is broken, and all the
outflow fault handlers are invoked. The response soap envelope
response containing a default fault is built by axis in between these
phases, so we can edit the fault accordingly @ the outflow fault
handlers.
- For REST requests, the inflow handler chain is also broken, but the
outflow fault handlers are not invoked. This is not a problem, and is
probably intended, since unlike soap there is no need to create a soap
envelope. The thing is when this happens it always returned 202
ACCEPTED, which is not enough to provide any feedback to the user who
made the request.
@ the inflow handler is now possible to set the desired status code
desired for the response, extra http headers, and/or http content. It
was already possible before, changes just weren't propagated to the
actual response.
inflow handler example with the patch:
..
// For REST requests
if (doing_rest AXIS2_FAILURE == result)
{
axis2_msg_ctx_set_status_code(msg_ctx, env,
AXIS2_HTTP_RESPONSE_HTTP_UNAUTHORIZED_CODE_VAL);
AXIS2_LOG_ERROR(env-log, AXIS2_LOG_SI,
[Inflow][authentication_in]
HTTP status code unauthorized);
axutil_stream_t *stream = axutil_stream_create_basic(env);
axis2_char_t *http_content = axutil_strcat(env,
AXIS2_HTTP_RESPONSE_HTTP_UNAUTHORIZED, \n, NULL);
axutil_stream_write(stream, env, http_content,
axutil_strlen(http_content));
axis2_msg_ctx_set_transport_out_stream(msg_ctx, env, stream);
}
return result;
}
--
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]
jUDDI v3 status meeting Oct 29, 2008
On the call: Jeff Faath, Tom Cunningham, Kurt Stam i. Jeff Faath Jeff has been very active and worked on implementing search functionality (144) He is processing with 144, and will look at the errorHandling framework (138), which is a prerequisite to validation (140) ii. Tom Cunnningham Worked on getting the unit test framework going (137) and is in the process of adding Derby as the default persistence store. Tom will proceed with this and also check if we can test the WS front-end with the framework, and also look at adding the persistence manager (132) iii. Kurt Stam Kurt worked on 135, and will finish this before updating the persistence layer 142 and 145. Marcos Vinicius Marcos since you missed the call, can you reply to this email with your status? I think you worked on table prefix functionality (144). Can you take a look at 147 and tell me if this is something you can help out with? Next status meeting is in 2 weeks Nov 12. Our goal for next meeting is to have a rough end to end jUDDI v3 :). Who's bringing the beer? Thx! --Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Agenda of the Woden Status Telecon, 2008-10-07
As a reminder, the Woden status telecon will be held at 9am EST and are open to all. See [1] for call and IRC information. [1] http://ws.apache.org/woden/dev/index.html#Weekly+Status+Call Agenda 1. Open Action Items - Lawrence Mandel 2008-05-13 - John will close the M8 plan and create the M9 plan with July 15 as the target date. 2008-06-03 John: No progress. Lawrence: I closed M8 in Jira and rolled all the incomplete items into M9. 2008-06-24 John: No progress. I'll get on this now that I have my access back. 2008-07-08 John: I'm working through the open Jiras and sizing some of the issues. I should have a plan ready by the end of the week. 2008-08-19 John: No progress. Lawrence: How about just creating a high level plan of what we'd like to include in M9? We don't need to put a specific date as it's been difficult to set a date. John: I'll try to get a plan with no date up tonight. 2008-09-16 John: I went through the M9 Jiras to ensure the list is up to date. I haven't updated the Web site yet. 2. Milestone 9 (M9) - John/Lawrence 3. Development Discussion - All 4. Other Business - All Thanks, Lawrence Mandel
Minutes of the Woden Status Telecon, 2008-09-16
Attendees: John Kaputin, Lawrence Mandel Minutes 1. Open Action Items - Lawrence Mandel 2008-05-13 - John will close the M8 plan and create the M9 plan with July 15 as the target date. 2008-06-03 John: No progress. Lawrence: I closed M8 in Jira and rolled all the incomplete items into M9. 2008-06-24 John: No progress. I'll get on this now that I have my access back. 2008-07-08 John: I'm working through the open Jiras and sizing some of the issues. I should have a plan ready by the end of the week. 2008-08-19 John: No progress. Lawrence: How about just creating a high level plan of what we'd like to include in M9? We don't need to put a specific date as it's been difficult to set a date. John: I'll try to get a plan with no date up tonight. 2008-09-16 John: I went through the M9 Jiras to ensure the list is up to date. I haven't updated the Web site yet. 2. Milestone 9 (M9) - John/Lawrence Lawrence: No status update. 3. Development Discussion - All John: I'm going to merge the serialization branch into trunk. There have been no complaints about the equivalence change so I'll move that into trunk as well. John: WRT the Maven refactoring we need to determine how this works from a development perspective. I don't think there are any issues with this change from a build perspective. I'll take another look and post my thoughts on the list. Lawrence: That sounds good. I just haven't found time to review yet. I'll look for your comments. 4. Other Business - All Lawrence: We need to follow up with the contributions that have been made. They've been sitting too long. Lawrence: Our next call will be Oct. 7, 2008. Thanks, Lawrence Mandel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Agenda of the Woden Status Telecon, 2008-09-16
As a reminder, the Woden status telecon will be held at 9am EST and are open to all. See [1] for call and IRC information. [1] http://ws.apache.org/woden/dev/index.html#Weekly+Status+Call Agenda 1. Open Action Items - Lawrence Mandel 2008-05-13 - John will close the M8 plan and create the M9 plan with July 15 as the target date. 2008-06-03 John: No progress. Lawrence: I closed M8 in Jira and rolled all the incomplete items into M9. 2008-06-24 John: No progress. I'll get on this now that I have my access back. 2008-07-08 John: I'm working through the open Jiras and sizing some of the issues. I should have a plan ready by the end of the week. 2008-08-19 John: No progress. Lawrence: How about just creating a high level plan of what we'd like to include in M9? We don't need to put a specific date as it's been difficult to set a date. John: I'll try to get a plan with no date up tonight. 2. Milestone 9 (M9) - John/Lawrence 3. Development Discussion - All 4. Other Business - All Thanks, Lawrence Mandel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
WODEN-208 and WODEN-65 status
Hi all, I think we can fix WODEN-208 issue for M9 , I have already updated the fix ,please review it .About the serialization, I implemented the remaining parts of OM based implementation also but still waiting for John's review. Meanwhile , I'm free to do some more issues , please assign couple of urgent issues for me . Regards, Sagara Gunathunga Blog - ssagara.blogspot.com Web - http://sagaras.awardspace.com/
Agenda of the Woden Status Telecon, 2008-08-19
As a reminder, the Woden status telecon will be held at 9am EST and are open to all. See [1] for call and IRC information. [1] http://ws.apache.org/woden/dev/index.html#Weekly+Status+Call Agenda 1. Open Action Items - Lawrence Mandel 2008-04-29 - John will update the build publish information to include information about publishing Maven components. 2008-05-13 John: No update. Lawrence: The location for the maven repo is /www/people.apache.org/repo/m2-ibiblio-rsync-repository and the distribution directory is /www/www.apache.org/dist/ws/woden, both on people.apache.org. 2008-06-03 John: No progress. 2008-06-24 John: No progress. I've been catching up with Woden issues. 2008-07-08 John: No progress. 2008-05-13 - John will close the M8 plan and create the M9 plan with July 15 as the target date. 2008-06-03 John: No progress. Lawrence: I closed M8 in Jira and rolled all the incomplete items into M9. 2008-06-24 John: No progress. I'll get on this now that I have my access back. 2008-07-08 John: I'm working through the open Jiras and sizing some of the issues. I should have a plan ready by the end of the week. 2. Milestone 9 (M9) - John/Lawrence 3. Development Discussion - All 4. Other Business - All Thanks, Lawrence Mandel
Minutes of the Woden Status Telecon, 2008-08-19
Attendees: Arthur Ryman, Lawrence Mandel, John Kaputin Minutes 1. Open Action Items - Lawrence Mandel 2008-04-29 - John will update the build publish information to include information about publishing Maven components. 2008-05-13 John: No update. Lawrence: The location for the maven repo is /www/people.apache.org/repo/m2-ibiblio-rsync-repository and the distribution directory is /www/www.apache.org/dist/ws/woden, both on people.apache.org. 2008-06-03 John: No progress. 2008-06-24 John: No progress. I've been catching up with Woden issues. 2008-07-08 John: No progress. 2008-08-19 John: No progress. Lawrence: How about asking Jeff Maury if he's interested in documenting the publish part of the build as he's been key in refactoring the source tree for maven. I've opened WODEN-213. Closed. [1]https://issues.apache.org/jira/browse/WODEN-213 2008-05-13 - John will close the M8 plan and create the M9 plan with July 15 as the target date. 2008-06-03 John: No progress. Lawrence: I closed M8 in Jira and rolled all the incomplete items into M9. 2008-06-24 John: No progress. I'll get on this now that I have my access back. 2008-07-08 John: I'm working through the open Jiras and sizing some of the issues. I should have a plan ready by the end of the week. 2008-08-19 John: No progress. Lawrence: How about just creating a high level plan of what we'd like to include in M9? We don't need to put a specific date as it's been difficult to set a date. John: I'll try to get a plan with no date up tonight. 2. Milestone 9 (M9) - John/Lawrence John: No update. I'll get a plan on the Woden site. 3. Development Discussion - All John: Has anyone else reviewed Jeff Maury's refactoring? Lawrence: I haven't yet but I need to look at this so we can get this contribution integrated into trunk. John: I've found it a bit awkward to work in Eclipse because of the organization. There may be a better way to work in Eclipse. Lawrence: I'll take a look at Eclipse and see what we can do. I'll try to follow up with refactoring this week. John: Sudhir Vishwanath has contributed some assertion validators. I'll follow up and review his contributions. Arthur: What's the status of the assertion coverage? John: We've only done a few. Sudhir Vishwanath has worked on a couple assertions as well. I still have work to do to handle extensions. 4. Other Business - All No other business raised. Thanks, Lawrence Mandel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GSoC] XPath Project Status.
Hi, Please find my commnets inline. Dumindu. On Tue, Aug 5, 2008 at 9:04 AM, Varuna Jayasiri [EMAIL PROTECTED]wrote: Hi, The XPath engine now supports most of the generally used XPath expressions. Expressions such as path expressions, predicates, unions, conditional expressions, namespaces, etc have been implemented as we have discussed and planned. great! For example expressions such as the following could be evaluated: root//test:[EMAIL PROTECTED]/child[grandchild = /root/node1] /root//test:node[3]/[EMAIL PROTECTED] = abc] And I would like to implement the complete XPath specification later, when I have time. XPath engine supports a set of expressions to be evaluated on streaming XML. However, since AXIOM does not support streaming XML the optimal level of performance cannot be achieved. Although XPath engine frees unwanted parts of the tree cached by AXIOM, it still stores certain information. I guess free'ing unwanted nodes is done only when streaming is enabled? I don't think we should free the process axiom trees even when streaming is enabled. It should happen at axiom level, i.e., not caching the tree in the first place. However it is good that you tried xpath processing with free'ing, since it validates that your XPath engine should work even for an streaming axiom implementation. The maximum advantage of streaming XPath can only be achieved by enabling streaming support at AXIOM level. Well I think you should not worry about axiom caching. But make sure that the required support is there for streaming. Basically, if you process the nodes as axiom provides them, without going up the tree you should be fine. -- Dumindu Pallewela Cinergix - Share, Reuse, Innovate cinergix.com
[GSoC] XPath Project Status.
Hi Varuna, I see that you've done quite a job implementing XPath by now. Could you please update the list on what you have done already and what remains to be completed. Thanks, Dumindu. -- Dumindu Pallewela Cinergix - Share, Reuse, Innovate cinergix.com
Re: [GSoC] XPath Project Status.
Hi, The XPath engine now supports most of the generally used XPath expressions. Expressions such as path expressions, predicates, unions, conditional expressions, namespaces, etc have been implemented as we have discussed and planned. For example expressions such as the following could be evaluated: root//test:[EMAIL PROTECTED]/child[grandchild = /root/node1] /root//test:node[3]/[EMAIL PROTECTED] = abc] And I would like to implement the complete XPath specification later, when I have time. XPath engine supports a set of expressions to be evaluated on streaming XML. However, since AXIOM does not support streaming XML the optimal level of performance cannot be achieved. Although XPath engine frees unwanted parts of the tree cached by AXIOM, it still stores certain information. The maximum advantage of streaming XPath can only be achieved by enabling streaming support at AXIOM level. I have planned to program support for all axes in this week and code the parser for XPath functions if possible. I will use the next week to clean the code, write comments and do some testing. Varuna www.xvpj.net On Mon, Aug 4, 2008 at 10:33 PM, Dumindu Pallewela [EMAIL PROTECTED]wrote: Hi Varuna, I see that you've done quite a job implementing XPath by now. Could you please update the list on what you have done already and what remains to be completed. Thanks, Dumindu. -- Dumindu Pallewela Cinergix - Share, Reuse, Innovate cinergix.com
2008-08-05 Woden Status Telecon Cancelled
The 2008-08-05 Woden status telecon has been cancelled. Please send status to the dev list. Thanks, Lawrence - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
2008-07-22 Woden Status Telecon Cancelled
The 2008-07-22 Woden status telecon has been cancelled. Please send status to the dev list. Thanks, Lawrence - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Agenda of the Woden Status Telecon, 2008-07-08
Hi Sagara, I committed your recent serialization patches to the woden65 branch yesterday (thanks), but I haven't finished reviewing them yet. If you're keen for more work, I was just reviewing the open JIRAs and noticed a new one, WODEN-208, which looks like a useful fix, but not something I have time to do at the moment. It's about more helpful error reporting when users try to read a WSDL 1.1 doc with Woden. Would you like to have a go at this? regards, John. On Tue, Jul 8, 2008 at 8:17 PM, Sagara Gunathunga [EMAIL PROTECTED] wrote: Hi all, I just want to update about my current status because still I don't have a way to participate for status telecon. 1.) In WSDLWritter I already completed more than 90% of works in both DOM and OM implementations. Only remaining task is to fix the test cases. 2.) Since I've been working on Woden for last few months ,now I can contribute for more development works in addition to Serialization. If you guys can point out any urgent task or specific area , I like to work on it . Thanks , On Tue, Jul 8, 2008 at 3:16 AM, Lawrence Mandel [EMAIL PROTECTED] wrote: As a reminder, the Woden status telecon will be held at 9am EST and are open to all. See [1] for call and IRC information. [1] http://ws.apache.org/woden/dev/index.html#Weekly+Status+Call Agenda 1. Open Action Items - Lawrence Mandel 2008-04-29 - John will update the build publish information to include information about publishing Maven components. 2008-05-13 John: No update. Lawrence: The location for the maven repo is /www/people.apache.org/repo/m2-ibiblio-rsync-repository and the distribution directory is /www/www.apache.org/dist/ws/woden, both on people.apache.org. 2008-06-03 John: No progress. 2008-06-24 John: No progress. I've been catching up with Woden issues. 2008-05-13 - John will close the M8 plan and create the M9 plan with July 15 as the target date. 2008-06-03 John: No progress. Lawrence: I closed M8 in Jira and rolled all the incomplete items into M9. 2008-06-24 John: No progress. I'll get on this now that I have my access back. 2. Milestone 9 (M9) - John/Lawrence 3. Development Discussion - All 4. Other Business - All Thanks, Lawrence Mandel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sagara Gunathunga Blog - ssagara.blogspot.com Web - http://sagaras.awardspace.com/
Re: Agenda of the Woden Status Telecon, 2008-07-08
Hi John, I've started working on WODEN-208 , I'm planing to upload my fix within few days . please assign WODEN-208 to me so that i can make some comments and upload my fix to JIRA. Thanks , On Tue, Jul 8, 2008 at 6:55 PM, Sagara Gunathunga [EMAIL PROTECTED] wrote: Hi John , I visited the WODEN-208 page , I think I can fix the issue .Also I will update you if i found any futher issues related to WODEN-208 . Thanks , On Tue, Jul 8, 2008 at 6:08 PM, John Kaputin (gmail) [EMAIL PROTECTED] wrote: Hi Sagara, I committed your recent serialization patches to the woden65 branch yesterday (thanks), but I haven't finished reviewing them yet. If you're keen for more work, I was just reviewing the open JIRAs and noticed a new one, WODEN-208, which looks like a useful fix, but not something I have time to do at the moment. It's about more helpful error reporting when users try to read a WSDL 1.1 doc with Woden. Would you like to have a go at this? regards, John. On Tue, Jul 8, 2008 at 8:17 PM, Sagara Gunathunga [EMAIL PROTECTED] wrote: Hi all, I just want to update about my current status because still I don't have a way to participate for status telecon. 1.) In WSDLWritter I already completed more than 90% of works in both DOM and OM implementations. Only remaining task is to fix the test cases. 2.) Since I've been working on Woden for last few months ,now I can contribute for more development works in addition to Serialization. If you guys can point out any urgent task or specific area , I like to work on it . Thanks , On Tue, Jul 8, 2008 at 3:16 AM, Lawrence Mandel [EMAIL PROTECTED] wrote: As a reminder, the Woden status telecon will be held at 9am EST and are open to all. See [1] for call and IRC information. [1] http://ws.apache.org/woden/dev/index.html#Weekly+Status+Call Agenda 1. Open Action Items - Lawrence Mandel 2008-04-29 - John will update the build publish information to include information about publishing Maven components. 2008-05-13 John: No update. Lawrence: The location for the maven repo is /www/people.apache.org/repo/m2-ibiblio-rsync-repository and the distribution directory is /www/www.apache.org/dist/ws/woden, both on people.apache.org. 2008-06-03 John: No progress. 2008-06-24 John: No progress. I've been catching up with Woden issues. 2008-05-13 - John will close the M8 plan and create the M9 plan with July 15 as the target date. 2008-06-03 John: No progress. Lawrence: I closed M8 in Jira and rolled all the incomplete items into M9. 2008-06-24 John: No progress. I'll get on this now that I have my access back. 2. Milestone 9 (M9) - John/Lawrence 3. Development Discussion - All 4. Other Business - All Thanks, Lawrence Mandel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sagara Gunathunga Blog - ssagara.blogspot.com Web - http://sagaras.awardspace.com/ -- Sagara Gunathunga Blog - ssagara.blogspot.com Web - http://sagaras.awardspace.com/ -- Sagara Gunathunga Blog - ssagara.blogspot.com Web - http://sagaras.awardspace.com/
Re: Refactoring status
+1 from me for option 3 as well. Thanks, Jeremy 2008/7/3 John Kaputin (gmail) [EMAIL PROTECTED]: Jeff, I think option 3 seems best too, although my knowledge of Maven is still a bit limited. I assume you will also refactor the converter and wsdl printer into woden-tools? thanks, John. On Fri, Jun 27, 2008 at 3:30 AM, Lawrence Mandel [EMAIL PROTECTED] wrote: Jeff, I'm in favour of following conventions where possible. I'd also go with option 3. Lawrence Jeff MAURY [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 06/26/2008 06:13 AM Please respond to woden-dev@ws.apache.org To woden-dev@ws.apache.org cc Subject Refactoring status Hello, just to report what I have done and what is left. I have refactored woden-api, woden-om, woden-dom and created woden-ant and woden-commons. As of yet, I have just refactored the source and not the tests. I have a little problem with the tests and need your opinion. Maven convention about test is to store the test with the Maven project. However, in our case, most of the tests are shared between woden-om and woden-dom. So the solutions presented to use are the following: 1) create a separate test folder under trunk and update woden-om and woden-dom to use this folder (like it is done today). Pros: easy to implement. Cons: does not follow Maven conventions 2) create a separate test Maven project with two profiles (om and dom) to manage the dependency for the execution. Pros: follow Maven conventions. Cons: needs to run Maven twice 3) create a separate test Maven project without profiles that will launch Maven twice (thanks to the maven-invoker-plugin http://maven.apache.org/plugins/maven-invoker-plugin) one for OM and one for DOM. Pros: follow Maven conventions. Cons: needs 3 POMs Please let me know what is your preferred choice, mine is the third. Jeff MAURY -- La mélancolie c'est communiste Tout le monde y a droit de temps en temps La mélancolie n'est pas capitaliste C'est même gratuit pour les perdants La mélancolie c'est pacifiste On ne lui rentre jamais dedans La mélancolie oh tu sais ça existe Elle se prend même avec des gants La mélancolie c'est pour les syndicalistes Il faut juste sa carte de permanent Miossec (2006) http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.lastfm.fr/listen/user/jeffmaury/personal - 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: Refactoring status
Jeff, I'm not sure what to do with the wsdl viewer. It is a stand alone xsl tool, not a resource used by a woden java tool, so perhaps making it a subdirectory of resource within the woden-tool jar is not the right thing. Do any of the other woden devs have any thoughts on where to place wsdl viewer in the new maven source structure and build tree? John. On Fri, Jul 4, 2008 at 12:29 AM, Jeff MAURY [EMAIL PROTECTED] wrote: John, Yes, I started the refactoring based on option 3. I'm almost finished, I just need to check the Ant build. Regarding the wsdlprinter, my intent is to put it into woden-tool, but don't know exactly how to do: if I put it as a resource, it will be in the woden-tool JAR, do you think this is ok ? Regards Jeff MAURY On Thu, Jul 3, 2008 at 4:20 PM, John Kaputin (gmail) [EMAIL PROTECTED] wrote: Jeff, I think option 3 seems best too, although my knowledge of Maven is still a bit limited. I assume you will also refactor the converter and wsdl printer into woden-tools? thanks, John. On Fri, Jun 27, 2008 at 3:30 AM, Lawrence Mandel [EMAIL PROTECTED] wrote: Jeff, I'm in favour of following conventions where possible. I'd also go with option 3. Lawrence Jeff MAURY [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 06/26/2008 06:13 AM Please respond to woden-dev@ws.apache.org To woden-dev@ws.apache.org cc Subject Refactoring status Hello, just to report what I have done and what is left. I have refactored woden-api, woden-om, woden-dom and created woden-ant and woden-commons. As of yet, I have just refactored the source and not the tests. I have a little problem with the tests and need your opinion. Maven convention about test is to store the test with the Maven project. However, in our case, most of the tests are shared between woden-om and woden-dom. So the solutions presented to use are the following: 1) create a separate test folder under trunk and update woden-om and woden-dom to use this folder (like it is done today). Pros: easy to implement. Cons: does not follow Maven conventions 2) create a separate test Maven project with two profiles (om and dom) to manage the dependency for the execution. Pros: follow Maven conventions. Cons: needs to run Maven twice 3) create a separate test Maven project without profiles that will launch Maven twice (thanks to the maven-invoker-plugin http://maven.apache.org/plugins/maven-invoker-plugin) one for OM and one for DOM. Pros: follow Maven conventions. Cons: needs 3 POMs Please let me know what is your preferred choice, mine is the third. Jeff MAURY -- La mélancolie c'est communiste Tout le monde y a droit de temps en temps La mélancolie n'est pas capitaliste C'est même gratuit pour les perdants La mélancolie c'est pacifiste On ne lui rentre jamais dedans La mélancolie oh tu sais ça existe Elle se prend même avec des gants La mélancolie c'est pour les syndicalistes Il faut juste sa carte de permanent Miossec (2006) http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.lastfm.fr/listen/user/jeffmaury/personal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- La mélancolie c'est communiste Tout le monde y a droit de temps en temps La mélancolie n'est pas capitaliste C'est même gratuit pour les perdants La mélancolie c'est pacifiste On ne lui rentre jamais dedans La mélancolie oh tu sais ça existe Elle se prend même avec des gants La mélancolie c'est pour les syndicalistes Il faut juste sa carte de permanent Miossec (2006) http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.lastfm.fr/listen/user/jeffmaury/personal
Re: Refactoring status
Jeff, I think option 3 seems best too, although my knowledge of Maven is still a bit limited. I assume you will also refactor the converter and wsdl printer into woden-tools? thanks, John. On Fri, Jun 27, 2008 at 3:30 AM, Lawrence Mandel [EMAIL PROTECTED] wrote: Jeff, I'm in favour of following conventions where possible. I'd also go with option 3. Lawrence Jeff MAURY [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 06/26/2008 06:13 AM Please respond to woden-dev@ws.apache.org To woden-dev@ws.apache.org cc Subject Refactoring status Hello, just to report what I have done and what is left. I have refactored woden-api, woden-om, woden-dom and created woden-ant and woden-commons. As of yet, I have just refactored the source and not the tests. I have a little problem with the tests and need your opinion. Maven convention about test is to store the test with the Maven project. However, in our case, most of the tests are shared between woden-om and woden-dom. So the solutions presented to use are the following: 1) create a separate test folder under trunk and update woden-om and woden-dom to use this folder (like it is done today). Pros: easy to implement. Cons: does not follow Maven conventions 2) create a separate test Maven project with two profiles (om and dom) to manage the dependency for the execution. Pros: follow Maven conventions. Cons: needs to run Maven twice 3) create a separate test Maven project without profiles that will launch Maven twice (thanks to the maven-invoker-plugin http://maven.apache.org/plugins/maven-invoker-plugin) one for OM and one for DOM. Pros: follow Maven conventions. Cons: needs 3 POMs Please let me know what is your preferred choice, mine is the third. Jeff MAURY -- La mélancolie c'est communiste Tout le monde y a droit de temps en temps La mélancolie n'est pas capitaliste C'est même gratuit pour les perdants La mélancolie c'est pacifiste On ne lui rentre jamais dedans La mélancolie oh tu sais ça existe Elle se prend même avec des gants La mélancolie c'est pour les syndicalistes Il faut juste sa carte de permanent Miossec (2006) http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.lastfm.fr/listen/user/jeffmaury/personal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Refactoring status
John, Yes, I started the refactoring based on option 3. I'm almost finished, I just need to check the Ant build. Regarding the wsdlprinter, my intent is to put it into woden-tool, but don't know exactly how to do: if I put it as a resource, it will be in the woden-tool JAR, do you think this is ok ? Regards Jeff MAURY On Thu, Jul 3, 2008 at 4:20 PM, John Kaputin (gmail) [EMAIL PROTECTED] wrote: Jeff, I think option 3 seems best too, although my knowledge of Maven is still a bit limited. I assume you will also refactor the converter and wsdl printer into woden-tools? thanks, John. On Fri, Jun 27, 2008 at 3:30 AM, Lawrence Mandel [EMAIL PROTECTED] wrote: Jeff, I'm in favour of following conventions where possible. I'd also go with option 3. Lawrence Jeff MAURY [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 06/26/2008 06:13 AM Please respond to woden-dev@ws.apache.org To woden-dev@ws.apache.org cc Subject Refactoring status Hello, just to report what I have done and what is left. I have refactored woden-api, woden-om, woden-dom and created woden-ant and woden-commons. As of yet, I have just refactored the source and not the tests. I have a little problem with the tests and need your opinion. Maven convention about test is to store the test with the Maven project. However, in our case, most of the tests are shared between woden-om and woden-dom. So the solutions presented to use are the following: 1) create a separate test folder under trunk and update woden-om and woden-dom to use this folder (like it is done today). Pros: easy to implement. Cons: does not follow Maven conventions 2) create a separate test Maven project with two profiles (om and dom) to manage the dependency for the execution. Pros: follow Maven conventions. Cons: needs to run Maven twice 3) create a separate test Maven project without profiles that will launch Maven twice (thanks to the maven-invoker-plugin http://maven.apache.org/plugins/maven-invoker-plugin) one for OM and one for DOM. Pros: follow Maven conventions. Cons: needs 3 POMs Please let me know what is your preferred choice, mine is the third. Jeff MAURY -- La mélancolie c'est communiste Tout le monde y a droit de temps en temps La mélancolie n'est pas capitaliste C'est même gratuit pour les perdants La mélancolie c'est pacifiste On ne lui rentre jamais dedans La mélancolie oh tu sais ça existe Elle se prend même avec des gants La mélancolie c'est pour les syndicalistes Il faut juste sa carte de permanent Miossec (2006) http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.lastfm.fr/listen/user/jeffmaury/personal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- La mélancolie c'est communiste Tout le monde y a droit de temps en temps La mélancolie n'est pas capitaliste C'est même gratuit pour les perdants La mélancolie c'est pacifiste On ne lui rentre jamais dedans La mélancolie oh tu sais ça existe Elle se prend même avec des gants La mélancolie c'est pour les syndicalistes Il faut juste sa carte de permanent Miossec (2006) http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.lastfm.fr/listen/user/jeffmaury/personal
[jira] Created: (AXIS2-3879) Ability to change the http status code in the response being sent to the client
Ability to change the http status code in the response being sent to the client
---
Key: AXIS2-3879
URL: https://issues.apache.org/jira/browse/AXIS2-3879
Project: Axis 2.0 (Axis2)
Issue Type: Improvement
Components: transports
Affects Versions: 1.4
Reporter: nikki
Hello
I'd like the ability to change the http status code in the reponse. For example
: I'd like to send in certain cases an http 503 (instead of a 500) when a soap
fault occurs. Another of my needs is to send a 202 (instead of 200 for an
in-out operation.)
Here's what i attempted which didn't work I was suggested by Saminda to open
a JIRA.
HttpServletResponse resp = (HttpServletResponse)
msgContext.getCurrentMessageContext().getProperty(org.apache.axis2.transport.http.HT
TPConstants.MC_HTTP_SERVLETRESPONSE);
if (resp != null) {
System.out.println(Resp not null );
resp.setStatus(503 );
}
thankyou
--
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]
Re: Changing the http status code in the response
If your response is a success or accepted, AxisServlet will return the
response code as 200 OK or 202 Accepted. You will not be able to change
this.
But you could change the response header to 401 Unauthorized, by setting
property Constants.HTTP_RESPONSE_STATE to
HttpServletResponse.SC_UNAUTHORIZED and Constants.HTTP_BASIC_AUTH_REALM,
thus the response header can be set with WWW-Authenticate. To do this you
would have to throw an AxisFault exception from your hander or service.
The exact requirement you are asking is not available at the moment. Please
open an JIRA as a feature improvement.
Thank you!
Saminda
On Sat, Jun 28, 2008 at 2:42 AM, Nikki Payne [EMAIL PROTECTED] wrote:
Hello
I am running a service on Axis2 v1.4 I am attempting to change the HTTP
status code in the reponse back to the client, but have been unsuccessful so
far. Here's what I am doing :
I get the response object from the messagecontext in the
MessageReceiverInOut
HttpServletResponse resp =
(HttpServletResponse)
msgContext.getCurrentMessageContext().getProperty(org.apache.axis2.transport.http.HTTPConstants.MC_HTTP_SERVLETRESPONSE);
if (resp != null) {
System.out.println(Resp not null );
resp.setStatus(503 );
resp.addHeader(abcd , newval11);
}
Here's the response http header :
HTTP/1.1 *500 *Internal Server Error
Server: Apache-Coyote/1.1
*abcd: newval11*
Content-Type: application/soap+xml; action=
http://www.w3.org/2005/08/addressing/soap/fault;charset=UTF-8
The new header abcd does show up, but the status-code remains unchanged
to 500 (not 503).
Any help will be greatly appreciated
thank you
-nikki
--
Saminda Abeyruwan
Senior Software Engineer
WSO2 Inc. - www.wso2.org
