Remote Services can help a lot if you can represent the remote calls as
a java interface.
This works well for a lot of transports like SOAP or the fastbin
transport from Redhat.
Circuit Breaker could be nicely added to Remote Services in a
transparent way. Remote Services have the notion of in
Yeah, agree.
IMHO, the key thing is to avoid bunch of examples. Karaf should embed
and provide ready to use examples, based on one framework.
End-users are pretty lost when you have a bunch of different ways to
implement the same thing.
Regards
JB
On 01/16/2017 11:20 AM, Christian Schneide
I generally like the idea of having one standard way to do dependency
injection in OSGi. Unfortunately until now we do not have a single
framework that most people are happy with.
I pushed a lot to make blueprint easier by using the CDI and JEE
annotations and create blueprint from it using th
That's why karaf-boot can provide starter and clearly document pro/cons.
End-users will choose the best match for their needs.
The same could happen for framework: I would like to create a REST
service, should I start with Jersey, with CXF-RS, ...
So, if in karaf-boot, it makes sense to suppo
2017-01-16 11:36 GMT+01:00 Christian Schneider :
> I generally like the idea of having one standard way to do dependency
> injection in OSGi. Unfortunately until now we do not have a single
> framework that most people are happy with.
>
> I pushed a lot to make blueprint easier by using the CDI an
2017-01-16 13:25 GMT+01:00 Guillaume Nodet :
>
>
> 2017-01-16 11:36 GMT+01:00 Christian Schneider :
>
>> I generally like the idea of having one standard way to do dependency
>> injection in OSGi. Unfortunately until now we do not have a single
>> framework that most people are happy with.
>>
>> I
It sounds like the abstraction is well under way then. It certainly would make
a great deal of sense to abstract away the details about connections. We no
longer code at high level with raw sockets but use libraries. It seems the
frameworks could take that to the next level.
Brad
From:
Absolutely! I've been consulting for over 5 years and it's rare that I come
into a client's sight where they aren't all confused about Camel and especially
how to use it with bundles. Once they "get" it from a bit of guidance their
reaction is positive.
Or I'll find places where one developer i
I wonder if there's a way to start the implementation of a CDI common
practice with DS where possible but blueprint where not and then migrate
toward DS.
>From my point of view when mentoring new developer's there are going to be
two general use cases for CDI, one is just for internal wiring i
I suspect just providing examples and documentation showing the "idiomatic"
and preferred way of coding would take care of a lot of those issues. It
isn't that one is saying use Jersey or use CXF but that the examples
themselves use one and not the other. Blog posts and secondary
documentation mig
This sounds like a fantastic approach and one that can really standardize the
uses, libraries, documentation and examples.
Because the libraries for use in examples are yet to be chosen, we can decide
to give examples using those that fit better.
Brad
From: Guillaume Nodet [mailto:gno
I have investigated reworking the blueprint core extender on top of DS
months ago, but I did not pursue. The Felix SCR core is now more reusable
(I made it that way in order to reuse it in pax-cdi), so maybe I could have
another quick look about the feasibility. But I am pessimistic as IIRC, the
p
We're based on blueprint here, but that has more to do with our legacy as a
Spring shop. Blueprint was familiar, standardized in the OSGI spec, and the
hope in the past was to use the Gemini implementation so we could leverage
Spring features and projects alongside OSGI (Transactions, AOP, Sprin
I believe one of the goals of the "Boot" project should be to provide an easier
introduction to developing with OSGI, Karaf and the broader community projects
(CXF, Camel, etc.). One aspect of this is introducing developers to the
dynamism, breadth and yes complexity of OSGI.
We try to ease p
On 1/16/2017 2:20 AM, Christian Schneider wrote:
- One way messaging. I think the purest form of remote communication
are one way messages backed by JMS or Kafka or other messaging
brokers. Unfortunately I think this is only partially supported in
Remote Services.
and Nick Baker just wrot
The event bus model has served us well for certain things, broadcasting
application events consumed by unknown plugins for instance. It's certainly
extensible and easy from the consumer and producer standpoint.
That said, we are basing much of our new work on Reactive Streams APIs. This
provide
Nick do you have a link to pentaho where you are doing some of this. I am
guessing you are using flow instead of the OSGI pushstreams api when you
say that streaming was considered for the OSGI standards.
David Daniel
On Mon, Jan 16, 2017 at 1:36 PM, Nick Baker wrote:
> The event bus model has
Nothing much worth seeing from a Karaf OSGI perspective yet. We're working on
some stuff for the next release that's not going to be open until then, but you
can see the API now:
From: David Daniel
Sent: Monday, January 16, 2017 1:56:10 PM
To: user@karaf.apache.
Nothing much worth seeing from a Karaf OSGI perspective yet. We're working on
some stuff for the next release that's not going to be open until then, but you
can see the API now. We have one main Producer interface:
https://github.com/pentaho/pentaho-kettle/blob/ael/pdi-execution-engine/api/src
Your questions about the other pieces of the stack and how they play in sort
of echoes what this discussion brought up for me. If there is a collection
of libraries and standard idiomatic elements like CDI to be recommended,
what would that basic stack look like?
I'd sort of thought of this as
20 matches
Mail list logo
