cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mandy Warren <mandys.in...@gmail.com>
Subject Re: Repackaging of cxf-api to remove Spring dependencies
Date Tue, 10 Jun 2014 21:52:59 GMT
Hi,

I just wanted to apologise that I hadn't done any work on this over the last month.. been
pretty hectic with work, sorry!

Hoping to have a bit more free time soon.

Mandy


On 3 May 2014, at 10:48, Andrei Shakirin wrote:

> Hi Mandy,
> 
> You can provide your transport components either as git pull request or as a patch (attached
to corresponded Jira Issue).
> In any case it make sense to create Jira Issue for that to keep the process traceable.
> 
> As far as it is a new feature I would apply this to the master. Short documentation in
CXF confluence wiki and system test are, of course, always welcome :) 
> As Christian said, we can support you in design of shared part, if you have any questions.
> 
> Shared code can be for instance a small interface registering per endpoint and containing
methods for writing/reading message properties and content (PipedInput/PipedOutput stream
or analogue of CXF CachedOutputStream).
> Destination will register this interface using JNDI with endpoint name. By request, Conduit
will look up the interface an write request message there, Destination will read and create
a new message and call own message observer. Vice versa for response.
> 
> Regards,
> Andrei.
> 
>> -----Original Message-----
>> From: Mandy Warren [mailto:mandys.inbox@gmail.com]
>> Sent: Freitag, 2. Mai 2014 23:45
>> To: dev@cxf.apache.org
>> Subject: Re: Repackaging of cxf-api to remove Spring dependencies
>> 
>> Thanks Christian,
>> 
>> Just to check the process, should I fork 2.7-fixes branch or master to implement
>> the local-jndi transport? I'm new to git so pls bear with me! I guess once I have
>> something to share I issue a pull request?
>> 
>> I am also going to produce a separate project in my github which generates 2
>> wars and shows the transport in use. As soon as I have something to share I will
>> let you know, hopefully in the next few days.
>> 
>> Many thanks to everyone for being so supportive!
>> 
>> Sent from a mobile device
>> 
>>> On 2 May 2014, at 21:36, Christian Schneider <chris@die-schneider.net>
>> wrote:
>>> 
>>> I agree with Dan that you should not put the cxf api into the shared
>>> space. Create a small lib that contains the minimal information that needs to
>> be shared and build the transport upon this base. The users of your transport
>> will thank you if you make the shared part really small and simple.
>>> 
>>> It would be great if you could upload your transport somehwere. I am sure we
>> can help a bit with designing the shared part.
>>> 
>>> Christian
>>> 
>>> Am 02.05.2014 11:44, schrieb Mandy Warren:
>>>> Just to clarify yes, I was doing exactly as Sergei described and Andrei
>> discussed, I am creating a new jndi local transport which duplicates local
>> transport except for the jndi lookup. If you give me a few days I can upload the
>> code to somewhere on github so you can see it in detail.
>>>> 
>>>> As Andrei stated, it just relied on registering a Destination and hence
>> needed a fee interface classes that lived in cxf-api.
>>>> 
>>>> Sent from a mobile device
>>> 
>>> 
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>> 
>>> Open Source Architect
>>> Talend Application Integration Division http://www.talend.com
>>> 


Mime
View raw message