Hi Eric,
you can still use the old configuration style in the wsdl it should be
almost 100% compatible.
For the new configuration style that can be used via the
JMSConfigFeature threre is currently no equivalent in WSDL.
I was planning to implement the SOAP/JMS standard proposal wsdl syntax
in
I know I should remember the answer to this, but I'm suffering from a
senior moment
Does the updated JMS configuration change the WSDL extensions for
specifying the JMS endpoint in WSDL?
-
Eric Johnson
Principal Technical Writer
MII-KS, FUSE
Progress Software Corporation
-Original Me
I'm honestly not seeing anything. I've sent a note to nabble support.
We'll see what they say.
Dan
On Monday 03 November 2008 7:44:33 am Glen Mazza wrote:
> Dan, I use Nabble for reading and sending ML posts--I've noticed for the
> svn commits (i.e., postings to the read-only cxf-commits
The aegis provider can't handle non-UTF-8 since Aegis can't produce it (yet).
On Mon, Nov 3, 2008 at 12:06 PM, Sergey Beryozkin (JIRA)
<[EMAIL PROTECTED]> wrote:
>
>[
> https://issues.apache.org/jira/browse/CXF-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focused
Hi
- align the ListenerHook interface with the final version used in Equinox
I've added CXF-1896 for this.
this should be just about renaming 3 standard methods and dropping the one we
introduced to support the direct lookups.
- find some alternative mechanism for transparent registration
> - align the ListenerHook interface with the final version used in Equinox
I've added CXF-1896 for this.
> - find some alternative mechanism for transparent registration of remote
> services looked up directly (i.e. via BundleContext.getServiceReferences() as
> opposed to a ServiceTracker/Liste
Thanks, that was it--needed to add that and the cxf-rt-ws-security dependency
as well. Now different error messages but I'm fighting through them.
Glen
dkulp wrote:
>
>
> Glen,
>
> Is this maven based?Have you added a dependency on the
> cxf-rt-ws-policy
> artifact?
>
> Dan
>
>
> On
On Monday 03 November 2008 9:28:41 am Benson Margulies wrote:
> In this particular case, it might be worth considering whether the
> particular use case holds water. 'Gee, I have these XMLBeans over here
> for some of my types, but I can't/don't want to bother to either build
> out XMLBeans for all
Hi
No. I actually expect this to be more important for the JMS folks than the
HTTP folks which is why it needs to be transport independent. Basically,
MOST HTTP users expect a fairly synchronous invokation path. That's pretty
much how its "always been" so people using HTTP, unless they sp
Glen,
Is this maven based?Have you added a dependency on the cxf-rt-ws-policy
artifact?
Dan
On Monday 03 November 2008 7:01:47 am Glen Mazza wrote:
> dkulp wrote:
> > Actually, the CLIENT side stuff is MUCH better tested right now. I've
> > been using the live MS WCF tests at:
> > http:
On Monday 03 November 2008 9:41:59 am Sergey Beryozkin wrote:
> Hi,
>
>
> It's an interesting idea. Worth having it in mind. However, I'm thinking,
> how reasonable it is to expect that a user would want to write a
> Continuations code portable across multiple transports ? I'd imagine that a
> use
Hi,
I guess my thinking was to tie the continutations directly to the
PhaseInterceptorChain (since that is going to need to know about them
anyway). However, I suppose it could easily be done with a new interface.
Probably the best thing to do is to stub out a sample usecase. So here
goes..
In this particular case, it might be worth considering whether the
particular use case holds water. 'Gee, I have these XMLBeans over here
for some of my types, but I can't/don't want to bother to either build
out XMLBeans for all of my types or build JAXB for those. Couldn't I
mix and match? It see
I share your sentiments that you placed in put in that bug report, namely
that CXF, like Metro, does not have a requirement or an architectural need
to do everything that XFire does. BTW, for the benefit of others, here's
the link: https://issues.apache.org/jira/browse/CXF-1891
Benson Margulies
Any other committers care to weigh in on this?
I've hit the bottom of my shallow pond of expertise here, can someone
else perhaps deconfuse him?
Dan, I use Nabble for reading and sending ML posts--I've noticed for the svn
commits (i.e., postings to the read-only cxf-commits mailing list) replies
can only be sent to the author and not the group as a whole. Does Nabble
give you the option to forward replies to the cxf-commits ML to the cxf-
dkulp wrote:
>
> Actually, the CLIENT side stuff is MUCH better tested right now. I've
> been using the live MS WCF tests at:
> http://mssoapinterop.org/ilab/
> as my testcases. For the most part, I just run wsdl2java on the wsdls
> and have a simple client that calls on them. For each
Thanks for these David, I'll do the needful ...
/Eoghan
-Original Message-
From: David Bosschaert [mailto:[EMAIL PROTECTED]
Sent: Mon 03/11/2008 04:44
To: dev@cxf.apache.org
Subject: Re: [DOSGi] Spring-DM based demo added to CXF-1879
Hi all,
I've also attached some small improvements
Hi David,
It would be great to have RFC 126 support in Felix as well as Equinox, as
obviously this would remove a barrier to wide adoption of dOSGi.
So I agree, it would be a good move to contribute back the ListenerHook support
from the forked version of Felix that we've put in the CXF sando
Hi all,
I've also attached some small improvements to the greeter demo in a
patch to this bug. It would be great if someone could apply these two
patches.
Many thanks,
David
2008/10/21 David Bosschaert <[EMAIL PROTECTED]>:
> Hi all,
>
> I've added a new Spring-DM based demo for the Distributed
Hi all,
The DOSGi sanbox project is getting closer to being a fully functional
Reference Implementation of the Distribution Software (DSW) component
of Distributed OSGi (RFC 119).
The main thing that prevents it from moving out of the sandbox is the
fact that it currently uses a modified version o
22 matches
Mail list logo
