[jira] Created: (AXIS2C-261) Password callback API needs redoing
Password callback API needs redoing
---
Key: AXIS2C-261
URL: http://issues.apache.org/jira/browse/AXIS2C-261
Project: Axis2-C
Issue Type: Improvement
Components: rampart
Affects Versions: Current (Nightly)
Reporter: James Clark
There are two distinct scenarios where Axis2/C might use the password:
1. There's an incoming message with a username and possibly digested password,
and Axis2/C needs to check whether the password is valid.
2. There's an outgoing message, and Axis2/C needs to know what username and
what password to use.
These are really, quite different situations with different requirements and
it's not a good idea to combine them into a single interface. Let's consider
them in turn.
1. The key point to bear in mind here is that you can't assume that the
password will be directly accessible. For example, the passwords may be stored
in a database that is readable by root but not by the Axis2/C userid; in this
case, password checking would be done by a separate daemon running as root
(like saslauthd) that provides a service over a Unix socket that accepts a
particular username/password pair and says whether or not it is valid. Or you
might be piggybacking on top of the apache2 authn provider interface.
typedef struct {
/* Given a username and password, expected to return AUTH_GRANTED
* if we can validate this user/password combination.
*/
authn_status (*check_password)(request_rec *r, const char *user,
const char *password);
/* Given a user and realm, expected to return AUTH_USER_FOUND if we
* can find a md5 hash of 'user:realm:password'
*/
authn_status (*get_realm_hash)(request_rec *r, const char *user,
const char *realm, char **rethash);
} authn_provider;
I would suggest what you need is an OO type rampart_authn_username_t with
methods similar to the following
axis2_status_t rampart_authn_username_check_password(rampart_authn_username_t
*, const axis2_env_t *, axis2_msg_ctx_t *, const axis2_char_t *username, const
axis2_char_t *password)
axis2_status_t
rampart_authn_username_check_password_digest(rampart_authn_username_t *, const
axis2_env_t *, axis2_msg_ctx_t *, const axis2_char_t *username, const char
*nonce, size_t nonce_length, const char *digest)
(nonce is the concatenation of the timestamp and nonce, ready for hashing;
digest is the binary 20-byte binary SHA-1 hash)
The message context is in there, because the realm (password database) to use
may depend on the message. You'll also need this in order to allow mod_axis2
to provide an implementation of this on top of the Apache auth providers (note
this won't work for password digests).
2. For the outgoing case, I would suggest an interface rampart_cred_username_t
like this:
axis2_status_t rampart_cred_username_get(rampart_cred_username_t *, const
axis2_env_t *, axis2_msg_ctx_t *, const char **username_res, const char
**password_res)
(the returned username/password will be owned by one of the context objects in
the context hierarchy)
This allows for a number of things not possible at the moment:
- different endpoints can have different username/passwords
- the user can be interactively asked for both the username and password; the
UI can provide a single dialog that allows both to entered at the same time
- the object can perform caching of the username/passwords at the appropriate
level of the context hierarchy, according to the particular policy that it
implements; for example, the username can be cached at the configuration level
(as now) and the password cached at the operation level
--
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-264) Introduce AXIS2_INTERNAL macro for use with non-static functions that are not exported from shared library
Introduce AXIS2_INTERNAL macro for use with non-static functions that are not exported from shared library -- Key: AXIS2C-264 URL: http://issues.apache.org/jira/browse/AXIS2C-264 Project: Axis2-C Issue Type: Improvement Affects Versions: Current (Nightly) Reporter: James Clark Priority: Minor I would recommend introducing an AXIS2_INTERNAL macro and using it in a similar way to AXIS2_EXTERN for every function that is not AXIS2_EXTERN and not static. In other words, every function would be declared as either AXIS2_EXTERN, AXIS2_INTERNAL or static. On Windows, this would map onto nothing (I think), but on Linux with gcc it would map onto __attribute__((visibility(hidden)). This allows gcc to generate better code. For more information, see http://people.redhat.com/drepper/dsohowto.pdf http://www.nedprod.com/programs/gccvisibility.html -- 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-265) axis2_string.h macro strangeness
axis2_string.h macro strangeness Key: AXIS2C-265 URL: http://issues.apache.org/jira/browse/AXIS2C-265 Project: Axis2-C Issue Type: Improvement Components: util Affects Versions: Current (Nightly) Reporter: James Clark Priority: Trivial I don't see how it's useful for axis2_string.h to provide macros like this: #define AXIS2_STRCMP(s1, s2) \ axis2_strcmp(s1, s2) Why not have the clients use axis2_strcmp directly? The macro just uglifies code that uses it. -- 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-267) Drop use of macros in method calls to improve backward compatibility of binary
Drop use of macros in method calls to improve backward compatibility of binary -- Key: AXIS2C-267 URL: http://issues.apache.org/jira/browse/AXIS2C-267 Project: Axis2-C Issue Type: Improvement Affects Versions: 0.93 Reporter: Samisa Abeysinghe There is a problem with our current approach of using macros for method calls. Our approach means that adding a method to a type is a binary-incompatible change, not a binary-compatible change. This makes our current approach not sustainable in the long-term. -- 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-268) AXIS2_CRTICAL_FAILURE = AXIS2_CRITICAL_FAILURE
AXIS2_CRTICAL_FAILURE = AXIS2_CRITICAL_FAILURE --- Key: AXIS2C-268 URL: http://issues.apache.org/jira/browse/AXIS2C-268 Project: Axis2-C Issue Type: Improvement Components: util Affects Versions: Current (Nightly) Reporter: James Clark Priority: Minor critical has two is -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-269) Try to clean up axis2_stream
Try to clean up axis2_stream Key: AXIS2C-269 URL: http://issues.apache.org/jira/browse/AXIS2C-269 Project: Axis2-C Issue Type: Improvement Components: util Affects Versions: Current (Nightly) Reporter: James Clark Priority: Minor For doing encryption and signing right, it will be important to have a clean, minimal stream interface. axis2_stream is a bit crufty at the moment. Specifically, the get_type method is bogus: if you have an OO type (which stream should be), then you shouldn't have a method returning a type-code for each implementation. It only seems to be used in axis2_http_transport_utils_on_data_request. I don't understand what that's doing, but I'm fairly sure get_type is not the best way to it. I would also suggest having separate input and output streams (unless there are really cases where you need to have a random access stream that can be both read and written). Having both get_char and read in an interface is a bad idea. Have just read. You can implement get_char as a function on top of read. unget is a bad idea on your fundamental stream type. If you really need it, create a lookahead_stream derived from stream that provides this additional operation and forwards to an underlying regular stream. Providing a peek method is better than unget (it's clear what the semantics of multiple peeks are). -- 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-269) Try to clean up axis2_stream
[ http://issues.apache.org/jira/browse/AXIS2C-269?page=comments#action_12433594 ] James Clark commented on AXIS2C-269: The output stream needs flush and close methods as well. Try to clean up axis2_stream Key: AXIS2C-269 URL: http://issues.apache.org/jira/browse/AXIS2C-269 Project: Axis2-C Issue Type: Improvement Components: util Affects Versions: Current (Nightly) Reporter: James Clark Priority: Minor For doing encryption and signing right, it will be important to have a clean, minimal stream interface. axis2_stream is a bit crufty at the moment. Specifically, the get_type method is bogus: if you have an OO type (which stream should be), then you shouldn't have a method returning a type-code for each implementation. It only seems to be used in axis2_http_transport_utils_on_data_request. I don't understand what that's doing, but I'm fairly sure get_type is not the best way to it. I would also suggest having separate input and output streams (unless there are really cases where you need to have a random access stream that can be both read and written). Having both get_char and read in an interface is a bad idea. Have just read. You can implement get_char as a function on top of read. unget is a bad idea on your fundamental stream type. If you really need it, create a lookahead_stream derived from stream that provides this additional operation and forwards to an underlying regular stream. Providing a peek method is better than unget (it's clear what the semantics of multiple peeks are). -- 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-270) base64 encoding/decoding should be implemented as a stream
base64 encoding/decoding should be implemented as a stream -- Key: AXIS2C-270 URL: http://issues.apache.org/jira/browse/AXIS2C-270 Project: Axis2-C Issue Type: Improvement Components: util Affects Versions: Current (Nightly) Reporter: James Clark Priority: Minor You should have something like this axis2_output_stream_t *axis2_create_base64_output_stream(axis2_output_stream_t *, const axis2_env_t *); Let's call the argument stream s1 and the returned stream s1. When you write bytes on s2, they will be written out as base64 encoded bytes on s2. Similarly, mapping base64 to binary is an input_stream. This allows you to efficiently deal with encoding/decoding large quantities of base64 data. You can have your existing functions as well. They should both be implemented on top of a lower-level layer that copies from buffer to buffer without doing allocation, e.g. something like base64_decode(const char *from, size_t from_length, char *to, size_t to_length, size_t *n_read, size_t *n_written) -- 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-271) axiom_xml_reader/writer should read/write from streams
axiom_xml_reader/writer should read/write from streams -- Key: AXIS2C-271 URL: http://issues.apache.org/jira/browse/AXIS2C-271 Project: Axis2-C Issue Type: Improvement Components: xml/parser Affects Versions: Current (Nightly) Reporter: James Clark axiom_xml_reader/writer should read/write from axis2_streams. -- 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-272) encryption/decryption should work on streams
encryption/decryption should work on streams Key: AXIS2C-272 URL: http://issues.apache.org/jira/browse/AXIS2C-272 Project: Axis2-C Issue Type: Improvement Components: rampart Affects Versions: Current (Nightly) Reporter: James Clark encryption/decryption should work on streams. axis2_output_stream_t *create_encryption_stream(..., axis2_output_stream *encrypted_stream) Writing output on the returned stream should cause the corresponding binary (not base64-encoded) encrypted bytes to be written to encrypted_stream. Similarly, for decryption axis2_input_stream *create_decryption_stream(..., axis2_input_stream *encrypted_stream) -- 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-273) rampart_generate_nonce should not use rand()
rampart_generate_nonce should not use rand() Key: AXIS2C-273 URL: http://issues.apache.org/jira/browse/AXIS2C-273 Project: Axis2-C Issue Type: Bug Components: rampart Affects Versions: Current (Nightly) Reporter: James Clark It's not thread-safe and it's not cryptographically strong. I believe openssl provides some functions for random number generation; use them instead. -- 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-274) rampart_generate_time should use date time stuff from util
rampart_generate_time should use date time stuff from util -- Key: AXIS2C-274 URL: http://issues.apache.org/jira/browse/AXIS2C-274 Project: Axis2-C Issue Type: Improvement Components: util Affects Versions: Current (Nightly) Reporter: James Clark Priority: Minor rampart_generate_time looks suspicious to me. It shouldn't be calling system functions directly. This sort of thing belongs in util. Why isn't it using axis2_date_time_*? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2C-268) AXIS2_CRTICAL_FAILURE = AXIS2_CRITICAL_FAILURE
[ http://issues.apache.org/jira/browse/AXIS2C-268?page=all ] Samisa Abeysinghe resolved AXIS2C-268. -- Fix Version/s: 0.94 Resolution: Fixed Assignee: Samisa Abeysinghe Fixed AXIS2_CRTICAL_FAILURE = AXIS2_CRITICAL_FAILURE --- Key: AXIS2C-268 URL: http://issues.apache.org/jira/browse/AXIS2C-268 Project: Axis2-C Issue Type: Improvement Components: util Affects Versions: Current (Nightly) Reporter: James Clark Assigned To: Samisa Abeysinghe Priority: Minor Fix For: 0.94 critical has two is -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Codegen problem
When I codegen for a WSDL, I get parameters with no type in generated C
code.
The WSDL has
wsdl:message name='saveMessage' /
and I get the C code:
axis2_status_t axis2_ServerAdmin_save (const axis2_env_t* env , param20 );
Java generated code is correct:
public void save ( ) {}
So obviously in the generated C code, param20 should not be there (or at
least it has to be void, but that is not neat)
I deem that this is a problem with C template, but I could not locate
where exactly. Please help fix this.
Thanks
Samisa...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Codegen problem
BTW I used '-d none' and '-u' in when generating code in both languages.
Samisa...
Samisa Abeysinghe wrote:
When I codegen for a WSDL, I get parameters with no type in generated
C code.
The WSDL has
wsdl:message name='saveMessage' /
and I get the C code:
axis2_status_t axis2_ServerAdmin_save (const axis2_env_t* env ,
param20 );
Java generated code is correct:
public void save ( ) {}
So obviously in the generated C code, param20 should not be there (or
at least it has to be void, but that is not neat)
I deem that this is a problem with C template, but I could not locate
where exactly. Please help fix this.
Thanks
Samisa...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2]Re: Codegen problem
Prefix corrected!
BTW I used '-d none' and '-u' in when generating code in both languages.
Samisa...
Samisa Abeysinghe wrote:
When I codegen for a WSDL, I get parameters with no type in generated
C code.
The WSDL has
wsdl:message name='saveMessage' /
and I get the C code:
axis2_status_t axis2_ServerAdmin_save (const axis2_env_t* env ,
param20 );
Java generated code is correct:
public void save ( ) {}
So obviously in the generated C code, param20 should not be there (or
at least it has to be void, but that is not neat)
I deem that this is a problem with C template, but I could not locate
where exactly. Please help fix this.
Thanks
Samisa...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2] Problem in codegen with ADB
I tried to codegen with '-d adb' and for both C and Java I get an error shown below. Any clues as to what may have caused the problems? Samisa... Exception in thread main org.apache.axis2.wsdl.codegen.CodeGenerationException: org.apache.axis2.wsdl.codegen.CodeGenerationException: No proper databinding has taken place 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: No proper databinding has taken place at org.apache.axis2.wsdl.codegen.extension.DefaultDatabindingExtension.engage(DefaultDatabindingExtension.java:37) at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:177) ... 2 more - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2]Re: Codegen problem
I corrected the problem in the templates. Please see whether it works
for you now :)
On 9/9/06, Samisa Abeysinghe [EMAIL PROTECTED] wrote:
Prefix corrected!
BTW I used '-d none' and '-u' in when generating code in both languages.
Samisa...
Samisa Abeysinghe wrote:
When I codegen for a WSDL, I get parameters with no type in generated
C code.
The WSDL has
wsdl:message name='saveMessage' /
and I get the C code:
axis2_status_t axis2_ServerAdmin_save (const axis2_env_t* env ,
param20 );
Java generated code is correct:
public void save ( ) {}
So obviously in the generated C code, param20 should not be there (or
at least it has to be void, but that is not neat)
I deem that this is a problem with C template, but I could not locate
where exactly. Please help fix this.
Thanks
Samisa...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ajith Ranabahu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-275) apache2_stream_write should use ap_rwrite, not ap_rputs
apache2_stream_write should use ap_rwrite, not ap_rputs --- Key: AXIS2C-275 URL: http://issues.apache.org/jira/browse/AXIS2C-275 Project: Axis2-C Issue Type: Bug Components: transport/http Affects Versions: Current (Nightly) Reporter: James Clark Surely apache2_stream_write should use ap_rwrite rather than ap_rputs. Apart from being inefficient, using ap_rputs won't work if the output has nuls. -- 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-1128) Layout of axis2/modules/tool
[ http://issues.apache.org/jira/browse/AXIS2-1128?page=comments#action_12433576 ] Jochen Wiedmann commented on AXIS2-1128: But, Dims, isn't that just another argument to break up the eclipse specific stuff into a separate directory? At least, I find it quite inconvenient to work with compiler excludes. Layout of axis2/modules/tool Key: AXIS2-1128 URL: http://issues.apache.org/jira/browse/AXIS2-1128 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: Tools Reporter: Jochen Wiedmann Hello, while working on the Maven 2 build of Axis 2, I detected a problem in the layout of the directory axis2/modules/tool. This directory contains, among others, a directory src and several directories with Maven 2 plugins. The src subdirectory means, that the directory is meant to produce artifacts, for example axis2-tools.jar. In other words, the axis2-tool project should have packaging jar. On the other hand, the presence of maven plugins below means, that the directory is a parent directory. In other words, it should have packaging pom. I see no other possibility to resolve the problem, apart from changing the directory layout. Suggested new layout: axis2 +-- modules +-- tool (I'd personally consider tools a better name.) +-- maven2 |+-- axis2-aar-maven-plugin |+-- axis2-idea-plugin |+-- axis2-java2wsdl-maven-plugin |+-- axis2-wsdl2code-maven-plugin |+-- pom.xml +-- general | +-- src | +-- conf | +-- script | +-- test | +-- pom.xml | +-- project.xml +-- pom.xml I do personally believe, that the directory general should be splitted into more subprojects. However, that could as well be done at a later point. -- 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] XmlSchema Axiom for next Axis2 release
John Kaputin (gmail) wrote: Hi all, what plans does the Axis2 community have regarding XmlSchema and Axiom releases for the next release of Axis2 proposed for later this month? Axiom release will, most probably, available by 15th Sep. XmlSchema, there are some changes that are being done these days by Dims and Jochen. I prefer if one of them can talk about it. Anyway, we need to have a release on XmlSchema, before Woden and Axis2 releases. Any volunteers for that? At the weekly Woden chat we discussed doing a milestone release of Woden in time for the next Axis2 release, but as Woden depends on XmlSchema and Axiom we really need to build against the same releases used (or to be used) by the next Axis2 release. John, I prefer if Woden also can depend on the latest Xmlschema stuff. So +1 for deciding Woden release plans soon after XmlSchema release. Thanks, Chinthaka signature.asc Description: OpenPGP digital signature
[jira] Created: (AXIS2-1130) Build with Maven 2
Build with Maven 2 -- Key: AXIS2-1130 URL: http://issues.apache.org/jira/browse/AXIS2-1130 Project: Apache Axis 2.0 (Axis2) Issue Type: Improvement Reporter: Jochen Wiedmann Assigned To: Jochen Wiedmann This is a tracker bug, which serves the following purposes: - Keep people informed about the ongoing efforts. - Prevent that someone else starts working on the same topic. - If possible, attract other people to start working here. - Collect dependencies on related bugs like AXIS2-1128 -- 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] Work started: (AXIS2-1130) Build with Maven 2
[ http://issues.apache.org/jira/browse/AXIS2-1130?page=all ] Work on AXIS2-1130 started by Jochen Wiedmann. Build with Maven 2 -- Key: AXIS2-1130 URL: http://issues.apache.org/jira/browse/AXIS2-1130 Project: Apache Axis 2.0 (Axis2) Issue Type: Improvement Reporter: Jochen Wiedmann Assigned To: Jochen Wiedmann Attachments: axis2-maven2.patch This is a tracker bug, which serves the following purposes: - Keep people informed about the ongoing efforts. - Prevent that someone else starts working on the same topic. - If possible, attract other people to start working here. - Collect dependencies on related bugs like AXIS2-1128 -- 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-1130) Build with Maven 2
[ http://issues.apache.org/jira/browse/AXIS2-1130?page=all ] Jochen Wiedmann updated AXIS2-1130: --- Attachment: axis2-maven2.patch Current state Build with Maven 2 -- Key: AXIS2-1130 URL: http://issues.apache.org/jira/browse/AXIS2-1130 Project: Apache Axis 2.0 (Axis2) Issue Type: Improvement Reporter: Jochen Wiedmann Assigned To: Jochen Wiedmann Attachments: axis2-maven2.patch This is a tracker bug, which serves the following purposes: - Keep people informed about the ongoing efforts. - Prevent that someone else starts working on the same topic. - If possible, attract other people to start working here. - Collect dependencies on related bugs like AXIS2-1128 -- 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] An approach for clustering Axis2
Hi Filip, Rajith, AllThanks to all the resources from Filip I guess we can now get a good undestanding of tribes and use it for an implementation of the ClusterManager. As u guys had mentioned the session updates hv to be done periodically. I guess this can be decided based on the Axis2 contexts we hope to replicate.
As it was decided earlier we will only be replicating ConfigurationContext, ServiceContexts and ServiceGroupContexts.(Fillip, Axis2 comes with a context hierarchy which should be used to store runtime infomation of various statget. For
e.g. ConfigurationContext is for the whole system, ServiceContexts for each service etc., so replicating the state of Axis2 system implies replicating a subset of this context hierarchy).Therefore a good place for calling the state update method would be at the end of an OperationContext. In other words when the cleanup method of the OperationContext get called.
ChamikaraOn 9/8/06, Filip Hanik - Dev Lists
[EMAIL PROTECTED] wrote:
Sure, resources can be found at:A brief introductionhttp://people.apache.org/~fhanik/tribes/docs/introduction.html
http://people.apache.org/%7Efhanik/tribes/docs/introduction.htmlSimple summary
http://people.apache.org/~fhanik/tribes/javadoc/org/apache/catalina/trib
http://people.apache.org/%7Efhanik/tribes/javadoc/org/apache/catalina/trib
es/package-summary.htmlDownloads
http://people.apache.org/~fhanik/tribes/archive/
http://people.apache.org/%7Efhanik/tribes/archive/
You can take a look at the org.apache.catalina.tribes.demos.MapDemojava -cp tribes-0.9.5.2.jar;commons-logging-api.jarorg.apache.catalina.tribes.demos.MapDemothis example uses a primary/secondary backup strategy, there is also a
similar all to all map as well.The replicated map extends HashMap, so if you implement your session manager to use a HashMap all you need to do is replace this hashmap with a replicated one.Take a look at
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/ha/src/share/org/apache/catalina/ha/session/BackupManager.java?view=markup
at the method*public* *void* start() *throws* LifecycleException {*if* ( *this*.started ) *return*;*try* {CatalinaCluster catclust = (CatalinaCluster)cluster;
catclust.addManager(getName(), *this*);LazyReplicatedMap map = *new* LazyReplicatedMap(*this*,catclust.getChannel(),DEFAULT_REPL_TIMEOUT,
getMapName(),getClassLoaders());map.setChannelSendOptions(mapSendOptions);*this*.sessions = map; //swap out the old hashmap for the replicated hashmap
*super*.start();}*catch* ( Exception x ) {log.error(*Unable to start BackupManager*,x);*throw* *new* LifecycleException(*Failed to start BackupManager*,x);
}}The objects your store in your HashMap can implement theorg.apache.catalina.tribes.tipis.ReplicatedMapEntry interface, and bydoing that allow for diffs/deltas to be replicated.
just a few examples, I can give more if you decide to use thisimplementation. Another option you have is to use the Jakarta JCS (JavaCaching System), Aaron there has done tons of work, and believe added ina small module for replication as well.
FilipRajith Attapattu wrote: Filip, Thank you for picking up the baton. Can u please provide a list of resources that people should be looking at if they are to use Tribes?
like where to download, documentation ...etc? Chamikar and Chathura (and everybody else interested)... shall we get started on the impl? We can each choose an area and then start working on the code.
comments? Regards, Rajith On 9/8/06, *Filip Hanik - Dev Lists*
[EMAIL PROTECTED] mailto:
[EMAIL PROTECTED] wrote: it all looks kosher to me. the logic that you are talking about is axis invocation logic. in tomcat for example, we intercept the request with a valve, and
after the request is complete, we simple check to see if the session was updated, and then notify the replicated map to flush out the changes. I'm not familiar enough with axis to know the details of the
invocation chain, but I can imagine it being pretty similar. I agree with that it should be easy and non intrusive, goes for all software :) Filip
Rajith Attapattu wrote: Hi All, As Chamikara pointed out we have left the proposal for about a week now for any comments/concerns.
I guess people are happy so far with the proposal. Shall we move on to the implementation stage? Filip could you please have a look and let us know your ideas?
Regards, Rajith On 8/25/06, *Rajith Attapattu*
[EMAIL PROTECTED] mailto:
[EMAIL PROTECTED] mailto:
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
Chamikara, I guess the other point that we don't have a clear grasp is the specific points where axis2 will invoke the cluster interface.
We should try to make this as easy and non-intrusive as possible. If we add this in AbstractMessageReceiver and the AbstractTransportSender then we clearly need to indicate this in
the documentation. If somebody wants to write there own message receiver or transport sender then either they should extend the
[jira] Commented: (AXIS2-1129) Doubled wrapper elements around XMLBeans-generated XML
[
http://issues.apache.org/jira/browse/AXIS2-1129?page=comments#action_12433598 ]
Ajith Harshana Ranabahu commented on AXIS2-1129:
This does seem to be a user error to me. For instance when I generated and
tried to compile your code this line seems to be in error
final FullDocument full = Full.Factory.newInstance();
it should be
final FullDocument full = FullDocument.Factory.newInstance();
I would also recommend that you try generating the object structure rather than
parsing the XML
something like this
private static Full getSituation ()
throws XmlException
{
Full f = Full.Factory.newInstance();
EventReference eventReference = f.addNewEventReference();
eventReference.setEventId(blah blah);
eventReference.setResponsePlanId(blah blah);
eventReference.setUpdate(234234234);
MessageHeader messageHeader = f.addNewMessageHeader();
//set something
return f;
}
When I do that I get the proper output from toString().
Doubled wrapper elements around XMLBeans-generated XML
--
Key: AXIS2-1129
URL: http://issues.apache.org/jira/browse/AXIS2-1129
Project: Apache Axis 2.0 (Axis2)
Issue Type: Bug
Components: core, om, wsdl, client-api, databinding
Affects Versions: 1.0
Reporter: Derek Foster
Priority: Blocker
I recently noticed a big problem in how Axis2 generates XML for XMLBeans
objects. It appears to be creating the wrapper element around
an XMLBean twice, thus generating erroneous XML for a SOAP message. This
appears to be a big problem that would affect a lot of web services, and is
making it impossible for my company to use Axis2 to talk to our server.
This error was found in the latest nightly build (September 8), but has
apparently been around for some time.
I have a particular WSDL, as follows:
?xml version=1.0 encoding=UTF-8?
definitions name=FDefinitions
targetNamespace=http://www.c-corp.com/wsdl/2004-10-01/F;
xmlns:tns=http://www.c-corp.com/wsdl/2004-10-01/F;
xmlns:c=http://www.c-corp.com/wsdl/2004-10-01/c;
xmlns:F=http://www.dummy-temp-address;
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
xmlns:xs=http://www.w3.org/2001/XMLSchema;
xmlns=http://schemas.xmlsoap.org/wsdl/;
types
xs:schema targetNamespace=http://www.c-corp.com/wsdl/2004-10-01/F;
xs:import namespace=http://www.dummy-temp-address;
schemaLocation=F.xsd/
xs:element name=return type=xs:string/
xs:element name=failure type=xs:string/
/xs:schema
xs:schema targetNamespace=http://www.c-corp.com/wsdl/2004-10-01/c;
xs:element name=CPassword type=xs:string/
xs:element name=CLogin type=xs:string/
/xs:schema
/types
message name=FEvent
part name=contents element=F:full/
/message
message name=FResponse
part name=return element=tns:return/
/message
message name=CPassword
part name=CPassword element=c:CPassword/
/message
message name=CLogin
part name=CLogin element=c:CLogin/
/message
message name=Failure
part name=faultDetail element=tns:failure/
/message
portType name=FPortType
documentationF Port Type/documentation
operation name=acceptFEvent parameterOrder=contents
input name=acceptFEventRequest message=tns:FEvent/
output name=acceptFEventResponse message=tns:FResponse/
fault name=Failure message=tns:Failure/
/operation
/portType
binding name=FSoapBinding type=tns:FPortType
documentationF Soap Binding/documentation
soap:binding style=document
transport=http://schemas.xmlsoap.org/soap/http/
operation name=acceptFEvent
soap:operation soapAction=acceptFEventAction/
input
soap:header message=tns:CLogin part=CLogin use=literal/
soap:header message=tns:CPassword part=CPassword
use=literal/
soap:body use=literal/
/input
output
soap:body use=literal/
/output
fault name=Failure
soap:fault name=Failure use=literal/
/fault
/operation
/binding
service name=FService
documentationF Web Service/documentation
port name=FPort binding=tns:FSoapBinding
soap:address
location=http://localhost:8080/axis/services/FService/
/port
/service
/definitions
My WSDL references the following XML schema:
?xml version=1.0 encoding=UTF-8?
xs:schema targetNamespace=http://www.dummy-temp-address;
xmlns=http://www.dummy-temp-address;
xmlns:xs=http://www.w3.org/2001/XMLSchema;
[jira] Commented: (AXIS2-747) Missing namespace on subelement
[
http://issues.apache.org/jira/browse/AXIS2-747?page=comments#action_12433599 ]
Ajith Harshana Ranabahu commented on AXIS2-747:
---
Is this still there - I mean has anyone tried the nightlies ?
Missing namespace on subelement
Key: AXIS2-747
URL: http://issues.apache.org/jira/browse/AXIS2-747
Project: Apache Axis 2.0 (Axis2)
Issue Type: Bug
Components: om
Affects Versions: 1.0
Environment: Windows 2K3, JDK 1.5, AXIS2 1.0 and Eclipse 3.1 with
tomcat plugin
Reporter: Qi An
Assigned To: Ajith Harshana Ranabahu
Priority: Blocker
The below all worked fine on 0.95:
The complex type in question is defined in the wsdl as:
s:complexType name=Credential
s:sequence/
/s:complexType
s:complexType name=EnterpriseCredential s:complexContent
s:extension base=s0:Credential
s:sequence/
s:attribute name=Login type=s:string use=required/
s:attribute name=Password type=s:string use=optional/
s:attribute name=Locale type=s:string use=optional/
s:attribute name=TimeZone type=s:string use=optional/
s:attribute name=Domain type=s:string use=optional/
s:attribute name=AuthType type=s:string use=optional/
/s:extension
/s:complexContent
/s:complexType
In the provider's skeleton, we have the following:
public com.businessobjects.dsws.session.LoginResponseDocument login(
com.businessobjects.dsws.session.LoginDocument param12)
throws
com.businessobjects.dsws.session.SessionSkeleton.DSWSExceptionException,
RemoteException {
Login obj = param12.getLogin();
Credential cred = obj.getCredential();
The problem is, on the getCredential() call, we actually get back an
object of type Credential (base class) when the method was invoked with
an enterprise credential. So that further on, on the line:
EnterpriseCredential enterpriseCredential = (EnterpriseCredential) cred;
We get a class cast exception.
Tracing through a bit with the SOAPMonitor, we noticed that the xml
envelope actually ends up looking like:
?xml version='1.0' encoding='utf-8'?
soapenv:Envelope
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
soapenv:Header /
soapenv:Body
login xmlns=session.dsws.businessobjects.com
credential xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
Password= Domain=vanyma01 xsi:type=ses:EnterpriseCredential
Login=administrator /
/login
/soapenv:Body
/soapenv:Envelope
Where the namespace definition of ses is clearly missing. If you
trace through the deserialization code a bit, this is why the object
comes back as the base class instead of the extended type.
Once thing interesting one of our developer's noticed, is that if, on
the consumer side, you add the lines:
XmlOptions op1 = new XmlOptions();
op1.setSaveNamespacesFirst();
m_credential =
EnterpriseCredential.Factory.newInstance(op1);
At the time you create the credential, it seems that *some of the time*
this fixes the problem, so that the xml appears as:
?xml version='1.0' encoding='utf-8'?
soapenv:Envelope
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
soapenv:Header /
soapenv:Body
login xmlns=session.dsws.businessobjects.com
credential xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:ses=session.dsws.businessobjects.com Password=
Domain=vanyma01 xsi:type=ses:EnterpriseCredential
Login=administrator /
/login
/soapenv:Body
/soapenv:Envelope
But only some of the time.
--
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-1128) Layout of axis2/modules/tool
[ http://issues.apache.org/jira/browse/AXIS2-1128?page=comments#action_12433614 ] Davanum Srinivas commented on AXIS2-1128: - yep, i will be doing that too. -- dims Layout of axis2/modules/tool Key: AXIS2-1128 URL: http://issues.apache.org/jira/browse/AXIS2-1128 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: Tools Reporter: Jochen Wiedmann Hello, while working on the Maven 2 build of Axis 2, I detected a problem in the layout of the directory axis2/modules/tool. This directory contains, among others, a directory src and several directories with Maven 2 plugins. The src subdirectory means, that the directory is meant to produce artifacts, for example axis2-tools.jar. In other words, the axis2-tool project should have packaging jar. On the other hand, the presence of maven plugins below means, that the directory is a parent directory. In other words, it should have packaging pom. I see no other possibility to resolve the problem, apart from changing the directory layout. Suggested new layout: axis2 +-- modules +-- tool (I'd personally consider tools a better name.) +-- maven2 |+-- axis2-aar-maven-plugin |+-- axis2-idea-plugin |+-- axis2-java2wsdl-maven-plugin |+-- axis2-wsdl2code-maven-plugin |+-- pom.xml +-- general | +-- src | +-- conf | +-- script | +-- test | +-- pom.xml | +-- project.xml +-- pom.xml I do personally believe, that the directory general should be splitted into more subprojects. However, that could as well be done at a later point. -- 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-1130) Build with Maven 2
[ http://issues.apache.org/jira/browse/AXIS2-1130?page=comments#action_12433615 ] Davanum Srinivas commented on AXIS2-1130: - jochen, you have karma for Axis2 as a ws committer. could you please work directly with svn? :) thx, dims Build with Maven 2 -- Key: AXIS2-1130 URL: http://issues.apache.org/jira/browse/AXIS2-1130 Project: Apache Axis 2.0 (Axis2) Issue Type: Improvement Reporter: Jochen Wiedmann Assigned To: Jochen Wiedmann Attachments: axis2-maven2.patch This is a tracker bug, which serves the following purposes: - Keep people informed about the ongoing efforts. - Prevent that someone else starts working on the same topic. - If possible, attract other people to start working here. - Collect dependencies on related bugs like AXIS2-1128 -- 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] Build failing
Still doesn't work. This is all that I have in the repo (for XmlSchema that is): ~ ls -lah .maven/repository/org.apache.ws.commons/jars total 144K drwxrwxr-x 2 nagy nagy 4.0K Sep 8 21:05 ./ drwxrwxr-x 3 nagy nagy 4.0K Jun 19 13:38 ../ -rw-rw-r-- 1 nagy nagy 120K Sep 8 21:05 XmlSchema-SNAPSHOT.jar -Bill On Fri, 2006-09-08 at 19:05 -0400, Davanum Srinivas wrote: Please cleanup your old Xmlschema jar from your maven repo... On 9/8/06, Bill Nagy [EMAIL PROTECTED] wrote: I just pulled from Subversion, did a full build (maven clean; maven), and found that some of the codegen tests are failing: Testsuite: org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtensionTest Tests run: 4, Failures: 0, Errors: 4, Time elapsed: 0.397 sec Testcase: testScenarioOne(org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtensionTest): Caused an ERROR The prefix xs is not bound. java.lang.IllegalStateException: The prefix xs is not bound. at org.apache.ws.commons.schema.SchemaBuilder.getRefQName(SchemaBuilder.java:515) at org.apache.ws.commons.schema.SchemaBuilder.getRefQName(SchemaBuilder.java:496) at org.apache.ws.commons.schema.SchemaBuilder.handleElement(SchemaBuilder.java:1390) at org.apache.ws.commons.schema.SchemaBuilder.handleSequence(SchemaBuilder.java:956) at org.apache.ws.commons.schema.SchemaBuilder.handleComplexType(SchemaBuilder.java:584) at org.apache.ws.commons.schema.SchemaBuilder.handleElement(SchemaBuilder.java:1417) at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:143) at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:67) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:294) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:286) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtensionTest.loadSchema(SchemaUnwrapperExtensionTest.java:161) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtensionTest.createAndWalkSchema(SchemaUnwrapperExtensionTest.java:147) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtensionTest.testScenarioOne(SchemaUnwrapperExtensionTest.java:65) Testcase: testScenarioTwo(org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtensionTest): Caused an ERROR The prefix xs is not bound. java.lang.IllegalStateException: The prefix xs is not bound. at org.apache.ws.commons.schema.SchemaBuilder.getRefQName(SchemaBuilder.java:515) at org.apache.ws.commons.schema.SchemaBuilder.getRefQName(SchemaBuilder.java:496) at org.apache.ws.commons.schema.SchemaBuilder.handleElement(SchemaBuilder.java:1390) at org.apache.ws.commons.schema.SchemaBuilder.handleSequence(SchemaBuilder.java:956) at org.apache.ws.commons.schema.SchemaBuilder.handleComplexType(SchemaBuilder.java:584) at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:138) at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:67) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:294) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:286) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtensionTest.loadSchema(SchemaUnwrapperExtensionTest.java:161) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtensionTest.createAndWalkSchema(SchemaUnwrapperExtensionTest.java:147) at org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtensionTest.testScenarioTwo(SchemaUnwrapperExtensionTest.java:87) Testcase: testScenarioThree(org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtensionTest): Caused an ERROR The prefix ns is not bound. java.lang.IllegalStateException: The prefix ns is not bound. at org.apache.ws.commons.schema.SchemaBuilder.getRefQName(SchemaBuilder.java:515) at org.apache.ws.commons.schema.SchemaBuilder.getRefQName(SchemaBuilder.java:496) at org.apache.ws.commons.schema.SchemaBuilder.handleComplexContentExtension(SchemaBuilder.java:875) at org.apache.ws.commons.schema.SchemaBuilder.handleComplexContent(SchemaBuilder.java:713) at org.apache.ws.commons.schema.SchemaBuilder.handleComplexType(SchemaBuilder.java:614) at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:138) at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:67) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:294) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:286) at
[jira] Commented: (AXIS2-937) WSDL2Java not generating parameters for stub methods
[
http://issues.apache.org/jira/browse/AXIS2-937?page=comments#action_12433664 ]
Ajith Harshana Ranabahu commented on AXIS2-937:
---
Hi,
The build problem you mentioned seems to be related to the XMLSchema jar not
being updated. I guess the code is pretty much changed now so I suggest that
you take an update and run the code.
One possible error that can happen when the batch file is used is that if your
system has an AXIS2_HOME environment variable already set pointing to an older
Axis2 installation, the class will be picked from that and not the new one. So
it will be better if you can run the java class directly and not through the
batch file.
WSDL2Java not generating parameters for stub methods
Key: AXIS2-937
URL: http://issues.apache.org/jira/browse/AXIS2-937
Project: Apache Axis 2.0 (Axis2)
Issue Type: Bug
Components: Tools
Reporter: William Ferguson
Assigned To: Deepal Jayasinghe
Priority: Blocker
Attachments: axis2-937.zip, JasperService.wsdl, JasperServiceStub.java
WSDL2Java from the nightly snapshot of 23-jul-2006 generates the
stub/interface, but tyhe methods on the stub don't have any parameters when
they should. The stub is created fine using WSDL2Java from Axis2-1.0
WSDL2Java params:
target name=generate.client depends=init
exec executable=${axis2.wsdl2java.home}/bin/WSDL2Java.bat
arg line=-uri ${wsdl.uri}/ !-- uri from which to
get WSDL --
arg line=-o ${build}/ !-- Output directory in
which to generate files --
arg line=-p ${generated.package.name}/ !-- package
in which to generate classes --
arg line=-pn ${port.name}/ !-- Specify the port to
hit --
arg value=-s/ !-- Synchronous style only --
arg value=-u/ !-- Unpacks the data-Binding classes
from the Stub --
/exec
/target
I will attach the WSDL in question
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-1126) Compile error in the 'Nightly Builds'
[
http://issues.apache.org/jira/browse/AXIS2-1126?page=comments#action_12433667 ]
Ajith Harshana Ranabahu commented on AXIS2-1126:
Hi,
Please provide more information about your environment (JDK version, Maven
version etc). Most of the time errors such as this are due to problems in the
users configuration.
Compile error in the 'Nightly Builds'
-
Key: AXIS2-1126
URL: http://issues.apache.org/jira/browse/AXIS2-1126
Project: Apache Axis 2.0 (Axis2)
Issue Type: Bug
Environment: Windows XP
Reporter: Evanthika Amarasiri
Assigned To: Deepal Jayasinghe
Priority: Blocker
Downloaded the nightly builds from the axis2 site and got a compilation error
while building them.
I have attached part of the error log below
+
| Gathering project list Apache Axis 2.0 - XMLBeans Data Binding
| Memory: 6M/7M
+
Starting the reactor...
Our processing order:
Apache Axis 2.0 - Data Binding
Apache Axis 2.0 - Addressing
Apache Axis 2.0 - Java2WSDL
Apache Axis 2.0 - Code Generation
Apache Axis 2.0 - JAXB-RI Data Binding
Apache Axis 2.0 - JiBX Data Binding
Apache Axis 2.0 - Samples
Apache Axis 2.0 - Tools
Apache Axis 2.0 - XMLBeans Data Binding
+
| Executing multiproject:install-callback Apache Axis 2.0 - Data Binding
| Memory: 6M/7M
+
Attempting to download axis2-kernel-SNAPSHOT.jar.
Error retrieving artifact from
[http://cvs.apache.org/repository/axis2/jars/axis
2-kernel-SNAPSHOT.jar]: java.io.IOException: Unknown error downloading;
status c
ode was: 302
Error retrieving artifact from
[http://www.apache.org/dist/java-repository/axis2
/jars/axis2-kernel-SNAPSHOT.jar]: java.io.IOException: Unknown error
downloading
; status code was: 301
Error retrieving artifact from
[http://www.openejb.org/maven/axis2/jars/axis2-ke
rnel-SNAPSHOT.jar]: java.io.IOException: Unknown error downloading; status
code
was: 302
warning: last-modified not specified
0K downloaded
warning: last-modified not specified
Error retrieving artifact from
[http://jibx.sourceforge.net/maven/axis2/jars/axi
s2-kernel-SNAPSHOT.jar]: java.net.ConnectException: Connection timed out:
connec
t
Attempting to download activation-.jar.
Error retrieving artifact from
[http://cvs.apache.org/repository/javax.activatio
n/jars/activation-.jar]: java.io.IOException: Unknown error downloading;
status
code was: 302
Error retrieving artifact from
[http://www.apache.org/dist/java-repository/javax
.activation/jars/activation-.jar]: java.io.IOException: Unknown error
downloadin
g; status code was: 301
Error retrieving artifact from
[http://www.openejb.org/maven/javax.activation/ja
rs/activation-.jar]: java.io.IOException: Unknown error downloading; status
code
was: 302
warning: last-modified not specified
0K downloaded
warning: last-modified not specified
multiproject:goal:
build:start:
multiproject:install-callback:
[echo] Running jar:install for Apache Axis 2.0 - Data Binding
java:prepare-filesystem:
[mkdir] Created dir: C:\WSO2-Projects\Axis2\Nightly
builds\axis2-std-SNAPSHO
T-src\modules\adb\target\classes
java:compile:
[echo] Compiling to C:\WSO2-Projects\Axis2\Nightly
builds\axis2-std-SNAPSHOT
-src\modules\adb/target/classes
[echo]
==
NOTE: Targetting JVM 1.5, classes
will not run on earlier JVMs
==
[javac] Compiling 56 source files to C:\WSO2-Projects\Axis2\Nightly
builds\a
xis2-std-SNAPSHOT-src\modules\adb\target\classes
[javac] javac: invalid flag: C:\WSO2-Projects\Axis2\Nightly
[javac] Usage: javac options source files
[javac] where possible options include:
[javac] -g Generate all debugging info
[javac] -g:noneGenerate no debugging info
[javac] -g:{lines,vars,source} Generate only some debugging info
[javac] -nowarnGenerate no warnings
[javac] -verbose Output messages about what the
compiler
is doing
[javac] -deprecation Output source locations where
deprecate
d APIs are used
[javac] -classpath path Specify where to find user class
files
[javac] -cp path Specify where to find user class
files
[javac] -sourcepath path Specify where to find input source
file
s
[javac] -bootclasspath path Override location of bootstrap class
fi
les
[javac] -extdirs dirsOverride location of installed
extensio
ns
[javac] -endorseddirs dirs
[jira] Commented: (AXIS2-1116) WSDL2Java with Xmlbeans binding is not generating classes for all schema
[
http://issues.apache.org/jira/browse/AXIS2-1116?page=comments#action_12433671 ]
Ajith Harshana Ranabahu commented on AXIS2-1116:
#2 is fixed and the code checked in. Please test against the latest nightly and
let us know
WSDL2Java with Xmlbeans binding is not generating classes for all schema
Key: AXIS2-1116
URL: http://issues.apache.org/jira/browse/AXIS2-1116
Project: Apache Axis 2.0 (Axis2)
Issue Type: Bug
Components: databinding
Affects Versions: 1.0
Environment: Windows XP, Axis 2.0 nightly build (2006-09-02)
Reporter: Brennan Spies
Priority: Blocker
Attachments: files.zip
I have 3 XML Schemas that are used by my service definition in Query.wsdl. I
am specifying 'xmlbeans' as the databinding option and doing the code
generation with the following ant task (see attached for source):
codegen wsdlfilename=${basedir}/xml/Query.wsdl
output=${basedir} serverside=true
generateservicexml=true
packagename=com.ejgallo.workflow.service.query synconly=true
namespaceToPackages=urn:ejgallo:workflow:routing=com.ejgallo.workflow.service.routing,urn:ejgallo:worklfow:service=com.ejgallo.workflow.service,urn:ejgallo:workflow:service:query=com.ejgallo.workflow.service.query
databindingName=xmlbeans
serviceName=QueryWebService generateAllClasses=true
serverSideInterface=true
testcase=true unpackclasses=true/
There are 3 problems here:
1) Only one of the schema files, workflowTypes.xsd, has XMLBeans source
files generated for it, though the console output indicates that all 3 are
found/referenced. (No problem when Xmlbeans' ant task is used instead).
2) Under the /resources directory, the referenced schema files are generated
as 'xsd0.xsd', 'xsd1.xsd', and 'xsd2.xsd'. Because the original schema file
names are referenced in the WSDL and XSD files, this leads to the appropriate
files not being found when it is deployed as an .aar.
3) The 'namespaceToPackages' attribute on the ant task is not being honored,
leading the source files for the generated Xmlbeans classes to be the default
that Axis chooses for them based on the namespace.
--
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]
