Hello Ioannis,
Thanks. I am suspecting a problem with different plugin
configurations/versions in pluginsManagement in parent pom and plugins
in pom.
There was also an issue with builds.apache.org not building OSGi
bundles (a bug, which seems fixed now). This made debugging harder.
I'll check it
Hi Ryan,
yes, I started to work on both Cellar 2.3.x and trunk yesterday.
It should be better by the end of this week.
Regards
JB
On 01/16/2013 05:12 AM, Ryan Moquin wrote:
I know I was told that this version isn't stable yet, but I still wanted
to see if the build should be able to complete
I just happen to change some of my bundle to start at level 100 and
the bundle get 'installed' state and would not go to 'active'. No
error found in log. Can some one confirm?
May karaf is 2.3.0
Thanks
-Dan
Hi Dan,
We have an issue about Aries Blueprint in Karaf 2.3.0.
Your bundles are blueprint bundles ?
I saw the issue randomly with Karaf sshd and management blueprint
bundles for instance.
A fix has been performed in Aries, I submitted another patch to be able
to work with Blueprint CM and
That's expecte because the start level of the framework is set to 100.
You can change that in etc/config.properties iirc.
On Wed, Jan 16, 2013 at 8:14 PM, Dan Tran dant...@gmail.com wrote:
I just happen to change some of my bundle to start at level 100 and
the bundle get 'installed' state
Yes, I am seeing 2 properties under config.properties
org.osgi.framework.startlevel.beginning=100
karaf.startlevel.bundle=80
It would be nice if those 2 are documented in the config file so that
other user may able to figure out the issue when the same problem
encounter.
May be
yes i am using blueprint for all of our bundle
-D
On Wed, Jan 16, 2013 at 11:18 AM, Jean-Baptiste Onofré j...@nanthrax.net
wrote:
Hi Dan,
We have an issue about Aries Blueprint in Karaf 2.3.0.
Your bundles are blueprint bundles ?
I saw the issue randomly with Karaf sshd and management
Hey Krzysztof,
Yeah, 2.3.0 and 2.2.10 contains change which is not backward compatible:
KARAF-1305. I belive it should not happen in 2.2.x branch.
Anyway, I'll review your patches and start necessary branches for webconsole to
support current Karaf releases.
Best regards,
Lukasz
Wiadomość
Hi Dan,
did you try both with Karaf 2.2.x and 2.3.x ?
did you see differences in the behavior ?
Regards
JB
On 01/16/2013 09:17 PM, Dan Tran wrote:
Hi I have a service's PreDestroy method which requires a service from
other bundle during shutdown. However at shutdown time, blueprint make
the
Hi,
We discussed about this with Achim (he's the author of the changes).
He proposed to rollback his change in Karaf 2.2.x.
Regards
JB
On 01/16/2013 09:18 PM, Łukasz Dywicki wrote:
Hey Krzysztof,
Yeah, 2.3.0 and 2.2.10 contains change which is not backward
compatible: KARAF-1305. I belive it
Hi JB,
I only try 2.3, my new work does not work with 2.2
what is osgi/karaf shutdown sequencing flow? like it would shutdown
all bundles with the same start- level in the order from high to low ?
Thanks
-D
On Wed, Jan 16, 2013 at 12:18 PM, Jean-Baptiste Onofré j...@nanthrax.net
wrote:
Hi
Yeah my bad, sorry for this.
I'm going to open a new issue for this and will fix it for 2.2.x
sent from tablet
Am 16.01.2013 21:20 schrieb Jean-Baptiste Onofré j...@nanthrax.net:
Hi,
We discussed about this with Achim (he's the author of the changes).
He proposed to rollback his change in
Many thanks for quick response. This rollback will make versioning of dependant
projects easier!
Cheers,
Lukasz
--
l...@code-house.org
Twitter: ldywicki
Blog: http://dywicki.pl
Code-House - http://code-house.org
Wiadomość napisana przez Achim Nierbeck w dniu 16 sty 2013, o godz. 22:01:
Yeah
Well, originally, it karaf.startlevel.bundle was at 50, and for some
reasons, it kept increasing over time.
I think 100 start levels is good enough, but we should lower from 80 back
to 50, which would give more room for users.
On Wed, Jan 16, 2013 at 9:01 PM, Dan Tran dant...@gmail.com wrote:
The way the start level service is that when the framework boots, it goes
from 0 to the value specified by org.osgi.framework.startlevel.beginning.
At each level, the start level service will start bundles on that level.
I think the default value is 1 if not otherwise specified.
On Wed, Jan 16,
Thanks Achim !
Regards
JB
On 01/16/2013 11:21 PM, Achim Nierbeck wrote:
it's https://issues.apache.org/jira/browse/KARAF-2120
and I'm taking care of it
2013/1/16 Łukasz Dywicki l...@code-house.org mailto:l...@code-house.org
Many thanks for quick response. This rollback will make
Jamie,
Once you're clear on the methodology, I will volunteer test it for the
project in CentOS 6.3 (building it, then deploying it as an RPM package).
On 1/16/2013 12:39 AM, jgoodyear [via Karaf] wrote:
The concept of providing an RPM/Deb release option is perfectly fine
from my POV, this
According to my experience the start-level is set to
'karaf.startlevel.bundle' if not specify in the feature xml file.
Also, what is the shutdown sequence, just like start up, but going
backward from org.osgi.framework.startlevel.beginning to 0?
does the shutdown ensure each start-level
No problem, I just want to figure out what the state of things are so I
know if it's just me or if it's possible it doesn't build. If it's
possible it doesn't I can file a couple jiras with suggested fixes for
you. The is also an enhancement request to file along with the suggested
fixes.
Hi Gareth, Michael
As I expressed I have a quick fix which is dirty ATM. I'll clean it up and
upload a patch in JIRA.
To give you further details of what I have:
It can list gogo commands along with other karaf commands in help with
their descriptions those provided with @Descriptor annotation.
Hi
As stated in https://issues.apache.org/jira/browse/KARAF-1001 the attribute
name has been removed from the command/ in 3.x and the command name can
be only configured using the @Command annotation. Please remove the
attribute from your blueprint file.
Best regards
Krzysztof
--
View this
21 matches
Mail list logo
