Perhaps.
I want to be able to use a bean in other Spring module.
What is also an issue it that two (or more) modules obviously result in two
sockets to be opened, in my case both 8400.
A solution could be to open a different socket per module, e.g. negotiated with
a module for that purpose
Hey Thomas,
I just got stack overflow myself and began to look for solution of my issue.
From my past experiences I can tell you that stack overflow prior 4.3.x
was usually result of multiple feature repositories (uris) delivering
same feature. This might happen if you have several
I started a service bridge allowing to implicit push some spring bean to the k5
registry and so that can be used from other modules running in k5. It’s a local
branch for now but I can push it on main.
Is it what you are looking for ?
Regards
JB
> Le 29 sept. 2021 à 21:43, jgfrm a écrit :
Is there already something working for exporting functionality of a Spring
modules to other modules?
|-Oorspronkelijk bericht-
|Van: Jean-Baptiste Onofré
|Verzonden: woensdag 29 september 2021 17:26
|Aan: user@karaf.apache.org
|Onderwerp: Re: Karaf 5
|
|Thanks for the update.
|
|I'm
Thanks for the update.
I'm happy to say you are the first one to "use/launch" Karaf 5 ;)
About the TomcatURLStreamHandlerFactory is known "issue":
The following works:
Karaf.json:
{
"applications": [
{
"name": "e3web",
"url": "file:///home/jaap/Karaf5Test/e3web-dev.jar",
"type": "spring-boot",
"properties": {
"enableHttp": true,
"enablePrometheus": true
}
}
]
}
Add to
Hi,
No it's not really possible without a framework extension.
Bundle classloader is directly managed by the framework.
However, you can create/federate/control classloader. It's what we do in
Cellar using the ClassLoaderService:
Hello,
Is it possible to replace the bundle classloader with another? The idea
behind this is that you have a groovy class loader which uses the bundle
class loader as a parent. Then after the initialization of the groovy class
loader this class loader loads additional classes during runtime.
That's a good point for Karaf 5 ;) (the OSGi headers/test/kwonledges ;)).
Regards
JB
On 29/09/2021 10:46, Richard Hierlmeier wrote:
The point is that the fix of issue 1616 in jsoup is sufficient for me.
It does not fix the problem in jsr305, it just does not use it.
I can wait until jsoup
The point is that the fix of issue 1616 in jsoup is sufficient for me. It
does not fix the problem in jsr305, it just does not use it.
I can wait until jsoup 1.14.3 is released.
Yes, you can't fix these issues. The problem is that most artifacts do not
run on OSGI primarily.
They have OSGI
It's what I said in my previous email: "you have to change the core
feature".
If you want, I can provide a forked specific version to you.
Regards
JB
On 29/09/2021 09:01, Matthias Leinweber wrote:
Hello,
I tried to downgrade to 3.6.8 and blacklisted to 3.7.0 but
deployer/4.3.3 has package
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
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
13 matches
Mail list logo
