I misunderstood what Christian suggested, as far as configuring the URI
with a servlet name was concerned. Christian explained to me (thanks) it
was for the internal purposes only to be used for bootstrapping the
common configuration, etc, where a URI would have the internal schema
and public s
On 25/09/14 15:07, Christian Schneider wrote:
On 25.09.2014 12:44, Sergey Beryozkin wrote:
Hi Christian
On 25/09/14 08:51, Christian Schneider wrote:
Having one servlet per bundle would definately work.
I see two problems though:
- Each servlet has its own base path where all services reside th
The filter approach is generally a good technique as it allows us more
flexibility. It has some drawbacks though.
The main issue for me is naming. If you have one servlet per application
you can name it like the application. The endpoint uris then only have
to be unique inside the application.
On 25.09.2014 12:44, Sergey Beryozkin wrote:
Hi Christian
On 25/09/14 08:51, Christian Schneider wrote:
Having one servlet per bundle would definately work.
I see two problems though:
- Each servlet has its own base path where all services reside then. Not
necessarily a bad thing but it would li
On Sep 25, 2014, at 3:51 AM, Christian Schneider
wrote:
> Having one servlet per bundle would definately work.
> I see two problems though:
> - Each servlet has its own base path where all services reside then. Not
> necessarily a bad thing but it would limit the freedom of the user to define
Hi Christian
On 25/09/14 08:51, Christian Schneider wrote:
Having one servlet per bundle would definately work.
I see two problems though:
- Each servlet has its own base path where all services reside then. Not
necessarily a bad thing but it would limit the freedom of the user to
define where hi
Having one servlet per bundle would definately work.
I see two problems though:
- Each servlet has its own base path where all services reside then. Not
necessarily a bad thing but it would limit the freedom of the user to
define where his endpoints live.
- Added configuration overhead and compl
On Sep 24, 2014, at 10:24 AM, Christian Schneider
wrote:
> On 24.09.2014 16:12, Daniel Kulp wrote:
>> This last thing should be possible already. All the “Bus” objects are
>> registered in the service registry. Thus, you should be able to look up a
>> Bus and use that from within another bund
On 24.09.2014 16:12, Daniel Kulp wrote:
This last thing should be possible already. All the “Bus” objects are
registered in the service registry. Thus, you should be able to look
up a Bus and use that from within another bundle. Dan
That sounds promising. I am a little concerned about the life
On Sep 24, 2014, at 9:03 AM, Christian Schneider
wrote:
> subsystems is a good idea. Still I think we also need to do changes in CXF.
> For example we would need to find a way to map the cxf servlet to different
> locations for each subsystem.
At one point, I turned the servlet into a Servlet
On 24 September 2014 15:03, Christian Schneider wrote:
> Hi David,
>
> I also still think it might be intersting to share a cxf bus between bundles
> to make it easier to configure common things. Any ideas about this?
Yes, this should be possible. The Composite Subsystem type allows you
to define
On 24/09/14 13:42, Christian Schneider wrote:
I would like to deploy two (or more) CXF based applications into the
same OSGi framework.
How can I enforce common rules per application while keeping the
applications separate from each other?
I created a wiki page to show the scenario and describe
Hi David,
subsystems is a good idea. Still I think we also need to do changes in CXF.
For example we would need to find a way to map the cxf servlet to
different locations for each subsystem.
I also still think it might be intersting to share a cxf bus between
bundles to make it easier to con
You could take a look at OSGi subsystems, which is chapter 134 of the
OSGi Enterprise R5 specs [1]. The Application and Composite subsystems
allow for separation of subsystems (while the Feature subsystem shares
everything, just like with Karaf features).
There is an implementation of OSGi subsyst
I would like to deploy two (or more) CXF based applications into the
same OSGi framework.
How can I enforce common rules per application while keeping the
applications separate from each other?
I created a wiki page to show the scenario and describe current
approaches I found and their limitat
15 matches
Mail list logo
