So what’s the point in your previous email ? If the third party fixed their
issue already that’s fine right ?
Karaf can’t fix whole world issue ;)
Regards
JB
> Le 29 sept. 2021 à 08:04, Richard Hierlmeier a
> écrit :
>
>
>
> Wrapping the bundle is not necessary for my use case. The bug i
Wrapping the bundle is not necessary for my use case. The bug is already
fixed in jsoup.
See https://github.com/jhy/jsoup/issues/1616
Unfortunately the release of jsoup 1.14.3 is yet not available.
The original findbugs development is no longer active. The newer project is
named spotbugs. It does
Hi Richard
Sorry I misread the trace especially this part:
export: osgi.wiring.package=org.atmosphere.cpr; uses:=javax.annotation
com.vaadin.external.atmosphere.runtime
[com.vaadin.external.atmosphere.runtime [141](R 141.0)]
import: (osgi.wiring.package=javax.annotation)
AFAIR we alre
Hi J.B,
The javax.annotation package is exported by
mvn:com.google.code.findbugs/jsr305/3.0.2 (dependency of jsoup)
and by
mvn:jakarta.annotation/jakarta.annotation-api/1.3.5 (from cxf-specs feature)
None of them comes from Vaadin. vaadin-server has a dependency to jsoup
that was upgraded with V
FYI
https://issues.apache.org/jira/browse/FELIX-6461
Regards
JB
> Le 28 sept. 2021 à 17:27, Matthias Leinweber a
> écrit :
>
> I am pretty sure its the same reason:
>
> https://github.com/apache/felix-dev/commit/101a360248311817e1ad4645c549ea3b0481#diff-263cdbacfd163ef5ce31dcbb1db83138f7
Hi Richard,
It seems that vaadin.annotations bundle is just wrong as it exports
javax.annotation whereas it should not.
You have basically three options:
1. Fix vaadin.annotations ;)
2. Wrap vaadin.annotations to remove the “bad” export
3. Don’t use six annotation-api-1.3 and use vaadin.annotati
Yeah, this change looks bad to me, especially as it doesn’t work in some
startup order (it works by default in karaf thanks to startup order enforcement
but it’s not really a solution°.
I will fix that and cut a new fileinstall release to include in Karaf release.
Regards
JB
> Le 28 sept. 2021
After upgrading the Vaadin OSGI demo to VAADIN 8.14.0 it tried
to integrate a jax-rs resource into this application.
I used the rest whiteboard examples from the Karaf 4.3.3 distribution. It
worked in a first step fine.
Finally I tried to implement a JAX-RS authentication filter for this
applica
Hi Matthias,
Thanks for the update, the order should be fine by default in the
features set.
However, I might have identify a change that may cause issue (related to
FELIX-6229, on some environment).
Just give me time to investigate and I will get back to you.
Regards
JB
On 28/09/2021 16:
Hello,
i debugged a bit and it looks like that die file installer is started
before the artifact listeners are added.
During processing these files are added to the processingFailures list.
This list is reprocessed everytime and has a retry, but only if at least
one file is changed see
public vo
today I upgraded my Vaadin 8 OSGI demo project to Vaadin 8.14.0.
see
https://github.com/rhierlmeier/vaadin8_karaf_demo
Feel free an integrate it into the Karaf examples.
Regards
Richard
JMX is just a "frontend" to MBean/services provided by a bundle.
So, I would create a bundle providing health check service and exposed
as a MBean (like this:
https://github.com/apache/karaf/tree/main/examples/karaf-mbean-example
Regards
JB
On 28/09/2021 11:12, Andrei Petru Mura wrote:
Ok. I
Ok. I got that a health service would be a good option. But would this
service have to be deployed as a bundle or can I install it via JMX?
I ask this because I would try to avoid as much as possible "static"
configuration.
Thanks,
Andrei
On Tue, Sep 28, 2021 at 12:05 PM Jean-Baptiste Onofré
wro
OK, if it's for testing purpose why not, but I think we already have
quite similar existing stuff for that (maybe Cave Deployer, or
implementing simple health check service).
NB: "gaz plant" means super complex stuff for simple purpose ;)
Regards
JB
On 28/09/2021 10:05, Andrei Petru Mura wrot
Ah, OK, you don't need the sync, just get the status.
In that case, maybe Cave Deployer API can help:
http://karaf.apache.org/manual/cave/latest-4/#_deployer
You can check features/bundles state on the Karaf instances farm.
Regards
JB
On 28/09/2021 10:15, Andrei Petru Mura wrote:
I don't need
I don't need to manage more instances of Karaf servers. I only need to get
the status programmatically. This behavior is used in an app that is for
testing purposes, as I already mentioned in a different thread. Do you
think it is a better approach to use cellar for such a small thing?
Form Cellar
Hmmm...
I intend to do this for testing purposes only. This means that I want to
check that new upgrades, features, updates, etc are fully working for the
current applications. In order to check this, I want to test my prod apps
in a dev environment.
Having all this said, I would go to talk on your
Hi,
1. are you sure it's a good idea to check the log ? Why not just having
a health check service in your app bundles ?
2. You can register a PaxAppender like this:
public class MyLogListener implements PaxAppender {
public void doAppend(PaxLoggingEvent event) {
//
In my scenario, I try to deploy some bundles in my Karaf server, check the
status that everything is working, make some work with the successfully
deployed bundles and undeploy them. In order to get the status of work
done, I would need a log listener for specific bundles.
I see the ideal case to b
19 matches
Mail list logo
