August 2009 - jboss-osgi-dev - Jboss List Archives

[JBoss OSGi Development] - Re: Change in manifest parser breaks symbolic name

by thomas.diesler＠jboss.com

| 2009-08-26 09:37:42,614 ERROR [org.jboss.osgi.plugins.metadata.QNameAttributeListValueCreator] Exception parsing parameters. | org.jboss.osgi.plugins.metadata.ParseException: Encountered "jboss-osgi-common" at line 1, column 1. | Was expecting: | <QNAME> ... | | at org.jboss.osgi.plugins.metadata.HeaderValue.generateParseException(HeaderValue.java:962) | at org.jboss.osgi.plugins.metadata.HeaderValue.jj_consume_token(HeaderValue.java:842) | at org.jboss.osgi.plugins.metadata.HeaderValue.parameterInfo(HeaderValue.java:214) | at org.jboss.osgi.plugins.metadata.HeaderValue.parseParameters(HeaderValue.java:122) | at org.jboss.osgi.plugins.metadata.HeaderValue.parseParameters(HeaderValue.java:65) | at org.jboss.osgi.plugins.metadata.HeaderValue.parseParameters(HeaderValue.java:87) | at org.jboss.osgi.plugins.metadata.QNameAttributeListValueCreator.parseAttribute(QNameAttributeListValueCreator.java:39) | at org.jboss.osgi.plugins.metadata.ParameterizedAttributeListValueCreator.useString(ParameterizedAttributeListValueCreator.java:39) | at org.jboss.osgi.plugins.metadata.ParameterizedAttributeListValueCreator.useString(ParameterizedAttributeListValueCreator.java:1) | at org.jboss.osgi.plugins.metadata.AbstractValueCreator.createValue(AbstractValueCreator.java:53) | at org.jboss.osgi.plugins.metadata.AbstractOSGiMetaData.get(AbstractOSGiMetaData.java:272) | at org.jboss.osgi.plugins.metadata.AbstractOSGiMetaData.get(AbstractOSGiMetaData.java:260) | at org.jboss.osgi.plugins.metadata.AbstractOSGiMetaData.parseSymbolicName(AbstractOSGiMetaData.java:250) | at org.jboss.osgi.plugins.metadata.AbstractOSGiMetaData.getBundleSymbolicName(AbstractOSGiMetaData.java:176) | at org.jboss.osgi.plugins.facade.bundle.OSGiBundleState.getSymbolicName(OSGiBundleState.java:184) | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251712#4251712 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251712

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Change in manifest parser breaks symbolic name

by thomas.diesler＠jboss.com

https://jira.jboss.org/jira/browse/JBOSGI-137 When you remove the fallback hack, you should see the SimpleBundleTestCase fail | DEPLOYMENTS IN ERROR: | Deployment "vfszip:/home/tdiesler/svn/jboss-osgi/projects/runtime/microcontainer/trunk/target/test-libs/simple-bundle.jar/" is in error due to the following reason(s): java.lang.IllegalStateException: Cannot obtain Bundle-SymbolicName | I guess that many BND generated bundles might fail. The fallback hack does not handle potential parameters. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251641#4251641 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251641

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Fixed version parsing and added initial split package suppor

by thomas.diesler＠jboss.com

| Version version = null; | if (versionString != null) | { | // Handle version strings with quotes | if (versionString.startsWith("\"") && versionString.endsWith("\"")) | versionString = versionString.substring(1, versionString.length() - 1); | | version = Version.parseVersion(versionString); | } | | OSGiPackageCapability capability = new OSGiPackageCapability(name, version, metadata, exportPackage); | capability.setSplitPackagePolicy(SplitPackagePolicy.First); | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251639#4251639 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251639

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: snapshots

by thomas.diesler＠jboss.com

of course - sorry View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251635#4251635 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251635

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: tests log4j.xml

by thomas.diesler＠jboss.com

This actually works for me very well 1) I set -Dlog4j.output.dir=${workspace_loc:jboss-osgi-runtime-microcontainer/target} in eclipse 2) Not sure what you mean. I always have target/test.log that contains all the logging 3) for me that's quite the opposite. I can grep test.log or have it open in gedit where I can search I prefer a console output like this | ------------------------------------------------------- | T E S T S | ------------------------------------------------------- | Running org.jboss.test.osgi.service.test.ServiceRegistrationUnitTestCase | Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.326 sec | Running org.jboss.test.osgi.bundle.test.BundleContextUnitTestCase | Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.817 sec | Running org.jboss.test.osgi.smoke.test.OSGiSmokeTestCase | Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.726 sec | Running org.jboss.test.bundle.metadata.VersionRangeTestCase | Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.022 sec | Running org.jboss.test.osgi.launch.FrameworkLaunchTestCase | Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.195 sec | Running org.jboss.test.osgi.integration.simple.SimpleLogServiceTestCase | FIXME [JBOSGI-136] Cannot resolve dependency against unstarted bundle | FIXME [JBOSGI-135] Cannot handle package beeing imported and exported by the same bundle | Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.172 sec | Running org.jboss.test.osgi.classloader.test.ExportImportPackageUnitTestCase | Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.579 sec <<< FAILURE! | Running org.jboss.test.osgi.classloader.test.RequireBundleUnitTestCase | Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 6.962 sec | Running org.jboss.test.osgi.integration.simple.SimpleBundleTestCase | Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.384 sec | Running org.jboss.test.osgi.bundle.test.BundleEntriesUnitTestCase | Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.374 sec | Running org.jboss.test.osgi.filter.test.FrameworkUtilFilterUnitTestCase | FIXME [JBOSGI-129] - Invalid (*=b) | FIXME [JBOSGI-129] - NoMatch (a=) | FIXME [JBOSGI-129] - NoMatch (a<= 2) | FIXME [JBOSGI-129] - NoMatch (a<=2 ) | FIXME [JBOSGI-129] - NoMatch (a<= ) | FIXME [JBOSGI-129] - NoMatch (a>= 0) | FIXME [JBOSGI-129] - NoMatch (a>=0 ) | FIXME [JBOSGI-129] - NoMatch (a>= ) | Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.362 sec | Running org.jboss.test.osgi.filter.test.BundleContextFilterUnitTestCase | FIXME [JBOSGI-129] - Invalid (*=b) | FIXME [JBOSGI-129] - NoMatch (a=) | FIXME [JBOSGI-129] - NoMatch (a<= 2) | FIXME [JBOSGI-129] - NoMatch (a<=2 ) | FIXME [JBOSGI-129] - NoMatch (a<= ) | FIXME [JBOSGI-129] - NoMatch (a>= 0) | FIXME [JBOSGI-129] - NoMatch (a>=0 ) | FIXME [JBOSGI-129] - NoMatch (a>= ) | Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.441 sec | Running org.jboss.test.osgi.service.test.GetServiceReferencesUnitTestCase | Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.062 sec | Running org.jboss.test.bundle.metadata.HeaderValuesTestCase | Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.068 sec | Running org.jboss.test.osgi.bundle.test.SystemBundleUnitTestCase | Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.272 sec | Running org.jboss.test.osgi.service.test.RegisterServiceUnitTestCase | Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.15 sec | Running org.jboss.test.osgi.service.test.GetUnGetServiceUnitTestCase | Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.276 sec | Running org.jboss.test.osgi.bundle.test.BundleUnitTestCase | Tests run: 17, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.193 sec | Running org.jboss.test.osgi.service.test.ServiceReferenceUnitTestCase | Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.487 sec | | Results : | | Failed tests: | testVersionImportPackageFails(org.jboss.test.osgi.classloader.test.ExportImportPackageUnitTestCase) | Anyway, I put log4j.xml in svn:ignore so you won't see it if you don't want to. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251631#4251631 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251631

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: Performance problem

by adrian＠jboss.org

"alesj" wrote : "adrian(a)jboss.org" wrote : I should also mention that most of these tests are using the AssembledDirectory | | so I can (re-)use the test support classes directly without having to do a packaging step. | | | | Maybe the issue is there? | As you already know, Assembled stuff is pretty slow - I remember your comments when we first used it in Deployers tests. | If you just recently changed this (applying its usage), than this is definitely the culprit. | If you used this before, then I'm out of ideas. :-) But that was building the stuff since the api required you to scan the whole file system with a filter instead of being able to say exactly what you wanted to include. e.g. if I want to include classes in classes/org/foo/bar I has to pass "classes" with a filter "org/foo/bar/*" which scans everything in classes. The runtime stuff shouldn't be slow, i.e. just looking at the constructed tree for the indirections. P.S. The AssembledDirectory also needs some remove() or clear() methods. There is one on AssembledDirectoryHandler but that is a private api. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251612#4251612 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251612

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: Package cannot have multiple exporters

by thomas.diesler＠jboss.com

This should be fixed with the latests classloading SNAPSHOT View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251611#4251611 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251611

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: HOWTO chage the behaviour of the CL policy

by thomas.diesler＠jboss.com

anonymous wrote : | My understanding was that non-core api had to be referenced using Import-Packag | Actually core API needs to have a wire too. That is why Felix and Equinox ship their frameworks as bundles that contain the core packages and versions in Export-Package directives. This proper fix would probably be to install some global PackageCapabilities that correspond to the system packages that are configured in the SystemPackagesPlugin View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251610#4251610 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251610

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: FrameworkUtil and Filter implementations

by thomas.diesler＠jboss.com

anonymous wrote : | According to my view this represents bugs in the OSGi provided class versus what I implemented? | I am still waiting for feedback on https://www.osgi.org/members/bugzilla/show_bug.cgi?id=1418 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251608#4251608 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251608

15 years, 1 month

1
0
0 / 0

[JBoss OSGi Development] - Re: FrameworkUtil and Filter implementations

by adrian＠jboss.org

What's the issue with JBOSGI-129? According to my view this represents bugs in the OSGi provided class versus what I implemented? e.g. | (*=b) is invalid since it doesn't have an attribute name | (a=) must be valid, it matches the empty string | (a<=2 ) must be invalid since the spec says spaces are significant for values and "2 " cannot be converted to a number using valueOf() as required by the spec - ok you could be a bit lenient here but it requires treating numbers in a special way | (a>= ) shouldn't throw NumberFormatException which isn't declared in the javadoc, it should either throw InvalidSyntaxException or return false when matching. | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251604#4251604 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251604

15 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

jboss-osgi-dev August 2009