Hi Nodet,
Comments are in the line.
Guillaume Nodet wrote:
On 9/19/07, Willem Jiang <[EMAIL PROTECTED]> wrote:
Hi ,
I agree to keep the binding as a separate object in the pipeline.
And I suggest to add the in and out flage to the binding .
form("http://soapendpoint";).binding(soap, in).to(
Hi,
No, here is not sample or unit test to show cxf+pojo.
But you can take a look at the CxfProducerTest, it shows how to process
pojo invocation as a soap request.
Willem.
Guillaume Nodet wrote:
Hmm, I guess I missed the point that the CXF component was relying
on the pojo component for the
[
https://issues.apache.org/activemq/browse/CAMEL-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Strachan resolved CAMEL-133.
--
Resolution: Fixed
patch applied with huge thanks Nicky! Great job!
> add support for a Mess
[
https://issues.apache.org/activemq/browse/CAMEL-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Strachan resolved CAMEL-134.
--
Resolution: Fixed
Am gonna mark this one as fixed for now; if anyone has any good ideas for
[
https://issues.apache.org/activemq/browse/CAMEL-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Strachan resolved CAMEL-137.
--
Resolution: Fixed
> improvements in the Visualisation plugin to render pipeline/multicast ni
I would like to cleanup the naming convention for jmx too if the release
could wait one day.
Cheers
Hadrian
Guillaume Nodet wrote:
I've just spotted that there is a big piece of code to write to be
able to discover components inside OSGi, as it needs to look into
bundles and across classloade
I've just spotted that there is a big piece of code to write to be
able to discover components inside OSGi, as it needs to look into
bundles and across classloaders ...
So feel free to do the release...
On 9/19/07, Hiram Chirino <[EMAIL PROTECTED]> wrote:
> Ok.. no worries.. I start working on it
[
https://issues.apache.org/activemq/browse/CAMEL-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved CAMEL-152.
---
Resolution: Fixed
URL: http://svn.apache.org/viewvc?rev=577424&view=rev
> Add a ref: uri
Add a ref: uri protocol to lookup existing endpoints or going to the registry
as this is not easy in the java dsl (ref are mainly available from xml)
oh that's no good.. I'll get that fixed.
On 9/19/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> Actually, camel main pom refers to activemq 5.0-SNAPSHOT...
>
> On 9/19/07, Hiram Chirino <[EMAIL PROTECTED]> wrote:
> > Hi Guillaume,
> >
> > Actually I think it's not circular because camel depends
Actually, camel main pom refers to activemq 5.0-SNAPSHOT...
On 9/19/07, Hiram Chirino <[EMAIL PROTECTED]> wrote:
> Hi Guillaume,
>
> Actually I think it's not circular because camel depends on a
> previously released version of ActiveMQ for testing. It would be
> circular if it depended on a SNAP
Ok.. no worries.. I start working on it anyways there is always a long
laundry list of things to check for the release anyways. Please ping
back once your verified the integration.
On 9/19/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> Just give me one day to make sure I can integrate camel in
Hi Guillaume,
Actually I think it's not circular because camel depends on a
previously released version of ActiveMQ for testing. It would be
circular if it depended on a SNAPSHOT. So that's why it works.
It should not lead to problems in releases AFAIK.
As far as the OSGi bundles.. what are th
[
https://issues.apache.org/activemq/browse/CAMEL-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicky Sandhu updated CAMEL-133:
---
Attachment: patch.txt
Fixed the previous problem with this patch. It now runs fine ( I learnt that
[
https://issues.apache.org/activemq/browse/CAMEL-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicky Sandhu updated CAMEL-133:
---
Attachment: (was: patch.txt)
> add support for a MessageExchangePattern enum property on Excha
Just give me one day to make sure I can integrate camel in servicemix 4.0 ...
On 9/19/07, James Strachan <[EMAIL PROTECTED]> wrote:
> On 9/19/07, Hiram Chirino <[EMAIL PROTECTED]> wrote:
> > Hey folks..
> >
> > It looks to me like camel has had a ton of new features and bug fixes
> > since the 1.1
On 9/19/07, Hiram Chirino <[EMAIL PROTECTED]> wrote:
> Hey folks..
>
> It looks to me like camel has had a ton of new features and bug fixes
> since the 1.1 release.. perhaps we should start gearing up to do a 1.2
> release... What do you guys think?? I'll start working on preparing
> release cand
Hey folks..
It looks to me like camel has had a ton of new features and bug fixes
since the 1.1 release.. perhaps we should start gearing up to do a 1.2
release... What do you guys think?? I'll start working on preparing
release candidates if no one objects.
--
Regards,
Hiram
Blog: http://hira
On 9/18/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> I think we should keep the seda component somehow, but change itssemantic
> (and name) so that it becomes a "in memory queue", like
> JMS without persistence and all. I think it still can be quite handy for
> unit testing, demos, etc
>
[
https://issues.apache.org/activemq/browse/CAMEL-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicky Sandhu updated CAMEL-133:
---
Attachment: patch.txt
I was in need to communicate with a text based protocol socket. I am adding
Hi,
has someone had a chance to review the patch of
http://issues.apache.org/activemq/browse/CAMEL-126 ? I'm currently not sure
if this patch fully addresses the description of this issue.
What I did in this patch was to change the StreamResequencer to start a
polling thread in the same wa
Hmm, I guess I missed the point that the CXF component was relying
on the pojo component for the actual service.
It makes more sense now.
Is there any example / unit test showing cxf + pojo ? I did not find
any and that's why I was a bit confused...
On 9/19/07, Willem Jiang <[EMAIL PROTECTED]> wr
On 9/19/07, Willem Jiang <[EMAIL PROTECTED]> wrote:
> Hi ,
>
> I agree to keep the binding as a separate object in the pipeline.
> And I suggest to add the in and out flage to the binding .
> form("http://soapendpoint";).binding(soap, in).to("pojo.service")
> and
> from("direct").binding(soap, out)
Hi ,
I agree to keep the binding as a separate object in the pipeline.
And I suggest to add the in and out flage to the binding .
form("http://soapendpoint";).binding(soap, in).to("pojo.service")
and
from("direct").binding(soap, out).to("http://localhost:/cxfservice";);
BTW, I don't want to mix
Hi Nodet,
Please see my comments in the line:
Guillaume Nodet wrote:
Yeah, i'm trying to dig into it.
What i'd like to do is use cxf just for soap processing.
Ideally, i'd like to have:
from(soap("http://localhost:8192/service";)).
process(xx).
to(soap("http://myhost:8080/another";)).
For the binding side, spring came up with oxm.
See http://static.springframework.org/spring-ws/site/reference/html/oxm.html
I'm not sure if we can reuse it or not, because it's only xml / pojo,
but it has support for jaxb1, jaxb2, xmlbeans, jibx, xstream and castor,
so it may be interesting to have
Sounds like a great idea! One thing I've always thought we needed was
some kind of 'binding' abstraction. So you could do something like
from(someFileOrHttpOrJmsUri).
binding(someBinding).
to(someFileOrHttpOrJmsUri);
where someBinding = JAXB2, jibx, xstream, Java Serialisation,
CORBA/II
27 matches
Mail list logo
