"I don't have confidence that when and if I run into future problems I
can find the resources or help to get around problems."
http://wso2.com/
http://covalent.net/
http://www.spikesource.com/
http://www.sourcelabs.com/
http://www.allesta.com/
-- dims
On 10/28/05, Paul Grillo <[EMAIL PROTECTED]>
Steve,
could we do a branch make the updates there to get a clearer picture?
- build against dom3
- try support dom2 at runtime
- update both the SAAJ and DOMImpl (to SAAJ 1.3 and DOM3)
once we have stuff working we can merge back to trunk.
thanks,
dims
On 10/28/05, Steve Loughran <[EMAIL PROTE
Davanum Srinivas wrote:
Steve,
could we do a branch make the updates there to get a clearer picture?
- build against dom3
- try support dom2 at runtime
- update both the SAAJ and DOMImpl (to SAAJ 1.3 and DOM3)
once we have stuff working we can merge back to trunk.
would make sense. I havent p
Should we break out the DOM2/DOM3 stuff from xml module? just like we
did for saaj?
+1 from me.
-- dims
On 10/28/05, Steve Loughran <[EMAIL PROTECTED]> wrote:
> Davanum Srinivas wrote:
> > Steve,
> >
> > could we do a branch make the updates there to get a clearer picture?
> > - build against do
Davanum Srinivas wrote:
Should we break out the DOM2/DOM3 stuff from xml module? just like we
did for saaj?
well, the issue is that both the OMElement and the SAAJ stuff declare
that they implement the dom interfaces, and you cannot build them on
java1.5 without marking every impl class as a
that's wrong...OMElement should not depend on DOM2...let me check.
-- dims
On 10/28/05, Steve Loughran <[EMAIL PROTECTED]> wrote:
> Davanum Srinivas wrote:
> > Should we break out the DOM2/DOM3 stuff from xml module? just like we
> > did for saaj?
> >
>
> well, the issue is that both the OMElemen
Steve,
all org.w3c imports are ONLY in org.apache.axis2.om.impl.dom.*
package. This can be ripped out w/o affecting xml module.
-- dims
On 10/28/05, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
> that's wrong...OMElement should not depend on DOM2...let me check.
>
> -- dims
>
> On 10/28/05, Steve
Davanum Srinivas wrote:
Steve,
all org.w3c imports are ONLY in org.apache.axis2.om.impl.dom.*
package. This can be ripped out w/o affecting xml module.
I'm checking. OK, the files that changed there were
AttrImpl, DocumentImpl, DOMImplementationImpl, NodeImpl, ParentNode,
TextImpl
and in
I've un-subbed your email ([EMAIL PROTECTED])
-- dims
On 10/28/05, McPhail, Jeff <[EMAIL PROTECTED]> wrote:
> I must say that I'm also extremely disappointed with Axis and
> this usergroup. I didn't like the fact that you have to sign up to
> receive ALL emails in order to participate --
Since SAAJ 1.3 implements DOM3, i feel we should just move this stuff
to SAAJ module. What do you think?
-- dims
On 10/28/05, Steve Loughran <[EMAIL PROTECTED]> wrote:
> Davanum Srinivas wrote:
> > Steve,
> >
> > all org.w3c imports are ONLY in org.apache.axis2.om.impl.dom.*
> > package. This can
Steve Loughran wrote:
> Davanum Srinivas wrote:
>
>> Should we break out the DOM2/DOM3 stuff from xml module? just like we
>> did for saaj?
>>
>
> well, the issue is that both the OMElement and the SAAJ stuff declare
> that they implement the dom interfaces, and you cannot build them on
> java1.
A BIG +1 from me for Glen's comments.
As Glen explained the base API should be as simple as possible and it
should not depend on any of the things like security/transaction/RM,
etc,
Paul, why do you wanna do that (I know you must be having a good
reason), when you can do the same thing using
Hi All,
The DOM impl that we have in the xml module implements the OM
interfaces. Therefore I included it under
org.apache.axis2.om.impl.dom.*
And I expected this to be used the same way we would use the llom
implementation of OM. (The linked list implementation of OM goes under
org.apache.axis2.o
Please send me the headers
-- dims
On 10/28/05, A B <[EMAIL PROTECTED]> wrote:
> Well it appears that things have become even worse. I tried to send an email
> and it bounced back. Since my email is no longer on the list, I can't send
> an email to the list in order to get me removed from the lis
Hi all, Ruchith ;-) ,
Ruchith Fernando wrote:
Hi All,
The DOM impl that we have in the xml module implements the OM
interfaces. Therefore I included it under
org.apache.axis2.om.impl.dom.*
And I expected this to be used the same way we would use the llom
implementation of OM. (The linked
OkI wasn't clear. Sorry. I also agree with Glen's comments :-) What I'm actually asking is that we move from: org.apache.sandesha.Constants.ClientPropertiesString LAST_MESSAGE = "lastMessage";
String CALL_KEY = "callKey";into org.apache.axis2.Constants.I am talking about using the property model, s
Folks,
I've moved the dom stuff out of the way and made the saaj build
optional. Now looking at test failures in JDK1.5
thanks,
-- dims
On 10/28/05, Eran Chinthaka <[EMAIL PROTECTED]> wrote:
> Hi all, Ruchith ;-) ,
>
>
> Ruchith Fernando wrote:
> Hi All,
>
> The DOM impl that we have in the x
One more reason to move these constants from Sandesha to Axis2 is so I don't need Sandesha in my classpath to write and run code that might one day use RM.PaulOn 10/28/05,
Paul Fremantle <[EMAIL PROTECTED]> wrote:
OkI wasn't clear. Sorry. I also agree with Glen's comments :-) What I'm actually ask
Paul Eran ..I do not read complete message ..but one option is to use
properties with the RM and give a RMClient interface that wrap the
Axis2 client and give first level support that properties.
My gut feeling is brunning the RM to Axis2 client API is not right ..
But we need to discuss
it more :
Steve,
You should be all set now.
Steps:
- Fetch latest SVN
- Create a project.properties in root directory
-
optional.includes=
-
- Drop latest
> you're probably right that java users expect to be able to run somethings
> out of the box. for axis, this probably means a war (of some type). so, it
> probably makes sense to include this in the binary distribution.
I will point out that I have never run Axis (even as one of its primary
impl
Hi Eran;
Building the OM from the SAX events is a good thing to have, even
though in that way differed parsing is possible.
That allows DOM -> SAX -> OM
Our first experimantal databinding approch (in M1 testcases .. see
org.apache.axis.databinding/encoding.*) we had this. There was a way
to crea
Hi All,
The requirement of supporting additional properties required for RM
through some client API was the case from the beginning of Sandesha. When
we initially write Sandesha, we had the same issue. With the 1.0
implementation and we end up using a SandeshaContext that will be
initialized with
Hi All,
Actually this is the way we have currently developed the client API for
Sandesha2. I hope following bit of code will clarify the issue.
Call call = new Call(AXIS2_CLIENT_PATH);
call.engageModule(new QName("sandesha"));
call.setTo(new EndpointReference(toEPR));
call.set(org.apache.sandesha
Chamikara,
In the generated code when RM module is engaged, we can generate what
we want. Am -0 to this proposal. I don't agree that the constants
should move to the core itself. If we start doing this we have to be
consistent and do the same for wss4j, kandula and others.
thanks,
dims
On 10/29/
[
http://issues.apache.org/jira/browse/AXIS-1982?page=comments#action_12356256 ]
Ralf Hauser commented on AXIS-1982:
---
a triple backflip workaround for something that should be easy might be this:
http://java2.5341.com/msg/43811.html
> enhance client Call
Request context (IP address and other request details) make available in
application
Key: AXIS-2276
URL: http://issues.apache.org/jira/browse/AXIS-2276
Project: Apache Axis
Type: Ne
I've been thinking about how Sandesha and Axis 2 should interact and how people can code to Axis2 with the idea in mind that they might be reliable later. I've just been asked a couple of times how can the code find out if a message has been delivered.
This is an interesting issue. I used to
belie
What is the maven goal to
-create the big jar of everything
-upload this and its pom to the local .m1 repository
I am having problems getting the output of a local build into the input
of the (m2-ant-task based) work I am doing.
the default goal uploads the many jar files as a separate modul
I have axis2 building under java1.5, and DOM 3. The extra methods in the
interfaces are just stubs, but it compiles.
Trouble is, I can't check this stuff in without 1.4 builds breaking,
because one of the new methods uses a datatype that is only in dom3.
Otherwise we could stick the stuff in
Hi Paul:
Great message! As I read it you're asking for three things:
1. Ability to pass SequenceKey in client API
2. Last message marker in client API
IMO, neither of these needs to be put as first-class concepts into the
Axis2 Call class, because we have easy-to-use mechanisms which allow
thi
31 matches
Mail list logo
