While making the first steps with concierge, i stepped over this issue.

My bundles are in start order

-install ThirdPartyBndShaded.jar

-istart gemini-blueprint-core.jar
-istart gemini-blueprint-io.jar
-istart gemini-blueprint-extender.jar

The shaded jar is a lot of third party stuff shaded together with a valid osgi manifest auto generated with bnd. It includes also the springframework. Where the "SpringProperties" try to access an resource out of the class path. But that resource didn't exist. Which leads to the following error.

Jun 13, 2018 3:47:18 PM org.eclipse.gemini.blueprint.extender.internal.boot.ChainActivator <init>
INFORMATION: Blueprint API detected; enabling Blueprint Container functionality
Jun 13, 2018 3:47:18 PM org.eclipse.gemini.blueprint.extender.internal.activator.LoggingActivator start
INFORMATION: Starting [org.eclipse.gemini.blueprint.extender] bundle v.[3.0.0.M01]
Exception in thread "main" org.osgi.framework.BundleException: Error starting bundle [org.eclipse.gemini.blueprint.extender-3.0.0.M01]
        at org.eclipse.concierge.BundleImpl.activate0(BundleImpl.java:600)
        at org.eclipse.concierge.BundleImpl.activate(BundleImpl.java:552)
        at org.eclipse.concierge.BundleImpl.start(BundleImpl.java:506)
        at org.eclipse.concierge.BundleImpl.start(BundleImpl.java:444)
        at org.eclipse.concierge.compat.service.XargsFileLauncher.processXargsInputStream(XargsFileLauncher.java:183)
        at org.eclipse.concierge.compat.service.XargsFileLauncher.processXargsFile(XargsFileLauncher.java:83)
        at org.eclipse.concierge.Concierge.doMain(Concierge.java:606)
        at org.eclipse.concierge.Concierge.main(Concierge.java:525)
Caused by: java.lang.ExceptionInInitializerError
        at org.springframework.beans.CachedIntrospectionResults.<clinit>(CachedIntrospectionResults.java:98)
        at org.eclipse.gemini.blueprint.extender.internal.activator.JavaBeansCacheActivator.initJavaBeansCache(JavaBeansCacheActivator.java:62)
        at org.eclipse.gemini.blueprint.extender.internal.activator.JavaBeansCacheActivator.start(JavaBeansCacheActivator.java:44)
        at org.eclipse.gemini.blueprint.extender.internal.boot.ChainActivator.start(ChainActivator.java:93)
        at org.eclipse.concierge.BundleImpl.activate0(BundleImpl.java:575)
        ... 7 more
Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
        at org.eclipse.concierge.RFC1960Filter.stringCompare(RFC1960Filter.java:623)
        at org.eclipse.concierge.BundleImpl$Revision$BundleClassLoader.findResource1(BundleImpl.java:2774)
        at org.eclipse.concierge.BundleImpl$Revision$BundleClassLoader.findResource0(BundleImpl.java:2687)
        at org.eclipse.concierge.BundleImpl$Revision$BundleClassLoader.findResource(BundleImpl.java:2543)
        at org.eclipse.concierge.BundleImpl$Revision$BundleClassLoader.getResource(BundleImpl.java:2519)
        at org.springframework.core.SpringProperties.<clinit>(SpringProperties.java:61)
        ... 12 more

I just added an empty matching resource to the classpath and the problem is gone away.

I would love to provide a patch, but as i mentioned these are my first steps, so i can't actually. Hope someone can solve that issue.

Using OpenJDK 11 and the Eclipse SmartHome Packaging Sample the concierge framework will not start up. This is the log output:

Using java: java
openjdk version "11.0.1" 2018-10-16
OpenJDK Runtime Environment 18.9 (build 11.0.1+13)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.1+13, mixed mode)
JAVA_VERSION=1101
JAVA_COMPACT_PROFILE=fulljre
JAVA_VENDOR=Oracle
java.lang.NumberFormatException: For input string: ""
	at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
	at java.base/java.lang.Integer.parseInt(Integer.java:662)
	at java.base/java.lang.Integer.parseInt(Integer.java:770)
	at org.eclipse.concierge.Concierge.<init>(Concierge.java:665)
	at org.eclipse.concierge.Factory.newFramework(Factory.java:33)
	at org.eclipse.concierge.compat.service.XargsFileLauncher.processXargsInputStream(XargsFileLauncher.java:79)
	at org.eclipse.concierge.compat.service.XargsFileLauncher.processXargsFile(XargsFileLauncher.java:70)
	at org.eclipse.concierge.Concierge.doMain(Concierge.java:606)
	at org.eclipse.concierge.Concierge.main(Concierge.java:525)
---------------------------------------------------------
  Concierge OSGi 5.0.0 on Mac OS X 10.14 starting ... (eclipse-smarthome) startlevel=3
---------------------------------------------------------
---------------------------------------------------------
  Framework started in 0.0 seconds.
---------------------------------------------------------
Exception in thread "main" org.osgi.framework.BundleException: Resolution failed [BundleRequirement {osgi.ee; filter:=(&(osgi.ee=JavaSE)(version=1.5))}]
	at org.eclipse.concierge.Concierge.resolve(Concierge.java:2645)
	at org.eclipse.concierge.BundleImpl$Revision.resolve(BundleImpl.java:1881)
	at org.eclipse.concierge.BundleImpl.activate(BundleImpl.java:532)
	at org.eclipse.concierge.BundleImpl.start(BundleImpl.java:506)
	at org.eclipse.concierge.BundleImpl.start(BundleImpl.java:444)
	at org.eclipse.concierge.compat.service.XargsFileLauncher.processXargsInputStream(XargsFileLauncher.java:169)
	at org.eclipse.concierge.compat.service.XargsFileLauncher.processXargsFile(XargsFileLauncher.java:70)
	at org.eclipse.concierge.Concierge.doMain(Concierge.java:606)
	at org.eclipse.concierge.Concierge.main(Concierge.java:525)

Migrated from Eclipse Bugzilla #499055

Jochen Seeber 2016-08-02 11:35:07 EDT

Hi,

the Git repo does not contain any tagged versions, however, there are public releases. This really prevents us from using concierge, since we need reliable and repeatable builds.

Regards,
Jochen

Comment 1 Jan S. Rellermeyer 2016-08-02 11:37:49 EDT

Thanks for reminding me of this issue, I totally forgot. I created a local tag when we released but I could not get it pushed (I believe Gerrit was the problem) and I simply forgot to research further how to get it done.
I will do it now.

When I tried Concierge with own launcher I found out that BundleContext.getBundle(String) does not work correctly when the framework uses an existing storage.

Basically the scenario follows this pseudocode:

Framework framework = factory.newFramework(properties); // Here the path to the storage is set
framework.init();
BundleContext systemBundle = framework.getBundleContext();
Bundle bundle = systemBundle.getBundle(location);
if (bundle == null) {
    try (InputStream is = open(location)) {
        bundle = systemBundle.installBundle(location, is);
    }
}

The bundle variable is always null, while it should return the installed bundle when the code is run second time with the same storage. I tried replacing getBundle with something like:

Bundle bundle = Stream.of(systemBundle.getBundles())
    .filter(b -> location.equals(b.getLocation())
    .findAny()
    .orElse(null);

And this always works. So the framework apparently knows which bundles were installed, it just does not update its structures for getBundle to work properly.

The described behavior of getBundle in this use case results in duplicated installation of the bundle – and what is even more interesting: the newly installed bundle has the same location as the existing bundle. I believe this is wrong as well and the location should be unique. Maybe the framework implementation fails to check the location duplicity for the same reason.

• What does this library do
• How can I find the docs and binaries
• Quickstart
• How do I contribute

I have confirmed that the exception is still there with the latest Concierge snapshot that I could find - 5.1.0.SNAPSHOT-20180523024817.

The scenario is following:

• I trigger uninstallation of OSGi Deployment Package;
• Bundle Tracker is notified about the removed bundle and checks if the bundle is a fragment;
• NullPointerException occurs.

The test-ext deployment package contains a single bundle, which is not a fragment.

Logs:

Concierge> 13:28:56.638 ERROR org.eclipse.kura.deployment.agent.impl.DeploymentAgent[:360] - Exception uninstalling package test-ext
java.lang.NullPointerException: null
	at org.eclipse.concierge.compat.packageadmin.PackageAdminImpl.isFragment(PackageAdminImpl.java:374)
	at org.eclipse.concierge.compat.packageadmin.PackageAdminImpl.getBundleType(PackageAdminImpl.java:370)
	at org.eclipse.smarthome.core.internal.i18n.ResourceBundleTracker.isFragmentBundle(ResourceBundleTracker.java:144)
	at org.eclipse.smarthome.core.internal.i18n.ResourceBundleTracker.removedBundle(ResourceBundleTracker.java:85)
	at org.osgi.util.tracker.BundleTracker$Tracked.customizerRemoved(BundleTracker.java:491)
	at org.osgi.util.tracker.BundleTracker$Tracked.customizerRemoved(BundleTracker.java:414)
	at org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341)
	at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:449)
	at org.eclipse.concierge.Concierge.notifyBundleListeners(Concierge.java:3697)
	at org.eclipse.concierge.Concierge.notifyBundleListeners(Concierge.java:3632)
	at org.eclipse.concierge.BundleImpl.uninstall(BundleImpl.java:780)
	at org.apache.felix.deploymentadmin.spi.DropAllBundlesCommand.execute(DropAllBundlesCommand.java:48)
	at org.apache.felix.deploymentadmin.spi.DeploymentSessionImpl.call(DeploymentSessionImpl.java:73)
	at org.apache.felix.deploymentadmin.DeploymentAdminImpl.uninstallDeploymentPackage(DeploymentAdminImpl.java:352)
	at org.apache.felix.deploymentadmin.AbstractDeploymentPackage.uninstall(AbstractDeploymentPackage.java:296)
	at org.eclipse.kura.deployment.agent.impl.DeploymentAgent.uninstaller(DeploymentAgent.java:347)
	at org.eclipse.kura.deployment.agent.impl.DeploymentAgent.lambda$1(DeploymentAgent.java:178)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

If I understand correctly expected result is int or IllegalArgumentException - https://osgi.org/javadoc/r5/core/org/osgi/service/packageadmin/PackageAdmin.html#getBundleType(org.osgi.framework.Bundle)

I would really appreciate your assistance with this issue, please let me know if you need additional information.

An user running Concierge on Skelmir CEE-J reports:

In this.getClass().getClassLoader().loadClass("org.w3c.dom.Document") CEE-J returns null on this.getClass().getClassLoader() which results in a NPE when loading class

See code at https://github.com/eclipse/concierge/blob/59ba0eb4d2c7a347bb3f084ae3524b4595585346/framework/org.eclipse.concierge/src/org/eclipse/concierge/Concierge.java#L699

I checked the Java spec on that: https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getClassLoader--

public ClassLoader getClassLoader()
Returns the class loader for the class. Some implementations may use null to represent the bootstrap class loader. This method will return null in such implementations if this class was loaded by the bootstrap class loader.

So according to spec, this seems to be valid if the JVM returns null on getClassLoader(), in case the current class has been loaded by the bootstrap class loader.

At Wolfgang: what is your proposal to do that in CEE-J ? Purpose is to get on Java 8 the compact profile where the JVM is running on.

We have to publish our releases (R5) to common used maven repositories, e.g. maven central.
Requested by the community and needed for integration in other projects

Hi!

I am running Concierge 5.1.0 and have an Import-Package dependency in my bundle to

org.osgi.framework.wiring;version="[1.2,2)"

and get a Resolution failed Exception. Is something wrong with this version number? This is the version exported by the system bundle.

CU
Thomas

Migrated from Eclipse Bugzilla #481680

Jochen Hiller 2015-11-09 02:51:11 EST

How to reproduce:

• use latest SNAPSHOT release from http://download.eclipse.org/concierge/snapshots/concierge-incubation-SNAPSHOT-latest.zip
• start equinox-console sample
  java -jar framework/org.eclipse.concierge-5.1.0.SNAPSHOT-20151108155258.jar samples/equinox-console.xargs
• all does work, Equinox console can be used (e.g. use "ss" command)
• exit framework
• start again with
  java -jar framework/org.eclipse.concierge-5.1.0.SNAPSHOT-20151108155258.jar samples/equinox-console.xargs
• previous storage named "equinox-console" will be reused
• equinox-console bundle can not be started (stays in INSTALLED state). see console output

java -jar framework/org.eclipse.concierge-5.1.0.SNAPSHOT-20151108155258.jar samples/equinox-console.xargs
RESTORED BUNDLE [org.apache.felix.configadmin-1.8.8] WITH SL 1 and autostart 2
RESTORED BUNDLE [org.eclipse.equinox.console-1.1.100.v20141023-1406] WITH SL 1 and autostart 2
RESTORED BUNDLE [org.eclipse.equinox.util-1.0.500.v20130404-1337] WITH SL 1 and autostart 2
RESTORED BUNDLE [org.eclipse.equinox.supplement-1.6.0.v20141009-1504] WITH SL 1 and autostart 2
RESTORED BUNDLE [org.eclipse.equinox.common-3.7.0.v20150402-1709] WITH SL 1 and autostart 2
RESTORED BUNDLE [org.apache.felix.gogo.runtime-0.10.0.v201209301036] WITH SL 1 and autostart 2
RESTORED BUNDLE [org.eclipse.concierge.service.packageadmin-5.1.0.SNAPSHOT-20151108155258] WITH SL 1 and autostart 2
RESTORED BUNDLE [org.apache.felix.gogo.command-0.10.0.v201209301215] WITH SL 1 and autostart 2
RESTORED BUNDLE [org.apache.felix.gogo.shell-0.10.0.v201212101605] WITH SL 1 and autostart 2
RESTORED BUNDLE [org.eclipse.concierge.extension.permission-5.1.0.SNAPSHOT-20151108155258] WITH SL 1 and autostart 0
Concierge OSGi 5.1.0.SNAPSHOT-20151108155258 on Mac OS X 10.10.5 starting ... (equinox-console) startlevel=3
org.osgi.framework.BundleException: Resolution failed [BundleRequirement{Import-Package org.osgi.service.condpermadmin}, BundleRequirement{Import-Package org.osgi.service.permissionadmin}]
at org.eclipse.concierge.Concierge.resolve(Concierge.java:2645)
at org.eclipse.concierge.BundleImpl$Revision.resolve(BundleImpl.java:1881)
at org.eclipse.concierge.BundleImpl.activate(BundleImpl.java:532)
at org.eclipse.concierge.Concierge.setLevel(Concierge.java:1936)
at org.eclipse.concierge.Concierge.start(Concierge.java:1359)
at org.eclipse.concierge.compat.service.XargsFileLauncher.processXargsInputStream(XargsFileLauncher.java:88)
at org.eclipse.concierge.compat.service.XargsFileLauncher.processXargsFile(XargsFileLauncher.java:72)
at org.eclipse.concierge.Concierge.doMain(Concierge.java:606)
at org.eclipse.concierge.Concierge.main(Concierge.java:525)
Framework restarted in 0.24 seconds.
osgi>

• I checked the storage are, looks good

Any idea?

Comment 1 Jochen Hiller 2015-11-09 11:27:44 EST

Added test case to reproduce that issue:
http://git.eclipse.org/c/concierge/org.eclipse.concierge.git/tree/org.eclipse.concierge/test/org/eclipse/concierge/BundlesWithFrameworkExtensionsTest.java#n82

Migrated from Eclipse Bugzilla #475432

Jan S. Rellermeyer 2015-08-20 00:20:01 EDT

Concierge should provide an implementation of the URLHandlers service.

https://github.com/eclipse/concierge/search?q=EXPORT_SERVICE&unscoped_q=EXPORT_SERVICE

Hey, I probably have missed something obvious, but what am I doing wrong here?

`D:_osgi\concierge-incubation-6.0.0.SNAPSHOT.tar\concierge-incubation-6.0.0.SNAPSHOT\concierge-incubation-6.0.0.SNAPSHOT>java -jar framework/org.eclipse.concierge-6.0.0.SNAPSHOT.jar samples/default.xargs

Exception in thread "main" org.osgi.framework.BundleException: Illegal attribute name ";java.vm.version="25.131-b11";org.osgi.supports.framework.fragment="true";user.variant="";java.awt.printerjob="sun.awt.windows.WPrinterJob";sun.io.unicode.encoding="UnicodeLittle";org.osgi.framework.version="1.5.0";org.osgi.framework.storage="storage";awt.toolkit="sun.awt.windows.WToolkit";sun.stdout.encoding="cp437";org.osgi.framework.bundle.parent="boot";user.script="";org.osgi.supports.bootclasspath.extension="false";user.home="C:\Users\valkov";java.specification.vendor="Oracle Corporation";java.library.path="C:\jdk1.8.0_131c1\bin
at org.eclipse.concierge.Utils.parseLiterals(Utils.java:162)
at org.eclipse.concierge.Resources$GenericReqCap.(Resources.java:74)
at org.eclipse.concierge.Resources$BundleCapabilityImpl.(Resources.java:138)
at org.eclipse.concierge.Concierge.init(Concierge.java:1316)
at org.eclipse.concierge.Concierge.init(Concierge.java:1120)
at org.eclipse.concierge.compat.service.XargsFileLauncher.processXargsInputStream(XargsFileLauncher.java:94)
at org.eclipse.concierge.compat.service.XargsFileLauncher.processXargsFile(XargsFileLauncher.java:83)
at org.eclipse.concierge.Concierge.doMain(Concierge.java:617)
at org.eclipse.concierge.Concierge.main(Concierge.java:536)
`

It seems that something is wrong with my passing of properties.
Thanks!

Migrated from Eclipse Bugzilla #493251

Simon Kaufmann 2016-05-09 10:58:54 EDT

When adding a BundleListener to the "framework bundle", this works nicely:

concierge.getBundleContext().addBundleListener(this);

However, removing it again does not work:

concierge.getBundleContext().removeBundleListener(this);

The reason clearly is the following in Concierge.BundleContextImpl.removeBundleListener():

if (bundle == Concierge.this) {
    return;
}

Maybe it's in there for a good reason, but I'm not sure if this asymmetry actually is intended.

Migrated from Eclipse Bugzilla #480566

Jochen Hiller 2015-10-24 07:12:43 EDT

We have yet some integration tests in Concierge (see http://git.eclipse.org/c/concierge/org.eclipse.concierge.git/tree/org.eclipse.concierge.tests.integration).
These tests are built on a "proprietary" solution to download and install bundles from online URLs, like Apache Felix, Eclipse Orbit and others.

A similar solution will be provided by the pax-exam project (see https://ops4j1.jira.com/wiki/display/PAXEXAM4/Pax+Exam, latest version 4.x).
This framework will allow easy writing test cases installing bundles from different sources (maven, p2 repo, local URLs, ...). It also allows to run tests against different OSGi frameworks, so same tests could also be applied to Equinox, Felix, to check about same or different behavior.
The pax-exam OSGi container integration tests requires minimum OSGi R4.3 and does support the Launcher API, so it should work out-of-the-box even with Concierge.

The problem:
pax-exam is not yet in Orbit. It is hosted in Maven central at http://mvnrepository.com/artifact/org.ops4j.pax.exam
Pax-exam is heavily based on other op4j projects, like ops4j base, pax-url, pax-links, ...

As these jars are only used for regression testing, that is a test-only dependency.

What do you think? Does it makes sense to invest time on getting that running, or does the license problem is a show-stopper?

I am referring to:

https://github.com/eclipse/concierge/blob/9399f771aa6b327612e45ce277c793929c1bbc2b/framework/org.eclipse.concierge/src/org/eclipse/concierge/Concierge.java#L149

It is more interesting how this affects the displayed bundle version:

You can imagine how difficult was to find where this "snapshot" version came from, as it is not available in any repository... :-)

Migrated from Eclipse Bugzilla #478371

Jan S. Rellermeyer 2015-09-24 21:59:09 EDT

It would be great to have a launcher plugin for the Eclipse IDE so that people could run Concierge within the IDE.

I briefly looked into that and it seems like that it mainly requires to implement a org.eclipse.pde.launching.AbstractPDELaunchConfigurationand to locate bundles and package them up for the framework (which is possibly the harder part).

Migrated from Eclipse Bugzilla #477412

Jan S. Rellermeyer 2015-09-14 22:38:33 EDT

We would like to have one or more cool demos that illustrate the value of Concierge on embedded devices and through IoT applications.

Hi guys,

I just noticed that a couple of your links on the website result in a 404:

• "Downloads" in the top menu: https://projects.eclipse.org/projects/rt.concierge/downloads
• "OSGi R5" in the last paragraph: https://www.osgi.org/Release5/HomePage

When multiple threads invoke Framework.waitForStop(), only one of them gets unblocked. I suppose that Concierge.stop0(boolean) should call notifyAll() instead of just notify() and it would be better to invoke it in finally to make sure that it would be executed always.

When calling installBundle(String location, InputStream in) with a null InputStream we fail with a NullPointerException.

However, the spec says:

The InputStream object from which this bundle will be read or null to indicate the Framework must
create the input stream from the specified location identifier. The input stream must always be
closed when this method completes, even if an exception is thrown

Goog morning.
I'm experiencing a peculiar failure:
A "meta" file inside storage/default/[bundle id]/ has gone corrupted (zero length).
"Concierge" class catchs EOFException and print the stack trace but do not take any action to perform a "clean start" and don't send the exception up in the class calling chain.
So for the calling program there is no way to handle the problem.

Here below the stack trace:

java.io.EOFException
at java.base/java.io.DataInputStream.readInt(Unknown Source)
at org.eclipse.concierge.BundleImpl.(BundleImpl.java:252)
at org.eclipse.concierge.Concierge.restoreProfile(Concierge.java:1517)
at org.eclipse.concierge.Concierge.init(Concierge.java:1330)
at org.myorg.ACallingClass .....

Thanks

Latest snapshots of Eclipse Concierge are not available in http://download.eclipse.org/concierge/download/snapshots/?d.

Last successful build is from 2018 05 23.

Migrated from - #59 (comment)

Migrated from Eclipse Bugzilla #475419

Jan S. Rellermeyer 2015-08-19 15:17:24 EDT

Concierge can be used as a standalone resolver (it registers itself as a resolver service) and as such should pass the entire R5 resolver TCK.

Comment 1 Jan S. Rellermeyer 2015-09-19 02:47:44 EDT

Three test cases remaining. One of them seems to have a problem.
Unfortunately, I wrote the TCK...

on start a bündle with a lost dependent bündle i have a NullPointerException and not a BundleException

excample:

Concierge > start 6
java.lang.NullPointerException
        at org.eclipse.concierge.Concierge$CapabilityRegistry.getByValue(Concierge.java:5032)
        at org.eclipse.concierge.RFC1960Filter.filterWithIndex(RFC1960Filter.java:1147)
        at org.eclipse.concierge.Concierge$10.findProviders(Concierge.java:2488)
        at org.eclipse.concierge.Concierge$ResolverImpl.resolveResource(Concierge.java:3025)
        at org.eclipse.concierge.Concierge$ResolverImpl.resolveResource(Concierge.java:3199)
        at org.eclipse.concierge.Concierge$ResolverImpl.resolveResource(Concierge.java:3199)
        at org.eclipse.concierge.Concierge$ResolverImpl.resolveResource(Concierge.java:3199)
        at org.eclipse.concierge.Concierge$ResolverImpl.resolve0(Concierge.java:2836)
...

the bug i have found on class Concierge.CapatibilityRegistry (Package org.eclipse.concierge) on method getByValue() (line 5032 on version 5.0.0, but also on version 5.1.0):
final List<Capability> result = attributeIndex.get(value);
fixed:
final List<Capability> result = attributeIndex == null ? null : attributeIndex.get(value);
with the fixed code, i have correct Exception:

Concierge > start 6
org.osgi.framework.BundleException: Resolution failed [BundleRequirement{Import-Package org.osgi.service.event;version="[1.2,2)"}, BundleRequirement{Import-Pack
age org.osgi.service.cm;version="1.2.0"}]
        at org.eclipse.concierge.Concierge.resolve(Concierge.java:2648)
        at org.eclipse.concierge.BundleImpl$Revision.resolve(BundleImpl.java:1881)
        at org.eclipse.concierge.BundleImpl.activate(BundleImpl.java:532)
....

pleace fixing on code :-)

An user running Concierge on Skelmir CEE-J reports:

The org.eclipse.concierge.Concierge constructor calls System.getProperty(“java.specification.name”). With CEE-J this system property is not defined which causes a NullPointerException and failure to start.

See code at https://github.com/eclipse/concierge/blob/59ba0eb4d2c7a347bb3f084ae3524b4595585346/framework/org.eclipse.concierge/src/org/eclipse/concierge/Concierge.java#L680

We can use a default value for the property of "" so we assume it is NOT a J2ME VM by default, and try to get execution environment base on java.specification.version

Migrated from Eclipse Bugzilla #480052

Jan S. Rellermeyer 2015-10-17 16:11:12 EDT

The "old Concierge" had a nice, minimal EventAdmin service implementation. We should implement the most recent version of this specification for Concierge since it is a functionality that is useful for many applications, especially in combination with R-OSGi.

The build from latest commit 5657c3c does fail with 3 failed tests:

org.eclipse.concierge.MultiMapTest > testOrder FAILED
    java.lang.AssertionError at MultiMapTest.java:52
org.eclipse.concierge.ConciergeMainOptionAllTest > testAllWithSortedBundles FAILED
    org.osgi.framework.BundleException at ConciergeMainOptionAllTest.java:118
org.eclipse.concierge.ConciergeMainOptionAllTest > testUnsortedBundles FAILED
    org.osgi.framework.BundleException at ConciergeMainOptionAllTest.java:137

We want to add Concierge as supported OSGi framework to pax-exam.
It should be working out-of-the-box, but at least confirm that it is running, and extend ops4j documentation that and how it can be used and configured

When asking a bundle for its contained resources via bundle.adapt(BundleWiring.class).listResources(...), the content of embedded JARs is not considered.

I have to admit that so far I couldn't spot anything in the OSGi specs which explicitly states that it should do so - I merely noticed that this works on equinox. I have a corresponding test case in sjka/concierge@testListResources.

I'd be happy if any of you experts could have a quick look and advise on this.

I am trying to run Californium on Concierge in Bndtools. It does not work because io.netty.handler has several Import-Package requirements to Java system packages.

! Failed to start bundle io.netty.handler-4.1.9.Final, exception Resolution failed [BundleRequirement{Import-Package javax.crypto}, BundleRequirement{Import-Package javax.crypto.spec}, BundleRequirement{Import-Package javax.net.ssl}, BundleRequirement{Import-Package javax.security.auth.x500}, BundleRequirement{Import-Package javax.security.cert}]

I learned about the org.osgi.framework.system.packages.extra and that I need to specify the javax packages this way. But using Bndtools I am somehow not able to specify that property in a way that it gets used. I tried adding it to the OSGi Framework Properties, Launcher Arguments and JVM Arguments. But none seems to fit.

Is this an issue in Bndtools or am I making something wrong?

I manually created a runtime with the necessary bundles and created an .xargs file with the following content

# specify additional system packages to load
-Dorg.osgi.framework.system.packages.extra+=javax.crypto,
-Dorg.osgi.framework.system.packages.extra+=javax.crypto.spec,
-Dorg.osgi.framework.system.packages.extra+=javax.net.ssl,
-Dorg.osgi.framework.system.packages.extra+=javax.security.auth.x500,
-Dorg.osgi.framework.system.packages.extra+=javax.security.cert,

# install and start all .jar files in bundles directory
-all bundles

which actually works.

Migrated from Eclipse Bugzilla #480172

Scott Lewis 2015-10-19 23:15:44 EDT

I have a bundle that uses javax.xml.parsers and org.xml.sax packages for xml parsing. It refuses to resolve on Concierge RC1 with the following exception:

Concierge> Exception in thread "main" org.osgi.framework.BundleException: Resolution failed [BundleRequirement{Import-Package javax.xml.parsers}]
at org.eclipse.concierge.Concierge.resolve(Concierge.java:2645)
at org.eclipse.concierge.BundleImpl$Revision.resolve(BundleImpl.java:188
1)
at org.eclipse.concierge.BundleImpl.activate(BundleImpl.java:532)
at org.eclipse.concierge.BundleImpl.start(BundleImpl.java:506)
at org.eclipse.concierge.BundleImpl.start(BundleImpl.java:444)
at org.eclipse.concierge.compat.service.XargsFileLauncher.processXargsInputStream(XargsFileLauncher.java:167)
at org.eclipse.concierge.compat.service.XargsFileLauncher.processXargsFile(XargsFileLauncher.java:68)
at org.eclipse.concierge.Concierge.doMain(Concierge.java:606)
at org.eclipse.concierge.Concierge.main(Concierge.java:525)

BTW, it would be very nice if this resolution exception were to also report the bundle that was being resolved.

javax.xml.parsers is part of the underlying VM and I believe exposed by including "javax.*" for the Constants.FRAMEWORK_BOOTDELEGATION property.

For example, Equinox seems to have this as the default:

org.osgi.framework.bootdelegation =
javax.,
org.ietf.jgss,
org.omg.,
org.w3c.,
org.xml.,
sun.,
com.sun.

Concierge seems to currently have this as it's boot delegation set:

  defaultProperties.setProperty(Constants.FRAMEWORK_BOOTDELEGATION,
          "java.*, sun.*, com.sun.*");

Would it be possible to add javax., and org.xml. to the Concierge default boot delegation? Or perhaps allow org.osgi.framework.bootdelegation to be somehow be configured to include these packages?

Here's what I would believe would do it for my use case:

  defaultProperties.setProperty(Constants.FRAMEWORK_BOOTDELEGATION,
          "java.*, sun.*, com.sun.*, javax.*, org.xml.*");

It's quite possible that org.w3c.* and org.omg.* should also be added, but I don't need them for my use case.

Thanks.

Comment 1 Jan S. Rellermeyer 2015-10-19 23:59:03 EDT

What you want is not boot delegation. However, this is a common misunderstanding. Boot delegation describes which packages are "silently" delegated to the parent classloader of the one that loaded the framework. This does not affect bundle resolution but only bundle classloaders trying to access specific classes without having an explicit import for the corresponding package.

The functionality that you are looking for is org.osgi.framework.system.packages (or, since you want to extend the default and not overwrite it, org.osgi.framework.system.packages.extra). This way you can tell Concierge which other packages you would like to be exported by the system bundle so that other bundles get resolved against them.

It is correct that Equinox has a different behavior since, if I remember correctly, it probes the JVM version and, with the help of internally stored profiles, exports a larger set of packages through the system bundle. We currently don't do that due to the overhead but I think the standard only asks for "reasonable defaults" so I would say what we do is sufficient and extra packages can always be configured.

Comment 2 Scott Lewis 2015-10-20 10:45:22 EDT (In reply to Jan S. Rellermeyer from comment #1)

It is correct that Equinox has a different behavior since, if I remember
correctly, it probes the JVM version and, with the help of internally stored
profiles, exports a larger set of packages through the system bundle. We
currently don't do that due to the overhead but I think the standard only
asks for "reasonable defaults" so I would say what we do is sufficient and
extra packages can always be configured.

But you do set sun.* and com.sun.*? Isn't that overhead too? Why would internal packages be preferred to something like xml processing (pretty common, no?)

In any event, I suppose you can choose whether boot delegation or system.packages...just some way is needed to add these packages. Is org.osgi.framework.system.packages.extra supported now?

Comment 3 Jan S. Rellermeyer 2015-10-20 11:15:21 EDT

But you do set sun.* and com.sun.*? Isn't that overhead too? Why would
internal packages be preferred to something like xml processing (pretty
common, no?)

You need these packages in the bootdelegation because some classes from java.* internally rely on them. They basically break if you don't delegate.

The overhead that I was talking about is not the delegation itself but keeping the "positive lists" of packages that can be exported on certain JVMs/versions.

In any event, I suppose you can choose whether boot delegation or
system.packages...just some way is needed to add these packages.

Well, as I said, the two options serve different purposes. If you application breaks at runtime because of ClassNotFound, you need bootdelegation. If it fails during resolve time because of a package that comes from the JVM, you need the system packages.

Is
org.osgi.framework.system.packages.extra supported now?

Yes, fully supported. I think the ".extra" version was introduced in one of the later R4s but this is the much more convenient way because you don't need to override the defaults.

Comment 4 Scott Lewis 2015-10-20 12:37:03 EDT

For sake of the Concierge's adoption, I suggest that you document as loudly as possible, and provide instructions WRT use of system.packages.*. Actually, it wouldn't hurt to provide examples and alternative startup configs.

Comment 5 Scott Lewis 2015-10-24 14:52:48 EDT

FWIW, I've been able to add o.o.f.s.packages.extra=javax.xml.parser,org.xml.sax and start/satisfy all of ECF RSA on Concierge RC1. I'll now attempt to run some simple Remote Services/RSA examples on various target platforms (e.g. raspberry pi) with one or more of the existing ECF providers (e.g. r-osgi, generic, jax-rs).

I would appreciate any documentation you might have on getting concierge to run properly on some recent version (hopefully) of Android. Note that since Proxy.newProxyInstance seems to be implemented/functioning on recent Android versions, most of the distribution providers should be able to create proxies. Since rosgi uses asm I expect there may be some additions or changes needed (although perhaps not).

Also FWIW, the RSA codebase (including one distribution provider) is < 1M of code (debug-enabled). There is some shrinking/refactoring that could occur to reduce that, and I will look into doing that.

Migrated from Eclipse Bugzilla #485642

Tim Verbelen 2016-01-12 07:02:10 EST

There is still some fixing to do in the checkConflicts method when attaching a fragment. Some rules are still commented out regarding TCK regressions.

The issue can be found in BundleImpl r2357-2378. Possibly this also involves some of our Junit tests involving Fragments failing?

We want to add Concierge as supported OSGi framework to pax-runner.
It should be working out-of-the-box, but at least confirm that it is running, and extend ops4j documentation that and how it can be used and configured

Migrated from Eclipse Bugzilla #475520

Jan S. Rellermeyer 2015-08-20 13:57:14 EDT

Add the REST service and Java REST client to Concierge as optional bundles.

Comment 1 Jan S. Rellermeyer 2015-09-19 01:28:36 EDT

awaiting decision on https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10150
Also requires https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10152 and https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10153
Moving to RC1.

Comment 2 Jan S. Rellermeyer 2015-10-20 00:27:52 EDT

Not in 5.0.0 release timeframe anymore.

We can do a 5.1 release that includes REST.

Migrated from Eclipse Bugzilla #481659

Jochen Hiller 2015-11-08 04:56:42 EST

When fixing https://bugs.eclipse.org/bugs/show_bug.cgi?id=481650 I added test cases with more start level options.

One test case fails if bundles with start levels of 10, 20, 30 will be installed. But these bundles could not be started, they simple ignore bundle.start().
See test case at http://git.eclipse.org/c/concierge/org.eclipse.concierge.git/tree/org.eclipse.concierge/test/org/eclipse/concierge/compat/service/XargsFileLauncherXargsTest.java#n140

I saw that this will happen since using a start level of 4.

Migrated from Eclipse Bugzilla #476071

Jan S. Rellermeyer 2015-08-27 15:09:09 EDT

Implement the OSGi Coordinator service specification (see the specs and https://osgi.org/javadoc/r6/enterprise/org/osgi/service/coordinator/package-summary.html) in a lightweight way.

We want to add Concierge as supported OSGi framework to Apache Karaf.
If this is working, openHAB2 can be considered as an option to use Karaf / Concierge as underlying OSGi framework

Migrated from Eclipse Bugzilla #477413

Jan S. Rellermeyer 2015-09-14 22:42:21 EDT

Many people use Pi4J in order to access low-level system capabilities of the Raspberry Pi platform. However, this library is neither very well designed, nor under a particularly pleasant license.
It would be great to have a Concierge bundle that would expose Raspberry Pi capabilities as OSGi services and without relying on Pi4J.

Hello,
I ran the Concierge runtime and I have great impressions from the startup time of the framework, I really appreciate your efforts on the project !

I have already started most of the Eclipse Kura bundles in the runtime and everything looked good until I faced a strange issue. I saw that @JochenHiller already made some tests running Kura, so maybe you can help me to understand the cause a little bit better.

The setup that I have is:

# Concierge services
-istart ${concierge.dir}/org.eclipse.concierge.service.packageadmin-${concierge.version}*.jar
-istart ${concierge.dir}/org.eclipse.concierge.service.startlevel-${concierge.version}*.jar
-istart ${concierge.dir}/org.eclipse.concierge.service.xmlparser-${concierge.version}*.jar

# OSGi Services
....
# Dependencies
...
# Start Kura Core bundles
-istart ${system.dir}/org.eclipse.kura.api-*.jar

-install ${system.dir}/org.eclipse.kura.localization.resources-*.jar  //This is a fragment bundle
-istart ${system.dir}/org.eclipse.kura.localization-*.jar                   //This is a host bundle

....
-istart ${system.dir}/org.eclipse.kura.wire.helper.provider-*.jar     //This is the caller who calls the host bundle 

The situation is the following - while org.eclipse.kura.internal.wire.helper.WireHelperServiceImpl is being registered the following exception is being logged on the console.

error-message.txt

I have attached a remote debugger and traced the cause of the NullPointerException that you see in the log above to a ClassLoader.getPackage(String name) returning null for a package in the fragment bundle.

I tried several things with different start levels, but I did not get far with them.

I feel a bit lost what can I do further, could you please give me some hints ?

Migrated from Eclipse Bugzilla #485749

Stef Boerrigter 2016-01-13 08:15:47 EST

We are building concierge here with 3 persons on different machines, and see that it compiles completely on 1 pc, the others have JUnit test failures on "testBundleNativeCodeMacOSX_X86_64_WithSelectionFilter" that cannot be reproduced on other machines.
another error seems to be the testBundleWithBadImports test.
it sometimes Failes and when we rebuild it is Succes or failure
(also dependant on what machine).
All 3 these machines have the same OS (Ubuntu 14.04 with same configuration) and we use Yocto to build our concierge (on OpenJDK-8)

Comment 1 Stef Boerrigter 2016-01-13 08:16:50 EST

Created attachment 259156 [details]
compile log
attached is the compile log.
log.do_compile.20625.txt

When running Eclipse SmartHome packaging sample (https://github.com/eclipse/smarthome-packaging-sample) using Concierge 5.1 with JDK11, it will complain when installing bundle "slf4j-jdk14-1.7.22.jar with this message:

Concierge> Exception in thread "main" org.osgi.framework.BundleException: Framework does not support extensions
	at org.eclipse.concierge.compat.service.BundleManifestTwo.processManifest(BundleManifestTwo.java:227)
	at org.eclipse.concierge.BundleImpl$Revision.<init>(BundleImpl.java:1579)
	at org.eclipse.concierge.BundleImpl$JarBundleRevision.<init>(BundleImpl.java:3587)
	at org.eclipse.concierge.BundleImpl.readAndProcessInputStream(BundleImpl.java:395)
	at org.eclipse.concierge.BundleImpl.<init>(BundleImpl.java:225)
	at org.eclipse.concierge.Concierge.installNewBundle(Concierge.java:4078)
	at org.eclipse.concierge.Concierge.installNewBundle(Concierge.java:4041)
	at org.eclipse.concierge.Concierge$BundleContextImpl.installBundle(Concierge.java:4662)
	at org.eclipse.concierge.compat.service.XargsFileLauncher.processXargsInputStream(XargsFileLauncher.java:189)
	at org.eclipse.concierge.compat.service.XargsFileLauncher.processXargsFile(XargsFileLauncher.java:83)
	at org.eclipse.concierge.Concierge.doMain(Concierge.java:606)
	at org.eclipse.concierge.Concierge.main(Concierge.java:525)

The check if JVM supports extensions in https://github.com/eclipse/concierge/blob/master/framework/org.eclipse.concierge/src/org/eclipse/concierge/Concierge.java#L927 seems not to work in JDK11.

An user running Concierge on Skelmir CEE-J reports:

Code within “org.eclipse.concierge.service.xmlparser-${concierge.version}*.jar” seems to reference “com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl”

We assume in that xmlparser bundle that the used XML parsers are from OpenJDK.
We might consider to name this bundle org.eclipse.concierge.service.xmlparser.openjdk to indicate that.
An user of CEE-J can have its own adapter bundle which adds the CEE-J specific factory classes.

In r6 branch one test fails checking about optional Bundle-NativeHeader statements.
I saw that the test case is wrong, optional ("*") has to be separated with a comma (",") from the other directives.

Resolving bundles within a bundle tracker apparently leads to a deadlock on the main thread:

"main" #1 prio=5 os_prio=31 tid=0x00007fe20b006800 nid=0x1b03 waiting on condition [0x000070000fd7c000]
   java.lang.Thread.State: TIMED_WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x0000000779608320> (a java.util.concurrent.CountDownLatch$Sync)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
	at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
	at org.apache.felix.scr.impl.Activator$ScrExtension.destroy(Activator.java:193)
	at org.apache.felix.utils.extender.AbstractExtender$2.run(AbstractExtender.java:290)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at org.apache.felix.utils.extender.AbstractExtender.destroyExtension(AbstractExtender.java:312)
	at org.apache.felix.utils.extender.AbstractExtender.bundleChanged(AbstractExtender.java:186)
	at org.eclipse.concierge.Concierge.notifyBundleListeners(Concierge.java:3685)
	at org.eclipse.concierge.Concierge.notifyBundleListeners(Concierge.java:3620)
	at org.eclipse.concierge.BundleImpl$Revision.markResolved(BundleImpl.java:2133)
	at org.eclipse.concierge.Concierge$ResolverImpl.resolveResource(Concierge.java:3291)
	at org.eclipse.concierge.Concierge$ResolverImpl.resolve0(Concierge.java:2879)
	at org.eclipse.concierge.Concierge.resolve(Concierge.java:2509)
	- locked <0x00000006c032ed78> (a org.eclipse.concierge.Concierge)
	at org.eclipse.concierge.Concierge.resolveBundles(Concierge.java:2272)
	at org.eclipse.concierge.compat.packageadmin.PackageAdminImpl.resolveBundles(PackageAdminImpl.java:223)
	at org.eclipse.smarthome.automation.internal.core.provider.HostFragmentMappingUtil.fillHostFragmentMapping(HostFragmentMappingUtil.java:70)
	at org.eclipse.smarthome.automation.internal.core.provider.AutomationResourceBundlesTracker.addingBundle(AutomationResourceBundlesTracker.java:187)
	at org.eclipse.smarthome.automation.internal.core.provider.AutomationResourceBundlesTracker.addingBundle(AutomationResourceBundlesTracker.java:1)
	at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:467)
	at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:414)
	at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
	at org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:183)
	at org.osgi.util.tracker.BundleTracker.open(BundleTracker.java:156)
	at org.eclipse.smarthome.automation.internal.core.provider.AutomationResourceBundlesTracker.activate(AutomationResourceBundlesTracker.java:78)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:231)
	at org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:39)
	at org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:624)
	at org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:508)
	at org.apache.felix.scr.impl.helper.ActivateMethod.invoke(ActivateMethod.java:149)
	at org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject(SingleComponentManager.java:315)
	at org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent(SingleComponentManager.java:127)
	at org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:871)
	at org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:838)
	at org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:850)
	at org.apache.felix.scr.impl.manager.AbstractComponentManager.enable(AbstractComponentManager.java:419)
	at org.apache.felix.scr.impl.config.ConfigurableComponentHolder.enableComponents(ConfigurableComponentHolder.java:376)
	at org.apache.felix.scr.impl.BundleComponentActivator.initialize(BundleComponentActivator.java:172)
	at org.apache.felix.scr.impl.BundleComponentActivator.<init>(BundleComponentActivator.java:120)
	at org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:258)
	at org.apache.felix.scr.impl.Activator.access$000(Activator.java:45)
	at org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:185)
	at org.apache.felix.utils.extender.AbstractExtender.createExtension(AbstractExtender.java:259)
	at org.apache.felix.utils.extender.AbstractExtender.modifiedBundle(AbstractExtender.java:232)
	at org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:479)
	at org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:414)
	at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:232)
	at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:443)
	at org.eclipse.concierge.Concierge.notifyBundleListeners(Concierge.java:3685)
	at org.eclipse.concierge.Concierge.notifyBundleListeners(Concierge.java:3620)
	at org.eclipse.concierge.BundleImpl.activate0(BundleImpl.java:586)
	at org.eclipse.concierge.BundleImpl.activate(BundleImpl.java:552)
	- locked <0x0000000779308270> (a org.eclipse.concierge.BundleImpl)
	at org.eclipse.concierge.BundleImpl.start(BundleImpl.java:506)
	at org.eclipse.concierge.BundleImpl.start(BundleImpl.java:444)
	at org.eclipse.concierge.compat.service.XargsFileLauncher.processXargsInputStream(XargsFileLauncher.java:183)
	at org.eclipse.concierge.compat.service.XargsFileLauncher.processXargsFile(XargsFileLauncher.java:83)
	at org.eclipse.concierge.Concierge.doMain(Concierge.java:606)
	at org.eclipse.concierge.Concierge.main(Concierge.java:525)

For details, see eclipse-archived/smarthome-packaging-sample#13 (comment).

When running the OSGi TCK test suite, some tests fail with native library support

Bug on rest.xargs sample (and loading org.eclipse.concierge.service.rest.client-1.0.0.*.jar.

Exception in thread "main" org.osgi.framework.BundleException: Syntactic error in bundle manifest at org.eclipse.concierge.compat.service.BundleManifestTwo.processManifest(BundleManifestTwo.java:116) at org.eclipse.concierge.BundleImpl$Revision.<init>(BundleImpl.java:1608) at org.eclipse.concierge.BundleImpl$JarBundleRevision.<init>(BundleImpl.java:3813) at org.eclipse.concierge.BundleImpl.readAndProcessInputStream(BundleImpl.java:399) at org.eclipse.concierge.BundleImpl.<init>(BundleImpl.java:228) at org.eclipse.concierge.Concierge.installNewBundle(Concierge.java:4253) at org.eclipse.concierge.Concierge.installNewBundle(Concierge.java:4216) at org.eclipse.concierge.Concierge$BundleContextImpl.installBundle(Concierge.java:4842) at org.eclipse.concierge.compat.service.XargsFileLauncher.processXargsInputStream(XargsFileLauncher.java:178) at org.eclipse.concierge.compat.service.XargsFileLauncher.processXargsFile(XargsFileLauncher.java:83) at org.eclipse.concierge.Concierge.doMain(Concierge.java:617) at org.eclipse.concierge.Concierge.main(Concierge.java:536) Caused by: java.lang.IllegalArgumentException: invalid version "1.0.0..SNAPSHOT-20190910193934": invalid qualifier ".SNAPSHOT-20190910193934" at org.osgi.framework.Version.validate(Version.java:205) at org.osgi.framework.Version.<init>(Version.java:156) at org.osgi.framework.Version.valueOf(Version.java:257) at org.osgi.framework.Version.parseVersion(Version.java:228) at org.eclipse.concierge.compat.service.BundleManifestTwo.processManifest(BundleManifestTwo.java:110) ... 11 more

Migrated from Eclipse Bugzilla #477411

Jan S. Rellermeyer 2015-09-14 22:27:23 EDT

We would like to have more unit tests for the Concierge core framework and the associated services. Jochen wrote a wonderful utility class that can easily generate synthetic bundles so that writing test cases should now be a lot easier.