Refactoring done and releasing the lock.
Thanks all for your help.
Eran Chinthaka wrote:
>Hi all,
>
>I'm Making the hierarchy as follows:
>
>s/ServiceDescription/AxisService/
>s/OperationDescription/AxisOperation/
>s/ServiceGroupDescription/AxisServiceGroup/ according to the proposal.
>This is s
Hi Ruchith:
I very much like the ability to quickly configure the handler chain
using axis2.xml. As long as nothing creates conflicts, why shouldn't we
allow this?
Are you talking about handlers in general?
If so... I was under the impression that with Axis2 the users will NOT
not have access
Hi Deepal:
As I understand we came to a conclusion that the only way to deploy
handlers using module. So if some one want to add a handler he has to
create module and write it module.xml correctly and engage that module.
(I know the fact that it make simple case harder). But I do not think we
What about the package name then? Are we going to retain "description"?
As the argument goes, as it is not meta data, "description" does not
sound correct.
Tanks,
Samisa...
Glen Daniels wrote:
For the record, I continue to really dislike
ServiceDescription/OperationDescription as class names
here is my +1
Thanks,
Deepal
~Future is Open~
- Original Message -
From: "Sanjiva Weerawarana" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc:
Sent: Wednesday, October 26, 2005 5:15 AM
Subject: Re: [axis2] Dispatchers
Hi glen and all;
As I understand we came to a conclusion that the only way to deploy handlers
using module. So if some one want to add a handler he has to create module
and write it module.xml correctly and engage that module. (I know the fact
that it make simple case harder). But I do not thi
Hi All,
Please see my commens below:
On 10/26/05, Glen Daniels <[EMAIL PROTECTED]> wrote:
> Hi Deepal, Sanjiva:
>
> >>> What I'm trying to say is that we should NOT hard-code the dispatch
> >>> order, we should have it simply exist as configuration in the default
> >>> axis2.xml file.
> >>
> >> +
Hi all,
I'm Making the hierarchy as follows:
s/ServiceDescription/AxisService/
s/OperationDescription/AxisOperation/
s/ServiceGroupDescription/AxisServiceGroup/ according to the proposal.
This is some what a big refactoring which effect most of the code. So
please please do not commit anything un
+1 from me too.
Are you all ok with the names of Context hierarchy ?
-- Chinthaka
Sanjiva Weerawarana wrote:
On Tue, 2005-10-25 at 19:12 -0400, Glen Daniels wrote:
Make the hierarchy as follows:
s/ServiceDescription/AxisService/
s/OperationDescription/AxisOperation/
s/ServiceGr
[
http://issues.apache.org/jira/browse/AXIS2-272?page=comments#action_12355912 ]
Eran Chinthaka commented on AXIS2-272:
--
Hi Douglas, thanks for the comment.
I looked at the issue you pointed above, but it seems, that integration was
with Axis 1.2 and y
On Tue, 2005-10-25 at 19:12 -0400, Glen Daniels wrote:
> Make the hierarchy as follows:
>
> s/ServiceDescription/AxisService/
> s/OperationDescription/AxisOperation/
> s/ServiceGroupDescription/AxisServiceGroup/
+1 from me for consistent names too.
I have one additional request- whenever people
+1 from me.
-- dims
On 10/25/05, Glen Daniels <[EMAIL PROTECTED]> wrote:
> For the record, I continue to really dislike
> ServiceDescription/OperationDescription as class names for these things.
> Consider Deepal's message below - the Service"Description" is the
> place you get the ClassLoader
On Tue, 2005-10-25 at 19:01 -0400, Davanum Srinivas wrote:
> +1 from me. Glen please go ahead and clean it up :) I agree with the
> principle, default should come from axis2.xml
+1 from me too!
Sanjiva.
For the record, I continue to really dislike
ServiceDescription/OperationDescription as class names for these things.
Consider Deepal's message below - the Service"Description" is the
place you get the ClassLoader from! It contains metadata, sure, but in
a real way it IS the runtime represent
+1 from me. Glen please go ahead and clean it up :) I agree with the
principle, default should come from axis2.xml
thanks,
dims
On 10/25/05, Glen Daniels <[EMAIL PROTECTED]> wrote:
> Hi Deepal, Sanjiva:
>
> >>> What I'm trying to say is that we should NOT hard-code the dispatch
> >>> order, we sh
Hi Deepal, Sanjiva:
What I'm trying to say is that we should NOT hard-code the dispatch
order, we should have it simply exist as configuration in the default
axis2.xml file.
+1 .. Deepal what's the advantage of having it fixed programmatically
instead of being read in from the config?
In the
[
http://issues.apache.org/jira/browse/AXIS-2271?page=comments#action_12355893 ]
Steve Green commented on AXIS-2271:
---
It looks like the problem was introduced in CVS version 1.112 of
SerializationContext.java with the creation of getActualJavaClass(). Re
[ http://issues.apache.org/jira/browse/AXIS-2271?page=all ]
Steve Green updated AXIS-2271:
--
Attachment: polytest.java
This test program is a modification of the polymorphism test case. It uses
LocalTransport to act as a stand alone test.
> Regression wit
[ http://issues.apache.org/jira/browse/AXIS-2271?page=all ]
Steve Green updated AXIS-2271:
--
Attachment: polymorphism.wsdl
This wsdl is a modification of the wsdl from the polymorphism test case. Note
that it adds a wrapper type around the type intended to
Regression with polymorphism
Key: AXIS-2271
URL: http://issues.apache.org/jira/browse/AXIS-2271
Project: Apache Axis
Type: Bug
Components: Serialization/Deserialization
Versions: current (nightly)
Reporter: Steve Green
P
[
http://issues.apache.org/jira/browse/AXIS2-272?page=comments#action_12355888 ]
Douglas Hubler commented on AXIS2-272:
--
Spring is working on this as well, only very different approach
http://opensource2.atlassian.com/projects/spring/browse/SPR-371
Hi Robert and All,
robert burrell donkin wrote:
some random musings...
On 10/24/05, Eran Chinthaka <[EMAIL PROTECTED]> wrote:
Hi all,
We all know that we have a small problem with our packaging of distros.
We were telling lot of things about this here and the
[
http://issues.apache.org/jira/browse/AXIS-1965?page=comments#action_12355872 ]
Jason Williams commented on AXIS-1965:
--
There seem to be several serialization related errors that are not easily
reproduceable, and are closed without any true fix. Is t
Hi folks!
This is an automatic reminder that the weekly Axis2 developer chat
will be occurring tomorrow, October 26, at:
7PM PDT, 10PM EDT, 2AM GMT, 8AM (next day) SLT, 12PM (next day) AEST
The chat takes place on the freenode IRC network, (use server
irc.freenode.net), on channel #apache-axis,
some random musings...
On 10/24/05, Eran Chinthaka <[EMAIL PROTECTED]> wrote:
Hi all,We all know that we have a small problem with our packaging of distros.
We were telling lot of things about this here and there, but no solidsolution so far.
IMHO this is part is of a bigger problem concerning ja
On 10/25/05, Steve Loughran <[EMAIL PROTECTED]> wrote:
Who owns the apache implementation of javax.qname?
IIRC xml-commons keeps a canonical version but it's probably best asking this question again on that list...
- robert
ClassCastException in AxisClient.getJAXRPCHandlerChain
--
Key: AXIS-2270
URL: http://issues.apache.org/jira/browse/AXIS-2270
Project: Apache Axis
Type: Bug
Environment: exists in axis 1.2.1 and code hasn't chaged i
[
http://issues.apache.org/jira/browse/AXIS-2186?page=comments#action_12355749 ]
Stefano Meneghello commented on AXIS-2186:
--
Hi,
Axis 1.3 final gives the same error message for >1MB attachments
Stefano
> AxisFault with DIME attachments greater th
Who owns the apache implementation of javax.qname? Is there one single
source tree that is the master, with one self-contained jar file that
implements it for the benefit of gump-enabled things. Or does every
project get to reimplement it themselves and redist it inside their own
JAR files?
[
http://issues.apache.org/jira/browse/AXIS2-294?page=comments#action_12355734 ]
Chamikara Jayalath commented on AXIS2-294:
--
OK. Please make it a new feature :)
BTW it is great if it shows an error message other than an exception.
Thanx,
Chamikar
[
http://issues.apache.org/jira/browse/AXIS2-294?page=comments#action_12355731 ]
Deepal Jayasinghe commented on AXIS2-294:
-
Hi Chamikara,
First of all it's NOT a bug it's a security feature, we had a long discussion
before we are doing so. And we d
[ http://issues.apache.org/jira/browse/AXIS-2216?page=all ]
Ralf Hauser updated AXIS-2216:
--
Attachment: patch.txt
patch to be able to set such a cipher.
It's a one liner:
call.setProperty(JSSESocketFactory.SUPPORTED_CIPHER_SUITES,
OpenSSLciphers.get
Can't add user defined phases before the PostDispatch phase
---
Key: AXIS2-294
URL: http://issues.apache.org/jira/browse/AXIS2-294
Project: Apache Axis 2.0 (Axis2)
Type: Bug
Components: deployment
Report
Glen Daniels wrote:
Hey Steve:
> Ooops wrong link:
> http://www.w3.org/2002/ws/addr/testsuite/
It still offends me that WS-A can consider themselves nearly ready to
be final and yet they only have a few draft test cases. For example,
where is their wsa:To header with a ? string in
ht
Steve Loughran wrote:
Rogan Dawes wrote:
Hi folks,
I recently attended a presentation at the OWASP (Open Web Application
Security Project) Conference in Washington, and the presenter showed an
attack scenario involving injection of repeated elements into the XML
document.
The idea is that if
hi
You can do that , but you need to do small modification add the following
method to the skeleton class , then that method will be called by
MessageReciver (called dependency injection)
class MySkel {
private MessageContext ctx;
public void init(MessageContext ctx){
this.ctx = ctx;
}
//
[ http://issues.apache.org/jira/browse/AXIS2-291?page=all ]
Eran Chinthaka resolved AXIS2-291:
--
Resolution: Fixed
Fixed.
> OMStaxWrapper throws unnecessary END_DOCUMENT event
> ---
>
> Key:
Umlauts (e.g. äöü) are not correctly handled
Key: AXIS2-293
URL: http://issues.apache.org/jira/browse/AXIS2-293
Project: Apache Axis 2.0 (Axis2)
Type: Bug
Components: core
Versions: 0.92
Reporter: Yves Lang
38 matches
Mail list logo
