[
https://issues.apache.org/jira/browse/FELIX-5247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15544488#comment-15544488
]
Fabian Lange commented on FELIX-5247:
-
I filed a ticket for karaf and proposed a solut
Thanks for spotting Karl - I assume we have this problem with all of the
http releases for quiet some time now. However, as I think we should fix
this as, I'll hereby cancel the vote.
Let's get it fixed and then cut a new release.
Regards
Carsten
Karl Pauls wrote
> Hm, I think we are running into
Thanks, Karl!
That happens when both just show as dev in my mail client.
Was indeed intended for karaf-dev.
Fabian
> On 3 Oct 2016, at 23:14, Karl Pauls wrote:
>
> I guess I'm not sure if this message is intended for dev@felix or dev@karaf?
>
> regards,
>
> Karl
>
> On Mon, Oct 3, 2016 at 9
Hm, I think we are running into on of the NOTICE in the root of the bundle
svn issues again.
Both, Bridge and Jetty do not get their NOTICE copied into their binary jar
causing the somewhat awkward situation that the source artifacts have a
NOTICE claiming they contain code from the OSGi Alliance
I guess I'm not sure if this message is intended for dev@felix or dev@karaf?
regards,
Karl
On Mon, Oct 3, 2016 at 9:21 PM, Fabian Lange
wrote:
> Hi,
> what do you guys think about:
> https://github.com/apache/karaf/pull/246
>
> As noticed by me, and already reported here:
> https://issues.apac
Checked signatures, did some basic tests.
+1 (binding)
thanks Carsten;
regards
/Pierre
On Fri, Sep 30, 2016 at 11:24 PM, David Bosschaert <
david.bosscha...@gmail.com> wrote:
> +1
>
> David
>
> On 30 September 2016 at 14:26, Carsten Ziegeler
> wrote:
>
> > I would like to call a vote on the f
2016-10-03 22:12 GMT+02:00 Karl Pauls :
> On Mon, Oct 3, 2016 at 9:49 PM, Guillaume Nodet wrote:
>
> > An extension sounds doable.
> > However, I found something weird:
> >
> > https://github.com/apache/felix/blob/trunk/framework/
> > src/main/java/org/apache/felix/framework/ExtensionManager.java
On Mon, Oct 3, 2016 at 9:49 PM, Guillaume Nodet wrote:
> An extension sounds doable.
> However, I found something weird:
>
> https://github.com/apache/felix/blob/trunk/framework/
> src/main/java/org/apache/felix/framework/ExtensionManager.java#L505-L507
>
> Is that expected that the framework is
An extension sounds doable.
However, I found something weird:
https://github.com/apache/felix/blob/trunk/framework/src/main/java/org/apache/felix/framework/ExtensionManager.java#L505-L507
Is that expected that the framework is using the classloader loading the
framework instead of the classloader
Hi,
what do you guys think about:
https://github.com/apache/karaf/pull/246
As noticed by me, and already reported here:
https://issues.apache.org/jira/browse/FELIX-5247
The current default behaviour is that every "resolve()" call will create a
new Executor Pool with number of CPU Cores as size. T
On 10/3/16 12:02 , Guillaume Nodet wrote:
I have a use case where the wiring is a bit complicated.
Karaf uses the felix resolver to compute the full wiring and then applies
it.
At this point, all the bundles are resolved and started correctly.
If Karaf is restarted, the framework restarts and res
I have a use case where the wiring is a bit complicated.
Karaf uses the felix resolver to compute the full wiring and then applies
it.
At this point, all the bundles are resolved and started correctly.
If Karaf is restarted, the framework restarts and resolves the bundles on
its own, using a bad so
I've downgraded the requirement or the gogo-runtime to java 7.
That's not really possible for the gogo-jline bundle which has a dependency
on jline requiring java 8 atm.
Given the amount of change, I think it would be better to bump the
gogo-runtime bundle version. Given it's currently at 0.17, w
13 matches
Mail list logo