[jira] Updated: (AXIS2C-323) Added set_listen_port method to svc_client
[ http://issues.apache.org/jira/browse/AXIS2C-323?page=all ] Damitha Kumarage updated AXIS2C-323: It is discussed that this is not the right place to put this method. So now I'm handling this from whithin wsclient code. Added set_listen_port method to svc_client -- Key: AXIS2C-323 URL: http://issues.apache.org/jira/browse/AXIS2C-323 Project: Axis2-C Issue Type: Improvement Components: core/clientapi Reporter: Damitha Kumarage axis2_status_t (AXIS2_CALL * set_listen_port)( const axis2_svc_client_t *svc_client, const axis2_env_t *env, axis2_char_t *port); method is added so that this can be used to specify the actual port the callback server is listening to. Previosly this is set in axis2.xml which is not good for users using wsclient or php clients. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-324) adding methods set_target_endpoint_ref and get_target_endpoint_ref to axis2_svc_client
[ http://issues.apache.org/jira/browse/AXIS2C-324?page=comments#action_12441069 ] Damitha Kumarage commented on AXIS2C-324: - I think this can be handled by setting a property in options called AXIS2_TARGET_EPR instead of adding these methods. adding methods set_target_endpoint_ref and get_target_endpoint_ref to axis2_svc_client -- Key: AXIS2C-324 URL: http://issues.apache.org/jira/browse/AXIS2C-324 Project: Axis2-C Issue Type: Improvement Components: core/clientapi Reporter: Damitha Kumarage I'm adding following two methods to axis2_options /** * Set the target endpoint reference the receiving end is listening to * @param options pointer to options struct * @param env pointer to environment struct * @return AXIS2_SUCCESS on success, else AXIS2_FAILURE */ axis2_status_t (AXIS2_CALL * set_target_epr) ( axis2_options_t *options, const axis2_env_t *env, axis2_endpoint_ref_t *epr); /** * Get the target endpoint reference the receiving end is listening to * @param options pointer to options struct * @param env pointer to environment struct * @return endpoint reference the receiving end is listening to */ axis2_endpoint_ref_t *(AXIS2_CALL * get_target_epr) ( const axis2_options_t *options, const axis2_env_t *env); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-329) segfault when I try to create dynamic invocation
segfault when I try to create dynamic invocation
--
Key: AXIS2C-329
URL: http://issues.apache.org/jira/browse/AXIS2C-329
Project: Axis2-C
Issue Type: Bug
Components: woden
Reporter: Buddhika Semasinghe
The sample code that I have tried;
ele = AXIS2_ARRAY_LIST_GET(ele_decls, env, i);
if (ele)
{
element_qname = WODEN_ELEMENT_DECL_GET_QNAME(ele, env);
tocompare = AXIS2_QNAME_GET_LOCALPART(element_qname, env);
axis2_char_t *test = add;
cmp = AXIS2_STRCMP(test, tocompare);
if (cmp == 0)
{
axis2_generic_obj_t *obj = NULL;
obj = WODEN_ELEMENT_DECL_GET_CONTENT(ele, env);
if (obj)
{
void *value = NULL;
value = AXIS2_GENERIC_OBJ_GET_VALUE(obj, env);
if(value)
{
void * types = NULL;
types = XML_SCHEMA_ELEMENT_GET_ELEMENT_TYPE(value, env);
}
but it seg faults when calling the XML_SCHEMA_ELEMENT_GET_ELEMENT_TYPE function
following is the gdb session
(gdb)
Program received signal SIGSEGV, Segmentation fault.
0x08048e82 in woden_dynamic_om_builder_init (om_builder=0x804b060,
wsdl_file_name=0xafcb97e9 ../CalculatorDoc.wsdl, env=0x804b048)
at dynamic_om_builder.c:276
(gdb) bt
#0 0x08048e82 in woden_dynamic_om_builder_init (om_builder=0x804b060,
wsdl_file_name=0xafcb97e9 ../CalculatorDoc.wsdl, env=0x804b048)
at dynamic_om_builder.c:276
#1 0x08049290 in main (argc=Cannot access memory at address 0xc
) at main.c:37
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-321) Registered handlers not invoked at all on REST GET requests
[
http://issues.apache.org/jira/browse/AXIS2C-321?page=comments#action_12441273 ]
Jean-Sebastien Delfino commented on AXIS2C-321:
---
I'd like to use handlers mainly to customize the dispatch algorithm.
For example, to invoke my REST service instead of doing this:
http://localhost:9090/axis2/services/CustomerService/getCustomer?customerID=1234
I'd like to do:
http://localhost:9090/axis2/services/Customer/1234
I also need to customize the dispatch algorithm to use the Tuscany metadata
directly (we use SCA bindings to describe which services are exposed and at
which URI) instead of having to translate it to services.xml etc.
Thanks.
Registered handlers not invoked at all on REST GET requests
---
Key: AXIS2C-321
URL: http://issues.apache.org/jira/browse/AXIS2C-321
Project: Axis2-C
Issue Type: Bug
Components: core/engine
Affects Versions: Current (Nightly), 0.93, 0.94
Reporter: Jean-Sebastien Delfino
Modules registered in the Dispatch phase are not invoked at all by the engine
during the processing of REST / HTTP GET requests.
The following code hardcodes a call to the req_uri_disp dispatcher. Instead
it should call the handlers registered in the Dispatch phase like is done for
regular Web Service requests.
AXIS2_EXTERN axis2_status_t AXIS2_CALL
axis2_http_transport_utils_dispatch_and_verify(
const axis2_env_t *env,
axis2_msg_ctx_t *msg_ctx)
{
axis2_disp_t *req_uri_disp = NULL;
axis2_handler_t *handler = NULL;
AXIS2_ENV_CHECK(env, AXIS2_FAILURE);
AXIS2_PARAM_CHECK(env-error, msg_ctx, AXIS2_FAILURE);
req_uri_disp = axis2_req_uri_disp_create(env);
handler = AXIS2_DISP_GET_BASE(req_uri_disp, env);
AXIS2_HANDLER_INVOKE(handler, env, msg_ctx);
if(NULL == AXIS2_MSG_CTX_GET_SVC(msg_ctx, env) || NULL ==
AXIS2_MSG_CTX_GET_OP(msg_ctx, env))
{
AXIS2_ERROR_SET(env-error, AXIS2_ERROR_SVC_OR_OP_NOT_FOUND,
AXIS2_FAILURE);
return AXIS2_FAILURE;
}
return AXIS2_SUCCESS;
}
This issue is blocking for us (the Tuscany project) and prevents us from
using Axis2C to handle REST / GET requests.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Changes in files
Hi,
I have done some changes and additions in some files in the core and
tested with existing samples. Please see the attached diffs. Please
also see comments in
https://issues.apache.org/jira/browse/AXIS2C-324
If there are no objections I'll commit the changes
thanks
Damitha
Index: transport/http/sender/http_client.c
===
--- transport/http/sender/http_client.c (revision 454293)
+++ transport/http/sender/http_client.c (working copy)
@@ -48,6 +48,7 @@
axis2_char_t *proxy_host;
int proxy_port;
axis2_char_t *proxy_host_port;
+axis2_bool_t dump_input_msg;
}
axis2_http_client_impl_t;
@@ -114,6 +115,12 @@
int port);
axis2_status_t AXIS2_CALL
+axis2_http_client_set_dump_input_msg(
+axis2_http_client_t *client,
+const axis2_env_t *env,
+axis2_bool_t dump_input_msg);
+
+axis2_status_t AXIS2_CALL
axis2_http_client_free(
axis2_http_client_t *client,
const axis2_env_t *env);
@@ -152,6 +159,7 @@
http_client_impl-proxy_port = 0;
http_client_impl-proxy_host = NULL;
http_client_impl-proxy_host_port = NULL;
+http_client_impl-dump_input_msg = AXIS2_FALSE;
http_client_impl-http_client.ops = AXIS2_MALLOC(env-allocator,
sizeof(axis2_http_client_ops_t));
@@ -177,6 +185,8 @@
axis2_http_client_set_proxy;
http_client_impl-http_client.ops-get_proxy =
axis2_http_client_get_proxy;
+http_client_impl-http_client.ops-set_dump_input_msg =
+axis2_http_client_set_dump_input_msg;
http_client_impl-http_client.ops-free = axis2_http_client_free;
return (http_client_impl-http_client);
@@ -247,6 +257,16 @@
AXIS2_ENV_CHECK(env, AXIS2_FAILURE);
client_impl = AXIS2_INTF_TO_IMPL(client);
+body_size = AXIS2_HTTP_SIMPLE_REQUEST_GET_BODY_BYTES(request, env,
+str_body);
+if(client_impl-dump_input_msg == AXIS2_TRUE)
+{
+/* We just print the input message and return */
+printf(Input message--:\n);
+printf(%s\n, str_body);
+return AXIS2_SUCCESS;
+}
+
if (NULL == client_impl-url)
{
AXIS2_ERROR_SET(env-error, AXIS2_ERROR_NULL_URL, AXIS2_FAILURE);
@@ -399,8 +419,6 @@
wire_format = NULL;
written = AXIS2_STREAM_WRITE(client_impl-data_stream, env,
AXIS2_HTTP_CRLF,
2);
-body_size = AXIS2_HTTP_SIMPLE_REQUEST_GET_BODY_BYTES(request, env,
-str_body);
if (body_size 0 str_body)
{
if (AXIS2_FALSE == chunking_enabled)
@@ -786,3 +804,19 @@
AXIS2_STREAM_FREE(tmp_stream, env);
return AXIS2_SUCCESS;
}
+
+axis2_status_t AXIS2_CALL
+axis2_http_client_set_dump_input_msg(
+axis2_http_client_t *client,
+const axis2_env_t *env,
+axis2_bool_t dump_input_msg)
+{
+axis2_http_client_impl_t *client_impl = NULL;
+
+client_impl = AXIS2_INTF_TO_IMPL(client);
+
+client_impl-dump_input_msg = dump_input_msg;
+
+return AXIS2_SUCCESS;
+}
+
Index: transport/http/sender/soap_over_http_sender.c
===
--- transport/http/sender/soap_over_http_sender.c (revision 454293)
+++ transport/http/sender/soap_over_http_sender.c (working copy)
@@ -209,6 +209,7 @@
axis2_byte_t *output_stream = NULL;
int output_stream_size = 0;
axis2_bool_t doing_mtom = AXIS2_FALSE;
+axis2_property_t *dump_property = NULL;
AXIS2_ENV_CHECK(env, AXIS2_FAILURE);
AXIS2_PARAM_CHECK(env-error, msg_ctx, AXIS2_FAILURE);
@@ -234,6 +235,18 @@
{
return AXIS2_FAILURE;
}
+
+dump_property = AXIS2_MSG_CTX_GET_PROPERTY(msg_ctx, env,
+AXIS2_DUMP_INPUT_MSG_TRUE, AXIS2_FALSE);
+if(dump_property)
+{
+axis2_char_t *dump_true = AXIS2_PROPERTY_GET_VALUE(dump_property, env);
+if(0 == AXIS2_STRCMP(dump_true, AXIS2_VALUE_TRUE))
+{
+AXIS2_HTTP_CLIENT_SET_DUMP_INPUT_MSG(sender_impl-client, env,
AXIS2_TRUE);
+}
+}
+
/* configure proxy settings if we have set so
*/
axis2_soap_over_http_sender_configure_proxy(sender, env, msg_ctx);
Index: clientapi/op_client.c
===
--- clientapi/op_client.c (revision 454293)
+++ clientapi/op_client.c (working copy)
@@ -405,7 +405,13 @@
if (!transport_out)
{
axis2_endpoint_ref_t *to_epr = NULL;
-to_epr = AXIS2_OPTIONS_GET_TO(op_client_impl-options, env);
+axis2_property_t *property = NULL;
+ property = AXIS2_OPTIONS_GET_PROPERTY(op_client_impl-options, env,
+ AXIS2_TARGET_EPR);
+ if(property)
+to_epr = AXIS2_PROPERTY_GET_VALUE(property, env);
+ if(!to_epr)
+to_epr = AXIS2_OPTIONS_GET_TO(op_client_impl-options, env);
if (!to_epr)
to_epr = AXIS2_MSG_CTX_GET_TO(msg_ctx, env);
[Axis2][Fwd: Changes in files]
---BeginMessage---
Hi,
I have done some changes and additions in some files in the core and
tested with existing samples. Please see the attached diffs. Please
also see comments in
https://issues.apache.org/jira/browse/AXIS2C-324
If there are no objections I'll commit the changes
thanks
Damitha
Index: transport/http/sender/http_client.c
===
--- transport/http/sender/http_client.c (revision 454293)
+++ transport/http/sender/http_client.c (working copy)
@@ -48,6 +48,7 @@
axis2_char_t *proxy_host;
int proxy_port;
axis2_char_t *proxy_host_port;
+axis2_bool_t dump_input_msg;
}
axis2_http_client_impl_t;
@@ -114,6 +115,12 @@
int port);
axis2_status_t AXIS2_CALL
+axis2_http_client_set_dump_input_msg(
+axis2_http_client_t *client,
+const axis2_env_t *env,
+axis2_bool_t dump_input_msg);
+
+axis2_status_t AXIS2_CALL
axis2_http_client_free(
axis2_http_client_t *client,
const axis2_env_t *env);
@@ -152,6 +159,7 @@
http_client_impl-proxy_port = 0;
http_client_impl-proxy_host = NULL;
http_client_impl-proxy_host_port = NULL;
+http_client_impl-dump_input_msg = AXIS2_FALSE;
http_client_impl-http_client.ops = AXIS2_MALLOC(env-allocator,
sizeof(axis2_http_client_ops_t));
@@ -177,6 +185,8 @@
axis2_http_client_set_proxy;
http_client_impl-http_client.ops-get_proxy =
axis2_http_client_get_proxy;
+http_client_impl-http_client.ops-set_dump_input_msg =
+axis2_http_client_set_dump_input_msg;
http_client_impl-http_client.ops-free = axis2_http_client_free;
return (http_client_impl-http_client);
@@ -247,6 +257,16 @@
AXIS2_ENV_CHECK(env, AXIS2_FAILURE);
client_impl = AXIS2_INTF_TO_IMPL(client);
+body_size = AXIS2_HTTP_SIMPLE_REQUEST_GET_BODY_BYTES(request, env,
+str_body);
+if(client_impl-dump_input_msg == AXIS2_TRUE)
+{
+/* We just print the input message and return */
+printf(Input message--:\n);
+printf(%s\n, str_body);
+return AXIS2_SUCCESS;
+}
+
if (NULL == client_impl-url)
{
AXIS2_ERROR_SET(env-error, AXIS2_ERROR_NULL_URL, AXIS2_FAILURE);
@@ -399,8 +419,6 @@
wire_format = NULL;
written = AXIS2_STREAM_WRITE(client_impl-data_stream, env,
AXIS2_HTTP_CRLF,
2);
-body_size = AXIS2_HTTP_SIMPLE_REQUEST_GET_BODY_BYTES(request, env,
-str_body);
if (body_size 0 str_body)
{
if (AXIS2_FALSE == chunking_enabled)
@@ -786,3 +804,19 @@
AXIS2_STREAM_FREE(tmp_stream, env);
return AXIS2_SUCCESS;
}
+
+axis2_status_t AXIS2_CALL
+axis2_http_client_set_dump_input_msg(
+axis2_http_client_t *client,
+const axis2_env_t *env,
+axis2_bool_t dump_input_msg)
+{
+axis2_http_client_impl_t *client_impl = NULL;
+
+client_impl = AXIS2_INTF_TO_IMPL(client);
+
+client_impl-dump_input_msg = dump_input_msg;
+
+return AXIS2_SUCCESS;
+}
+
Index: transport/http/sender/soap_over_http_sender.c
===
--- transport/http/sender/soap_over_http_sender.c (revision 454293)
+++ transport/http/sender/soap_over_http_sender.c (working copy)
@@ -209,6 +209,7 @@
axis2_byte_t *output_stream = NULL;
int output_stream_size = 0;
axis2_bool_t doing_mtom = AXIS2_FALSE;
+axis2_property_t *dump_property = NULL;
AXIS2_ENV_CHECK(env, AXIS2_FAILURE);
AXIS2_PARAM_CHECK(env-error, msg_ctx, AXIS2_FAILURE);
@@ -234,6 +235,18 @@
{
return AXIS2_FAILURE;
}
+
+dump_property = AXIS2_MSG_CTX_GET_PROPERTY(msg_ctx, env,
+AXIS2_DUMP_INPUT_MSG_TRUE, AXIS2_FALSE);
+if(dump_property)
+{
+axis2_char_t *dump_true = AXIS2_PROPERTY_GET_VALUE(dump_property, env);
+if(0 == AXIS2_STRCMP(dump_true, AXIS2_VALUE_TRUE))
+{
+AXIS2_HTTP_CLIENT_SET_DUMP_INPUT_MSG(sender_impl-client, env,
AXIS2_TRUE);
+}
+}
+
/* configure proxy settings if we have set so
*/
axis2_soap_over_http_sender_configure_proxy(sender, env, msg_ctx);
Index: clientapi/op_client.c
===
--- clientapi/op_client.c (revision 454293)
+++ clientapi/op_client.c (working copy)
@@ -405,7 +405,13 @@
if (!transport_out)
{
axis2_endpoint_ref_t *to_epr = NULL;
-to_epr = AXIS2_OPTIONS_GET_TO(op_client_impl-options, env);
+axis2_property_t *property = NULL;
+ property = AXIS2_OPTIONS_GET_PROPERTY(op_client_impl-options, env,
+ AXIS2_TARGET_EPR);
+ if(property)
+to_epr = AXIS2_PROPERTY_GET_VALUE(property, env);
+ if(!to_epr)
+to_epr = AXIS2_OPTIONS_GET_TO(op_client_impl-options, env);
if (!to_epr)
to_epr = AXIS2_MSG_CTX_GET_TO(msg_ctx, env);
[Axis2][Fwd: Savan/C (WS-Eventing implementation for Axis2/C)]
---BeginMessage--- Hi, I have been working on a Savan implementation. The initial design is as follows. This is implemented as an Axis2 module, in the same level as rampart. Folder structure savan/ +--src/ | +--client/ | | savan_client.c | +--core/ | | mod_savan.c | | savan_sub_processor.c | +--data/ | | module.xml | +--handlers/ | | savan_in_handler.c | | savan_out_handler.c | +--msgreceivers/ | | savan_msg_recv.c | +--subscribers/ | | savan_subscriber.c | +--util/ |savan_util.c +--samples/ +server/ | +client/ savan_client.c -- - This provides the WSE client API. The following functions can be called to send a subscribe request. xiom_node_t* AXIS2_CALL savan_client_subscribe( const axis2_env_t *env, axis2_svc_client_t *svc_client, axis2_hash_t *options) options is a hash map with the values that can be included in a Subscribe request. The following keys are provided to identify those values. #define SAVAN_OP_KEY_ENDTO_EPR savan_op_key_endto #define SAVAN_OP_KEY_DELIVERY_MODE savan_op_key_del_mode #define SAVAN_OP_KEY_NOTIFY_EPR savan_op_key_notify #define SAVAN_OP_KEY_SUB_ID savan_op_key_sub_id #define SAVAN_OP_KEY_EXPIRESsavan_op_key_expires #define SAVAN_OP_KEY_FILTER savan_op_key_filter Similar functions would be provided for Renew, Unsubscribe and GetStatus operations. savan_sub_processor.c - This is the Savan Subscription Processor. It will be called by the Savan In Handler to process incoming WSE client requests. It's main function is as follows: - extract subcription details such as NotifyTo and EndTo from the incoming request - create a subscriber instance and set the extracted info - put the created subscriber in a subscriber store (a hash map) maintained in the service The subscription processor will also process Unsubscribe and Renew requests. savan_msg_recv.c This will create the responses to client requests. e.g.: For a Subscription request it will create a SubscriptionResponse message. savan_subscriber.c -- A server side representation of a WSE client In addition to holding request data, this will also handle publications. axis2_status_t AXIS2_CALL savan_subscriber_publish(const axis2_env_t *env, struct axis2_msg_ctx *msg_ctx); Issues == 1. The existing message receivers (e.g. axis2_raw_xml_in_out_msg_recv) are separate libraries, with their own axis2_get_instance() functions. However, savan_msg_recv() should be bundled in to the savan library. How can this be done? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ---End Message--- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2][1.1-RC1] Security sample is not included
I would not recommend you to try mixing the stuff between 1.0 and 1.1... You can try the snapshots together with 1.1-RC1... http://people.apache.org/repository/org.apache.axis2/mars/rampart-1.1.mar IMO this version number is wrong.. Should be 1.1-snapshots.. ~Thilina On 10/10/06, Ali Sadik Kumlali [EMAIL PROTECTED] wrote: Thanks Thilina. Do I have a chance to test my codebase which uses Axis2 1.0(Rampart included) against Axis2 1.1 RC1(Rampart excluded) by adding Rampart externally somehow? Or am I required to wait till Axis2 1.1 and then Rampart has been released? Regards, Ali Sadik Kumlali - Original Message From: Thilina Gunarathne [EMAIL PROTECTED] To: axis-dev@ws.apache.org Sent: Tuesday, October 10, 2006 2:24:38 AM Subject: Re: [Axis2][1.1-RC1] Security sample is not included We will not be releasing the security stuff (Rampart,Rahas) with Axis2 1.1. They will be released separately after the Axis2 1.1 release.. ~Thilina On 10/10/06, Ali Sadik Kumlali [EMAIL PROTECTED] wrote: Hi devs, I haven't seen the security sample within the nightlies for a while. And it isn't included in the 1.1 RC1, either. Is it a known issue? Regards, Ali Sadik Kumlali - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://webservices.apache.org/~thilina/ http://thilinag.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://webservices.apache.org/~thilina/ http://thilinag.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2] What should be included in Axis2 minimal distribution
Hi, Can we please re-visit the modules that should be included in Axis2 minimal distribution. Currently kernel, adb and java2wsdl modules are included, but I saw even adb-codegen was added recently. What do you think? Thanks, Chinthaka signature.asc Description: OpenPGP digital signature
Disable Transfer-Encoding: chunked response
Hi,How can I disable Transfer-Encoding: chunked in the response of my axis 1.4 webservice? Thanks in advance
Re: [Axis2][1.1-RC1] AxisFault example not included
William Ferguson wrote: I can't find the Axis Fault sample in the release candidate. http://issues.apache.org/jira/browse/AXIS2-917 Done !! Sorry I forgot to add it to the maven script. -- Chinthaka signature.asc Description: OpenPGP digital signature
[jira] Created: (AXIS2-1333) InvocationTargetException thrown when accessing 'Engage Module For a Service' page in Axis2 admin console
InvocationTargetException thrown when accessing 'Engage Module For a Service' page in Axis2 admin console - Key: AXIS2-1333 URL: http://issues.apache.org/jira/browse/AXIS2-1333 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Affects Versions: 1.1 Environment: Windows XP, jdk1.5.0_08, Mozilla Firefox 1.5.0.6, Apache Tomcat 5.5.16 Reporter: Charitha Kankanamge System returns HTTP 500 error with the follwoing exception in the logs when accessing 'Engage Module For a Service' page in Axis2 admin console. Oct 10, 2006 12:47:36 PM org.apache.axis2.transport.http.AbstractAgent handle WARNING: Error dispatching request /axis2/axis2-admin/engageToService java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) Please note that this issue exists in Windows XP environment only. Steps to reproduce: 1. Deploy Axis2.war from the axis2-std-1.1-RC1 distribution 2. Access the admin console 3. Click on 'For a Service' link under the 'Engage Module' in the left pane Issue: == HTTP 500 error is shown to the user. Complete stack trace is attached here with. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] What should be included in Axis2 minimal distribution
Hi, AFAIK ADB is there because we need the RPCMessageReceiver to work in the minimal distro... Just now I figured out that RPCMessageReceiver resides in the codegen module..Which means we have to include codegen module to the minimal distro.. I'm not sure why we are putting the adb-codegen in to the minimal distro... ~Thilina On 10/10/06, Eran Chinthaka [EMAIL PROTECTED] wrote: Hi, Can we please re-visit the modules that should be included in Axis2 minimal distribution. Currently kernel, adb and java2wsdl modules are included, but I saw even adb-codegen was added recently. What do you think? Thanks, Chinthaka -- http://webservices.apache.org/~thilina/ http://thilinag.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] What should be included in Axis2 minimal distribution
While we're looking into this, we should also check the war file contents. It looks like the full set of jars are included, which is certainly unnecessary. JiBX support only needs axis2-jibx-XXX.jar and jibx-run-XXX.jar, not the much larger bcel-XXX.jar (.5 MB) and jibx-bind-XXX.jar (.3 MB). I can strip these two unnecessary files out of the war build if someone wants to point me at the appropriate magic maven file, but I'm sure there's a lot more that can also be eliminated. - Dennis Dennis M. Sosnoski SOA, Web Services, and XML Training and Consulting http://www.sosnoski.com - http://www.sosnoski.co.nz Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117 Thilina Gunarathne wrote: Hi, AFAIK ADB is there because we need the RPCMessageReceiver to work in the minimal distro... Just now I figured out that RPCMessageReceiver resides in the codegen module..Which means we have to include codegen module to the minimal distro.. I'm not sure why we are putting the adb-codegen in to the minimal distro... ~Thilina On 10/10/06, Eran Chinthaka [EMAIL PROTECTED] wrote: Hi, Can we please re-visit the modules that should be included in Axis2 minimal distribution. Currently kernel, adb and java2wsdl modules are included, but I saw even adb-codegen was added recently. What do you think? Thanks, Chinthaka - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-729) 404 Not Found trying to access JiBX example page
[ http://issues.apache.org/jira/browse/AXIS2-729?page=all ] Dennis Sosnoski resolved AXIS2-729. --- Fix Version/s: nightly Resolution: Fixed Added more JiBX documentation, including details of wrapped and unwrapped examples. All links should now be good. http://svn.apache.org/viewvc?view=revrev=454672 404 Not Found trying to access JiBX example page Key: AXIS2-729 URL: http://issues.apache.org/jira/browse/AXIS2-729 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: samples, build,site docs Affects Versions: 1.0 Reporter: Brent Ulbricht Assigned To: Dennis Sosnoski Priority: Minor Fix For: nightly The link for the JiBX example from http://ws.apache.org/axis2/1_0/jibx/jibx-codegen-integration.html leads to http://ws.apache.org/axis2/1_0/jibx/jibx-example.html, which gives a 404 Not Found. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] What should be included in Axis2 minimal distribution
Hi Dennis, http://svn.apache.org/viewvc/webservices/axis2/branches/java/1_1/maven.xml This is it Have fun :) Thanks, ~Thilina On 10/10/06, Thilina Gunarathne [EMAIL PROTECTED] wrote: Yes.. We need to figure out the unnecessary jars... Good to know that we can get rid of bcel-xxx.jar and jibx bind... I'll set up a wiki page ot figure out what we need and what we don't need.. ~Thilina On 10/10/06, Dennis Sosnoski [EMAIL PROTECTED] wrote: While we're looking into this, we should also check the war file contents. It looks like the full set of jars are included, which is certainly unnecessary. JiBX support only needs axis2-jibx-XXX.jar and jibx-run-XXX.jar, not the much larger bcel-XXX.jar (.5 MB) and jibx-bind-XXX.jar (.3 MB). I can strip these two unnecessary files out of the war build if someone wants to point me at the appropriate magic maven file, but I'm sure there's a lot more that can also be eliminated. - Dennis Dennis M. Sosnoski SOA, Web Services, and XML Training and Consulting http://www.sosnoski.com - http://www.sosnoski.co.nz Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117 Thilina Gunarathne wrote: Hi, AFAIK ADB is there because we need the RPCMessageReceiver to work in the minimal distro... Just now I figured out that RPCMessageReceiver resides in the codegen module..Which means we have to include codegen module to the minimal distro.. I'm not sure why we are putting the adb-codegen in to the minimal distro... ~Thilina On 10/10/06, Eran Chinthaka [EMAIL PROTECTED] wrote: Hi, Can we please re-visit the modules that should be included in Axis2 minimal distribution. Currently kernel, adb and java2wsdl modules are included, but I saw even adb-codegen was added recently. What do you think? Thanks, Chinthaka - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://webservices.apache.org/~thilina/ http://thilinag.blogspot.com/ -- http://webservices.apache.org/~thilina/ http://thilinag.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-1335) Code Generation Exception occurred when Generating Clients
Code Generation Exception occurred when Generating Clients -- Key: AXIS2-1335 URL: http://issues.apache.org/jira/browse/AXIS2-1335 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Affects Versions: 1.1 Environment: Windows XP, jdk1.5.0_08, Maven 1.0.2, Mozilla Firefox 1.5.0.6 Reporter: Evanthika Amarasiri Priority: Critical 1. Login to the Tungsten Management Console 2. Click on the link Services which is on the left pane of the page 3. Click on the link Generate Client 4. Select the following Stub Generation options to create the stub a) Port - CommodityQuoteSOAP11port_https b) Invocation Style - Both c) Databinding - ADB d) Unpack Classes - True e) Unwrap - True f) Generate Testcase - False 5. Select the above options and click on the button Generate (You can change the values of any other option but the value of the option Unwrap should be set to True and the port should be either CommodityQuoteSOAP11port_https or CommodityQuoteSOAP11port_http1) 6. A Code Generation Exception is thrown ERROR [2006-10-10 16:12:49,343] Error occurred during code generation. Unsupported Schema format fo r unwrapping! found unknown but expected sequence org.apache.axis2.wsdl.codegen.CodeGenerationException: org.apache.axis2.wsdl.codegen.CodeGenerationE xception: Unsupported Schema format for unwrapping! found unknown but expected sequence at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224 ) at com.wso2.tungsten.admin.service.wsdl2code.WSDL2CodeService.generate(WSDL2CodeService.java :154) at com.wso2.tungsten.admin.service.wsdl2code.WSDL2CodeServiceMessageReceiverInOut.invokeBusi nessLogic(WSDL2CodeServiceMessageReceiverInOut.java:55) at org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.receive(AbstractInOutSyncMess ageReceiver.java:39) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:493) at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUt ils.java:323) at org.apache.axis2.transport.http.util.SOAPUtil.processPostRequest(SOAPUtil.java:57) at com.wso2.tungsten.transport.jetty.Axis2SOAPHandler.processPostRequest(Axis2SOAPHandler.ja va:42) at com.wso2.tungsten.transport.jetty.Axis2Handler.dispatch(Axis2Handler.java:175) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) at org.mortbay.http.HttpServer.service(HttpServer.java:909) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) Caused by: org.apache.axis2.wsdl.codegen.CodeGenerationException: Unsupported Schema format for unwr apping! found unknown but expected sequence at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.processXMLSchemaSequence (SchemaUnwrapperExtension.java:287) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.handleAllCasesOfComplexT ypes(SchemaUnwrapperExtension.java:164) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.walkSchema(SchemaUnwrapp erExtension.java:122) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.engage(SchemaUnwrapperEx tension.java:87) at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:177 ) ... 18 more ERROR [2006-10-10 16:12:49,343] org.apache.axis2.AxisFault: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown but expected sequence; nested exception is: java.lang.RuntimeException: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown but expected sequence; nested exception is: org.apache.axis2.AxisFault: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown but expected sequence; nested exception is: java.lang.RuntimeException: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown but expected sequence ERROR [2006-10-10 16:12:49,343] Unable to handle request com.wso2.tungsten.TungstenException: org.apache.axis2.AxisFault: Error occurred during code generati on. Unsupported Schema format for
[jira] Updated: (AXIS2-1335) Code Generation Exception occurred when Generating Clients
[ http://issues.apache.org/jira/browse/AXIS2-1335?page=all ] Evanthika Amarasiri updated AXIS2-1335: --- Attachment: Error 6.JPG Code Generation Exception occurred when Generating Clients -- Key: AXIS2-1335 URL: http://issues.apache.org/jira/browse/AXIS2-1335 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Affects Versions: 1.1 Environment: Windows XP, jdk1.5.0_08, Maven 1.0.2, Mozilla Firefox 1.5.0.6 Reporter: Evanthika Amarasiri Priority: Critical Attachments: Error 6.JPG 1. Login to the Tungsten Management Console 2. Click on the link Services which is on the left pane of the page 3. Click on the link Generate Client 4. Select the following Stub Generation options to create the stub a) Port - CommodityQuoteSOAP11port_https b) Invocation Style - Both c) Databinding - ADB d) Unpack Classes - True e) Unwrap - True f) Generate Testcase - False 5. Select the above options and click on the button Generate (You can change the values of any other option but the value of the option Unwrap should be set to True and the port should be either CommodityQuoteSOAP11port_https or CommodityQuoteSOAP11port_http1) 6. A Code Generation Exception is thrown ERROR [2006-10-10 16:12:49,343] Error occurred during code generation. Unsupported Schema format fo r unwrapping! found unknown but expected sequence org.apache.axis2.wsdl.codegen.CodeGenerationException: org.apache.axis2.wsdl.codegen.CodeGenerationE xception: Unsupported Schema format for unwrapping! found unknown but expected sequence at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224 ) at com.wso2.tungsten.admin.service.wsdl2code.WSDL2CodeService.generate(WSDL2CodeService.java :154) at com.wso2.tungsten.admin.service.wsdl2code.WSDL2CodeServiceMessageReceiverInOut.invokeBusi nessLogic(WSDL2CodeServiceMessageReceiverInOut.java:55) at org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.receive(AbstractInOutSyncMess ageReceiver.java:39) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:493) at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUt ils.java:323) at org.apache.axis2.transport.http.util.SOAPUtil.processPostRequest(SOAPUtil.java:57) at com.wso2.tungsten.transport.jetty.Axis2SOAPHandler.processPostRequest(Axis2SOAPHandler.ja va:42) at com.wso2.tungsten.transport.jetty.Axis2Handler.dispatch(Axis2Handler.java:175) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) at org.mortbay.http.HttpServer.service(HttpServer.java:909) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) Caused by: org.apache.axis2.wsdl.codegen.CodeGenerationException: Unsupported Schema format for unwr apping! found unknown but expected sequence at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.processXMLSchemaSequence (SchemaUnwrapperExtension.java:287) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.handleAllCasesOfComplexT ypes(SchemaUnwrapperExtension.java:164) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.walkSchema(SchemaUnwrapp erExtension.java:122) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.engage(SchemaUnwrapperEx tension.java:87) at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:177 ) ... 18 more ERROR [2006-10-10 16:12:49,343] org.apache.axis2.AxisFault: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown but expected sequence; nested exception is: java.lang.RuntimeException: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown but expected sequence; nested exception is: org.apache.axis2.AxisFault: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown but expected sequence; nested exception is: java.lang.RuntimeException: Error occurred during
Re: [Axis2] What should be included in Axis2 minimal distribution
Folks, lets move rpc* out of coden. it does not belong there. -- dims On 10/10/06, Thilina Gunarathne [EMAIL PROTECTED] wrote: Hi, AFAIK ADB is there because we need the RPCMessageReceiver to work in the minimal distro... Just now I figured out that RPCMessageReceiver resides in the codegen module..Which means we have to include codegen module to the minimal distro.. I'm not sure why we are putting the adb-codegen in to the minimal distro... ~Thilina On 10/10/06, Eran Chinthaka [EMAIL PROTECTED] wrote: Hi, Can we please re-visit the modules that should be included in Axis2 minimal distribution. Currently kernel, adb and java2wsdl modules are included, but I saw even adb-codegen was added recently. What do you think? Thanks, Chinthaka -- http://webservices.apache.org/~thilina/ http://thilinag.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2][1.1-RC1] Security sample is not included
Thilina, if i add snapshots to the name, the mar wont load :( -- dims On 10/10/06, Thilina Gunarathne [EMAIL PROTECTED] wrote: I would not recommend you to try mixing the stuff between 1.0 and 1.1... You can try the snapshots together with 1.1-RC1... http://people.apache.org/repository/org.apache.axis2/mars/rampart-1.1.mar IMO this version number is wrong.. Should be 1.1-snapshots.. ~Thilina On 10/10/06, Ali Sadik Kumlali [EMAIL PROTECTED] wrote: Thanks Thilina. Do I have a chance to test my codebase which uses Axis2 1.0(Rampart included) against Axis2 1.1 RC1(Rampart excluded) by adding Rampart externally somehow? Or am I required to wait till Axis2 1.1 and then Rampart has been released? Regards, Ali Sadik Kumlali - Original Message From: Thilina Gunarathne [EMAIL PROTECTED] To: axis-dev@ws.apache.org Sent: Tuesday, October 10, 2006 2:24:38 AM Subject: Re: [Axis2][1.1-RC1] Security sample is not included We will not be releasing the security stuff (Rampart,Rahas) with Axis2 1.1. They will be released separately after the Axis2 1.1 release.. ~Thilina On 10/10/06, Ali Sadik Kumlali [EMAIL PROTECTED] wrote: Hi devs, I haven't seen the security sample within the nightlies for a while. And it isn't included in the 1.1 RC1, either. Is it a known issue? Regards, Ali Sadik Kumlali - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://webservices.apache.org/~thilina/ http://thilinag.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://webservices.apache.org/~thilina/ http://thilinag.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Proposal to add return type to Handler.invoke(...)
+1 from me.
On 10/10/06, Srinath Perera [EMAIL PROTECTED] wrote:
+1
On 10/9/06, Bill Nagy [EMAIL PROTECTED] wrote:
There is currently a race condition between code that pauses the message
flow within a handler and resumes it on another thread (e.g. Sandesha)
and the message flow processing chain (Phase.invoke(...),
AxisEngine.invoke(...), etc.)
(http://issues.apache.org/jira/browse/SANDESHA2-32) This is caused
because the control of processing is keyed off of MessageContext.paused
and not through some other mechanism (return code, semaphore, etc.). If
a handler pauses a message and returns, handing the message off to
another thread for execution, there is the possibility that the new
execution thread will resume processing of the message, unsetting
MessageContext.paused, before control returns to one of the invoke
methods. If this happens, the logic in the invoke method, which looks
at the MessageContext.paused flag, will believe that it should continue
execution instead of halting.
Since the problem revolves around flow control logic, I suggest that we
use the return code from the method invocation to deal with it. I would
like to add a return code to the Handler.invoke(...) which would
identify how processing of the message should proceed, e.g. :
/**
* This type encapsulates an enumeration of possible message processing
* instruction values that may be returned by a handler/phase within the
* runtime.
*/
public class InvocationProcessingInstruction
{
public static InvocationProcessingInstruction CONTINUE_PROCESSING =
new InvocationProcessingInstruction(0);
public static InvocationProcessingInstruction SUSPEND_PROCESSING = new
InvocationProcessingInstruction(1);
public static InvocationProcessingInstruction ABORT_PROCESSING = new
InvocationProcessingInstruction(2);
private int instructionID;
private InvocationProcessingInstruction(int instructionID)
{
this.instructionID = instructionID;
}
public boolean equals(InvocationProcessingInstruction instruction)
{
return this.instructionID == instruction.instructionID;
}
public int hashCode()
{
return instructionID;
}
}
Most handlers will return
InvocationProcessingInstruction.CONTINUE_PROCESSING; the RM handler may
return that, SUSPEND_PROCESSING (for a pause), or ABORT_PROCESSING (for
a duplicate msg.)
Comments?
-Bill
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Srinath Perera:
Indiana University, Bloomington
http://www.cs.indiana.edu/~hperera/
http://www.bloglines.com/blog/hemapani
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Deleted: (AXIS2-1335) Code Generation Exception occurred when Generating Clients
Out of curiosity why gets an issue deleted without comment? Greetings Franz Davanum Srinivas (JIRA) schrieb: [ http://issues.apache.org/jira/browse/AXIS2-1335?page=all ] Davanum Srinivas deleted AXIS2-1335: Code Generation Exception occurred when Generating Clients -- Key: AXIS2-1335 URL: http://issues.apache.org/jira/browse/AXIS2-1335 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Environment: Windows XP, jdk1.5.0_08, Maven 1.0.2, Mozilla Firefox 1.5.0.6 Reporter: Evanthika Amarasiri Priority: Critical 1. Login to the Tungsten Management Console 2. Click on the link "Services" which is on the left pane of the page 3. Click on the link "Generate Client" 4. Select the following "Stub Generation options" to create the stub a) Port - CommodityQuoteSOAP11port_https b) Invocation Style - Both c) Databinding - ADB d) Unpack Classes - True e) Unwrap - True f) Generate Testcase - False 5. Select the above options and click on the button "Generate" (You can change the values of any other option but the value of the option "Unwrap" should be set to "True" and the port should be either CommodityQuoteSOAP11port_https or CommodityQuoteSOAP11port_http1) 6. A Code Generation Exception is thrown ERROR [2006-10-10 16:12:49,343] Error occurred during code generation. Unsupported Schema format fo r unwrapping! found unknown but expected sequence org.apache.axis2.wsdl.codegen.CodeGenerationException: org.apache.axis2.wsdl.codegen.CodeGenerationE xception: Unsupported Schema format for unwrapping! found unknown but expected sequence at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224 ) at com.wso2.tungsten.admin.service.wsdl2code.WSDL2CodeService.generate(WSDL2CodeService.java :154) at com.wso2.tungsten.admin.service.wsdl2code.WSDL2CodeServiceMessageReceiverInOut.invokeBusi nessLogic(WSDL2CodeServiceMessageReceiverInOut.java:55) at org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.receive(AbstractInOutSyncMess ageReceiver.java:39) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:493) at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUt ils.java:323) at org.apache.axis2.transport.http.util.SOAPUtil.processPostRequest(SOAPUtil.java:57) at com.wso2.tungsten.transport.jetty.Axis2SOAPHandler.processPostRequest(Axis2SOAPHandler.ja va:42) at com.wso2.tungsten.transport.jetty.Axis2Handler.dispatch(Axis2Handler.java:175) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) at org.mortbay.http.HttpServer.service(HttpServer.java:909) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) Caused by: org.apache.axis2.wsdl.codegen.CodeGenerationException: Unsupported Schema format for unwr apping! found unknown but expected sequence at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.processXMLSchemaSequence (SchemaUnwrapperExtension.java:287) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.handleAllCasesOfComplexT ypes(SchemaUnwrapperExtension.java:164) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.walkSchema(SchemaUnwrapp erExtension.java:122) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.engage(SchemaUnwrapperEx tension.java:87) at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:177 ) ... 18 more ERROR [2006-10-10 16:12:49,343] org.apache.axis2.AxisFault: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown but expected sequence; nested exception is: java.lang.RuntimeException: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown but expected sequence; nested exception is: org.apache.axis2.AxisFault: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown but expected sequence; nested exception is: java.lang.RuntimeException: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown but
RE: Apache Axis 1.6b
Wow ! Excellent - well done and thanks ! I suggest you create a JIRA and attach the files to that. Haiping Zhao [EMAIL PROTECTED] 09/10/2006 18:06 Please respond to axis-dev@ws.apache.org To axis-dev@ws.apache.org cc Subject RE: Apache Axis 1.6b Hi, We have adopted Apache Axis C++ 1.6b since around Februry of this year, and we have made quite a few bug fixes and improvements. Where can I submit those? Here are some of them, 1. Fixed incorrect large packet handling in three transports: apache 2.0 transport, simple axis transport and axis client transport. 2. Fixed XML unrepresentable character handling on outbound. 3. Fixed a crash on apache shutdown from module unloading. 4. Fixed some bugs from code generation tool wsdl2ws: (1) incorrect all parsing; (2) weak choice parsing; (3) missing required element checking; (4) bad header include when array is xsd__string_array; (5) wrong xsd__int enumeration code; (6) memory leaking code. 5. Fixed bugs in XMLParserXerces.cpp: (1) not throwing SAX parser exceptions; (2) incorrect end tag handling. 6. Supporting JSON and XML input and output, in addition to SOAP ones. 7. Supporting pretty print of SOAP/XML/JSON formats. 8. Supporting getting IP address and HTTP cookies from transport layer. Haiping Zhao Computer never make mistakes. 赵海平 Server Architect Plaxo, inc. tel: mobile: (650) 810-1093 (650) 248-4587 Add me to your address book... Want a signature like this?
[jira] Created: (AXIS2-1336) Code Generation Exception occurred when Generating stubs
Code Generation Exception occurred when Generating stubs Key: AXIS2-1336 URL: http://issues.apache.org/jira/browse/AXIS2-1336 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Affects Versions: 1.1 Environment: Windows XP, jdk1.5.0_08, Maven 1.0.2, Mozilla Firefox 1.5.0.6 Reporter: Evanthika Amarasiri Priority: Critical 1. Tried to create a stub using the following command wsdl2java.bat -uri \wsdl\CommodityQuote.wsdl -p com.wso2.tungsten.client -d adb -u true -t -uw true 2. The following exception occured Exception in thread main org.apache.axis2.wsdl.codegen.CodeGenerationException: org.apache.axis2.wsdl.codegen.CodeGenerationException: Unsupported S chema format for unwrapping! found unknown but expected sequence at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224) at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:32) at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:21) Caused by: org.apache.axis2.wsdl.codegen.CodeGenerationException: Unsupported Schema format for unwrapping! found unknown but expected sequence at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.processXMLSchemaSequence(SchemaUnwrapperExtension.java:287) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.handleAllCasesOfComplexTypes(SchemaUnwrapperExtension.java:164) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.walkSchema(SchemaUnwrapperExtension.java:122) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.engage(SchemaUnwrapperExtension.java:87) at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:177) ... 2 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-1337) Null value is returned when accessing the 'List Single Service' page of an available service group
Null value is returned when accessing the 'List Single Service' page of an available service group -- Key: AXIS2-1337 URL: http://issues.apache.org/jira/browse/AXIS2-1337 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Affects Versions: 1.1 Environment: Axis2 1.1 RC1, Mozilla FireFox 1.5.0.7, Apach Tomcat 5.5.16, JDK 1.5 Reporter: Charitha Kankanamge Note that this issue occurs when accessing the 'List Single Service' page through FireFox only. This will not occur with IE. Steps to reproduce: 1. Deploy a service 2. Navigate to the 'Available Service Group' page in the admin console (Access through Mozilla FireFox 1.5.0.7) 3. Click on a link of a deployed service Actual Result: == Null value is returned and following text can be seen in the page. 'List Single service This Web axisService has deployment faults null' Expected Result: Service should be listed with available operations Please check the screen shots taken from the same service accessed through FireFox 1.5.0.7 and IE 6.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
WS Addressing :: Issue with setting ReplyTo :: Axis2-1.1-SNAPSHOT
Hi All, I am trying to explore WS Addressing by creating a flow in which i call a WS (INOUT-with NonBlockingDual client) and then i want the response to be directed to another WS on a different port and server. I have explicitly set the To/ReplyTo in my client. In the resluting SOAP request the wsa:To parmeter gets set based on what i mentioned but somehow the wsa:ReplyTo is set to the default listener address !! I have also set:: options.setProperty(AddressingConstants.REPLACE_ADDRESSING_HEADERS, Boolean.TRUE) and then am setting replyto as :: options.setTo(targetEPR); options.setReplyTo(targetReplyEPR); options.setTransportInProtocol(Constants.TRANSPORT_HTTP); i also tried :: options.setProperty(AddressingConstants.WSA_REPLY_TO, targetReplyEPR); but what i found after looking at the source code was that in the message context itself the replyTo address is set to default whereas the To address is set based on what i mentioned. Kindly guide me as to what am i supposed to do. Regards, Vaibhav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-1338) Code generation drops the element which holds an xsd:anyType element at both client and server sides
Code generation drops the element which holds an xsd:anyType element at both client and server sides Key: AXIS2-1338 URL: http://issues.apache.org/jira/browse/AXIS2-1338 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: adb Environment: Axis2 1.1 RC-1 Reporter: Asankha C. Perera The following is a fragment from the WSDL used (attached to the JIRA). The element value is of type xsd:anyType complexType name=NamedValue sequence element name=name nillable=true type=xsd:string/ element name=value nillable=true type=xsd:anyType/ /sequence /complexType complexType name=MyComplexType2 sequence element name=username type=xsd:string/ element name=password type=xsd:string/ element name=options type=tns1:NamedValue maxOccurs=unbounded/ element name=userAttributes type=tns1:AttributeRequest maxOccurs=unbounded/ /sequence /complexType Codegen using -o outputpath -s -t -ss -sd -g -uri echo.wsdl and use attached client and server skeleton implementations to test. On TCPMon the SOAP request sent is as follows: ns1:options ns1:nameRequest NV1 name/ns1:name foo:requestValue1 xmlns:foo=requestFoo / /ns1:options When a correct request of the form shown below is sent to the server: ns1:options ns1:nameRequest NV1 name/ns1:name ns1:valuefoo:requestValue1 xmlns:foo=requestFoo //ns1:value /ns1:options The server replies as: ns1:MyElement2Response xmlns:ns1=http://types.echo.services; ns1:loginReturn ns1:nameResponse NV1 name/ns1:name bar:responseValue1 xmlns:bar=responseBar / /ns1:loginReturn Again, thw WSDL defines the response as follows: element name=MyElement2Response complexType sequence element name=loginReturn type=tns1:NamedValue maxOccurs=unbounded/ /sequence /complexType /element -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-1338) Code generation drops the element which holds an xsd:anyType element at both client and server sides
[ http://issues.apache.org/jira/browse/AXIS2-1338?page=all ] Asankha C. Perera updated AXIS2-1338: - Attachment: echo.wsdl ComplexEchoServiceSkeleton.java ComplexEchoServiceTest.java Code generation drops the element which holds an xsd:anyType element at both client and server sides Key: AXIS2-1338 URL: http://issues.apache.org/jira/browse/AXIS2-1338 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: adb Environment: Axis2 1.1 RC-1 Reporter: Asankha C. Perera Attachments: AbstractTestCase.java, ComplexEchoServiceSkeleton.java, ComplexEchoServiceTest.java, echo.wsdl The following is a fragment from the WSDL used (attached to the JIRA). The element value is of type xsd:anyType complexType name=NamedValue sequence element name=name nillable=true type=xsd:string/ element name=value nillable=true type=xsd:anyType/ /sequence /complexType complexType name=MyComplexType2 sequence element name=username type=xsd:string/ element name=password type=xsd:string/ element name=options type=tns1:NamedValue maxOccurs=unbounded/ element name=userAttributes type=tns1:AttributeRequest maxOccurs=unbounded/ /sequence /complexType Codegen using -o outputpath -s -t -ss -sd -g -uri echo.wsdl and use attached client and server skeleton implementations to test. On TCPMon the SOAP request sent is as follows: ns1:options ns1:nameRequest NV1 name/ns1:name foo:requestValue1 xmlns:foo=requestFoo / /ns1:options When a correct request of the form shown below is sent to the server: ns1:options ns1:nameRequest NV1 name/ns1:name ns1:valuefoo:requestValue1 xmlns:foo=requestFoo //ns1:value /ns1:options The server replies as: ns1:MyElement2Response xmlns:ns1=http://types.echo.services; ns1:loginReturn ns1:nameResponse NV1 name/ns1:name bar:responseValue1 xmlns:bar=responseBar / /ns1:loginReturn Again, thw WSDL defines the response as follows: element name=MyElement2Response complexType sequence element name=loginReturn type=tns1:NamedValue maxOccurs=unbounded/ /sequence /complexType /element -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-1338) Code generation drops the element which holds an xsd:anyType element at both client and server sides
[ http://issues.apache.org/jira/browse/AXIS2-1338?page=all ] Asankha C. Perera updated AXIS2-1338: - Attachment: AbstractTestCase.java Code generation drops the element which holds an xsd:anyType element at both client and server sides Key: AXIS2-1338 URL: http://issues.apache.org/jira/browse/AXIS2-1338 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: adb Environment: Axis2 1.1 RC-1 Reporter: Asankha C. Perera Attachments: AbstractTestCase.java, ComplexEchoServiceSkeleton.java, ComplexEchoServiceTest.java, echo.wsdl The following is a fragment from the WSDL used (attached to the JIRA). The element value is of type xsd:anyType complexType name=NamedValue sequence element name=name nillable=true type=xsd:string/ element name=value nillable=true type=xsd:anyType/ /sequence /complexType complexType name=MyComplexType2 sequence element name=username type=xsd:string/ element name=password type=xsd:string/ element name=options type=tns1:NamedValue maxOccurs=unbounded/ element name=userAttributes type=tns1:AttributeRequest maxOccurs=unbounded/ /sequence /complexType Codegen using -o outputpath -s -t -ss -sd -g -uri echo.wsdl and use attached client and server skeleton implementations to test. On TCPMon the SOAP request sent is as follows: ns1:options ns1:nameRequest NV1 name/ns1:name foo:requestValue1 xmlns:foo=requestFoo / /ns1:options When a correct request of the form shown below is sent to the server: ns1:options ns1:nameRequest NV1 name/ns1:name ns1:valuefoo:requestValue1 xmlns:foo=requestFoo //ns1:value /ns1:options The server replies as: ns1:MyElement2Response xmlns:ns1=http://types.echo.services; ns1:loginReturn ns1:nameResponse NV1 name/ns1:name bar:responseValue1 xmlns:bar=responseBar / /ns1:loginReturn Again, thw WSDL defines the response as follows: element name=MyElement2Response complexType sequence element name=loginReturn type=tns1:NamedValue maxOccurs=unbounded/ /sequence /complexType /element -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Deleted: (AXIS2-1335) Code Generation Exception occurred when Generating Clients
Franz, the delete button in JIRA does not allow us to add comments as the comments are part of the issue that is to be deleted :) -- dims On 10/10/06, Franz Fehringer [EMAIL PROTECTED] wrote: Out of curiosity why gets an issue deleted without comment? Greetings Franz Davanum Srinivas (JIRA) schrieb: [ http://issues.apache.org/jira/browse/AXIS2-1335?page=all ] Davanum Srinivas deleted AXIS2-1335: Code Generation Exception occurred when Generating Clients -- Key: AXIS2-1335 URL: http://issues.apache.org/jira/browse/AXIS2-1335 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Environment: Windows XP, jdk1.5.0_08, Maven 1.0.2, Mozilla Firefox 1.5.0.6 Reporter: Evanthika Amarasiri Priority: Critical 1. Login to the Tungsten Management Console 2. Click on the link Services which is on the left pane of the page 3. Click on the link Generate Client 4. Select the following Stub Generation options to create the stub a) Port - CommodityQuoteSOAP11port_https b) Invocation Style - Both c) Databinding - ADB d) Unpack Classes - True e) Unwrap - True f) Generate Testcase - False 5. Select the above options and click on the button Generate (You can change the values of any other option but the value of the option Unwrap should be set to True and the port should be either CommodityQuoteSOAP11port_https or CommodityQuoteSOAP11port_http1) 6. A Code Generation Exception is thrown ERROR [2006-10-10 16:12:49,343] Error occurred during code generation. Unsupported Schema format fo r unwrapping! found unknown but expected sequence org.apache.axis2.wsdl.codegen.CodeGenerationException: org.apache.axis2.wsdl.codegen.CodeGenerationE xception: Unsupported Schema format for unwrapping! found unknown but expected sequence at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224 ) at com.wso2.tungsten.admin.service.wsdl2code.WSDL2CodeService.generate(WSDL2CodeService.java :154) at com.wso2.tungsten.admin.service.wsdl2code.WSDL2CodeServiceMessageReceiverInOut.invokeBusi nessLogic(WSDL2CodeServiceMessageReceiverInOut.java:55) at org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.receive(AbstractInOutSyncMess ageReceiver.java:39) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:493) at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUt ils.java:323) at org.apache.axis2.transport.http.util.SOAPUtil.processPostRequest(SOAPUtil.java:57) at com.wso2.tungsten.transport.jetty.Axis2SOAPHandler.processPostRequest(Axis2SOAPHandler.ja va:42) at com.wso2.tungsten.transport.jetty.Axis2Handler.dispatch(Axis2Handler.java:175) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) at org.mortbay.http.HttpServer.service(HttpServer.java:909) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) Caused by: org.apache.axis2.wsdl.codegen.CodeGenerationException: Unsupported Schema format for unwr apping! found unknown but expected sequence at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.processXMLSchemaSequence (SchemaUnwrapperExtension.java:287) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.handleAllCasesOfComplexT ypes(SchemaUnwrapperExtension.java:164) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.walkSchema(SchemaUnwrapp erExtension.java:122) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.engage(SchemaUnwrapperEx tension.java:87) at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:177 ) ... 18 more ERROR [2006-10-10 16:12:49,343] org.apache.axis2.AxisFault: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown but expected sequence; nested exception is: java.lang.RuntimeException: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown but expected sequence; nested exception is: org.apache.axis2.AxisFault: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown but expected sequence; nested exception is: java.lang.RuntimeException: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown but expected sequence ERROR [2006-10-10 16:12:49,343] Unable to handle request com.wso2.tungsten.TungstenException: org.apache.axis2.AxisFault:
Re: [jira] Deleted: (AXIS2-1335) Code Generation Exception occurred when Generating Clients
And what was wrong with this issue i.e. why got it deleted? Franz Davanum Srinivas schrieb: Franz, the delete button in JIRA does not allow us to add comments as the comments are part of the issue that is to be deleted :) -- dims On 10/10/06, Franz Fehringer [EMAIL PROTECTED] wrote: Out of curiosity why gets an issue deleted without comment? Greetings Franz Davanum Srinivas (JIRA) schrieb: [ http://issues.apache.org/jira/browse/AXIS2-1335?page=all ] Davanum Srinivas deleted AXIS2-1335: Code Generation Exception occurred when Generating Clients -- Key: AXIS2-1335 URL: http://issues.apache.org/jira/browse/AXIS2-1335 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Environment: Windows XP, jdk1.5.0_08, Maven 1.0.2, Mozilla Firefox 1.5.0.6 Reporter: Evanthika Amarasiri Priority: Critical 1. Login to the Tungsten Management Console 2. Click on the link Services which is on the left pane of the page 3. Click on the link Generate Client 4. Select the following Stub Generation options to create the stub a) Port - CommodityQuoteSOAP11port_https b) Invocation Style - Both c) Databinding - ADB d) Unpack Classes - True e) Unwrap - True f) Generate Testcase - False 5. Select the above options and click on the button Generate (You can change the values of any other option but the value of the option Unwrap should be set to True and the port should be either CommodityQuoteSOAP11port_https or CommodityQuoteSOAP11port_http1) 6. A Code Generation Exception is thrown ERROR [2006-10-10 16:12:49,343] Error occurred during code generation. Unsupported Schema format fo r unwrapping! found unknown but expected sequence org.apache.axis2.wsdl.codegen.CodeGenerationException: org.apache.axis2.wsdl.codegen.CodeGenerationE xception: Unsupported Schema format for unwrapping! found unknown but expected sequence at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224 ) at com.wso2.tungsten.admin.service.wsdl2code.WSDL2CodeService.generate(WSDL2CodeService.java :154) at com.wso2.tungsten.admin.service.wsdl2code.WSDL2CodeServiceMessageReceiverInOut.invokeBusi nessLogic(WSDL2CodeServiceMessageReceiverInOut.java:55) at org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.receive(AbstractInOutSyncMess ageReceiver.java:39) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:493) at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUt ils.java:323) at org.apache.axis2.transport.http.util.SOAPUtil.processPostRequest(SOAPUtil.java:57) at com.wso2.tungsten.transport.jetty.Axis2SOAPHandler.processPostRequest(Axis2SOAPHandler.ja va:42) at com.wso2.tungsten.transport.jetty.Axis2Handler.dispatch(Axis2Handler.java:175) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) at org.mortbay.http.HttpServer.service(HttpServer.java:909) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) Caused by: org.apache.axis2.wsdl.codegen.CodeGenerationException: Unsupported Schema format for unwr apping! found unknown but expected sequence at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.processXMLSchemaSequence (SchemaUnwrapperExtension.java:287) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.handleAllCasesOfComplexT ypes(SchemaUnwrapperExtension.java:164) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.walkSchema(SchemaUnwrapp erExtension.java:122) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.engage(SchemaUnwrapperEx tension.java:87) at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:177 ) ... 18 more ERROR [2006-10-10 16:12:49,343] org.apache.axis2.AxisFault: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown but expected sequence; nested exception is: java.lang.RuntimeException: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown but expected sequence; nested exception is: org.apache.axis2.AxisFault: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown but expected sequence; nested exception is: java.lang.RuntimeException: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown
Re: [Axis2][1.1-RC1] Security sample is not included
On Tue, 2006-10-10 at 07:15 -0400, Davanum Srinivas wrote: Thilina, if i add snapshots to the name, the mar wont load :( -- dims On 10/10/06, Thilina Gunarathne [EMAIL PROTECTED] wrote: I would not recommend you to try mixing the stuff between 1.0 and 1.1... You can try the snapshots together with 1.1-RC1... http://people.apache.org/repository/org.apache.axis2/mars/rampart-1.1.mar IMO this version number is wrong.. Should be 1.1-snapshots.. s/rampart-1.1.mar/rampart-SNAPSHOT-1.1.mar/g ?? Sanjiva. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Deleted: (AXIS2-1335) Code Generation Exception occurred when Generating Clients
Franz, I asked the reporter (a colleague) to open an issue using just the WSDL2Java bat file and not using a product/gui. Here's the new issue: http://issues.apache.org/jira/browse/AXIS2-1336 thanks, dims On 10/10/06, Franz Fehringer [EMAIL PROTECTED] wrote: And what was wrong with this issue i.e. why got it deleted? Franz Davanum Srinivas schrieb: Franz, the delete button in JIRA does not allow us to add comments as the comments are part of the issue that is to be deleted :) -- dims On 10/10/06, Franz Fehringer [EMAIL PROTECTED] wrote: Out of curiosity why gets an issue deleted without comment? Greetings Franz Davanum Srinivas (JIRA) schrieb: [ http://issues.apache.org/jira/browse/AXIS2-1335?page=all ] Davanum Srinivas deleted AXIS2-1335: Code Generation Exception occurred when Generating Clients -- Key: AXIS2-1335 URL: http://issues.apache.org/jira/browse/AXIS2-1335 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Environment: Windows XP, jdk1.5.0_08, Maven 1.0.2, Mozilla Firefox 1.5.0.6 Reporter: Evanthika Amarasiri Priority: Critical 1. Login to the Tungsten Management Console 2. Click on the link Services which is on the left pane of the page 3. Click on the link Generate Client 4. Select the following Stub Generation options to create the stub a) Port - CommodityQuoteSOAP11port_https b) Invocation Style - Both c) Databinding - ADB d) Unpack Classes - True e) Unwrap - True f) Generate Testcase - False 5. Select the above options and click on the button Generate (You can change the values of any other option but the value of the option Unwrap should be set to True and the port should be either CommodityQuoteSOAP11port_https or CommodityQuoteSOAP11port_http1) 6. A Code Generation Exception is thrown ERROR [2006-10-10 16:12:49,343] Error occurred during code generation. Unsupported Schema format fo r unwrapping! found unknown but expected sequence org.apache.axis2.wsdl.codegen.CodeGenerationException: org.apache.axis2.wsdl.codegen.CodeGenerationE xception: Unsupported Schema format for unwrapping! found unknown but expected sequence at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224 ) at com.wso2.tungsten.admin.service.wsdl2code.WSDL2CodeService.generate(WSDL2CodeService.java :154) at com.wso2.tungsten.admin.service.wsdl2code.WSDL2CodeServiceMessageReceiverInOut.invokeBusi nessLogic(WSDL2CodeServiceMessageReceiverInOut.java:55) at org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.receive(AbstractInOutSyncMess ageReceiver.java:39) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:493) at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUt ils.java:323) at org.apache.axis2.transport.http.util.SOAPUtil.processPostRequest(SOAPUtil.java:57) at com.wso2.tungsten.transport.jetty.Axis2SOAPHandler.processPostRequest(Axis2SOAPHandler.ja va:42) at com.wso2.tungsten.transport.jetty.Axis2Handler.dispatch(Axis2Handler.java:175) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) at org.mortbay.http.HttpServer.service(HttpServer.java:909) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) Caused by: org.apache.axis2.wsdl.codegen.CodeGenerationException: Unsupported Schema format for unwr apping! found unknown but expected sequence at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.processXMLSchemaSequence (SchemaUnwrapperExtension.java:287) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.handleAllCasesOfComplexT ypes(SchemaUnwrapperExtension.java:164) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.walkSchema(SchemaUnwrapp erExtension.java:122) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.engage(SchemaUnwrapperEx tension.java:87) at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:177 ) ... 18 more ERROR [2006-10-10 16:12:49,343] org.apache.axis2.AxisFault: Error occurred during code generation. Unsupported Schema format for unwrapping! found unknown but expected sequence; nested exception is: java.lang.RuntimeException: Error occurred during code generation. Unsupported Schema format for
Re: [Axis2] Proposal to add return type to Handler.invoke(...)
On Mon, 2006-10-09 at 19:51 -0700, Bill Nagy wrote:
There is currently a race condition between code that pauses the message
flow within a handler and resumes it on another thread (e.g. Sandesha)
and the message flow processing chain (Phase.invoke(...),
AxisEngine.invoke(...), etc.)
(http://issues.apache.org/jira/browse/SANDESHA2-32) This is caused
because the control of processing is keyed off of MessageContext.paused
and not through some other mechanism (return code, semaphore, etc.). If
a handler pauses a message and returns, handing the message off to
another thread for execution, there is the possibility that the new
execution thread will resume processing of the message, unsetting
MessageContext.paused, before control returns to one of the invoke
methods. If this happens, the logic in the invoke method, which looks
at the MessageContext.paused flag, will believe that it should continue
execution instead of halting.
Can't this be solved by synchronizing access to MessageContext.paused()?
Sorry I looked at the sandesha issue but didn't see it.
Alternatively,
synchronized {
h.invoke();
h.getPaused();
}
I must be missing something obvious as to why this doesn't work.
Since the problem revolves around flow control logic, I suggest that we
use the return code from the method invocation to deal with it. I would
like to add a return code to the Handler.invoke(...) which would
identify how processing of the message should proceed, e.g. :
How does this solve the problem as other thread could go get the MC and
do stuff while still in this method?
/**
* This type encapsulates an enumeration of possible message processing
* instruction values that may be returned by a handler/phase within the
* runtime.
*/
public class InvocationProcessingInstruction
{
public static InvocationProcessingInstruction CONTINUE_PROCESSING =
new InvocationProcessingInstruction(0);
public static InvocationProcessingInstruction SUSPEND_PROCESSING = new
InvocationProcessingInstruction(1);
public static InvocationProcessingInstruction ABORT_PROCESSING = new
InvocationProcessingInstruction(2);
private int instructionID;
private InvocationProcessingInstruction(int instructionID)
{
this.instructionID = instructionID;
}
public boolean equals(InvocationProcessingInstruction instruction)
{
return this.instructionID == instruction.instructionID;
}
public int hashCode()
{
return instructionID;
}
}
Most handlers will return
InvocationProcessingInstruction.CONTINUE_PROCESSING; the RM handler may
return that, SUSPEND_PROCESSING (for a pause), or ABORT_PROCESSING (for
a duplicate msg.)
I must be really jetlagged (traveling again): do we need all this or
just use an int to return the status?? (some consts basically).
Sanjiva.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2][1.1-RC1] Security sample is not included
Will that load when dropped as-is into a repo? I remember we nixed the SNAPSHOT off the name of the mar to prevent such problems. -- dims On 10/10/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: On Tue, 2006-10-10 at 07:15 -0400, Davanum Srinivas wrote: Thilina, if i add snapshots to the name, the mar wont load :( -- dims On 10/10/06, Thilina Gunarathne [EMAIL PROTECTED] wrote: I would not recommend you to try mixing the stuff between 1.0 and 1.1... You can try the snapshots together with 1.1-RC1... http://people.apache.org/repository/org.apache.axis2/mars/rampart-1.1.mar IMO this version number is wrong.. Should be 1.1-snapshots.. s/rampart-1.1.mar/rampart-SNAPSHOT-1.1.mar/g ?? Sanjiva. -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-1334) Deployment of Sandesha2 causes exception in Axis2 Admin-Frontend
[ http://issues.apache.org/jira/browse/AXIS2-1334?page=all ] Davanum Srinivas updated AXIS2-1334: Priority: Critical (was: Blocker) Not a blocker. -- dims Deployment of Sandesha2 causes exception in Axis2 Admin-Frontend Key: AXIS2-1334 URL: http://issues.apache.org/jira/browse/AXIS2-1334 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: core Affects Versions: 1.1 Environment: Axis2 1.1 RC1 Sandesha2 1.0 Reporter: Thilo Frotscher Priority: Critical - deploy a fresh Axis2 1.1 RC1 into Tomcat - startup Tomcat - check out Axis2 Web Admin Frontend with browser - works fine! - shut down Tomcat - copy sandesha2-1.0.mar into WEB-INF/modules - add name of module archive to modules.list (not sure if this step is needed, but bug occurs with or without this step!) - add RMPhase to all four flows, according to Sandesha2 user guide: http://ws.apache.org/sandesha/sandesha2/userGuide.html - start up Tomcat - check out Axis2 Web Admin Frontend with browser - Exception! TOMCAT's LOG FILE = java.lang.NoSuchMethodError: org.apache.axis2.description.PolicyInclude.getEffectivePolicy()Lorg/apache/ws/policy/Policy; at org.apache.sandesha2.util.PropertyManager.loadPropertiesFromModuleDescPolicy(PropertyManager.java:158) at org.apache.sandesha2.SandeshaModule.init(SandeshaModule.java:50) at org.apache.axis2.context.ConfigurationContextFactory.initModules(ConfigurationContextFactory.java:217) at org.apache.axis2.context.ConfigurationContextFactory.init(ConfigurationContextFactory.java:193) at org.apache.axis2.context.ConfigurationContextFactory.createConfigurationContext(ConfigurationContextFactory.java:70) at org.apache.axis2.transport.http.AxisServlet.initConfigContext(AxisServlet.java:366) at org.apache.axis2.transport.http.AxisServlet.init(AxisServlet.java:304) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1105) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:932) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3917) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4197) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:809) at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:698) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:472) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1112) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1021) at org.apache.catalina.core.StandardHost.start(StandardHost.java:718) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442) at org.apache.catalina.core.StandardService.start(StandardService.java:450) at org.apache.catalina.core.StandardServer.start(StandardServer.java:709) at org.apache.catalina.startup.Catalina.start(Catalina.java:551) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:275) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) BROWSER === org.apache.jasper.JasperException org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:510) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:375) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) root cause org.apache.jasper.JasperException org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:510) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:393)
Re: [Axis2][1.1-RC1] Security sample is not included
On Tue, 2006-10-10 at 08:57 -0400, Davanum Srinivas wrote: Will that load when dropped as-is into a repo? I remember we nixed the SNAPSHOT off the name of the mar to prevent such problems. You'd have to engage as rampart-SNAPSHOT but otherwise should work fine. Deepal?? Sanjiva. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-1252) java2wsdl generates unknown namespace
[ http://issues.apache.org/jira/browse/AXIS2-1252?page=comments#action_12441139 ] Davanum Srinivas commented on AXIS2-1252: - Venkat, Kinichiro, Deepal, I think we need the ability to specify a namespace/pakage mapping to fully control the schema generation. What do you think about the following algorithm: #1: If ONE schematargetnamespace is specified then push all types to that namespace. Throw an error and exit on collision. #2: If MANY schematargetnamespace/package name mappings are specified, then push types to specified namespaces. Again, Throw an error on collision. #3: If NO schematargetnamespace or mappings specified, then auto generate namespaces from packages. Hopefully there will be no collisions. We need full control over this from both java2wsdl command line and from services.xml. Please note that there is runtime support we need to enhance too when we change to this model/algo. Specifically when we serialize/deserialize we need to take into account the schema namespaces as the user has specified. Will this solve all issues? Did i miss anything? Thanks, dims java2wsdl generates unknown namespace - Key: AXIS2-1252 URL: http://issues.apache.org/jira/browse/AXIS2-1252 Project: Apache Axis 2.0 (Axis2) Issue Type: Improvement Components: wsdl Reporter: Kinichiro Inoguchi Priority: Blocker This issue comes from user mailing list. http://marc.theaimsgroup.com/?t=11593771594r=1w=2 java2wsdl generates unknown namespace, http://test/xsd;. I'm using current nightly. My service class has method sayHello, and returns array of simple java beans HelloBean. Then I run java2wsdl, sayHello and sayHelloResponse are in namespace http://aaa.bbb/types;. But, HelloBean is in unknown namespace http://test/xsd;. Is this a bug ? C:\axis2-std-SNAPSHOT-bin\bin\java2wsdl.bat -cn test.TestService1 -cp . -tn http://aaa.bbb -tp xxx -stn http://aaa.bbb/types -stp yyy -sn TestService1 -of TestService1.wsdl generated WSDL is like this; wsdl:definitions xmlns:soap12=http://schemas.xmlsoap.org/wsdl/soap12/; xmlns:http=http://schemas.xmlsoap.org/wsdl/http/; xmlns:mime=http://schemas.xmlsoap.org/wsdl/mime/; xmlns:ns1=http://aaa.bbb/types; xmlns:xxx=http://aaa.bbb; xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/; xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/; targetNamespace=http://aaa.bbb; wsdl:types xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns:ax22=http://test/xsd; targetNamespace=http://test/xsd; attributeFormDefault=qualified elementFormDefault=qualified xs:element name=HelloBean type=ax22:HelloBean / xs:complexType name=HelloBean xs:sequence xs:element name=ret1 type=xs:string / xs:element name=ret2 type=xs:int / xs:element name=ret3 type=xs:long / xs:element name=ret4 type=xs:double / xs:element name=ret5 type=xs:float / xs:element name=ret6 type=xs:short / xs:element name=ret7 type=xs:boolean / /xs:sequence /xs:complexType /xs:schema xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns:gen798=http://test/xsd; xmlns:ax21=http://aaa.bbb/types; targetNamespace=http://aaa.bbb/types; attributeFormDefault=qualified elementFormDefault=qualified xs:element name=sayHello xs:complexType xs:sequence xs:element name=var1 type=xs:string / xs:element name=var2 type=xs:int / xs:element name=var3 type=xs:long / xs:element name=var4 type=xs:double / xs:element name=var5 type=xs:float / xs:element name=var6 type=xs:short / xs:element name=var7 type=xs:boolean / /xs:sequence /xs:complexType /xs:element xs:element name=sayHelloResponse xs:complexType xs:sequence xs:element name=return maxOccurs=unbounded type=gen798:HelloBean nillable=true / /xs:sequence /xs:complexType /xs:element /xs:schema /wsdl:types ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [axis2] Improvements to Service life cycle in handling - setOperationContext not thread-safe??!!
I think I agree with you. How about we drop setOperationContext() and introduce Axis1-style MessageContext.getCurrentContext() which returns it for this thread? Have to be careful to put it in TLS and take it off! We must be careful to tell users that instance variables are not supported; you have to use MessageContext properties to store state (or wherever else). Sanjiva. On Sun, 2006-09-24 at 14:12 +0200, Christopher Sahnwaldt wrote: Entered as http://issues.apache.org/jira/browse/AXIS2-1224 . I set the priority to blocker as David suggested. IMHO it's probably best to drop the method. Many users will use it in an intuitive but wrong way. The only way to store the data it provides is an instance variable, and telling users to either use only request scope or use a ThreadLocal to store the data does not seem to be compatible with the rule of least surprise. Something like MessageContext.getCurrentContext() in Axis 1 might be better. Bye, Christopher. Davanum Srinivas wrote: Chris, Can you please raise a new issue in JIRA? thanks, dims On 9/23/06, Christopher Sahnwaldt [EMAIL PROTECTED] wrote: Something worries me: setOperationContext(OperationContext) - per call. The messageContext can be obtained to gain per call instance information. That doesn't seem to be thread-safe, does it? If I understand this correctly, one service object is created per application (if the service has application scope). When a request comes in, Axis calls the setOperationContext method, and the service object may store the OperationContext or the MessageContext. Then Axis calls the actual service method, in which the service code can access the stored OperationContext or MessageContext. But what if two requests come in almost simultaneously? The following sequence of method calls may occur: - Axis calls setOperationContext with context for request A, the service object stores the context in an instance field. - Axis calls setOperationContext with context for request B, the same service object stores the context in the same instance field and thus *overwrites* the context for call A. - Axis calls the service method with the input parameters for request A. - The service method processes the call, using data from the stored context, and thus *mixes the input parameters for call A with the context data for call B*. Anything can happen... - Finally, Axis calls the service method with the input parameters for call B, the service method processes the call, using data from the stored context, and thus correctly uses the input parameters for call B with the context data for call B. Probably ok, unless the service method updated the context in some way during the call for request A. But I hope I'm wrong or misunderstood or forgot something... ;-) Axis 1 avoided this problem by MessageContext.getCurrentContext(), which gives access to the MessageContext *for the current thread* from within any service method, without the need for a setMessageContext (or setOperationContext) method on the service object. Bye, Christopher. Tony Dean wrote: Can we fully document the logical semantics behind each method? init(ServiceContext) - To me this use to mean application init. Now it means session init. However, when running scope=Application, it is analogous to application init since you will only have one session; but, still probably not appropriate to think in those terms. How should an application use this method? A session use-case would be nice. destroy(ServiceContext) - inverse of init() Use-case? setOperationContext(OperationContext) - per call. The messageContext can be obtained to gain per call instance information. StartUp() - one time initialization... DB connections etc... Shutdown() - inverse of StartUp() Any more insight or corrections to pattern usage would be grateful... Thanks. -Original Message- From: robert lazarski [mailto:[EMAIL PROTECTED] Sent: Friday, September 15, 2006 8:49 AM To: axis-dev@ws.apache.org Subject: Re: Improvements to Service life cycle in handling That makes sense to me. I've been using startUp() and it doesn't really fit with the other methods of the interface in its current form. +1 for 1.1 since its interface changes and it'd be better to do it now. One question: Currently you need this in services.xml to get startUp() to invoke: parameter name=load-on-startup locked=falsetrue/parameter I plan on testing this when its ready ... since the spring tutorial depends on it ... so I thought I'd ask if the services.xml param will remain the same. Thanks, Robert On 9/14/06, Deepal Jayasinghe [EMAIL PROTECTED] wrote: Hi All; Currently we have an interface called Service and which has few methods that are
Re: [jira] Commented: (AXIS2-1334) Deployment of Sandesha2 causes exception in Axis2 Admin-Frontend
Hi Thilo, Yes. Sandesha2 1.0 release does not work with the Axis2 1.0 RC1 release. But we hope to do a Sandesha2 release compatible with Axis2 1.1 after it get release. For now you'll have to work with Sandesha2 SNAPSHOTs from http://people.apache.org/repository/sandesha2/ BTW the Sandesha2 releases and compatible Axis2 versions are given here http://ws.apache.org/sandesha/sandesha2/download.cgi Chamikara On 10/10/06, Thilo Frotscher (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/AXIS2-1334?page=comments#action_12441104 ]Thilo Frotscher commented on AXIS2-1334: I investigated further... Sandesha2 1.0 works fine with Axis2 1.0 but not with Axis2 1.1 RC1. But I don't know whether this is an issue with Axis2 1.1 or whether there is just a new Sandesha2 release needed. In the latter case, it should be documented in the Sandesha2 user guide which Sandesha release works with which Axis2 release. Deployment of Sandesha2 causes exception in Axis2 Admin-Frontend Key: AXIS2-1334 URL: http://issues.apache.org/jira/browse/AXIS2-1334 Project: Apache Axis 2.0 (Axis2)Issue Type: BugComponents: core Affects Versions: 1.1 Environment: Axis2 1.1 RC1 Sandesha2 1.0Reporter: Thilo FrotscherPriority: Blocker - deploy a fresh Axis2 1.1 RC1 into Tomcat - startup Tomcat - check out Axis2 Web Admin Frontend with browser - works fine! - shut down Tomcat - copy sandesha2-1.0.mar into WEB-INF/modules - add name of module archive to modules.list (not sure if this step is needed, but bug occurs with or without this step!) - add RMPhase to all four flows, according to Sandesha2 user guide: http://ws.apache.org/sandesha/sandesha2/userGuide.html - start up Tomcat - check out Axis2 Web Admin Frontend with browser - Exception! TOMCAT's LOG FILE = java.lang.NoSuchMethodError : org.apache.axis2.description.PolicyInclude.getEffectivePolicy()Lorg/apache/ws/policy/Policy; at org.apache.sandesha2.util.PropertyManager.loadPropertiesFromModuleDescPolicy(PropertyManager.java:158) at org.apache.sandesha2.SandeshaModule.init(SandeshaModule.java:50) at org.apache.axis2.context.ConfigurationContextFactory.initModules(ConfigurationContextFactory.java:217) at org.apache.axis2.context.ConfigurationContextFactory.init (ConfigurationContextFactory.java:193) at org.apache.axis2.context.ConfigurationContextFactory.createConfigurationContext(ConfigurationContextFactory.java:70) at org.apache.axis2.transport.http.AxisServlet.initConfigContext (AxisServlet.java:366) at org.apache.axis2.transport.http.AxisServlet.init(AxisServlet.java:304) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1105) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:932) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3917) at org.apache.catalina.core.StandardContext.start (StandardContext.java:4197) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:809) at org.apache.catalina.startup.HostConfig.deployWARs (HostConfig.java:698) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:472) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1112) at org.apache.catalina.startup.HostConfig.lifecycleEvent (HostConfig.java:310) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1021) at org.apache.catalina.core.StandardHost.start(StandardHost.java:718) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java :442) at org.apache.catalina.core.StandardService.start(StandardService.java:450) at org.apache.catalina.core.StandardServer.start(StandardServer.java:709) at org.apache.catalina.startup.Catalina.start (Catalina.java:551) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:275) at org.apache.catalina.startup.Bootstrap.main (Bootstrap.java:413) BROWSER === org.apache.jasper.JasperException org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:510) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:375) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) org.apache.jasper.servlet.JspServlet.service
[jira] Commented: (AXIS2-1252) java2wsdl generates unknown namespace
[ http://issues.apache.org/jira/browse/AXIS2-1252?page=comments#action_12441152 ] Kinichiro Inoguchi commented on AXIS2-1252: --- dims, Venkat, Deepal, Thanks for your discussions. I agree with algorithm of dims, and I believe current SVN implements #1 and #3. But I think algorithm #2 seems difficult to use, because I can't imagine how to specify MANY schematargetnamespace. Do you mean like this ? command line option of java2wsdl java2wsdl -stn test1=http://aaa/ -stn test2=http://bbb/ ... services.xml schema pkg=test1 schemaNamespace=http://aaa// schema pkg=test2 schemaNamespace=http://bbb// This examples, test1 and test2 means package of class. java2wsdl generates unknown namespace - Key: AXIS2-1252 URL: http://issues.apache.org/jira/browse/AXIS2-1252 Project: Apache Axis 2.0 (Axis2) Issue Type: Improvement Components: wsdl Reporter: Kinichiro Inoguchi Priority: Blocker This issue comes from user mailing list. http://marc.theaimsgroup.com/?t=11593771594r=1w=2 java2wsdl generates unknown namespace, http://test/xsd;. I'm using current nightly. My service class has method sayHello, and returns array of simple java beans HelloBean. Then I run java2wsdl, sayHello and sayHelloResponse are in namespace http://aaa.bbb/types;. But, HelloBean is in unknown namespace http://test/xsd;. Is this a bug ? C:\axis2-std-SNAPSHOT-bin\bin\java2wsdl.bat -cn test.TestService1 -cp . -tn http://aaa.bbb -tp xxx -stn http://aaa.bbb/types -stp yyy -sn TestService1 -of TestService1.wsdl generated WSDL is like this; wsdl:definitions xmlns:soap12=http://schemas.xmlsoap.org/wsdl/soap12/; xmlns:http=http://schemas.xmlsoap.org/wsdl/http/; xmlns:mime=http://schemas.xmlsoap.org/wsdl/mime/; xmlns:ns1=http://aaa.bbb/types; xmlns:xxx=http://aaa.bbb; xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/; xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/; targetNamespace=http://aaa.bbb; wsdl:types xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns:ax22=http://test/xsd; targetNamespace=http://test/xsd; attributeFormDefault=qualified elementFormDefault=qualified xs:element name=HelloBean type=ax22:HelloBean / xs:complexType name=HelloBean xs:sequence xs:element name=ret1 type=xs:string / xs:element name=ret2 type=xs:int / xs:element name=ret3 type=xs:long / xs:element name=ret4 type=xs:double / xs:element name=ret5 type=xs:float / xs:element name=ret6 type=xs:short / xs:element name=ret7 type=xs:boolean / /xs:sequence /xs:complexType /xs:schema xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns:gen798=http://test/xsd; xmlns:ax21=http://aaa.bbb/types; targetNamespace=http://aaa.bbb/types; attributeFormDefault=qualified elementFormDefault=qualified xs:element name=sayHello xs:complexType xs:sequence xs:element name=var1 type=xs:string / xs:element name=var2 type=xs:int / xs:element name=var3 type=xs:long / xs:element name=var4 type=xs:double / xs:element name=var5 type=xs:float / xs:element name=var6 type=xs:short / xs:element name=var7 type=xs:boolean / /xs:sequence /xs:complexType /xs:element xs:element name=sayHelloResponse xs:complexType xs:sequence xs:element name=return maxOccurs=unbounded type=gen798:HelloBean nillable=true / /xs:sequence /xs:complexType /xs:element /xs:schema /wsdl:types ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-1252) java2wsdl generates unknown namespace
[ http://issues.apache.org/jira/browse/AXIS2-1252?page=comments#action_12441163 ] Kinichiro Inoguchi commented on AXIS2-1252: --- I see. I fully agreed with your algorithm. java2wsdl generates unknown namespace - Key: AXIS2-1252 URL: http://issues.apache.org/jira/browse/AXIS2-1252 Project: Apache Axis 2.0 (Axis2) Issue Type: Improvement Components: wsdl Reporter: Kinichiro Inoguchi Priority: Blocker This issue comes from user mailing list. http://marc.theaimsgroup.com/?t=11593771594r=1w=2 java2wsdl generates unknown namespace, http://test/xsd;. I'm using current nightly. My service class has method sayHello, and returns array of simple java beans HelloBean. Then I run java2wsdl, sayHello and sayHelloResponse are in namespace http://aaa.bbb/types;. But, HelloBean is in unknown namespace http://test/xsd;. Is this a bug ? C:\axis2-std-SNAPSHOT-bin\bin\java2wsdl.bat -cn test.TestService1 -cp . -tn http://aaa.bbb -tp xxx -stn http://aaa.bbb/types -stp yyy -sn TestService1 -of TestService1.wsdl generated WSDL is like this; wsdl:definitions xmlns:soap12=http://schemas.xmlsoap.org/wsdl/soap12/; xmlns:http=http://schemas.xmlsoap.org/wsdl/http/; xmlns:mime=http://schemas.xmlsoap.org/wsdl/mime/; xmlns:ns1=http://aaa.bbb/types; xmlns:xxx=http://aaa.bbb; xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/; xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/; targetNamespace=http://aaa.bbb; wsdl:types xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns:ax22=http://test/xsd; targetNamespace=http://test/xsd; attributeFormDefault=qualified elementFormDefault=qualified xs:element name=HelloBean type=ax22:HelloBean / xs:complexType name=HelloBean xs:sequence xs:element name=ret1 type=xs:string / xs:element name=ret2 type=xs:int / xs:element name=ret3 type=xs:long / xs:element name=ret4 type=xs:double / xs:element name=ret5 type=xs:float / xs:element name=ret6 type=xs:short / xs:element name=ret7 type=xs:boolean / /xs:sequence /xs:complexType /xs:schema xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns:gen798=http://test/xsd; xmlns:ax21=http://aaa.bbb/types; targetNamespace=http://aaa.bbb/types; attributeFormDefault=qualified elementFormDefault=qualified xs:element name=sayHello xs:complexType xs:sequence xs:element name=var1 type=xs:string / xs:element name=var2 type=xs:int / xs:element name=var3 type=xs:long / xs:element name=var4 type=xs:double / xs:element name=var5 type=xs:float / xs:element name=var6 type=xs:short / xs:element name=var7 type=xs:boolean / /xs:sequence /xs:complexType /xs:element xs:element name=sayHelloResponse xs:complexType xs:sequence xs:element name=return maxOccurs=unbounded type=gen798:HelloBean nillable=true / /xs:sequence /xs:complexType /xs:element /xs:schema /wsdl:types ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-586) CLONE -Axis2 does not deserialise abstract types correctly when receiving WSA messages
[ http://issues.apache.org/jira/browse/AXIS2-586?page=comments#action_12441165 ] Davanum Srinivas commented on AXIS2-586: Justin, Could you please upload your java test code that you use to send the message? I am assuming you ran w2j on the wsdl's in the prev comment. thanks, dims CLONE -Axis2 does not deserialise abstract types correctly when receiving WSA messages -- Key: AXIS2-586 URL: http://issues.apache.org/jira/browse/AXIS2-586 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Affects Versions: 0.94 Environment: Suse Linux 9.3 Server, Tomcat 5.0, Axis2 0.94 Reporter: Justin Schoeman Assigned To: Ajith Harshana Ranabahu When receiving WSA encoded messages containing abstract types, the created objects are for the implementation of the abstract class, instead of the actual type sent over the wire. In the following example, DeviceID is an abstract type, and EANDeviceID is an implementation of that type. The following information is obtained from the deserialised DeviceID object (which is sent as an EANDeviceID object): WSA: getClass().getName(): za.co.eskom.nrs.www.xmlvend.base._2_0.schema.impl.DeviceIDImpl schemaType(): [EMAIL PROTECTED]://www.nrs.eskom.co.za/xmlvend/base/2.0/schema toString(): xml-fragment type=sch:GenericDeviceID id=255255010 xmlns:sch=http://www.nrs.eskom.co.za/xmlvend/base/2.0/schema/ XSI: getClass().getName(): za.co.eskom.nrs.www.xmlvend.base._2_0.schema.impl.GenericDeviceIDImpl schemaType(): [EMAIL PROTECTED]://www.nrs.eskom.co.za/xmlvend/base/2.0/schema toString(): xml-fragment xsi:type=sch:GenericDeviceID id=255255010 xmlns:sch=http://www.nrs.eskom.co.za/xmlvend/base/2.0/schema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance/ As you can see, in both cases, the correct information is contained in the xmlbean, but for the WSA message it is deserialised incorrectly. -justin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-586) CLONE -Axis2 does not deserialise abstract types correctly when receiving WSA messages
[ http://issues.apache.org/jira/browse/AXIS2-586?page=comments#action_12441169 ] Justin Schoeman commented on AXIS2-586: --- The client code is on: http://www.schoeman.org.za/axis2_test_client.tbz It is hard coded to call either of the test methods (ConfirmCustomerRequest or CreditVendRequest). Thanks, -justin CLONE -Axis2 does not deserialise abstract types correctly when receiving WSA messages -- Key: AXIS2-586 URL: http://issues.apache.org/jira/browse/AXIS2-586 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Affects Versions: 0.94 Environment: Suse Linux 9.3 Server, Tomcat 5.0, Axis2 0.94 Reporter: Justin Schoeman Assigned To: Ajith Harshana Ranabahu When receiving WSA encoded messages containing abstract types, the created objects are for the implementation of the abstract class, instead of the actual type sent over the wire. In the following example, DeviceID is an abstract type, and EANDeviceID is an implementation of that type. The following information is obtained from the deserialised DeviceID object (which is sent as an EANDeviceID object): WSA: getClass().getName(): za.co.eskom.nrs.www.xmlvend.base._2_0.schema.impl.DeviceIDImpl schemaType(): [EMAIL PROTECTED]://www.nrs.eskom.co.za/xmlvend/base/2.0/schema toString(): xml-fragment type=sch:GenericDeviceID id=255255010 xmlns:sch=http://www.nrs.eskom.co.za/xmlvend/base/2.0/schema/ XSI: getClass().getName(): za.co.eskom.nrs.www.xmlvend.base._2_0.schema.impl.GenericDeviceIDImpl schemaType(): [EMAIL PROTECTED]://www.nrs.eskom.co.za/xmlvend/base/2.0/schema toString(): xml-fragment xsi:type=sch:GenericDeviceID id=255255010 xmlns:sch=http://www.nrs.eskom.co.za/xmlvend/base/2.0/schema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance/ As you can see, in both cases, the correct information is contained in the xmlbean, but for the WSA message it is deserialised incorrectly. -justin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-1339) WSDL2Java client side stub code does not work with AXIS2 TCP Server
WSDL2Java client side stub code does not work with AXIS2 TCP Server
---
Key: AXIS2-1339
URL: http://issues.apache.org/jira/browse/AXIS2-1339
Project: Apache Axis 2.0 (Axis2)
Issue Type: Bug
Components: core
Affects Versions: 1.1
Environment: Sun JVM 1.5, Axis2 1.1, WinXP
Reporter: yogen
Priority: Critical
The sample service axis2-rc1\samples\userguide\MyService.aar and client
\axis2-rc1\samples\userguide\src\userguide\clients\TCPClient.java *works* with
AXIS2 TCP Server.
But the code generated using wsdl2java for
\axis2-rc1\samples\wsdl\Axis2SampleDocLit.wsdl and service
Axis2SampleDocLitService.aar *does not work* with AXIS2 TCP Server (works with
HTTP Server).
1. the code is generated like this: wsdl2java -d xmlbeans -p com.sample -ss
-sd -g -uri Axis2SampleDocLit.wsdl -pn Axis2SampleDocLitPort
2. the service runs on port 6060.
3. Running the client code throws this exception stack trace:
Oct 10, 2006 12:06:02 PM org.apache.axis2.deployment.DeploymentEngine doDeploy
INFO: Deploying module : addressing-1.09
org.apache.axis2.AxisFault: Service not found operation terminated !!
at
org.apache.axis2.description.OutInAxisOperationClient.execute(OutInAxisOperation.java:294)
at
com.sample.Axis2SampleDocLitServiceStub.echoString(Axis2SampleDocLitServiceStub.java:505)
at TCP1Client.echoString(TCP1Client.java:28)
at TCP1Client.main(TCP1Client.java:17)
The client code is attached:
import javax.xml.namespace.QName;
import org.apache.axis2.Constants;
import org.apache.axis2.addressing.EndpointReference;
import org.apache.axis2.userguide.xsd.*;
import com.sample.*;
public class TCP1Client{
public static void main(java.lang.String args[]){
Axis2SampleDocLitServiceStub stub = null;
try{
stub = new Axis2SampleDocLitServiceStub(null,
tcp://localhost:6060/axis2/services/Axis2SampleDocLitService);
stub._getServiceClient().getOptions().setTo(new
EndpointReference(tcp://localhost:6060/axis2/services/Axis2SampleDocLitService));
stub._getServiceClient().getOptions().setTransportInProtocol(Constants.TRANSPORT_TCP);
stub._getServiceClient().engageModule(new
QName(Constants.MODULE_ADDRESSING));
System.out.println(echoString(stub));
} catch(Exception e){
e.printStackTrace();
}
}
public static String echoString(Axis2SampleDocLitServiceStub stub){
try{
EchoStringParamDocument reqDoc00 =
EchoStringParamDocument.Factory.newInstance();
reqDoc00.setEchoStringParam(echo);
EchoStringReturnDocument resDoc00 = stub.echoString(reqDoc00);
return resDoc00.getEchoStringReturn();
} catch(Exception e){
e.printStackTrace();
}
return null;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-749) Mixing compile time and runtime support in codegen jar
[ http://issues.apache.org/jira/browse/AXIS2-749?page=comments#action_12441182 ] Davanum Srinivas commented on AXIS2-749: Problem shows up in user environments. we need to to this... http://marc.theaimsgroup.com/?l=axis-devm=116047863220600w=2 the code relies on adb. so the 2 choices are to create a new module/jar and make that depend on adb or just move the package as-is to ADB. I am going to try doing the latter as it is least problematic w.r.t build/release process. thanks, dims Mixing compile time and runtime support in codegen jar -- Key: AXIS2-749 URL: http://issues.apache.org/jira/browse/AXIS2-749 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Reporter: Davanum Srinivas Assigned To: Deepal Jayasinghe org.apache.axis2.rpc.receivers.RPCMessageReceiver is currently in axis2-codegen-SNAPSHOT.jar...why codegen? can we please have just the compile/build time stuff in codegen? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-749) Mixing compile time and runtime support in codegen jar
[ http://issues.apache.org/jira/browse/AXIS2-749?page=comments#action_12441185 ] Davanum Srinivas commented on AXIS2-749: Again, the idea is that you should be able to deploy rpc/pojo using just the min distro. -- dims Mixing compile time and runtime support in codegen jar -- Key: AXIS2-749 URL: http://issues.apache.org/jira/browse/AXIS2-749 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Reporter: Davanum Srinivas Assigned To: Deepal Jayasinghe org.apache.axis2.rpc.receivers.RPCMessageReceiver is currently in axis2-codegen-SNAPSHOT.jar...why codegen? can we please have just the compile/build time stuff in codegen? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [axis2] Improvements to Service life cycle in handling - setOperationContext not thread-safe??!!
Ok... Here's my suggestion.. Let's create new service objects per invocation.. AFAIK two things happen when we deploy a service in application scope. One is that Axis2 will maintain a single service context throughout the life of the service.. Other thing is Axis2 maintains one service class object throughout the life of the service, serving for all the requests.. Maintaining of the service context is really important and useful.. Users can use it to store whatever the state data that needs to shared throughout the life of the service. IIRC this is one of the use cases we came up with for the Axis2 context hierarchy- to make the engine stateless.. On the other hand, i don't see any reason for maintaining a single service object throughout the life of the service. IMO anybody can use the ServiceContext to store whatever the state data needed to be shared across the life of the service...Are there any special cases where we can't do that.. If there aren't any reasons my suggestion is to create the service object per invocation. Also a user who uses the application scope might most probably be working in the messagereceiver(MR) level, since MR is known to be the ultimate message recipient in Axis2. One possible example is a BPEL engine.. In that case the concept of one service object for the life time of the service invalidates.. AFAIKS AXIS2-1133 is another implication of this design... Thanks, Thilina On 10/10/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: Other choices? The approach we used back in ApacheSOAP was to tell the user to add an additional first parameter to their methods if they wanted the context .. so the signature would have an additional param and that'd tell us to do the right thing. Very thread safe. Need to avoid reflection - but can be done by a codegen flag. For RPC case its reflective anyway so its not a big deal. Sanjiva. On Tue, 2006-10-10 at 09:40 -0400, Davanum Srinivas wrote: Sanjiva, We had terrible problems with TLS in Axis1...let me recollect my thougts and post. -- dims On 10/10/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: I think I agree with you. How about we drop setOperationContext() and introduce Axis1-style MessageContext.getCurrentContext() which returns it for this thread? Have to be careful to put it in TLS and take it off! We must be careful to tell users that instance variables are not supported; you have to use MessageContext properties to store state (or wherever else). Sanjiva. On Sun, 2006-09-24 at 14:12 +0200, Christopher Sahnwaldt wrote: Entered as http://issues.apache.org/jira/browse/AXIS2-1224 . I set the priority to blocker as David suggested. IMHO it's probably best to drop the method. Many users will use it in an intuitive but wrong way. The only way to store the data it provides is an instance variable, and telling users to either use only request scope or use a ThreadLocal to store the data does not seem to be compatible with the rule of least surprise. Something like MessageContext.getCurrentContext() in Axis 1 might be better. Bye, Christopher. Davanum Srinivas wrote: Chris, Can you please raise a new issue in JIRA? thanks, dims On 9/23/06, Christopher Sahnwaldt [EMAIL PROTECTED] wrote: Something worries me: setOperationContext(OperationContext) - per call. The messageContext can be obtained to gain per call instance information. That doesn't seem to be thread-safe, does it? If I understand this correctly, one service object is created per application (if the service has application scope). When a request comes in, Axis calls the setOperationContext method, and the service object may store the OperationContext or the MessageContext. Then Axis calls the actual service method, in which the service code can access the stored OperationContext or MessageContext. But what if two requests come in almost simultaneously? The following sequence of method calls may occur: - Axis calls setOperationContext with context for request A, the service object stores the context in an instance field. - Axis calls setOperationContext with context for request B, the same service object stores the context in the same instance field and thus *overwrites* the context for call A. - Axis calls the service method with the input parameters for request A. - The service method processes the call, using data from the stored context, and thus *mixes the input parameters for call A with the context data for call B*. Anything can happen... - Finally, Axis calls the service method with the input parameters for call B, the service method processes the call, using data from the stored context, and thus correctly uses the input parameters for call B with the context data for call B. Probably ok, unless the service method updated
Re: [Axis2] What should be included in Axis2 minimal distribution
+1... Seeems like you have already migrated it to ADB :).. ~Thilina On 10/10/06, Davanum Srinivas [EMAIL PROTECTED] wrote: Folks, lets move rpc* out of coden. it does not belong there. -- dims On 10/10/06, Thilina Gunarathne [EMAIL PROTECTED] wrote: Hi, AFAIK ADB is there because we need the RPCMessageReceiver to work in the minimal distro... Just now I figured out that RPCMessageReceiver resides in the codegen module..Which means we have to include codegen module to the minimal distro.. I'm not sure why we are putting the adb-codegen in to the minimal distro... ~Thilina On 10/10/06, Eran Chinthaka [EMAIL PROTECTED] wrote: Hi, Can we please re-visit the modules that should be included in Axis2 minimal distribution. Currently kernel, adb and java2wsdl modules are included, but I saw even adb-codegen was added recently. What do you think? Thanks, Chinthaka -- http://webservices.apache.org/~thilina/ http://thilinag.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://webservices.apache.org/~thilina/ http://thilinag.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] What should be included in Axis2 minimal distribution
Yes i did :) -- dims On 10/10/06, Thilina Gunarathne [EMAIL PROTECTED] wrote: +1... Seeems like you have already migrated it to ADB :).. ~Thilina On 10/10/06, Davanum Srinivas [EMAIL PROTECTED] wrote: Folks, lets move rpc* out of coden. it does not belong there. -- dims On 10/10/06, Thilina Gunarathne [EMAIL PROTECTED] wrote: Hi, AFAIK ADB is there because we need the RPCMessageReceiver to work in the minimal distro... Just now I figured out that RPCMessageReceiver resides in the codegen module..Which means we have to include codegen module to the minimal distro.. I'm not sure why we are putting the adb-codegen in to the minimal distro... ~Thilina On 10/10/06, Eran Chinthaka [EMAIL PROTECTED] wrote: Hi, Can we please re-visit the modules that should be included in Axis2 minimal distribution. Currently kernel, adb and java2wsdl modules are included, but I saw even adb-codegen was added recently. What do you think? Thanks, Chinthaka -- http://webservices.apache.org/~thilina/ http://thilinag.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://webservices.apache.org/~thilina/ http://thilinag.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [axis2] Improvements to Service life cycle in handling - setOperationContext not thread-safe??!!
Hi Thilina Thilina Gunarathne wrote: Ok... Here's my suggestion.. Let's create new service objects per invocation.. I do not agree with this approach :) , with this if some one deploy a service with application scope then there will be multiple instance of same service impl class. Deploying a service in application scope , user want to have once service impl instance (im I were a user , I want that ) btw : there was a JIRA issues on this couple of month ago. Here in ApacheCon US , we are discussed abt the this issue deeper ,and we agreed to use Sanjiva's suggestion. MessageContext.getCurrentContext(). P.S : Deepal41: hi dims [12:06]GlenD: [11:59] GlenD so we're now talking about setting a TLS OperationContext.getCurrentContext() into the AxisEngine, right before it calls the MessageReceiver [12:06]GlenD: [11:59] GlenD and putting the thread ClassLoader stuff right in the same place [12:06]GlenD: [11:59] GlenD so it's factored out of the individual MRs [12:06]dims: +1 [12:07]ruchith: +1 [12:07]ruchith: we don't have to duplicate code this way [12:07]Deepal41: in the mean time shall we move saveTCCL(messageCtx); [12:07]Deepal41: into AxisEnine too [12:07]Deepal41: what do u think dims ? [12:07]dims: ok [12:08]dims: sounds good [12:08]dims: need to get Ali to test his ejb stuff and get Robert to test spring support again after that change [12:09]GlenD: +1 [12:09]sanka has joined [12:10]Deepal41: +1 [12:12]Deepal41: one more q [12:13]Deepal41: is that OperationContext.getCurrentConetct(); [12:13]GlenD: getCurrentContext() [12:13]Deepal41: or MessageContext..getCurrentContext(); [12:14]GlenD: Personally, I prefer MC.getCurrentContext() [12:14]GlenD: but I'm fine with OC.getCurrentContext() too [12:14]Deepal41: how abt others [12:14]dims: Let's write it up and post to the list (with both options) [12:14]GlenD: I just think you don't lose anything by doing it in the MC, and it allows you to get the current MC properties without having to know which one to ask for from the OC [12:14]GlenD: sure, dims [12:15]Deepal41: ok , then let's go with MC.getCurrentContext(); [12:15]dims: was just reading email from incubator folks about not taking decisions on the irc :) [12:15]Deepal41: :) [12:16]Deepal41: hmm , I am +1 on MC.getCurrentContext(); [12:17]GlenD: hee hee [12:17]GlenD: we were just talking about IRC vs email a bit ago [12:17]dims: guys read the email from thilina as well [12:17]GlenD: k AFAIK two things happen when we deploy a service in application scope. One is that Axis2 will maintain a single service context throughout the life of the service.. Other thing is Axis2 maintains one service class object throughout the life of the service, serving for all the requests.. We should maintain both ,I mean - should have only one serviceContext - and only one service impl Maintaining of the service context is really important and useful.. Users can use it to store whatever the state data that needs to shared throughout the life of the service. IIRC this is one of the use cases we came up with for the Axis2 context hierarchy- to make the engine stateless.. Totallly agrred. On the other hand, i don't see any reason for maintaining a single service object throughout the life of the service. What if user want to keep local variable inside the impl class . I know that is not the best practice bt ppl are using that . IMO anybody can use the ServiceContext to store whatever the state data needed to be shared across the life of the service...Are there any special cases where we can't do that.. If there aren't any reasons my suggestion is to create the service object per invocation. Also a user who uses the application scope might most probably be working in the messagereceiver(MR) level, since MR is known to be the ultimate message recipient in Axis2. One possible example is a BPEL engine.. In that case the concept of one service object for the life time of the service invalidates.. AFAIKS AXIS2-1133 is another implication of this design... Thanks, Thilina On 10/10/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: Other choices? The approach we used back in ApacheSOAP was to tell the user to add an additional first parameter to their methods if they wanted the context .. so the signature would have an additional param and that'd tell us to do the right thing. Very thread safe. Need to avoid reflection - but can be done by a codegen flag. For RPC case its reflective anyway so its not a big deal. Sanjiva. On Tue, 2006-10-10 at 09:40 -0400, Davanum Srinivas wrote: Sanjiva, We had terrible problems with TLS in Axis1...let me recollect my thougts and post. -- dims
Re: [axis2] Improvements to Service life cycle in handling - setOperationContext not thread-safe??!!
Thilina,Here is my concern. If you have application scope the expectation is that we have a single instance throught the life of the app.So I could be initializing very expensive stuff in my init() and thats ok bcos the expectation is that you do that only once. Imagine if we have to do this for every invocation bocs we choose to create a new object for every invocation?This could be a severe performance hit as I maybe doing very expensive object creations.So in my opinion we have to look at a different stratergy from a performance POV. Regards,RajithOn 10/10/06, Thilina Gunarathne [EMAIL PROTECTED] wrote: Ok... Here's my suggestion.. Let's create new service objects per invocation..AFAIK two things happen when we deploy a service in application scope.One is that Axis2 will maintain a single service context throughout the life of the service.. Other thing is Axis2 maintains one serviceclass object throughout the life of the service, serving for all therequests..Maintaining of the service context is really important and useful.. Users can use it to store whatever the state data that needs to sharedthroughout the life of the service. IIRC this is one of the use caseswe came up with for the Axis2 context hierarchy- to make the engine stateless..On the other hand, i don't see any reason for maintaining a singleservice object throughout the life of the service. IMO anybody can usethe ServiceContext to store whatever the state data needed to be shared across the life of the service...Are there any special caseswhere we can't do that.. If there aren't any reasons my suggestion istocreate the service object per invocation.Also a user who uses the application scope might most probably be working in the messagereceiver(MR) level, since MR is known to be theultimate message recipient in Axis2. One possible example is a BPELengine.. In that case the concept of one service object for the lifetime of the service invalidates.. AFAIKS AXIS2-1133 is another implication of this design...Thanks,ThilinaOn 10/10/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: Other choices? The approach we used back in ApacheSOAP was to tell the user to add an additional first parameter to their methods if they wanted the context .. so the signature would have an additional param and that'd tell us to do the right thing. Very thread safe. Need to avoid reflection - but can be done by a codegen flag. For RPC case its reflective anyway so its not a big deal. Sanjiva. On Tue, 2006-10-10 at 09:40 -0400, Davanum Srinivas wrote: Sanjiva, We had terrible problems with TLS in Axis1...let me recollect my thougts and post. -- dims On 10/10/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: I think I agree with you. How about we drop setOperationContext() and introduce Axis1-style MessageContext.getCurrentContext() which returns it for this thread? Have to be careful to put it in TLS and take it off! We must be careful to tell users that instance variables are not supported; you have to use MessageContext properties to store state (or wherever else). Sanjiva. On Sun, 2006-09-24 at 14:12 +0200, Christopher Sahnwaldt wrote: Entered as http://issues.apache.org/jira/browse/AXIS2-1224 .I set the priority to blocker as David suggested. IMHO it's probably best to drop the method. Many users will use it in anintuitive but wrong way. The only way to store the data it provides is aninstance variable, and telling users to either use only request scope or use a ThreadLocal to store the data does not seem to be compatible with therule of least surprise. Something like MessageContext.getCurrentContext()in Axis 1 might be better. Bye,Christopher. Davanum Srinivas wrote: Chris, Can you please raise a new issue in JIRA? thanks, dims On 9/23/06, Christopher Sahnwaldt [EMAIL PROTECTED] wrote: Something worries me: setOperationContext(OperationContext) - per call.The messageContext can be obtained to gain per call instance information. That doesn't seem to be thread-safe, does it? If I understand this correctly, one service object is created per application (if the service has application scope). When a request comes in, Axis calls the setOperationContext method, and the service object may store the OperationContext or the MessageContext. Then Axis calls the actual service method, in which the service code can access the stored OperationContext or MessageContext. But what if two requests come in almost simultaneously? The following sequence of method calls may occur: - Axis calls setOperationContext with context for request A, the service object stores the context in an instance field. - Axis calls setOperationContext with context for request B, the same service object stores the context in the same instance field and thus *overwrites* the context for call A. -
[jira] Created: (AXIS2-1340) Axis2Util.toOM() needs to work w/o XML-Security jar
Axis2Util.toOM() needs to work w/o XML-Security jar --- Key: AXIS2-1340 URL: http://issues.apache.org/jira/browse/AXIS2-1340 Project: Apache Axis 2.0 (Axis2) Issue Type: Improvement Components: om Environment: Any Reporter: Sathija Pavuluri Priority: Minor When converting a DOM element to OMElement, the process is not straightforward. We first need to use the org.apache.rampart.util.Axis2Utils.toOM() from axis2-security-SNAPSHOT.jar. The toOM() method references the org.apache.xml.security.utils.XMLUtils class from xml-security jar file. So one needs to include that jar in the classpath. And then this error is seen: org.apache.xml.security.c14n.InvalidCanonicalizerException: You must initialize the xml-security library correctly before you use it. Call the static method org.apache.xml.security.Init.init(); to do that before you use any functionality from that library. at org.apache.xml.security.c14n.Canonicalizer.init(Unknown Source) at org.apache.xml.security.c14n.Canonicalizer.getInstance(Unknown Source) at org.apache.xml.security.utils.XMLUtils.outputDOM(Unknown Source) at org.apache.rampart.util.Axis2Util.toOM(Axis2Util.java:176) To fix this, I have had to call org.apache.xml.security.Init.init(); in my class before invoking Axis2Utils.toOM(). This is rather cumbersome. It would be nice if the axis2-security was packaged so that the xml-security jar need not be imported. Or the toOM() method needs to correctly initialize the xml-security jar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] What should be included in Axis2 minimal distribution
Does this mean, now we can happily ship the minimal distro with kernel, adb and java2wsdl in it? Agreed? -- Chinthaka Davanum Srinivas wrote: Yes i did :) -- dims On 10/10/06, Thilina Gunarathne [EMAIL PROTECTED] wrote: +1... Seeems like you have already migrated it to ADB :).. ~Thilina On 10/10/06, Davanum Srinivas [EMAIL PROTECTED] wrote: Folks, lets move rpc* out of coden. it does not belong there. -- dims On 10/10/06, Thilina Gunarathne [EMAIL PROTECTED] wrote: Hi, AFAIK ADB is there because we need the RPCMessageReceiver to work in the minimal distro... Just now I figured out that RPCMessageReceiver resides in the codegen module..Which means we have to include codegen module to the minimal distro.. I'm not sure why we are putting the adb-codegen in to the minimal distro... ~Thilina On 10/10/06, Eran Chinthaka [EMAIL PROTECTED] wrote: Hi, Can we please re-visit the modules that should be included in Axis2 minimal distribution. Currently kernel, adb and java2wsdl modules are included, but I saw even adb-codegen was added recently. What do you think? Thanks, Chinthaka -- http://webservices.apache.org/~thilina/ http://thilinag.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://webservices.apache.org/~thilina/ http://thilinag.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
[jira] Commented: (AXIS2-1247) wsdl2java generated client throws NumberFormatException on nil integer
[ http://issues.apache.org/jira/browse/AXIS2-1247?page=comments#action_12441249 ] Tom Jordahl commented on AXIS2-1247: Note that an Axis 1.x, any integer type that is nillable has to become a Java Integer. Otherwise you can not tell if 0 is sent or it was omitted. Axsi 2 should follow the same convention. Any nillable type must be converted in to the Java wrapper type. wsdl2java generated client throws NumberFormatException on nil integer -- Key: AXIS2-1247 URL: http://issues.apache.org/jira/browse/AXIS2-1247 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Affects Versions: nightly Environment: Java 1.4.2, Tomcat 4, Axis 2 Nightly Build Reporter: Todd Doolittle Priority: Blocker I used wsdl2java to create a client based on wsdl from a non-java service. The wsdl specifies that one of the returned values is an integer and is nillable like this... xsd:element name=ksn nillable=true type=xsd:int / When the service returns a null/nill value it looks like this in the SOAP body: fjs1:ksn xsi:nil=true/ The client code throws a number format exception while processing this... Caused by: java.lang.NumberFormatException: For input string: at java.lang.NumberFormatException.forInputString(Unknown Source) at java.lang.Integer.parseInt(Unknown Source) at java.lang.Integer.parseInt(Unknown Source) at org.apache.axis2.databinding.utils.ConverterUtil.convertToInt(ConverterUtil.java:210) at org.tempuri.POCStub$Item_type0$Factory.parse(POCStub.java:2149) at org.tempuri.POCStub$Items_type1$Factory.parse(POCStub.java:1157) at org.tempuri.POCStub$GetinfoResponse$Factory.parse(POCStub.java:1593) at org.tempuri.POCStub.fromOM(POCStub.java:2330) ... 3 more Here is the SOAP message my client sent (which looks fine): POST /ws/r/poc?WSDL HTTP/1.1 SOAPAction: getinfo User-Agent: Axis2 Host: localhost:8090 Transfer-Encoding: chunked Content-Type: text/xml; charset=UTF-8 160 ?xml version='1.0' encoding='UTF-8'? soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; soapenv:Header / soapenv:Body ns1:lookup xmlns:ns1=http://tempuri.org/; count=1 ns1:upc200910/ns1:upc ns1:upc xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; nil=true / /ns1:lookup /soapenv:Body /soapenv:Envelope 0 Here is the non-java service's reply: HTTP/1.1 200 OK Date: Wed, 27 Sep 2006 15:23:37 GMT Server: Four J's Server (Build 369) Content-Type: text/xml; charset=UTF-8 Content-Length: 532 ?xml version=1.0 encoding=UTF-8 standalone=no ? SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/; SOAP-ENV:Body fjs1:GetinfoResponse xmlns:fjs1=http://tempuri.org/; count=1 xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; fjs1:items fjs1:item fjs1:ksn xsi:nil=true / fjs1:upc200910/fjs1:upc fjs1:maintdt xsi:nil=true / fjs1:dpt xsi:nil=true / /fjs1:item /fjs1:items /fjs1:GetinfoResponse /SOAP-ENV:Body /SOAP-ENV:Envelope Here is the WSDL from the service... ?xml version=1.0 encoding=UTF-8 standalone=no ? wsdl:definitions xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/; name=POC targetNamespace=http://tempuri.org/; xmlns:fjs=http://tempuri.org/; xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; wsdl:types xsd:schema elementFormDefault=qualified targetNamespace=http://tempuri.org/; xmlns:s1=http://tempuri.org/; xsd:element name=lookup xsd:complexType xsd:sequence xsd:element maxOccurs=unbounded minOccurs=0 name=upc nillable=true type=xsd:string / /xsd:sequence xsd:attribute name=count type=xsd:int use=required / /xsd:complexType /xsd:element xsd:element name=GetinfoResponse xsd:complexType xsd:sequence xsd:element name=items nillable=true xsd:complexType xsd:sequence xsd:element maxOccurs=unbounded minOccurs=0 name=item nillable=true xsd:complexType xsd:sequence xsd:element name=ksn nillable=true type=xsd:int / xsd:element name=upc nillable=true type=xsd:string / xsd:element name=maintdt nillable=true type=xsd:date / xsd:element name=dpt nillable=true type=xsd:int /
[jira] Commented: (AXIS2-1272) Cannot differentiate between an int sent as 0 and an int sent as nil
[ http://issues.apache.org/jira/browse/AXIS2-1272?page=comments#action_12441253 ] Tom Jordahl commented on AXIS2-1272: (Commented on AXIS2-1247 also) Note that an Axis 1.x, any integer type that is nillable has to become a Java Integer. Otherwise you can not tell if 0 is sent or it was omitted. Axsi 2 should follow the same convention. Any nillable type must be converted in to the Java wrapper type. Cannot differentiate between an int sent as 0 and an int sent as nil Key: AXIS2-1272 URL: http://issues.apache.org/jira/browse/AXIS2-1272 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: databinding Affects Versions: nightly Environment: Axis 2 nightly, Java 1.4.2, Tomcat 4 Reporter: Todd Doolittle The service I deal with often sends back values a nil (or NULL). For most datatypes, such as String and Date the value of the object is NULL (using client code generated by WSDL2JAVA). However for anything that is an integer, it is set to 0. This makes it impossible to tell if the value in the message was really a 0, or if it was nil=true. For example, the type in the wsdl is defined as... xsd:element name=response xsd:complextType xsd:sequence xsd:element name=firstNumber type=xsd:int/ xsd:element name=secondNumber type=xsd:int/ /xsd:sequence /xsd:complexType /xsd:element The server returns this response... response firstNumber0/firstNumber secondNumber nil=true/ /response In the client code, response.getFirstNumber() would return 0, and response.getSecondNumber() would also return 0. To get around this could we do one of the following... **When an int is returned from a service as nil=true set the value to Integer.MIN_VALUE. or **In the generated classes using java.lang.Integer instead of int and in the case of a nil=true response, set the Integer object to null. or **In the generated classes, for each int value include a isNull() method that would return a boolean. Thanks! Todd -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-1274) WSDL2Java does not create Stub class for PortType
[ http://issues.apache.org/jira/browse/AXIS2-1274?page=comments#action_12441255 ] Tom Jordahl commented on AXIS2-1274: Dims, Does this mean that by default wsdl2java does not emit code for all the ports in a WSDL? That seems bad to me. WSDL2Java does not create Stub class for PortType - Key: AXIS2-1274 URL: http://issues.apache.org/jira/browse/AXIS2-1274 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: wsdl Affects Versions: 1.0 Environment: WinXP, Sun JVM 1.5 Reporter: yogen I am using AXIS2 1.0. I ran wsdl2java on samples/wsdl/Axis2SampleDocLit.wsdl like this: wsdl2java -d xmlbeans -uri Axis2SampleDocLit.wsdl -p com.sample -ss -sd -g; it does not generate Axis2SampleDocLitPortTypeStub.java. when I tried this wsdl2java -d xmlbeans -uri Axis2SampleDocLit.wsdl -p com.sample -ss -sd -g -pn Axis2SampleDocLitPortType it complains that Axis2SampleDocLitPortType not found in WSDL. The problem is in nightly build as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-1274) WSDL2Java does not create Stub class for PortType
[ http://issues.apache.org/jira/browse/AXIS2-1274?page=comments#action_12441258 ] Davanum Srinivas commented on AXIS2-1274: - Yep :( I tried... WSDL2Java does not create Stub class for PortType - Key: AXIS2-1274 URL: http://issues.apache.org/jira/browse/AXIS2-1274 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: wsdl Affects Versions: 1.0 Environment: WinXP, Sun JVM 1.5 Reporter: yogen I am using AXIS2 1.0. I ran wsdl2java on samples/wsdl/Axis2SampleDocLit.wsdl like this: wsdl2java -d xmlbeans -uri Axis2SampleDocLit.wsdl -p com.sample -ss -sd -g; it does not generate Axis2SampleDocLitPortTypeStub.java. when I tried this wsdl2java -d xmlbeans -uri Axis2SampleDocLit.wsdl -p com.sample -ss -sd -g -pn Axis2SampleDocLitPortType it complains that Axis2SampleDocLitPortType not found in WSDL. The problem is in nightly build as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Axis2]WSDL2Java Code generation option
+1 for Sanjiva's suggestions: -c client side -s server side -t test case generation. I think -a should be for all, but I assume it is in use already? -- Tom Jordahl Adobe ColdFusion Team -Original Message- From: Sanjiva Weerawarana [mailto:[EMAIL PROTECTED] Sent: Monday, October 09, 2006 5:13 PM To: axis-dev@ws.apache.org Cc: Thilina Gunarathne Subject: Re: [Axis2]WSDL2Java Code generation option On Mon, 2006-10-09 at 07:54 -0400, Srinath Perera wrote: Hi AJith,All; As far as I understand 1) no options client side only 2) -s server side 3) -sd -ss service side discriptions, this only work with -ss 4) -g all, but no service.xml .. So I put -g -sd ..still none becouse -sd only works with -ss .. so -g -ss and -sd Ouch. Sorry but I feel this is far too complex. shall we change the options for 1.1? for example (Or do we need to me backward compatible with the tool options?) -GClient or nothing for Client -GServer for server with service.xml -GAll for everything -GTest all with test case How about: - -c or nothing for client - -s for service side with services.xml - -g for both client and server (both the above basically) - -g -t for all and test case That is, introduce a -t argument for test case generation. By test case we mean what exactly .. a stub?? In that case its only meaningful for a server side case anyway. Do we have use case for generating server side code without a service.xml file ? Do we have use case for generating service.xml without server side code? (we could at least assume -ss given -sd) +1. So basically same as your proposal except use option names that are closer to what we have now. Sanjiva. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Axis2]Embdeding Jetty to Axis2
-0 from me. While Jetty is super sweet, Axis2 has a serious jar file dependency problem. I think its going to have to go in to a detox program soon! -- Tom Jordahl Adobe ColdFusion Team -Original Message- From: Sanjiva Weerawarana [mailto:[EMAIL PROTECTED] Sent: Monday, October 09, 2006 5:17 PM To: axis-dev@ws.apache.org Subject: Re: [Axis2]Embdeding Jetty to Axis2 +1 from me too! Sanjiva. On Mon, 2006-10-09 at 10:36 -0400, Rajith Attapattu wrote: Srinath, I personally think it's a good move. Regards, Rajith On 10/9/06, Brian De Pradine [EMAIL PROTECTED] wrote: +1 from me. Cheers Brian DePradine Web Services Development IBM Hursley External +44 (0) 1962 816319 Internal 246319 If you can't find the time to do it right the first time, where will you find the time to do it again? Jaliya Ekanayake [EMAIL PROTECTED] wrote on 08/10/2006 15:20:49: Hi All, One other advantage is that we can simply give an Axis2 server for the user as well. All they want is to start the Axis2 server which is based on Jetty. Thanks, -Jaliya - Original Message - From: Srinath Perera [EMAIL PROTECTED] To: axis-dev@ws.apache.org Cc: Thilina Gunarathne [EMAIL PROTECTED]; Jaliya Ekanayake [EMAIL PROTECTED] Sent: Sunday, October 08, 2006 7:56 AM Subject: [Axis2]Embdeding Jetty to Axis2 Hi All; Myself and jaliya were talking about trying to do lot of async requests using Axis2 client .. it falis at about 40-50 requests and we belive that is becouse ..simple HTTP server can't handle the load. I was looking at the jetty and found out that Jetty6 allow you to embed it to the application tightly. For an example Server server = new Server(8080); Context root = new Context(server,/,Context.SESSIONS); root.addServlet(new ServletHolder(new HelloServlet(serviceMap)), /*); server.start(); Will create a new server and add a servlet. I belive if we embdeded Jetty to Axis2 1) Axis2 can use jetty as the listener for async messages 2) Axis2 can started up standalone using jetty I belive I could port our Axis2 servlet to jetty pretty easily. If people agree I think we should have it as a module and if it is sucessful I think we should switch to it as our default container some day thoughts? Srinath -- Srinath Perera: http://www.cs.indiana.edu/~hperera/ http://www.bloglines.com/blog/hemapani - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [axis2] Improvements to Service life cycle in handling - setOperationContext not thread-safe??!!
Hi Deepal, Deploying a service in application scope , user want to have once service impl instance (im I were a user , I want that ) Frankly I don't... :) Service impl class is a Axis2 bundled MR(eg: RawXMLInOut..) specific notion... Service impl is meaning less if the user has written a custom MR.. yes , I agree. btw we use all those concept in code gen as well , I mean all the generated MR support all those. One example would be a BPELEngine (which I did :) ), where we had our own Message Receiver and we stored all the state data in the service context.. yes , as I told you earlier thats the perfect way , but there are users how want to store values in service impl. (And for me I think that is not that bad when you deploy a service in application scope) See http://issues.apache.org/jira/browse/AXIS2-1133 this too.. so we're now talking about setting a TLS OperationContext.getCurrentContext() into the AxisEngine, right before it calls the MessageReceiver I'm not sure about the impact of this change... If this is not a straight forward change I doubt whether we should do this at this moment... Don't want to take any chances towards 1.1 :(... no , if we are going to make this change we have to do that before 1.1 , and I dont think the change we are planing to do will affect that much :) We should maintain both ,I mean - should have only one serviceContext - and only one service impl any concrete use cases Use cases which cannot be implemented using by storing the state data in the service context... What if user want to keep local variable inside the impl class . I know that is not the best practice bt ppl are using that . Then why we gonna encourage that ?? Thanks, ~Thilina IMO anybody can use the ServiceContext to store whatever the state data needed to be shared across the life of the service...Are there any special cases where we can't do that.. If there aren't any reasons my suggestion is to create the service object per invocation. Also a user who uses the application scope might most probably be working in the messagereceiver(MR) level, since MR is known to be the ultimate message recipient in Axis2. One possible example is a BPEL engine.. In that case the concept of one service object for the life time of the service invalidates.. AFAIKS AXIS2-1133 is another implication of this design... Thanks, Thilina On 10/10/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: Other choices? The approach we used back in ApacheSOAP was to tell the user to add an additional first parameter to their methods if they wanted the context .. so the signature would have an additional param and that'd tell us to do the right thing. Very thread safe. Need to avoid reflection - but can be done by a codegen flag. For RPC case its reflective anyway so its not a big deal. Sanjiva. On Tue, 2006-10-10 at 09:40 -0400, Davanum Srinivas wrote: Sanjiva, We had terrible problems with TLS in Axis1...let me recollect my thougts and post. -- dims On 10/10/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: I think I agree with you. How about we drop setOperationContext() and introduce Axis1-style MessageContext.getCurrentContext() which returns it for this thread? Have to be careful to put it in TLS and take it off! We must be careful to tell users that instance variables are not supported; you have to use MessageContext properties to store state (or wherever else). Sanjiva. On Sun, 2006-09-24 at 14:12 +0200, Christopher Sahnwaldt wrote: Entered as http://issues.apache.org/jira/browse/AXIS2-1224 . I set the priority to blocker as David suggested. IMHO it's probably best to drop the method. Many users will use it in an intuitive but wrong way. The only way to store the data it provides is an instance variable, and telling users to either use only request scope or use a ThreadLocal to store the data does not seem to be compatible with the rule of least surprise. Something like MessageContext.getCurrentContext() in Axis 1 might be better. Bye, Christopher. Davanum Srinivas wrote: Chris, Can you please raise a new issue in JIRA? thanks, dims On 9/23/06, Christopher Sahnwaldt [EMAIL PROTECTED] wrote: Something worries me: setOperationContext(OperationContext) - per call. The messageContext can be obtained to gain per call instance information. That doesn't seem to be thread-safe, does it? If I understand this correctly, one service object is created per application (if the service has application scope). When a request comes in, Axis calls the setOperationContext method, and the service object may store the OperationContext or the MessageContext. Then
RE: [axis2] Improvements to Service life cycle in handling -setOperationContext not thread-safe??!!
While we may have had to work around some bugs in Thread Local Storage (TLS) on the whole I think the Axis 1.x MessageContext.getCurrentContext() works exceptionally well. Since JDK 1.4 is the minimum for Axis2, I believe we have all the TLS bugs behind us, no? -- Tom Jordahl Adobe ColdFusion Team -Original Message- From: Sanjiva Weerawarana [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 10, 2006 10:28 AM To: [EMAIL PROTECTED] Cc: axis-dev@ws.apache.org Subject: Re: [axis2] Improvements to Service life cycle in handling -setOperationContext not thread-safe??!! Other choices? The approach we used back in ApacheSOAP was to tell the user to add an additional first parameter to their methods if they wanted the context .. so the signature would have an additional param and that'd tell us to do the right thing. Very thread safe. Need to avoid reflection - but can be done by a codegen flag. For RPC case its reflective anyway so its not a big deal. Sanjiva. On Tue, 2006-10-10 at 09:40 -0400, Davanum Srinivas wrote: Sanjiva, We had terrible problems with TLS in Axis1...let me recollect my thougts and post. -- dims On 10/10/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: I think I agree with you. How about we drop setOperationContext() and introduce Axis1-style MessageContext.getCurrentContext() which returns it for this thread? Have to be careful to put it in TLS and take it off! We must be careful to tell users that instance variables are not supported; you have to use MessageContext properties to store state (or wherever else). Sanjiva. On Sun, 2006-09-24 at 14:12 +0200, Christopher Sahnwaldt wrote: Entered as http://issues.apache.org/jira/browse/AXIS2-1224 . I set the priority to blocker as David suggested. IMHO it's probably best to drop the method. Many users will use it in an intuitive but wrong way. The only way to store the data it provides is an instance variable, and telling users to either use only request scope or use a ThreadLocal to store the data does not seem to be compatible with the rule of least surprise. Something like MessageContext.getCurrentContext() in Axis 1 might be better. Bye, Christopher. Davanum Srinivas wrote: Chris, Can you please raise a new issue in JIRA? thanks, dims On 9/23/06, Christopher Sahnwaldt [EMAIL PROTECTED] wrote: Something worries me: setOperationContext(OperationContext) - per call. The messageContext can be obtained to gain per call instance information. That doesn't seem to be thread-safe, does it? If I understand this correctly, one service object is created per application (if the service has application scope). When a request comes in, Axis calls the setOperationContext method, and the service object may store the OperationContext or the MessageContext. Then Axis calls the actual service method, in which the service code can access the stored OperationContext or MessageContext. But what if two requests come in almost simultaneously? The following sequence of method calls may occur: - Axis calls setOperationContext with context for request A, the service object stores the context in an instance field. - Axis calls setOperationContext with context for request B, the same service object stores the context in the same instance field and thus *overwrites* the context for call A. - Axis calls the service method with the input parameters for request A. - The service method processes the call, using data from the stored context, and thus *mixes the input parameters for call A with the context data for call B*. Anything can happen... - Finally, Axis calls the service method with the input parameters for call B, the service method processes the call, using data from the stored context, and thus correctly uses the input parameters for call B with the context data for call B. Probably ok, unless the service method updated the context in some way during the call for request A. But I hope I'm wrong or misunderstood or forgot something... ;-) Axis 1 avoided this problem by MessageContext.getCurrentContext(), which gives access to the MessageContext *for the current thread* from within any service method, without the need for a setMessageContext (or setOperationContext) method on the service object. Bye, Christopher. Tony Dean wrote: Can we fully document the logical semantics behind each method? init(ServiceContext) - To me this use to mean application init. Now it means session init. However, when running scope=Application, it is analogous to application init since you will only have one session; but, still probably not appropriate to think in those terms. How should an application use this method? A
Re: [axis2] Improvements to Service life cycle in handling - setOperationContext not thread-safe??!!
Thilina,I understand your use case about having to create a new object for each invocation.But your use case is clearly in the minority. (meaning people will not do that often)So if you have a special requirment like that then why not use the concept of ServiceObjectSupplier. So if u specify a custom service object supplier which creates a new service object irrespective of the scope then you are fine.We should not in my opinion change the general expectation of the users at large to implement special cases. As a user my understanding of Application Scope is that I have a Service that will live for the life of the application.And I may have (or choose to do so) instance variables that I maybe relying across multiple invocations. I may also want to init expensive resources in my init().All these assumptions which are based on the general idea about application scope are no longer valid if choose to create new objects each time. Regards,RajithOn 10/10/06, Thilina Gunarathne [EMAIL PROTECTED] wrote: Hi Deepal,Deploying a service in application scope , user want to have onceservice impl instance (im I were a user , I want that )Frankly I don't... Service impl class is a Axis2 bundled MR(eg: RawXMLInOut..) specific notion... Service impl is meaning less if theuser has written a custom MR.. One example would be a BPELEngine(which I did :) ), where we had our own Message Receiver and we storedall thestate data in the service context.. See http://issues.apache.org/jira/browse/AXIS2-1133 this too..so we're now talking about setting a TLS OperationContext.getCurrentContext() into the AxisEngine, right before it calls the MessageReceiverI'm not sure about the impact of this change... If this is not astraight forward change I doubt whether we should do this at thismoment... Don't want to take any chances towards 1.1 :(... We should maintain both ,I mean - should have only oneserviceContext - and only one service implany concrete use cases Use cases which cannot be implemented usingby storing the state data in the service context... What if user want to keep local variable inside the impl class . I know that is not the best practice bt ppl are using that .Then why we gonna encourage that ??Thanks,~Thilina IMO anybody can use the ServiceContext to store whatever the state data needed to be shared across the life of the service...Are there any special cases where we can't do that.. If there aren't any reasons my suggestion is tocreate the service object per invocation. Also a user who uses the application scope might most probably be working in the messagereceiver(MR) level, since MR is known to be the ultimate message recipient in Axis2. One possible example is a BPEL engine.. In that case the concept of one service object for the life time of the service invalidates.. AFAIKS AXIS2-1133 is another implication of this design... Thanks, Thilina On 10/10/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: Other choices? The approach we used back in ApacheSOAP was to tell the user to add an additional first parameter to their methods if they wanted the context .. so the signature would have an additional param and that'd tell us to do the right thing. Very thread safe. Need to avoid reflection - but can be done by a codegen flag. For RPC case its reflective anyway so its not a big deal. Sanjiva. On Tue, 2006-10-10 at 09:40 -0400, Davanum Srinivas wrote: Sanjiva, We had terrible problems with TLS in Axis1...let me recollect my thougts and post. -- dims On 10/10/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote:I think I agree with you. How about we drop setOperationContext() andintroduce Axis1-style MessageContext.getCurrentContext() which returnsit for this thread? Have to be careful to put it in TLS and take it off! We must be careful to tell users that instance variables are notsupported; you have to use MessageContext properties to store state (orwherever else). Sanjiva. On Sun, 2006-09-24 at 14:12 +0200, Christopher Sahnwaldt wrote: Entered as http://issues.apache.org/jira/browse/AXIS2-1224 . I set the priority to blocker as David suggested. IMHO it's probably best to drop the method. Many users will use it in an intuitive but wrong way. The only way to store the data it provides is an instance variable, and telling users to either use only request scope or use a ThreadLocal to store the data does not seem to be compatible with the rule of least surprise. Something like MessageContext.getCurrentContext() in Axis 1 might be better. Bye, Christopher. Davanum Srinivas wrote: Chris, Can you please raise a new issue in JIRA? thanks, dims On 9/23/06, Christopher Sahnwaldt [EMAIL PROTECTED] wrote: Something worries me: setOperationContext(OperationContext) - per call.The messageContext can be
Re: [axis2] Improvements to Service life cycle in handling -setOperationContext not thread-safe??!!
In terms of setting up TLS info, I'm interested by the comment that it would be set in the AxisEngine. When we had the conversation about the ThreadContextMigrator interface (which does now exist) I understood that there wasn't any guarantee that there is a single thread in use through the handler chain. Was this a misunderstanding or is this a change? David On 10/10/06, Tom Jordahl [EMAIL PROTECTED] wrote: While we may have had to work around some bugs in Thread Local Storage (TLS) on the whole I think the Axis 1.x MessageContext.getCurrentContext() works exceptionally well. Since JDK 1.4 is the minimum for Axis2, I believe we have all the TLS bugs behind us, no? -- Tom Jordahl Adobe ColdFusion Team -Original Message- From: Sanjiva Weerawarana [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 10, 2006 10:28 AM To: [EMAIL PROTECTED] Cc: axis-dev@ws.apache.org Subject: Re: [axis2] Improvements to Service life cycle in handling -setOperationContext not thread-safe??!! Other choices? The approach we used back in ApacheSOAP was to tell the user to add an additional first parameter to their methods if they wanted the context .. so the signature would have an additional param and that'd tell us to do the right thing. Very thread safe. Need to avoid reflection - but can be done by a codegen flag. For RPC case its reflective anyway so its not a big deal. Sanjiva. On Tue, 2006-10-10 at 09:40 -0400, Davanum Srinivas wrote: Sanjiva, We had terrible problems with TLS in Axis1...let me recollect my thougts and post. -- dims On 10/10/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: I think I agree with you. How about we drop setOperationContext() and introduce Axis1-style MessageContext.getCurrentContext() which returns it for this thread? Have to be careful to put it in TLS and take it off! We must be careful to tell users that instance variables are not supported; you have to use MessageContext properties to store state (or wherever else). Sanjiva. On Sun, 2006-09-24 at 14:12 +0200, Christopher Sahnwaldt wrote: Entered as http://issues.apache.org/jira/browse/AXIS2-1224 . I set the priority to blocker as David suggested. IMHO it's probably best to drop the method. Many users will use it in an intuitive but wrong way. The only way to store the data it provides is an instance variable, and telling users to either use only request scope or use a ThreadLocal to store the data does not seem to be compatible with the rule of least surprise. Something like MessageContext.getCurrentContext() in Axis 1 might be better. Bye, Christopher. Davanum Srinivas wrote: Chris, Can you please raise a new issue in JIRA? thanks, dims On 9/23/06, Christopher Sahnwaldt [EMAIL PROTECTED] wrote: Something worries me: setOperationContext(OperationContext) - per call. The messageContext can be obtained to gain per call instance information. That doesn't seem to be thread-safe, does it? If I understand this correctly, one service object is created per application (if the service has application scope). When a request comes in, Axis calls the setOperationContext method, and the service object may store the OperationContext or the MessageContext. Then Axis calls the actual service method, in which the service code can access the stored OperationContext or MessageContext. But what if two requests come in almost simultaneously? The following sequence of method calls may occur: - Axis calls setOperationContext with context for request A, the service object stores the context in an instance field. - Axis calls setOperationContext with context for request B, the same service object stores the context in the same instance field and thus *overwrites* the context for call A. - Axis calls the service method with the input parameters for request A. - The service method processes the call, using data from the stored context, and thus *mixes the input parameters for call A with the context data for call B*. Anything can happen... - Finally, Axis calls the service method with the input parameters for call B, the service method processes the call, using data from the stored context, and thus correctly uses the input parameters for call B with the context data for call B. Probably ok, unless the service method updated the context in some way during the call for request A. But I hope I'm wrong or misunderstood or forgot something... ;-) Axis 1 avoided this problem by MessageContext.getCurrentContext(), which gives access to the MessageContext *for the current thread* from within any service method, without the need for a setMessageContext (or setOperationContext) method on the service object. Bye, Christopher. Tony Dean wrote: Can we
[jira] Closed: (AXIS2-1233) Handlers do not get a chance to undo work if a fault occurs or complete work when message processing finishes (this was split off from AXIS2-653)
[ http://issues.apache.org/jira/browse/AXIS2-1233?page=all ] Bill Nagy closed AXIS2-1233. Resolution: Fixed Handlers do not get a chance to undo work if a fault occurs or complete work when message processing finishes (this was split off from AXIS2-653) - Key: AXIS2-1233 URL: http://issues.apache.org/jira/browse/AXIS2-1233 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: core Reporter: Bill Nagy Assigned To: Bill Nagy Attachments: qoslifecyclepatch.txt I split this off of AXIS2-653, so that we could track this bit of work separately. The basic gist of the matter is that the handlers do not have an opportunity to clean up/complete their work after message processing has completed (either due to a fault or to successful processing.) Here's some of the original discussion: http://marc.theaimsgroup.com/?l=axis-devm=114505970102143w=2 . -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] What should be included in Axis2 minimal distribution
Dennis Sosnoski wrote: While we're looking into this, we should also check the war file contents. It looks like the full set of jars are included, which is certainly unnecessary. JiBX support only needs axis2-jibx-XXX.jar and jibx-run-XXX.jar, not the much larger bcel-XXX.jar (.5 MB) and jibx-bind-XXX.jar (.3 MB). I can strip these two unnecessary files out of the war build if someone wants to point me at the appropriate magic maven file, but I'm sure there's a lot more that can also be eliminated. Done. Removed bcel-XXX.jar and jibx-bind-XXX.jar from the build. BTW, we have no way of knowing which jars are really required. What the maven scripts does is (in case if some one doesn't know), when we name some modules, it will pick up all the dependencies of those modules and add them to the war (refer cache-war-deps goal in maven.xml). How I overcome the above problem is deleting un-necessary files, after the above goal is invoked (see line 384 of maven.xml). I could have done the same thing by excluding the jars within the war ant task, but I opted the above. Those couple of lines were to reveal the magic behind maven logic :). -- Chinthaka signature.asc Description: OpenPGP digital signature
[jira] Commented: (AXIS2-1339) WSDL2Java client side stub code does not work with AXIS2 TCP Server
[
http://issues.apache.org/jira/browse/AXIS2-1339?page=comments#action_12441283 ]
yogen commented on AXIS2-1339:
--
This is further information on this issue
One difference I debugged is ...
In TCP Server impl the MessageContext.Options.to value is never set. Therefore
none of the org.apache.axis2.engine.xxxDispatcher classes find the service
implementation.
Whereas in HTTP Server implementation HttpTransportUtils.processHTTPPostRequest
calls MessageContext.setTo to set it value to
/axis2/services/Axis2SampleDocLitServer.
WSDL2Java client side stub code does not work with AXIS2 TCP Server
---
Key: AXIS2-1339
URL: http://issues.apache.org/jira/browse/AXIS2-1339
Project: Apache Axis 2.0 (Axis2)
Issue Type: Bug
Components: core
Affects Versions: 1.1
Environment: Sun JVM 1.5, Axis2 1.1, WinXP
Reporter: yogen
Priority: Critical
The sample service axis2-rc1\samples\userguide\MyService.aar and client
\axis2-rc1\samples\userguide\src\userguide\clients\TCPClient.java *works*
with AXIS2 TCP Server.
But the code generated using wsdl2java for
\axis2-rc1\samples\wsdl\Axis2SampleDocLit.wsdl and service
Axis2SampleDocLitService.aar *does not work* with AXIS2 TCP Server (works
with HTTP Server).
1. the code is generated like this: wsdl2java -d xmlbeans -p com.sample -ss
-sd -g -uri Axis2SampleDocLit.wsdl -pn Axis2SampleDocLitPort
2. the service runs on port 6060.
3. Running the client code throws this exception stack trace:
Oct 10, 2006 12:06:02 PM org.apache.axis2.deployment.DeploymentEngine doDeploy
INFO: Deploying module : addressing-1.09
org.apache.axis2.AxisFault: Service not found operation terminated !!
at
org.apache.axis2.description.OutInAxisOperationClient.execute(OutInAxisOperation.java:294)
at
com.sample.Axis2SampleDocLitServiceStub.echoString(Axis2SampleDocLitServiceStub.java:505)
at TCP1Client.echoString(TCP1Client.java:28)
at TCP1Client.main(TCP1Client.java:17)
The client code is attached:
import javax.xml.namespace.QName;
import org.apache.axis2.Constants;
import org.apache.axis2.addressing.EndpointReference;
import org.apache.axis2.userguide.xsd.*;
import com.sample.*;
public class TCP1Client{
public static void main(java.lang.String args[]){
Axis2SampleDocLitServiceStub stub = null;
try{
stub = new Axis2SampleDocLitServiceStub(null,
tcp://localhost:6060/axis2/services/Axis2SampleDocLitService);
stub._getServiceClient().getOptions().setTo(new
EndpointReference(tcp://localhost:6060/axis2/services/Axis2SampleDocLitService));
stub._getServiceClient().getOptions().setTransportInProtocol(Constants.TRANSPORT_TCP);
stub._getServiceClient().engageModule(new
QName(Constants.MODULE_ADDRESSING));
System.out.println(echoString(stub));
} catch(Exception e){
e.printStackTrace();
}
}
public static String echoString(Axis2SampleDocLitServiceStub stub){
try{
EchoStringParamDocument reqDoc00 =
EchoStringParamDocument.Factory.newInstance();
reqDoc00.setEchoStringParam(echo);
EchoStringReturnDocument resDoc00 = stub.echoString(reqDoc00);
return resDoc00.getEchoStringReturn();
} catch(Exception e){
e.printStackTrace();
}
return null;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-1339) WSDL2Java client side stub code does not work with AXIS2 TCP Server
[
http://issues.apache.org/jira/browse/AXIS2-1339?page=comments#action_12441284 ]
yogen commented on AXIS2-1339:
--
This is further information on this issue
One difference I debugged is ...
In TCP Server impl the MessageContext.Options.to value is never set. Therefore
none of the org.apache.axis2.engine.xxxDispatcher classes find the service
implementation.
Whereas in HTTP Server implementation HttpTransportUtils.processHTTPPostRequest
calls MessageContext.setTo to set it value to
/axis2/services/Axis2SampleDocLitService.
WSDL2Java client side stub code does not work with AXIS2 TCP Server
---
Key: AXIS2-1339
URL: http://issues.apache.org/jira/browse/AXIS2-1339
Project: Apache Axis 2.0 (Axis2)
Issue Type: Bug
Components: core
Affects Versions: 1.1
Environment: Sun JVM 1.5, Axis2 1.1, WinXP
Reporter: yogen
Priority: Critical
The sample service axis2-rc1\samples\userguide\MyService.aar and client
\axis2-rc1\samples\userguide\src\userguide\clients\TCPClient.java *works*
with AXIS2 TCP Server.
But the code generated using wsdl2java for
\axis2-rc1\samples\wsdl\Axis2SampleDocLit.wsdl and service
Axis2SampleDocLitService.aar *does not work* with AXIS2 TCP Server (works
with HTTP Server).
1. the code is generated like this: wsdl2java -d xmlbeans -p com.sample -ss
-sd -g -uri Axis2SampleDocLit.wsdl -pn Axis2SampleDocLitPort
2. the service runs on port 6060.
3. Running the client code throws this exception stack trace:
Oct 10, 2006 12:06:02 PM org.apache.axis2.deployment.DeploymentEngine doDeploy
INFO: Deploying module : addressing-1.09
org.apache.axis2.AxisFault: Service not found operation terminated !!
at
org.apache.axis2.description.OutInAxisOperationClient.execute(OutInAxisOperation.java:294)
at
com.sample.Axis2SampleDocLitServiceStub.echoString(Axis2SampleDocLitServiceStub.java:505)
at TCP1Client.echoString(TCP1Client.java:28)
at TCP1Client.main(TCP1Client.java:17)
The client code is attached:
import javax.xml.namespace.QName;
import org.apache.axis2.Constants;
import org.apache.axis2.addressing.EndpointReference;
import org.apache.axis2.userguide.xsd.*;
import com.sample.*;
public class TCP1Client{
public static void main(java.lang.String args[]){
Axis2SampleDocLitServiceStub stub = null;
try{
stub = new Axis2SampleDocLitServiceStub(null,
tcp://localhost:6060/axis2/services/Axis2SampleDocLitService);
stub._getServiceClient().getOptions().setTo(new
EndpointReference(tcp://localhost:6060/axis2/services/Axis2SampleDocLitService));
stub._getServiceClient().getOptions().setTransportInProtocol(Constants.TRANSPORT_TCP);
stub._getServiceClient().engageModule(new
QName(Constants.MODULE_ADDRESSING));
System.out.println(echoString(stub));
} catch(Exception e){
e.printStackTrace();
}
}
public static String echoString(Axis2SampleDocLitServiceStub stub){
try{
EchoStringParamDocument reqDoc00 =
EchoStringParamDocument.Factory.newInstance();
reqDoc00.setEchoStringParam(echo);
EchoStringReturnDocument resDoc00 = stub.echoString(reqDoc00);
return resDoc00.getEchoStringReturn();
} catch(Exception e){
e.printStackTrace();
}
return null;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [axis2] Improvements to Service life cycle in handling -setOperationContext not thread-safe??!!
On Tue, 2006-10-10 at 20:21 +0100, David Illsley wrote: In terms of setting up TLS info, I'm interested by the comment that it would be set in the AxisEngine. When we had the conversation about the ThreadContextMigrator interface (which does now exist) I understood that there wasn't any guarantee that there is a single thread in use through the handler chain. I believe it'll be set in the message receiver just before invoking the method right guys? I can't see why it needs to be set earlier. Sanjiva. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [axis2] Improvements to Service life cycle in handling -setOperationContext not thread-safe??!!
On 10/10/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: On Tue, 2006-10-10 at 20:21 +0100, David Illsley wrote: In terms of setting up TLS info, I'm interested by the comment that it would be set in the AxisEngine. When we had the conversation about the ThreadContextMigrator interface (which does now exist) I understood that there wasn't any guarantee that there is a single thread in use through the handler chain. I believe it'll be set in the message receiver just before invoking the method right guys? I can't see why it needs to be set earlier. I agree it doesn't need to be earlier. From Deepal earlier in this thread: Deepal41: hi dims [12:06]GlenD: [11:59] GlenD so we're now talking about setting a TLS OperationContext.getCurrentContext() into the AxisEngine, right before it calls the MessageReceiver [12:06]GlenD: [11:59] GlenD and putting the thread ClassLoader stuff right in the same place [12:06]GlenD: [11:59] GlenD so it's factored out of the individual MRs [12:06]dims: +1 [12:07]ruchith: +1 [12:07]ruchith: we don't have to duplicate code this way [12:07]Deepal41: in the mean time shall we move ... David -- David Illsley - IBM Web Services Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [axis2] Improvements to Service life cycle in handling -setOperationContext not thread-safe??!!
Hi Sanjiva Weerawarana wrote: On Tue, 2006-10-10 at 20:21 +0100, David Illsley wrote: In terms of setting up TLS info, I'm interested by the comment that it would be set in the AxisEngine. When we had the conversation about the ThreadContextMigrator interface (which does now exist) I understood that there wasn't any guarantee that there is a single thread in use through the handler chain. I believe it'll be set in the message receiver just before invoking the method right guys? I can't see why it needs to be set earlier. Yes that was the final conclusion. FYI: Deepal: hi dims [15:07]Deepal: u there [15:08]Deepal: I dont think we can move saveTCCL(messageCtx); in AxisEngine [15:23]GlenD: dims? [15:23]GlenD: u there? [15:26]dims: ping [15:26]GlenD: hey [15:26]GlenD: so Deepal and I were chatting about the context stuff [15:26]dims: yes [15:26]GlenD: and ended up coming up with a very interesting idea which we wanted to run past you [15:26]dims: sure [15:26]GlenD: I think it's too big a change for now, but it's pretty cool for a future release [15:27]dims: we need to make a list of those :) [15:28]GlenD: the issue is that there's a lot of code duplication amongst MessageReceivers [15:28]dims: ah. that one :) [15:28]GlenD: if we want this setTCCL stuff and the setCurrentContext stuff to live in the MRs, it's hard to figure out where to put it so it isn't dup'ed everywhere [15:29]dims: call back to engine? [15:29]dims: sorry...go ahead. [15:29]GlenD: so we're wondering if you could maybe factor it out into a single AbstractMessageReceiver [15:29]GlenD: which would do the TCCL/Context stuff, then call invokeBusinessLogic() but pass only the OperationContext [15:29]dims: we have one of those [15:30]dims: AbstractMessageReceiver [15:30]GlenD: not have separate ones that pass either (inContext) or (inContext, outContext) [15:30]GlenD: we do? [15:30]dims: we need to structure it better [15:30]Deepal: we have 4 of them :) [15:30]GlenD: right [15:30]GlenD: we have 4 [15:30]dims: org.apache.axis2.receivers.AbstractMessageReceiver [15:31]dims: ah. i see [15:31]Deepal: and we are thinking of chaning invokeBusinessLogic signature [15:31]GlenD: only the lower level ones (AbstractInOnlyMR, etc) actually have receive() [15:31]GlenD: the top level one doesn't do anything [15:31]GlenD: except hold utility methods [15:31]dims: any cleanup is very welcome! sorely needed in this area. [15:31]dims: +1 [15:31]GlenD: so the interesting part is that SOMEONE needs to know to take the outMessageContext from the operationContext and send it [15:31]dims: please make sure you handle the spring scenario [15:31]Deepal: invokeBusinessLogice will take OperationContext as it argument [15:32]GlenD: that's the real difference between in and inout [15:32]dims: and then check isinstanceof? [15:32]GlenD: we're wondering if there's a way to genericize that by calling invokeBusinessLogic() and then something like complete() or doNext() [15:32]GlenD: but we need to think about it a little more I think :) [15:33]dims: yep... [15:33]dims: pre and post? [15:34]GlenD: (thinking here) [15:34]dims: first step is to collapse all 4 into 1 AbstractMessageReceiver? [15:34]dims: somehow [15:34]GlenD: that was the thought yes but we're seeing if it can work [15:35]dims: then adjust the calls to invokeBusinessLogic and maybe call something before it and something after it for special processing for different MEP's? [15:36]dims: are we looking for clean code or new feature here? [15:36]Deepal: I think both :) [15:37]dims: and the new Feature is?.. [15:37]GlenD: its really mostly clean code [15:37]GlenD: and a good place to put the common stuff for tls [15:38]dims: :) ok. [15:53]GlenD: ok never mind :) [15:53]GlenD: I think we just came to the conclusion that it's actually useful to have different abstract Receiver types [15:54]GlenD: because they're the ones that know the logic for message processing [15:54]GlenD: if you had an in/in/out MR, for instance, it could have processMessage1() and processMessage2() abstract operations [15:54]GlenD: that's nicer than just relying on a single invokeBusinessLogic(OperationContext), I think [15:56]GlenD: So the idea is to coalesce the TCCL stuff and the CurrentContext stuff into a setupThreadContext() and removeThreadContext() on AbstractMessageReceiver [15:57]GlenD: so developers of new MRs that want TLS functionality would need to know to call that
[Axis2] Summery of todays Hackathon
Hi All;
Few note from todays Hackathon we had at ApacheCon US.
We are having very ugly name called finalizeInvoke() in service client
with restriction, so we (Glen and I agreed) to remove that method and
move the code into cleanup (well I am doing the changes in current
codebase).
Why do we need operation client ?
As Dennis suggested , having annon name as public static seems not that
good , so we need to remove them I mean we need to make the private.
Rather than giving two client API to client cant we have one API , we
can have all the methods in serviceClient then no one need to know about
the operationClient (service client will use that internally ). So our
proposal is to add few more methods into ServiceCleint;
public MessageContext sendReceive(MessageContext req){}
public void sendReceiveNonBlocking(MessageContext req){}
public fireAndForget(MessageContext req){}
public sendRobust(MessageContext req){}
if we introduce these methods into ServiceClient then we do not too much
worry about how to create operationClient etc...
I am +1 on adding these four methods in to serviceClient.
===
How do we reflect service group concept in to client , and manage
session using that. Well I do understand if we use Axis2 client -
Axis2 service this will work , but what if we use .Net client - Axis2
Service. Is there any kind of specification sending session related data
in SOAP message ? , if there is such a thing then we need to use them.
Thanks
Deepal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Summery of todays Hackathon
Deepal,
Please create JIRA issue(s) and let's work on them.
thanks,
dims
On 10/10/06, Deepal Jayasinghe [EMAIL PROTECTED] wrote:
Hi All;
Few note from todays Hackathon we had at ApacheCon US.
We are having very ugly name called finalizeInvoke() in service client
with restriction, so we (Glen and I agreed) to remove that method and
move the code into cleanup (well I am doing the changes in current
codebase).
Why do we need operation client ?
As Dennis suggested , having annon name as public static seems not that
good , so we need to remove them I mean we need to make the private.
Rather than giving two client API to client cant we have one API , we
can have all the methods in serviceClient then no one need to know about
the operationClient (service client will use that internally ). So our
proposal is to add few more methods into ServiceCleint;
public MessageContext sendReceive(MessageContext req){}
public void sendReceiveNonBlocking(MessageContext req){}
public fireAndForget(MessageContext req){}
public sendRobust(MessageContext req){}
if we introduce these methods into ServiceClient then we do not too much
worry about how to create operationClient etc...
I am +1 on adding these four methods in to serviceClient.
===
How do we reflect service group concept in to client , and manage
session using that. Well I do understand if we use Axis2 client -
Axis2 service this will work , but what if we use .Net client - Axis2
Service. Is there any kind of specification sending session related data
in SOAP message ? , if there is such a thing then we need to use them.
Thanks
Deepal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2][RC-1.1] problem with HTTP/BOM content before SOAP response
Hi, I'm having a problem with the Axis2 1.1 RC on the client side. My services still work as normal when I upgrade them to 1.1, but my non-Axis2 clients fail when trying to parse the response message. I get the following error message from the JAXP DocumentBuilder (Xerces): [Fatal Error] :1:1: Content is not allowed in prolog. I initially thought this was related to an old bug in the processing of byte-order marks at the beginning of XML documents: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4508058 However, when I look at the SOAP response in my TCP/IP monitor, I see the following: --MIMEBoundaryurn_uuid_D29F76E66EC97F738911605255931147 content-type: application/xop+xml; charset=UTF-8; type=application/soap+xml; content-transfer-encoding: binary content-id: 0.urn:uuid:[EMAIL PROTECTED] ?xml version='1.0' encoding='UTF-8'? soapenv:Envelope xmlns:wsa=http://www.w3.org/2005/08/addressing; xmlns:soapenv=http://www.w3.org/2003/05/soap-envelope; soapenv:Header wsa:Tohttp://www.w3.org/2005/08/addressing/anonymous/wsa:To wsa:ReplyTowsa:Addresshttp://www.w3.org/2005/08/addressing/none/wsa:Address/wsa:ReplyTo wsa:MessageIDurn:uuid:26F070AB96AC17B8D811605255931048/wsa:MessageID wsa:Actionhttp://ws.apache.org/muse/test/http-server/Stop/wsa:Action wsa:RelatesTo wsa:RelationshipType=http://www.w3.org/2005/08/addressing/reply;uuid:80882292-b452-7e92-919d-01ed1f001f17/wsa:RelatesTo /soapenv:Header soapenv:Body muse-op:StopResponse xmlns:tns=http://ws.apache.org/axis2; xmlns:muse-op=http://ws.apache.org/muse/test/http-server; / /soapenv:Body /soapenv:Envelope --MIMEBoundaryurn_uuid_D29F76E66EC97F738911605255931147-- Can anyone comment on why the MIMEBoundary wrapper and some HTTP headers seem to be in the POST data? I think this is what's causing Xerces to fail when parsing the POST content into a DOM Document. This may be a significant issue since most web services clients assume that the only POST data in a SOAP response is the SOAP XML document. Thanks, Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Summery of todays Hackathon
Hi,
public MessageContext sendReceive(MessageContext req){}
public void sendReceiveNonBlocking(MessageContext req){}
public fireAndForget(MessageContext req){}
public sendRobust(MessageContext req){}
Huge +1.
Currently we provide SwA support only in the OperationClient level,
cause we need to access the message context... This will solve that
issue..
~Thilina
if we introduce these methods into ServiceClient then we do not too much
worry about how to create operationClient etc...
I am +1 on adding these four methods in to serviceClient.
===
How do we reflect service group concept in to client , and manage
session using that. Well I do understand if we use Axis2 client -
Axis2 service this will work , but what if we use .Net client - Axis2
Service. Is there any kind of specification sending session related data
in SOAP message ? , if there is such a thing then we need to use them.
Thanks
Deepal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
http://webservices.apache.org/~thilina/
http://thilinag.blogspot.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Proposal to add return type to Handler.invoke(...)
Hi Sanjiva,
The problem isn't that both people are modifying MessageContext.paused,
so synchronizing that isn't going to work, the problem is that if the RM
handler, for instance, pauses the message and returns, but the RM thread
picks up the message and resumes it (thereby unpausing the message)
before control returns to the logic in the Phase/AxisEngine, the
Phase/AxisEngine are going to proceed as if the message was never
paused.
I was trying to avoid the overhead of synchronization when we have
another solution that works just as well (i.e. the return value) without
the overhead (and is more logically correct IMO.)
Using the return code also allows us to capture whether or not a message
was 'paused' vs 'aborted' -- this is important in the handler unwinding,
as no unwinding needs to occur in the 'paused' case while it does in the
'aborted' case.
I prefer an enumeration object because it's clear from the method
signature what is being returned (InvocationProcessingInstruction vs.
int in this case,) but if that's all that is holding you up, I'll switch
it to constants.
-Bill
On Tue, 2006-10-10 at 18:13 +0530, Sanjiva Weerawarana wrote:
On Mon, 2006-10-09 at 19:51 -0700, Bill Nagy wrote:
There is currently a race condition between code that pauses the message
flow within a handler and resumes it on another thread (e.g. Sandesha)
and the message flow processing chain (Phase.invoke(...),
AxisEngine.invoke(...), etc.)
(http://issues.apache.org/jira/browse/SANDESHA2-32) This is caused
because the control of processing is keyed off of MessageContext.paused
and not through some other mechanism (return code, semaphore, etc.). If
a handler pauses a message and returns, handing the message off to
another thread for execution, there is the possibility that the new
execution thread will resume processing of the message, unsetting
MessageContext.paused, before control returns to one of the invoke
methods. If this happens, the logic in the invoke method, which looks
at the MessageContext.paused flag, will believe that it should continue
execution instead of halting.
Can't this be solved by synchronizing access to MessageContext.paused()?
Sorry I looked at the sandesha issue but didn't see it.
Alternatively,
synchronized {
h.invoke();
h.getPaused();
}
I must be missing something obvious as to why this doesn't work.
Since the problem revolves around flow control logic, I suggest that we
use the return code from the method invocation to deal with it. I would
like to add a return code to the Handler.invoke(...) which would
identify how processing of the message should proceed, e.g. :
How does this solve the problem as other thread could go get the MC and
do stuff while still in this method?
/**
* This type encapsulates an enumeration of possible message processing
* instruction values that may be returned by a handler/phase within the
* runtime.
*/
public class InvocationProcessingInstruction
{
public static InvocationProcessingInstruction CONTINUE_PROCESSING =
new InvocationProcessingInstruction(0);
public static InvocationProcessingInstruction SUSPEND_PROCESSING = new
InvocationProcessingInstruction(1);
public static InvocationProcessingInstruction ABORT_PROCESSING = new
InvocationProcessingInstruction(2);
private int instructionID;
private InvocationProcessingInstruction(int instructionID)
{
this.instructionID = instructionID;
}
public boolean equals(InvocationProcessingInstruction instruction)
{
return this.instructionID == instruction.instructionID;
}
public int hashCode()
{
return instructionID;
}
}
Most handlers will return
InvocationProcessingInstruction.CONTINUE_PROCESSING; the RM handler may
return that, SUSPEND_PROCESSING (for a pause), or ABORT_PROCESSING (for
a duplicate msg.)
I must be really jetlagged (traveling again): do we need all this or
just use an int to return the status?? (some consts basically).
Sanjiva.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spring support broken ?????
Hi All,The current spring support fails with the following exception possibly due to the new code change of obtaining the servlet config from the AxisConfiguration instead from the Message Context.Caused by:
org.apache.axis2.AxisFault: Axis2 Can't find ServletConfig; nested exception is:java.lang.Exception: Axis2 Can't find ServletConfigat org.apache.axis2.AxisFault.makeFault(AxisFault.java:318)at
org.apache.axis2.extensions.spring.receivers.SpringServletContextObjectSupplier.getServiceObject(SpringServletContextObjectSupplier.java:70)... 43 moreCaused by: java.lang.Exception: Axis2 Can't find ServletConfig
at org.apache.axis2.extensions.spring.receivers.SpringServletContextObjectSupplier.getServiceObject(SpringServletContextObjectSupplier.java:53)... 43 moreNow when I look at the code I see that at revesion 426884 the code was obtaining the servlet config from the msgContext.
servletContext servletContext = (ServletContext) msgContext.getOptions(). getProperty(HTTPConstants.MC_HTTP_SERVLETCONTEXT);However the head revision was obtaining the servlet config via the AxisConfiguration.
ServletConfig servletConfig = (ServletConfig) axisService.getAxisConfiguration().getParameter(HTTPConstants.HTTP_SERVLETCONFIG);if (servletConfig == null) {throw new Exception(Axis2 Can't find ServletConfig);
}Why did we make the change ??? If we did so are we making sure that we populate the AxisConfiguration with the servlet config ?
[axis2] Spring support broken ?????
Forwarding with the axis2 prefix.-- Forwarded message --From: Rajith Attapattu [EMAIL PROTECTED]
Date: Oct 10, 2006 10:17 PMSubject: Re: Spring support broken ?To: axis-dev@ws.apache.orgCc: [EMAIL PROTECTED]
Hi All,The current spring support fails with the following exception possibly due to the new code change of obtaining the servlet config from the AxisConfiguration instead from the Message Context.
Caused by:
org.apache.axis2.AxisFault: Axis2 Can't find ServletConfig; nested exception is:java.lang.Exception: Axis2 Can't find ServletConfigat org.apache.axis2.AxisFault.makeFault(AxisFault.java:318)at
org.apache.axis2.extensions.spring.receivers.SpringServletContextObjectSupplier.getServiceObject(SpringServletContextObjectSupplier.java:70)... 43 moreCaused by: java.lang.Exception: Axis2 Can't find ServletConfig
at org.apache.axis2.extensions.spring.receivers.SpringServletContextObjectSupplier.getServiceObject(SpringServletContextObjectSupplier.java:53)... 43 moreNow when I look at the code I see that at revesion 426884 the code was obtaining the servlet config from the msgContext.
servletContext servletContext = (ServletContext) msgContext.getOptions(). getProperty(HTTPConstants.MC_HTTP_SERVLETCONTEXT);However the head revision was obtaining the servlet config via the AxisConfiguration.
ServletConfig servletConfig = (ServletConfig) axisService.getAxisConfiguration().getParameter(HTTPConstants.HTTP_SERVLETCONFIG);if (servletConfig == null) {throw new Exception(Axis2 Can't find ServletConfig);
}Why did we make the change ??? If we did so are we making sure that we populate the AxisConfiguration with the servlet config ?
Re: [Axis2] Summery of todays Hackathon
On Tue, 2006-10-10 at 17:54 -0500, Deepal Jayasinghe wrote:
Why do we need operation client ?
??? You gotta be kidding.
We have it because that's the client API for a generic MEP.
As Dennis suggested , having annon name as public static seems not that
good , so we need to remove them I mean we need to make the private.
Sorry I don't understand what you're referring to. If its the constants
we used to make the simple API work then I don't agree there's any
problem.
Rather than giving two client API to client cant we have one API , we
can have all the methods in serviceClient then no one need to know about
the operationClient (service client will use that internally ). So our
proposal is to add few more methods into ServiceCleint;
public MessageContext sendReceive(MessageContext req){}
public void sendReceiveNonBlocking(MessageContext req){}
public fireAndForget(MessageContext req){}
public sendRobust(MessageContext req){}
This only works for the 4 built-in MEPs. Have we decided to narrow Axis2
down to the built in MEPs? If so half of the machinery in Axis2 can be
removed.
if we introduce these methods into ServiceClient then we do not too much
worry about how to create operationClient etc...
I am +1 on adding these four methods in to serviceClient.
Sorry, I'm -1 to this change. No way. It fundamentally breaks the client
API
If you want to do this then in the minimum it has to be after 1.1. No
way we're going to change the client API after RC1 has been cut!
===
How do we reflect service group concept in to client , and manage
session using that. Well I do understand if we use Axis2 client -
Axis2 service this will work , but what if we use .Net client - Axis2
Service. Is there any kind of specification sending session related data
in SOAP message ? , if there is such a thing then we need to use them.
You're forgetting a design decision we made a while ago: to make the
service group concept not visible to the outside. That's why we said
services withing group become top level services. I was against it but
that's what we decided. As such there's no need to expose it to the
client.
What will be useful is for one service in a group to be able to get the
EPR of another service in a group. Something like
ServiceGroupContext.getEPRForService (serviceName). That can propagate
the contextID etc. so that they share the same interaction session.
Sanjiva.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Summery of todays Hackathon
SanjivaI also agree on your comments regarding the operation client.Now about the whole session/clustering thing. You mention that outside of Axis2 the concept of Service Group does not exist !!!So a client would expect to interact with Services from two Service Groups in a single session.
Thats the reason why I proposed a WS-Addressing or WS-Context
based approach which has a notion of session outside the context
heirachy and spans ServiceGroups. It's a lot more simple than ServiceGroupContext.getEPRForService
(serviceName) to propogate information.Why
can't we have a single lightweight mechanism to share application
data among services without all the hassel of being tied down to
the context heirachy.
However we still need to replicate Service Context and
ServiceGroupContext as there maybe axis2 specific operational data that
needs to available to service the client properly.I hear your argument about isolation at Service and Service Group level. But I think it should be limited to operational data.
For business data we should be able to share across Services that spans serveral Service Groups if the user chooses to do so.Comments are welcomed !!Regards,Rajith
On 10/10/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote:
On Tue, 2006-10-10 at 17:54 -0500, Deepal Jayasinghe wrote: Why do we need operation client ???? You gotta be kidding.We have it because that's the client API for a generic MEP. As Dennis suggested , having annon name as public static seems not that
good , so we need to remove them I mean we need to make the private.Sorry I don't understand what you're referring to. If its the constantswe used to make the simple API work then I don't agree there's any
problem. Rather than giving two client API to client cant we have one API , we can have all the methods in serviceClient then no one need to know about the operationClient (service client will use that internally ). So our
proposal is to add few more methods into ServiceCleint; public MessageContext sendReceive(MessageContext req){} public void sendReceiveNonBlocking(MessageContext req){} public fireAndForget(MessageContext req){}
public sendRobust(MessageContext req){}This only works for the 4 built-in MEPs. Have we decided to narrow Axis2down to the built in MEPs? If so half of the machinery in Axis2 can beremoved.
if we introduce these methods into ServiceClient then we do not too much worry about how to create operationClient etc... I am +1 on adding these four methods in to serviceClient.Sorry, I'm -1 to this change. No way. It fundamentally breaks the client
APIIf you want to do this then in the minimum it has to be after 1.1. Noway we're going to change the client API after RC1 has been cut! === How do we reflect service group concept in to client , and manage
session using that. Well I do understand if we use Axis2 client - Axis2 service this will work , but what if we use .Net client - Axis2 Service. Is there any kind of specification sending session related data
in SOAP message ? , if there is such a thing then we need to use them.You're forgetting a design decision we made a while ago: to make theservice group concept not visible to the outside. That's why we said
services withing group become top level services. I was against it butthat's what we decided. As such there's no need to expose it to theclient.What will be useful is for one service in a group to be able to get the
EPR of another service in a group. Something likeServiceGroupContext.getEPRForService (serviceName). That can propagatethe contextID etc. so that they share the same interaction session.Sanjiva.
-To unsubscribe, e-mail: [EMAIL PROTECTED]For additional commands, e-mail:
[EMAIL PROTECTED]
Re: [axis2] Spring support broken ?????
Its late here so I'll take a look tomorrow. In the meantime, the
reason why this wasn't caught is because I'm not sure how to get a
ServletContext from our testing environment or if its even possible.
There are tests for the non-servlet container config. If someone knows
how to test the former case please post to the list. I've been mostly
focused on the latter lately, ie, non-servletContext config inside the
AAR.
Thanks for catching that Rajith.
Robert
On 10/10/06, Rajith Attapattu [EMAIL PROTECTED] wrote:
Forwarding with the axis2 prefix.
-- Forwarded message --
From: Rajith Attapattu [EMAIL PROTECTED]
Date: Oct 10, 2006 10:17 PM
Subject: Re: Spring support broken ?
To: axis-dev@ws.apache.org
Cc: [EMAIL PROTECTED]
Hi All,
The current spring support fails with the following exception possibly due
to the new code change of obtaining the servlet config from the
AxisConfiguration instead from the Message Context.
Caused by: org.apache.axis2.AxisFault: Axis2 Can't find ServletConfig;
nested exception is:
java.lang.Exception: Axis2 Can't find ServletConfig
at
org.apache.axis2.AxisFault.makeFault(AxisFault.java:318)
at
org.apache.axis2.extensions.spring.receivers.SpringServletContextObjectSupplier.getServiceObject(SpringServletContextObjectSupplier.java:70)
... 43 more
Caused by: java.lang.Exception: Axis2 Can't find ServletConfig
at
org.apache.axis2.extensions.spring.receivers.SpringServletContextObjectSupplier.getServiceObject(SpringServletContextObjectSupplier.java:53)
... 43 more
Now when I look at the code I see that at revesion 426884 the code was
obtaining the servlet config from the msgContext.
servletContext servletContext = (ServletContext) msgContext.getOptions().
getProperty(HTTPConstants.MC_HTTP_SERVLETCONTEXT);
However the head revision was obtaining the servlet config via the
AxisConfiguration.
ServletConfig servletConfig = (ServletConfig)
axisService.getAxisConfiguration()
.getParameter(HTTPConstants.HTTP_SERVLETCONFIG);
if (servletConfig == null) {
throw new Exception(Axis2 Can't find ServletConfig);
}
Why did we make the change ??? If we did so are we making sure that we
populate the AxisConfiguration with the servlet config ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r462672 - in /webservices/axis2/branches/java/1_1/modules: integration/maven.xml kernel/conf/axis2.xml
I dont' remember that. I do remember this:
http://marc.theaimsgroup.com/?l=axis-devm=115869598518264w=2
which was, that If mtom enabled is on, then we always use mime stuff
whether there is an attachment or not.
-- dims
On 10/10/06, Thilina Gunarathne [EMAIL PROTECTED] wrote:
Ahh... My bad.. I thought I removed all the references to
kernel/conf/axis2.xml...
Regarding the MIME issue, i thought we came to a decision to switch
on MTOM by default... Anyway I'm fine with either...
~Thilina
On 10/11/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: dims
Date: Tue Oct 10 19:53:17 2006
New Revision: 462672
URL: http://svn.apache.org/viewvc?view=revrev=462672
Log:
Fix for Problem mentioned here:
http://marc.theaimsgroup.com/?l=axis-devm=116052679312513w=2
We should not be generating MIME stuff for non-mtom requests, fails miserably
for non-Axis2 clients. Also removed references to kernel/conf/axis2.xml from the
maven.xml in integration.
Thilina, Could you please review and verify this change?
Modified:
webservices/axis2/branches/java/1_1/modules/integration/maven.xml
webservices/axis2/branches/java/1_1/modules/kernel/conf/axis2.xml
Modified: webservices/axis2/branches/java/1_1/modules/integration/maven.xml
URL:
http://svn.apache.org/viewvc/webservices/axis2/branches/java/1_1/modules/integration/maven.xml?view=diffrev=462672r1=462671r2=462672
==
--- webservices/axis2/branches/java/1_1/modules/integration/maven.xml
(original)
+++ webservices/axis2/branches/java/1_1/modules/integration/maven.xml Tue Oct
10 19:53:17 2006
@@ -1030,22 +1030,22 @@
mkdir dir=target/Repository/modules/
copy
file=../addressing/target/addressing-${addressing_version}.mar
tofile=target/Repository/modules/addressing-${addressing_version}.mar/
-copy file=../kernel/conf/axis2.xml
+copy file=conf/axis2.xml
tofile=target/Repository/conf/axis2.xml/
mkdir dir=target/perf2/build/repo/conf/
mkdir dir=target/perf/build/repo/conf/
- copy file=../kernel/conf/axis2.xml
+ copy file=conf/axis2.xml
tofile=target/perf2/build/repo/conf/axis2.xml/
-copy file=../kernel/conf/axis2.xml
+ copy file=conf/axis2.xml
tofile=target/perf/build/repo/conf/axis2.xml/
-mkdir dir=target/perf2/build/repo/modules/
+ mkdir dir=target/perf2/build/repo/modules/
copy
file=../addressing/target/addressing-${addressing_version}.mar
tofile=target/perf2/build/repo/modules/addressing-${addressing_version}.mar/
-mkdir dir=target/perf/build/repo/modules/
+ mkdir dir=target/perf/build/repo/modules/
copy
file=../addressing/target/addressing-${addressing_version}.mar
tofile=target/perf/build/repo/modules/addressing-${addressing_version}.mar/
Modified: webservices/axis2/branches/java/1_1/modules/kernel/conf/axis2.xml
URL:
http://svn.apache.org/viewvc/webservices/axis2/branches/java/1_1/modules/kernel/conf/axis2.xml?view=diffrev=462672r1=462671r2=462672
==
--- webservices/axis2/branches/java/1_1/modules/kernel/conf/axis2.xml
(original)
+++ webservices/axis2/branches/java/1_1/modules/kernel/conf/axis2.xml Tue Oct
10 19:53:17 2006
@@ -4,7 +4,7 @@
!-- = --
parameter name=hotdeployment locked=falsetrue/parameter
parameter name=hotupdate locked=falsefalse/parameter
-parameter name=enableMTOM locked=falsetrue/parameter
+parameter name=enableMTOM locked=falsefalse/parameter
parameter name=enableSwA locked=falsefalse/parameter
!--Uncomment if you want to enable file caching for attachments --
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
http://webservices.apache.org/~thilina/
http://thilinag.blogspot.com/
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-1340) Axis2Util.toOM() needs to work w/o XML-Security jar
[ http://issues.apache.org/jira/browse/AXIS2-1340?page=all ] Davanum Srinivas resolved AXIS2-1340. - Resolution: Fixed Looks like this is fixed: http://marc.theaimsgroup.com/?l=axis-cvsm=116052397203244w=2 http://svn.apache.org/viewvc?view=revrev=462640 Axis2Util.toOM() needs to work w/o XML-Security jar --- Key: AXIS2-1340 URL: http://issues.apache.org/jira/browse/AXIS2-1340 Project: Apache Axis 2.0 (Axis2) Issue Type: Improvement Components: om Environment: Any Reporter: Sathija Pavuluri Priority: Minor When converting a DOM element to OMElement, the process is not straightforward. We first need to use the org.apache.rampart.util.Axis2Utils.toOM() from axis2-security-SNAPSHOT.jar. The toOM() method references the org.apache.xml.security.utils.XMLUtils class from xml-security jar file. So one needs to include that jar in the classpath. And then this error is seen: org.apache.xml.security.c14n.InvalidCanonicalizerException: You must initialize the xml-security library correctly before you use it. Call the static method org.apache.xml.security.Init.init(); to do that before you use any functionality from that library. at org.apache.xml.security.c14n.Canonicalizer.init(Unknown Source) at org.apache.xml.security.c14n.Canonicalizer.getInstance(Unknown Source) at org.apache.xml.security.utils.XMLUtils.outputDOM(Unknown Source) at org.apache.rampart.util.Axis2Util.toOM(Axis2Util.java:176) To fix this, I have had to call org.apache.xml.security.Init.init(); in my class before invoking Axis2Utils.toOM(). This is rather cumbersome. It would be nice if the axis2-security was packaged so that the xml-security jar need not be imported. Or the toOM() method needs to correctly initialize the xml-security jar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (AXIS2-1163) replace service endpoint when serving original wsdl using useOriginalwsdl param
[ http://issues.apache.org/jira/browse/AXIS2-1163?page=all ] Davanum Srinivas reassigned AXIS2-1163: --- Assignee: Eran Chinthaka replace service endpoint when serving original wsdl using useOriginalwsdl param --- Key: AXIS2-1163 URL: http://issues.apache.org/jira/browse/AXIS2-1163 Project: Apache Axis 2.0 (Axis2) Issue Type: Improvement Affects Versions: 1.0 Reporter: rajesh Assigned To: Eran Chinthaka Priority: Blocker I've used the recently added useOriginalwsdl attribute to services.xml to serve the wsdl from META-INF (and thanks for the fix). It would be nice to just replace the endpoint address using the request url and context when serving the original wsdl. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS-2541) Deserializing dates in attributes
[
http://issues.apache.org/jira/browse/AXIS-2541?page=comments#action_12441342 ]
Christian Phan-Trong commented on AXIS-2541:
I have exactly the same issue. I Took a look at similar issues in Jira, and it
seems like this one is a recurrent one. The same problem is reported in
AXIS-2115 and some very intersting comments can also be found in AXIS-1050. I
still didn't solve the issue though.
Deserializing dates in attributes
-
Key: AXIS-2541
URL: http://issues.apache.org/jira/browse/AXIS-2541
Project: Apache Axis
Issue Type: Bug
Affects Versions: 1.2.1, 1.4
Environment: JDK1.5, Windows, Axis 1.2.1 and 1.4
Reporter: Michael Becke
Dates are not correctly deserialized when used as in the following WSDL:
?xml version=1.0?
definitions name=TestDates
xmlns=http://schemas.xmlsoap.org/wsdl/;
xmlns:xs=http://www.w3.org/2001/XMLSchema;
targetNamespace=http://ws.apache.org/test;
xmlns:tns=http://ws.apache.org/test;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
types
xs:schema
targetNamespace=http://ws.apache.org/test;
xmlns:tns=http://ws.apache.org/test;
xmlns:xs=http://www.w3.org/2001/XMLSchema;
elementFormDefault=qualified
xs:element name=DateRequest
xs:complexType
xs:all
xs:element name=DateValue
type=tns:DateValueType minOccurs=1 maxOccurs=1 /
/xs:all
/xs:complexType
/xs:element
xs:complexType name=DateValueType
xs:attribute name=date type=xs:date /
xs:attribute name=value type=xs:decimal /
/xs:complexType
xs:element name=DateResponse
xs:complexType
xs:all
xs:element name=Date type=xs:date
minOccurs=1 maxOccurs=1 /
/xs:all
/xs:complexType
/xs:element
/xs:schema
/types
message name=TestRequestMsg
part name=body element=tns:DateRequest/
/message
message name=TestResponseMsg
part name=body element=tns:DateResponse/
/message
portType name=TestPortType
operation name=TestDates
input message=tns:TestRequestMsg/
output message=tns:TestResponseMsg/
/operation
/portType
binding name=TestSoapBinding type=tns:TestPortType
soap:binding style=document
transport=http://schemas.xmlsoap.org/soap/http/
operation name=TestDates
soap:operation soapAction=http://ws.apache.org/
input
soap:body use=literal/
/input
output
soap:body use=literal/
/output
/operation
/binding
service name=TestService
documentation/documentation
port name=TestService binding=tns:TestSoapBinding
soap:address location=http://localhost/axis/ws/TestService/
/port
/service
/definitions
I am using WSDL2Java to gerate the client/server for this service. Once
generated and installed, calling the service produces the following exception:
AxisFault
faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
faultSubcode:
faultString: java.lang.NumberFormatException: For input string:
quot;2006-08-16quot;
faultActor:
faultNode:
faultDetail:
{http://xml.apache.org/axis/}hostname:mbecke
java.lang.NumberFormatException: For input string: 2006-08-16
at
org.apache.axis.message.SOAPFaultBuilder.createFault(SOAPFaultBuilder.java:222)
at
org.apache.axis.message.SOAPFaultBuilder.endElement(SOAPFaultBuilder.java:129)
at
org.apache.axis.encoding.DeserializationContext.endElement(DeserializationContext.java:1087)
at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown
Source)
at
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:375)
at
[jira] Resolved: (AXIS2-1333) InvocationTargetException thrown when accessing 'Engage Module For a Service' page in Axis2 admin console
[ http://issues.apache.org/jira/browse/AXIS2-1333?page=all ] Davanum Srinivas resolved AXIS2-1333. - Resolution: Fixed Charitha, fixed in r462694 (branch 1.1). Can u please try this? thanks, dims PS: Make sure your completely remove the work directory under tomcat before you start tomcat (each time!) for better testing. It caches the generated files (from jsp) in that directory. InvocationTargetException thrown when accessing 'Engage Module For a Service' page in Axis2 admin console - Key: AXIS2-1333 URL: http://issues.apache.org/jira/browse/AXIS2-1333 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Affects Versions: 1.1 Environment: Windows XP, jdk1.5.0_08, Mozilla Firefox 1.5.0.6, Apache Tomcat 5.5.16 Reporter: Charitha Kankanamge Attachments: stacktrace.txt System returns HTTP 500 error with the follwoing exception in the logs when accessing 'Engage Module For a Service' page in Axis2 admin console. Oct 10, 2006 12:47:36 PM org.apache.axis2.transport.http.AbstractAgent handle WARNING: Error dispatching request /axis2/axis2-admin/engageToService java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) Please note that this issue exists in Windows XP environment only. Steps to reproduce: 1. Deploy Axis2.war from the axis2-std-1.1-RC1 distribution 2. Access the admin console 3. Click on 'For a Service' link under the 'Engage Module' in the left pane Issue: == HTTP 500 error is shown to the user. Complete stack trace is attached here with. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-1336) Code Generation Exception occurred when Generating stubs
[ http://issues.apache.org/jira/browse/AXIS2-1336?page=all ] Evanthika Amarasiri updated AXIS2-1336: --- Attachment: CommodityQuote.wsdl Wsdl File used to generate the stub Code Generation Exception occurred when Generating stubs Key: AXIS2-1336 URL: http://issues.apache.org/jira/browse/AXIS2-1336 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Affects Versions: 1.1 Environment: Windows XP, jdk1.5.0_08, Maven 1.0.2, Mozilla Firefox 1.5.0.6 Reporter: Evanthika Amarasiri Priority: Critical Attachments: CommodityQuote.wsdl 1. Tried to create a stub using the following command wsdl2java.bat -uri \wsdl\CommodityQuote.wsdl -p com.wso2.tungsten.client -d adb -u true -t -uw true 2. The following exception occured Exception in thread main org.apache.axis2.wsdl.codegen.CodeGenerationException: org.apache.axis2.wsdl.codegen.CodeGenerationException: Unsupported S chema format for unwrapping! found unknown but expected sequence at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224) at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:32) at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:21) Caused by: org.apache.axis2.wsdl.codegen.CodeGenerationException: Unsupported Schema format for unwrapping! found unknown but expected sequence at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.processXMLSchemaSequence(SchemaUnwrapperExtension.java:287) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.handleAllCasesOfComplexTypes(SchemaUnwrapperExtension.java:164) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.walkSchema(SchemaUnwrapperExtension.java:122) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.engage(SchemaUnwrapperExtension.java:87) at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:177) ... 2 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-1341) Cannot disengage a globally engaged module
Cannot disengage a globally engaged module -- Key: AXIS2-1341 URL: http://issues.apache.org/jira/browse/AXIS2-1341 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Affects Versions: 1.1 Environment: Windows XP, jdk1.5.0_08, Mozilla Firefox 1.5.0.6, Apache Tomcat 5.5.16 Reporter: Charitha Kankanamge Priority: Critical Globally engaged module cannot be disengaged from a service. A blank screen appears when clicking on 'Disengage' link and module is not disengaged. Steps to reproduce: === 1. Log in to Axis2 admin console 2. Check globally engaged modules by clicking on 'Globally Engaged Modules' hyperlink 3. Click on 'Available Services' in the left pane 4. Click on 'Disengage' link to disengage a module from the service Issue: = A blank screen appears. Module is not disengaged from the service -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: WS Addressing :: Issue with setting ReplyTo :: Axis2-1.1-SNAPSHOT
Hi, Thanks for the prompt reply Eran, this issue was resolved yesterday after a suggestion by Brian, that in such a scenario we should use fireandforget instead of sendrecievenonblocking and this worked for meand that comes out to be the same tht you have suggested :-) thanks newayz. Regards, Vaibhav -Original Message- From: Eran Chinthaka [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 11, 2006 12:35 AM To: axis-dev@ws.apache.org Subject: Re: WS Addressing :: Issue with setting ReplyTo :: Axis2-1.1-SNAPSHOT I answered this question couple of time, but let me try again. If you invoke send-receive from your client then your response *must* come to it and Axis2 engine helps you to do that by starting up the proper listeners. What you could have done was invoke one way and put your replyTo. Even if you are invoking an IN-OUT service, for your clients it is just IN-Only as it won't receive a response. But there was a valid scenario, actually pointed out by Chamikara, that some might want to get his replies through a proxy like tcp-mon. Yes in that case, you might want to override the replyTo value. I can remember Chamikara was talking about this but not sure whether he implemented it. Chamikara, you wanna add something here? -- Chinthaka Vaibhav Pandey wrote: Hi All, I am trying to explore WS Addressing by creating a flow in which i call a WS (INOUT-with NonBlockingDual client) and then i want the response to be directed to another WS on a different port and server. I have explicitly set the To/ReplyTo in my client. In the resluting SOAP request the wsa:To parmeter gets set based on what i mentioned but somehow the wsa:ReplyTo is set to the default listener address !! I have also set:: options.setProperty(AddressingConstants.REPLACE_ADDRESSING_HEADERS, Boolean.TRUE) and then am setting replyto as :: options.setTo(targetEPR); options.setReplyTo(targetReplyEPR); options.setTransportInProtocol(Constants.TRANSPORT_HTTP); i also tried :: options.setProperty(AddressingConstants.WSA_REPLY_TO, targetReplyEPR); but what i found after looking at the source code was that in the message context itself the replyTo address is set to default whereas the To address is set based on what i mentioned. Kindly guide me as to what am i supposed to do. Regards, Vaibhav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
