Ok, thanks !
It's great to ear usages of Karaf ;)
As JB said, the last release of Karaf Cave provider the Deployer helping
to deal with Karaf instance administration and it also provide an API Rest.
You can take a look to the implementation, may be you can find some
usefull stuff :
https://gith
Sure! Here our software works mostly on premises and we need a two-way
communication, a JMX connection from our admin to thousands of clients would
be a pain, also there are some commands we need a guarantee of execution and
JMS help us with that.
fpapon wrote
> Hi,
>
> I don't really understand
I guess for async.
Regards
JB
On 19/08/2018 12:21, Francois Papon wrote:
> Hi,
>
> I don't really understand why using JMS, can you explain ?
>
> regards,
>
> François Papon
> fpa...@apache.org
>
> Le 19/08/2018 à 03:13, Castor a écrit :
>> "by the way, what do you mean about remote admin ? I
Hi,
I don't really understand why using JMS, can you explain ?
regards,
François Papon
fpa...@apache.org
Le 19/08/2018 à 03:13, Castor a écrit :
> "by the way, what do you mean about remote admin ? Is it something like
> the Deployer feature we have in Cave?"
>
> Yes! the deploy module is quit
That sounds like Cave Deployer to me.
Regards
JB
On 19/08/2018 08:27, Christian Schneider wrote:
> Sounds interesting. Do you think you could write blog about your approach?
>
> Christian
>
> Am So., 19. Aug. 2018 um 01:42 Uhr schrieb Castor :
>
>> "by the way, what do you mean about remote ad
Sounds interesting. Do you think you could write blog about your approach?
Christian
Am So., 19. Aug. 2018 um 01:42 Uhr schrieb Castor :
> "by the way, what do you mean about remote admin ? Is it something like
> the Deployer feature we have in Cave?"
>
> Yes! the deploy module is quite similar,
Catcha.
Don't hesitate to create a Jira to extend the Cave Deployer to use the
same features !
Regards
JB
On 19/08/2018 01:13, Castor wrote:
> "by the way, what do you mean about remote admin ? Is it something like
> the Deployer feature we have in Cave?"
>
> Yes! the deploy module is quite si
"by the way, what do you mean about remote admin ? Is it something like
the Deployer feature we have in Cave?"
Yes! the deploy module is quite similar, but using JMS instead of JMX, i've
also created a suport to pre and post install hooks and plugins, blue-green
deployment, remote health checks a
I disagree here. We can have different perspective.
We have some users that use Karaf on Docker for infra, and use Cellar
with Kubernetes for node discovery. That's an approach.
Another option is to use the Karaf static profile (we have an example
now in the distribution) or a custom distribution
For cloud deployments you normally want to implement the immutable server
pattern:
https://martinfowler.com/bliki/ImmutableServer.html
This means that your whole deployment including config should be defined
from e.g. a github repository.
You do not want to have upgrades of bundles or config durin
I haven't directly used Karaf in a couple years, so I can't speak to what
my old team did with my old app, but we had a hell of a time upgrading
between point releases of Karaf. Part of that was immaturity at the time in
automating our infrastructure, but another part was simply trying to
coordinat
Hi,
by the way, what do you mean about remote admin ? Is it something like
the Deployer feature we have in Cave ?
By the way, I will take some days off next week, but after I will send a
proposal on the mailing list with:
1. Release agenda
2. Karaf Container roadmap
3. Karaf Vineyard
Stay tuned
Ohh yeah, at the beginning the mechanism was quite confusing, it still give
me some headaches sometimes, like a feature with no dependencies with a
bundle importing only a servlet triggering a refresh of the whole platform.
"For the update, I don't know which karaf version you are using, but
Kar
Hi,
Thanks for sharing your experience.
I don't say that it's your case, but most of the time, when people
complains about refresh, it's because they don't know/understand the
underlying mechanisms.
Basically, I had the case with a customer that used a bunch of optional
import and complain of the
I can tell a little about my experience with karaf.
Here we have an ERP writen in delphi (that was written in natural before
that) which we need to "upgrade" to a cloud capable software, using the same
database and mantaining the old software while we rewrite negotial rules in
java. Great part of
On 17/08/18 15:30, Jean-Baptiste Onofré wrote:
> Hi Robert,
Hello JB,
> thanks for your feedback, and I fully agree with you.
>
> For the release, it's largely my fault for 4.2.1: I wanted to include
> too much fixes, upgrades and new features. My bad, and apologize for
> that. That's why I want
Hi Robert,
thanks for your feedback, and I fully agree with you.
For the release, it's largely my fault for 4.2.1: I wanted to include
too much fixes, upgrades and new features. My bad, and apologize for
that. That's why I wanted to propose to reduce scope of the releases and
do it on a regular p
Hello Jamie, everyone,
On 16/08/18 10:46, Jamie G. wrote:
> Karaf is used / consumed heavily in the SDN world (see OpenDaylight &
> its ecosystem).
>
> For that community they do treat Karaf as a SDK for developing their
> apps, its also of course their runtime.
>
> The long support runs we prov
Hi Toni,
That's an aspect of Karaf that we should improve, and that's exactly the
purpose of:
1. The examples coming in the 4.2.1 (as part of the standard
distribution): https://github.com/jbonofre/karaf/tree/DEV_GUIDE
2. karaf-boot.
I started karaf-boot exactly to facilitate the view of Karaf
Thanks everyone for your quick replies.
I see your point, JB. "One of the key part of Karaf is use friendly." thats
what i mean by "opinionated felix distro".
It may sound as a bad thing but i mean it as a feature: it puts "batteries"
included onto the osgi fw, has opinions how to configure stuff
yes, +1 for the description :)
François Papon
fpa...@apache.org
On 16/08/2018 12:50, Jamie G. wrote:
> I like the phrase "Product Project", perhaps we should add that to
> Karaf's description ;)
> On Thu, Aug 16, 2018 at 6:18 AM Jean-Baptiste Onofré
> wrote:
>> Hi Toni,
>>
>> I know a fairly la
I like the phrase "Product Project", perhaps we should add that to
Karaf's description ;)
On Thu, Aug 16, 2018 at 6:18 AM Jean-Baptiste Onofré wrote:
>
> Hi Toni,
>
> I know a fairly large set of users that use Karaf without knowing OSGi.
>
> That's why it's a polymorphic container: some use sprin
Hi Toni,
I know a fairly large set of users that use Karaf without knowing OSGi.
That's why it's a polymorphic container: some use spring, some use OSGi,
some use blueprint, some use directly war, etc. There are several facet
of using Karaf.
About the distribution, to be honest, I only know user
Karaf is used / consumed heavily in the SDN world (see OpenDaylight &
its ecosystem).
For that community they do treat Karaf as a SDK for developing their
apps, its also of course their runtime.
The long support runs we provide for Karaf major versions is seen as a
benefit as SDN deployments typi
As mentioned, here are some more thoughts on Karaf audience/usage.
Do you know how Karaf users consume/use Karaf? This is important to get a
good release cycle and granularity. (as teased by JB on this list recently).
Why i am mentioning that? Well,i always felt that Karaf (the container) is
a ra
25 matches
Mail list logo
