Re: svn commit: r915184 - in /felix/trunk: bundlerepository/src/main/java/org/apache/felix/bundlerepository/ bundlerepository/src/test/java/org/apache/felix/bundlerepository/ org.osgi.service.obr/src/
On 2/23/10 1:03 PM, rickh...@apache.org wrote:
Author: rickhall
Date: Tue Feb 23 05:03:47 2010
New Revision: 915184
URL: http://svn.apache.org/viewvc?rev=915184&view=rev
Log:
Fixed an apparent type. (FELIX-2115)
That should say, "typo"...d'oh!
-> richard
Added:
felix/trunk/org.osgi.service.obr/src/main/java/org/osgi/service/obr/InterruptedResolutionException.java
- copied, changed from r915176,
felix/trunk/org.osgi.service.obr/src/main/java/org/osgi/service/obr/InterrupteResolutionException.java
Removed:
felix/trunk/org.osgi.service.obr/src/main/java/org/osgi/service/obr/InterrupteResolutionException.java
Modified:
felix/trunk/bundlerepository/src/main/java/org/apache/felix/bundlerepository/ResolverImpl.java
felix/trunk/bundlerepository/src/test/java/org/apache/felix/bundlerepository/FilterImplTest.java
felix/trunk/bundlerepository/src/test/java/org/apache/felix/bundlerepository/RepositoryAdminTest.java
felix/trunk/bundlerepository/src/test/java/org/apache/felix/bundlerepository/ResolverImplTest.java
felix/trunk/org.osgi.service.obr/src/main/java/org/osgi/service/obr/Resolver.java
Modified:
felix/trunk/bundlerepository/src/main/java/org/apache/felix/bundlerepository/ResolverImpl.java
URL:
http://svn.apache.org/viewvc/felix/trunk/bundlerepository/src/main/java/org/apache/felix/bundlerepository/ResolverImpl.java?rev=915184&r1=915183&r2=915184&view=diff
==
---
felix/trunk/bundlerepository/src/main/java/org/apache/felix/bundlerepository/ResolverImpl.java
(original)
+++
felix/trunk/bundlerepository/src/main/java/org/apache/felix/bundlerepository/ResolverImpl.java
Tue Feb 23 05:03:47 2010
@@ -481,7 +481,7 @@
{
if (Thread.interrupted())
{
-throw new InterrupteResolutionException();
+throw new InterruptedResolutionException();
}
}
Modified:
felix/trunk/bundlerepository/src/test/java/org/apache/felix/bundlerepository/FilterImplTest.java
URL:
http://svn.apache.org/viewvc/felix/trunk/bundlerepository/src/test/java/org/apache/felix/bundlerepository/FilterImplTest.java?rev=915184&r1=915183&r2=915184&view=diff
==
---
felix/trunk/bundlerepository/src/test/java/org/apache/felix/bundlerepository/FilterImplTest.java
(original)
+++
felix/trunk/bundlerepository/src/test/java/org/apache/felix/bundlerepository/FilterImplTest.java
Tue Feb 23 05:03:47 2010
@@ -119,4 +119,4 @@
dict.put("PACKAGE", "org.eclipse.core.runtime");
assertFalse(filterImpl.matchCase(dict));
}
-}
+}
\ No newline at end of file
Modified:
felix/trunk/bundlerepository/src/test/java/org/apache/felix/bundlerepository/RepositoryAdminTest.java
URL:
http://svn.apache.org/viewvc/felix/trunk/bundlerepository/src/test/java/org/apache/felix/bundlerepository/RepositoryAdminTest.java?rev=915184&r1=915183&r2=915184&view=diff
==
---
felix/trunk/bundlerepository/src/test/java/org/apache/felix/bundlerepository/RepositoryAdminTest.java
(original)
+++
felix/trunk/bundlerepository/src/test/java/org/apache/felix/bundlerepository/RepositoryAdminTest.java
Tue Feb 23 05:03:47 2010
@@ -27,7 +27,6 @@
public class RepositoryAdminTest extends TestCase
{
-
public void testResourceFilterOnCapabilities() throws Exception
{
URL url = getClass().getResource("/repo_for_resolvertest.xml");
@@ -44,7 +43,6 @@
assertEquals(1, resources.length);
}
-
private RepositoryAdminImpl createRepositoryAdmin()
{
final MockBundleContext bundleContext = new MockBundleContext() {
@@ -63,5 +61,4 @@
return repoAdmin;
}
-
-}
+}
\ No newline at end of file
Modified:
felix/trunk/bundlerepository/src/test/java/org/apache/felix/bundlerepository/ResolverImplTest.java
URL:
http://svn.apache.org/viewvc/felix/trunk/bundlerepository/src/test/java/org/apache/felix/bundlerepository/ResolverImplTest.java?rev=915184&r1=915183&r2=915184&view=diff
==
---
felix/trunk/bundlerepository/src/test/java/org/apache/felix/bundlerepository/ResolverImplTest.java
(original)
+++
felix/trunk/bundlerepository/src/test/java/org/apache/felix/bundlerepository/ResolverImplTest.java
Tue Feb 23 05:03:47 2010
@@ -22,7 +22,7 @@
import junit.framework.TestCase;
-import org.osgi.service.obr.InterrupteResolutionException;
+import org.osgi.service.obr.InterruptedResolutionException;
import org.osgi.service.obr.Repository;
import org.osgi.service.obr.Requirement;
import org.osgi.service.obr.Resolver;
@@ -91,7 +91,7 @@
resolver.resolve();
fail("An excepiton should have been thrown");
}
-catch (InterrupteResolutionException e)
+catch
[jira] Commented: (FELIX-2106) Resolver scoped Repository
[ https://issues.apache.org/jira/browse/FELIX-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12837075#action_12837075 ] Richard S. Hall commented on FELIX-2106: The main issue with the former is that means that the lifetime of the repositories is not the same as the lifetime of the resolver object. This is not a big deal, necessarily, but we just need to define what it means when these change. For example, if they change during a resolve operation are they ignored? What happens if they are changed after a resolve, does that invalidate the result? Not too big of a deal, but we just need to define it. > Resolver scoped Repository > -- > > Key: FELIX-2106 > URL: https://issues.apache.org/jira/browse/FELIX-2106 > Project: Felix > Issue Type: Improvement > Components: Bundle Repository (OBR) >Reporter: Alasdair Nottingham > > I'm a committer on the apache aries podling and I have been involved > in creating an application resolver that makes use of OBR to resolve > dependencies. In our model we resolve applications against configure > OBR repositories, and against a private repository that exists just > for that application. > From what I can tell when you add a repository to RepositoryAdmin it > has a global effect which means that any other calls to resolve will > use the repository. This means my private repository isn't necessarily > private. I currently remove it again after resolving and synchronise > so I only resolve one application at a time, but any other > RepositoryAdmin client will be exposed to my externals. > I am raising this JIRA to get an enhancement to the Resolver interface to > add an addRepository method so I can add a repository that is only > used by that Resolver instance and isn't global. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2108) The log4j from felix launcher is messing up felix osgi container
[
https://issues.apache.org/jira/browse/FELIX-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls resolved FELIX-2108.
---
Resolution: Invalid
Well, it is a context classloader problem after all. The context classloader is
set to the system classloader by default -- hence, log4j is picking it up and
does see the classes on the outside.
There are two ways to fix this in your case:
1) Set the context classloader to
1.1) null in your launcher before you start felix (notice, this might cause
problems with other libraries which are known to expect it to be set to
something other than null)
1.2) your own classloader which doesn't see classes you don't want to "leak"
into the framework (mainly to avoid the null issue of 1.1)
2) "tell" log4j to ignore the context classloader by setting
-Dlog4j.ignoreTCL=true
I used 2) and it worked without any issues.
I'll resolve with invalid - please close if you are satisfied or reopen if you
see room for improvement.
> The log4j from felix launcher is messing up felix osgi container
> -
>
> Key: FELIX-2108
> URL: https://issues.apache.org/jira/browse/FELIX-2108
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: felix-1.4.1
>Reporter: Shrini Joshi
>Assignee: Karl Pauls
> Attachments: felix-launcher.zip, log4jconfig_1.0.0.jar,
> osgi-simple-service.zip
>
>
> This issue is not type question rather than a bug
> I have created a launcher programme which is responsible for laoding the
> config values and instantiating the felix container (1.4.1).
> Everything is working fine except for one small glitch. Please take a look
> for following error message thrown by the log4j bundle.
> The launcher programme is using log4j for logging. But when it starts the
> felix container, log4j bundle is installed since it is used by the
> application itself.
> I have listed deployed bundles further below.
> My view is, the log4j library loaded by launcher is visible to felix
> container and hence log4j bundle fails to start cleanly. This is going to be
> a big problem for dpeloyment.
> I am using felix 1.4.1, is that too old to be good?
> Is there any setting that I need to pass to instruct the felix to create
> comepletly new classloader as system-classloader? Being a OSGI container I
> expected it to create new class-loader as system-classloader but now I feel
> it does not.
> Can someome please help me understand?
> Shrini
> ===
> log4j: reset attribute= "false".
> log4j: Threshold ="null".
> log4j: Level value for root is [DEBUG].
> log4j: root level set to DEBUG
> log4j: Class name: [org.apache.log4j.RollingFileAppender]
> log4j: Setting property [file] to [**/launcher.log].
> log4j: Setting property [append] to [true].
> log4j: Setting property [maxFileSize] to [10MB].
> log4j: Setting property [maxBackupIndex] to [15].
> log4j: Parsing layout of class: "org.apache.log4j.PatternLayout"
> log4j: Setting property [conversionPattern] to [%d{dd MMM HH:mm:ss,SSS}
> %t %-5p %c{2} - %m%n].
> log4j: setFile called: **/launcher.log, true
> log4j: setFile ended
> log4j: Adding appender named [FILE] to category [root].
> -> log4j:ERROR A "org.apache.log4j.xml.DOMConfigurator" object is not
> assignable to a "org.apache.log4j.spi.Configurator" variable.
> log4j:ERROR The class "org.apache.log4j.spi.Configurator" was loaded by
> log4j:ERROR [6.0] whereas object of type
> log4j:ERROR "org.apache.log4j.xml.DOMConfigurator" was loaded by
> [sun.misc.launcher$appclassloa...@17182c1].
> log4j:ERROR Could not instantiate configurator
> [org.apache.log4j.xml.DOMConfigurator].
> log4j:WARN No appenders could be found for logger
> (org.springframework.osgi.extender.internal.activator.ContextLoaderListener).
> log4j:WARN Please initialize the log4j system properly.
> =
> [ 0] [Active ] [0] System Bundle (2.0.1)
> [ 1] [Active ] [5] AOP Alliance API (1.0.0)
> [ 2] [Active ] [5] Apache Commons Collections (3.2.0)
> [ 3] [Active ] [5] Apache Commons Lang (2.4.0)
> [ 4] [Active ] [5] Apache Commons Logging (1.1.1)
> [ 5] [Active ] [5] Apache Commons Pool (1.3.0)
> [ 6] [Active ] [5] Apache Log4J (1.2.15)
> [ 7] [Active ] [5] Apache Felix Bundle Repository (1.4.2)
> [ 8] [Active ] [5] Apache Felix Shell Service (1.4.1)
> [ 9] [Active ] [5] Apache Felix Shell TUI (1.4.1)
> [ 10] [Active ] [5] Spring AOP (2.5.6)
> [ 11] [Active ] [5] Spring Beans (2.5.6)
> [ 12] [Active ] [5] Spring Context (2.5.6)
> [ 13] [Active ] [5] Spring Context Support (2.5.6)
> [ 14] [Active ] [5] Spring Core (2.5.6)
> [ 15] [Active ] [5] spring-osgi-co
[jira] Assigned: (FELIX-2108) The log4j from felix launcher is messing up felix osgi container
[
https://issues.apache.org/jira/browse/FELIX-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls reassigned FELIX-2108:
-
Assignee: Karl Pauls
> The log4j from felix launcher is messing up felix osgi container
> -
>
> Key: FELIX-2108
> URL: https://issues.apache.org/jira/browse/FELIX-2108
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: felix-1.4.1
>Reporter: Shrini Joshi
>Assignee: Karl Pauls
> Attachments: felix-launcher.zip, log4jconfig_1.0.0.jar,
> osgi-simple-service.zip
>
>
> This issue is not type question rather than a bug
> I have created a launcher programme which is responsible for laoding the
> config values and instantiating the felix container (1.4.1).
> Everything is working fine except for one small glitch. Please take a look
> for following error message thrown by the log4j bundle.
> The launcher programme is using log4j for logging. But when it starts the
> felix container, log4j bundle is installed since it is used by the
> application itself.
> I have listed deployed bundles further below.
> My view is, the log4j library loaded by launcher is visible to felix
> container and hence log4j bundle fails to start cleanly. This is going to be
> a big problem for dpeloyment.
> I am using felix 1.4.1, is that too old to be good?
> Is there any setting that I need to pass to instruct the felix to create
> comepletly new classloader as system-classloader? Being a OSGI container I
> expected it to create new class-loader as system-classloader but now I feel
> it does not.
> Can someome please help me understand?
> Shrini
> ===
> log4j: reset attribute= "false".
> log4j: Threshold ="null".
> log4j: Level value for root is [DEBUG].
> log4j: root level set to DEBUG
> log4j: Class name: [org.apache.log4j.RollingFileAppender]
> log4j: Setting property [file] to [**/launcher.log].
> log4j: Setting property [append] to [true].
> log4j: Setting property [maxFileSize] to [10MB].
> log4j: Setting property [maxBackupIndex] to [15].
> log4j: Parsing layout of class: "org.apache.log4j.PatternLayout"
> log4j: Setting property [conversionPattern] to [%d{dd MMM HH:mm:ss,SSS}
> %t %-5p %c{2} - %m%n].
> log4j: setFile called: **/launcher.log, true
> log4j: setFile ended
> log4j: Adding appender named [FILE] to category [root].
> -> log4j:ERROR A "org.apache.log4j.xml.DOMConfigurator" object is not
> assignable to a "org.apache.log4j.spi.Configurator" variable.
> log4j:ERROR The class "org.apache.log4j.spi.Configurator" was loaded by
> log4j:ERROR [6.0] whereas object of type
> log4j:ERROR "org.apache.log4j.xml.DOMConfigurator" was loaded by
> [sun.misc.launcher$appclassloa...@17182c1].
> log4j:ERROR Could not instantiate configurator
> [org.apache.log4j.xml.DOMConfigurator].
> log4j:WARN No appenders could be found for logger
> (org.springframework.osgi.extender.internal.activator.ContextLoaderListener).
> log4j:WARN Please initialize the log4j system properly.
> =
> [ 0] [Active ] [0] System Bundle (2.0.1)
> [ 1] [Active ] [5] AOP Alliance API (1.0.0)
> [ 2] [Active ] [5] Apache Commons Collections (3.2.0)
> [ 3] [Active ] [5] Apache Commons Lang (2.4.0)
> [ 4] [Active ] [5] Apache Commons Logging (1.1.1)
> [ 5] [Active ] [5] Apache Commons Pool (1.3.0)
> [ 6] [Active ] [5] Apache Log4J (1.2.15)
> [ 7] [Active ] [5] Apache Felix Bundle Repository (1.4.2)
> [ 8] [Active ] [5] Apache Felix Shell Service (1.4.1)
> [ 9] [Active ] [5] Apache Felix Shell TUI (1.4.1)
> [ 10] [Active ] [5] Spring AOP (2.5.6)
> [ 11] [Active ] [5] Spring Beans (2.5.6)
> [ 12] [Active ] [5] Spring Context (2.5.6)
> [ 13] [Active ] [5] Spring Context Support (2.5.6)
> [ 14] [Active ] [5] Spring Core (2.5.6)
> [ 15] [Active ] [5] spring-osgi-core (1.2.1)
> [ 16] [Active ] [5] spring-osgi-extender (1.2.1)
> [ 17] [Active ] [5] spring-osgi-io (1.2.1)
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2106) Resolver scoped Repository
[ https://issues.apache.org/jira/browse/FELIX-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12836927#action_12836927 ] Alasdair Nottingham commented on FELIX-2106: >From an API perspective I would go for the former option. It looks like a less >invasive change, and it doesn't affect users of the existing API. Also I think >it works better for progressive disclosure perspective. It is less in your >face. Not sure which is easier to implement though. > Resolver scoped Repository > -- > > Key: FELIX-2106 > URL: https://issues.apache.org/jira/browse/FELIX-2106 > Project: Felix > Issue Type: Improvement > Components: Bundle Repository (OBR) >Reporter: Alasdair Nottingham > > I'm a committer on the apache aries podling and I have been involved > in creating an application resolver that makes use of OBR to resolve > dependencies. In our model we resolve applications against configure > OBR repositories, and against a private repository that exists just > for that application. > From what I can tell when you add a repository to RepositoryAdmin it > has a global effect which means that any other calls to resolve will > use the repository. This means my private repository isn't necessarily > private. I currently remove it again after resolving and synchronise > so I only resolve one application at a time, but any other > RepositoryAdmin client will be exposed to my externals. > I am raising this JIRA to get an enhancement to the Resolver interface to > add an addRepository method so I can add a repository that is only > used by that Resolver instance and isn't global. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2106) Resolver scoped Repository
[ https://issues.apache.org/jira/browse/FELIX-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12836889#action_12836889 ] Guillaume Nodet commented on FELIX-2106: I'd like to tackle this issue, but I'm still wondering if the best solution is to: * add the following methods to the Resolver: addRepository/removeRepository/getRepositories or * add the following methods to the RepositoryAdmin: getLocalRepository/getSystemRepository/resolver(Respository[]) > Resolver scoped Repository > -- > > Key: FELIX-2106 > URL: https://issues.apache.org/jira/browse/FELIX-2106 > Project: Felix > Issue Type: Improvement > Components: Bundle Repository (OBR) >Reporter: Alasdair Nottingham > > I'm a committer on the apache aries podling and I have been involved > in creating an application resolver that makes use of OBR to resolve > dependencies. In our model we resolve applications against configure > OBR repositories, and against a private repository that exists just > for that application. > From what I can tell when you add a repository to RepositoryAdmin it > has a global effect which means that any other calls to resolve will > use the repository. This means my private repository isn't necessarily > private. I currently remove it again after resolving and synchronise > so I only resolve one application at a time, but any other > RepositoryAdmin client will be exposed to my externals. > I am raising this JIRA to get an enhancement to the Resolver interface to > add an addRepository method so I can add a repository that is only > used by that Resolver instance and isn't global. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2083) bundlerepository should mark dependencies it includes as optional
[ https://issues.apache.org/jira/browse/FELIX-2083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved FELIX-2083. Resolution: Fixed Assignee: Guillaume Nodet Committing to https://svn.apache.org/repos/asf/felix/trunk ... M bundlerepository/pom.xml Committed r915043 > bundlerepository should mark dependencies it includes as optional > - > > Key: FELIX-2083 > URL: https://issues.apache.org/jira/browse/FELIX-2083 > Project: Felix > Issue Type: Bug > Components: Bundle Repository (OBR) >Affects Versions: bundlerepository-1.4.3 >Reporter: David Jencks >Assignee: Guillaume Nodet > Fix For: bundlerepository-1.6.0 > > Attachments: FELIX-2083.diff > > > I'm finding it really annoying to have to exclude in maven the dependencies > that are bundled right into bundlerepository. If they are marked "optional" > then it's a lot easier to use the bundlerepository bundle in maven projects. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-1951) The SchemaObr.xsd in bundleplugin is incomplete
[ https://issues.apache.org/jira/browse/FELIX-1951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved FELIX-1951. Resolution: Fixed Fix Version/s: maven-bundle-plugin-2.1.0 Assignee: Guillaume Nodet Committing to https://svn.apache.org/repos/asf/felix/trunk ... M bundleplugin/src/main/resources/SchemaObr.xsd Committed r915042 > The SchemaObr.xsd in bundleplugin is incomplete > --- > > Key: FELIX-1951 > URL: https://issues.apache.org/jira/browse/FELIX-1951 > Project: Felix > Issue Type: Bug > Components: Bundle Repository (OBR), Maven Bundle Plugin >Reporter: Jarek Gawor >Assignee: Guillaume Nodet > Fix For: maven-bundle-plugin-2.1.0 > > Attachments: FELIX-1951.patch > > > The SchemaObr.xsd in bundleplugin is incomplete. It's missing a few elements > and attributes and the repository.xml generated by maven-bundle-plugin does > not validate against it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-1007) OBR search doesn't take 'categories' into account
[ https://issues.apache.org/jira/browse/FELIX-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved FELIX-1007. Resolution: Fixed Fix Version/s: bundlerepository-1.6.0 Committing to https://svn.apache.org/repos/asf/felix/trunk ... M bundlerepository/src/main/java/org/apache/felix/bundlerepository/ResourceImpl.java A bundlerepository/src/test/java/org/apache/felix/bundlerepository/RepositoryAdminTest.java M org.osgi.service.obr/src/main/java/org/osgi/service/obr/Resource.java Committed r915039 > OBR search doesn't take 'categories' into account > - > > Key: FELIX-1007 > URL: https://issues.apache.org/jira/browse/FELIX-1007 > Project: Felix > Issue Type: Bug > Components: Bundle Repository (OBR) >Reporter: Kristian Koehler >Assignee: Guillaume Nodet > Fix For: bundlerepository-1.6.0 > > Attachments: categoriesQueryPatch_2009_03_27.txt > > > Hi > the RFC-0112 Bundle Repository document says: "The element defines > a category. The purpose is to easy the discovery." and the description of the > method org.osgi.servicex.obr. RepositoryAdmin#discoverResources says "The > attributes that can be checked are: [...] category" but filtering resources > with a given category doesn't work. The following filter is "meaningless": > "(category:*>sampleCategory)" > Kristian -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Karaf 1.4.0
On Fri, Feb 19, 2010 at 18:33, David Jencks wrote: > Eventually I found the source archives at > > https://repository.apache.org/content/repositories/orgapachefelix-010/org/apache/felix/karaf/apache-felix-karaf/1.4.0/apache-felix-karaf-1.4.0-src.tar.gz > > The layout of this archive seems a bit peculiar, but I can build it. Not sure why you say the archive is peculiar, it looks as the usual one to me. > > The following file is found by rat:check to be missing license headers: > > deployer/blueprint/src/test/resources/test.xml > > The copyright date in the root NOTICE file is 2009 > > My understanding of best practice for NOTICE files is that they should refer > to only what is in the artifact they are in. So the root NOTICE file would > be better if it left out the "Used Software" section and the license > summary. I also don't think its appropriate to include license info in the > NOTICE file unless it's required by the included software NOTICE; this > applies to all the NOTICE files. Yeah and that's how the Felix PMC has decided to work with NOTICE files AFAIK. There has been some discussions about changing that but no decision so far IIRC. > > I find the duplicated legal files in root and src to be confusing. Why not > just use the standard source distro from the apache 7 pom apache-release > profile? The goal is to have clean generated notice files. In addition, as a felix subproject, we need to have felix-parent as the parent-pom. Not sure what the apache 7 changes, but we > > I'd advise fixing these problems and re-rolling the release. I'm +1 for the release. > thanks > david jencks > > > On Feb 19, 2010, at 12:39 AM, Chris Custine wrote: > >> The Karaf 1.4.0 artifacts have been staged for release. >> >> Release notes are here: >> >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&styleName=Html&version=12314410 >> >> Staging repository: >> https://repository.apache.org/content/repositories/orgapachefelix-010/ >> >> You can use this UNIX script to download the release and verify the >> signatures: >> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh >> >> Usage: >> sh check_staged_release.sh 010 /tmp/felix-staging >> >> Please vote to approve this release: >> >> [ ] +1 Approve the release >> [ ] -1 Veto the release (please provide specific comments) >> >> This vote will be open for 72 hours. >> >> -- >> Chris Custine >> FUSESource :: http://fusesource.com >> My Blog :: http://blog.organicelement.com >> Apache ServiceMix :: http://servicemix.apache.org >> Apache Felix :: http://felix.apache.org >> Apache Directory Server :: http://directory.apache.org > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Felix embeded in Android - problem for instantiate a Service.
This sounds like a ThreadContextClassloader (TCL) problem.
Not sure about the sample you are using but usually you can get
arround this setting TCL to "null" when creating the framework:
Thread.currentThread().setContextClassLoader( null );
Make you reset it when you are done (getContextClassLoader(..))
Reason behind this: Classes
(tutorial.example2b.Activator$DictionaryImpl) exist twice (at least)
in your case: once in the host (where you start felix) and once in the
bundle.
Chances are also that you have to delegate the packages from the
system bundle, but that should have been part of the tutorial you are
using/referring to.
Toni
On Mon, Feb 22, 2010 at 5:52 PM, pablomj wrote:
>
> Good day Karl,
>
> I also proved
> ds=(DictionaryService) bc.getService(sb[j]);
> but also generates a class exception.
>
> 02-22 16:47:14.794: DEBUG/Felix(2365): Could not create framework:
> java.lang.ClassCastException: tutorial.example2b.Activator$DictionaryImpl
>
> I'm sorry. I know that it is maybe an OSGi problem...but I think that maybe
> someone here could help me.
> I continue with this. Thank you for answer,
> Pablo.
>
>
>
>
>
> Karl Pauls wrote:
>>
>> You are trying to cast a servicereference to a service object. That
>> doesn't work. You need to first get the real service by:
>>
>> bc.getService(sb[j]);
>>
>> Nothing to do with android btw. - just osgi.
>> regards,
>>
>> Karl
>>
>> On Mon, Feb 22, 2010 at 4:28 PM, pablomj wrote:
>>>
>>> Good day, I trying embedding Felix in Android. I installed some bundles
>>> (English Dictionary, French Dictionary, Spellchecker...). Well, the
>>> program
>>> compiles but I can't instanciate a DictionaryService for use for example
>>> d.checkword("the");
>>>
>>> The code is:
>>>
>>>
>>> try {
>>> m_felix.start();
>>>
>>> BundleContext bc=m_felix.getBundleContext();
>>> bc.installBundle("file:/data/felix/EnglishDictionary.jar");
>>> bc.installBundle("file:/data/felix/FrenchDictionary.jar");
>>> bc.installBundle("file:/data/felix/SpellChecker.jar");
>>>
>>> //start all bundles
>>> org.osgi.framework.Bundle[] bs=bc.getBundles();
>>> for(int i=0; i>>
>>> //get registered services
>>> ServiceReference[]
>>> sb=bc.getAllServiceReferences("tutorial.example2.service.DictionaryService","(Language=*)");
>>>
>>> ServiceReference[]
>>> sb=bc.getAllServiceReferences("tutorial.example2.service.DictionaryService","(Language=*)");
>>>
>>> if(sb !=null)
>>> {
>>> for(int j=0;j>> {
>>> Log.d("FELIX","registered services:
>>> "+sb[j].toString());
>>> ERROR --->DictionaryService d=(DictionaryService) sb[j];
>>> boolean b=d.checkWord("the");
>>> }
>>> }
>>> else
>>> {
>>> Log.d("FELIX","No registered services");
>>> }
>>> }
>>> catch { ... }
>>>
>>>
>>> The log is:
>>> 02-22 15:06:30.734: DEBUG/FELIX(759): registered services:
>>> [tutorial.example2.service.DictionaryService]
>>> 02-22 15:09:51.754: DEBUG/Felix(863): Could not create framework:
>>> java.lang.ClassCastException:
>>> org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl
>>>
>>>
>>> Somebody can help me for make an instance of a service? I don't know how
>>> I
>>> can obtain it. Thanks,
>>> Pablo
>>>
>>> --
>>> View this message in context:
>>> http://old.nabble.com/Felix-embeded-in-Android---problem-for-instantiate-a-Service.-tp27688984p27688984.html
>>> Sent from the Apache Felix - Dev mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>>
>> --
>> Karl Pauls
>> karlpa...@gmail.com
>>
>>
>
> --
> View this message in context:
> http://old.nabble.com/Felix-embeded-in-Android---problem-for-instantiate-a-Service.-tp27688984p27690380.html
> Sent from the Apache Felix - Dev mailing list archive at Nabble.com.
>
>
--
Toni Menzel
Independent Software Developer
Professional Profile: http://okidokiteam.com
t...@okidokiteam.com
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.
Re: Felix embeded in Android - problem for instantiate a Service.
Good day Karl,
I also proved
ds=(DictionaryService) bc.getService(sb[j]);
but also generates a class exception.
02-22 16:47:14.794: DEBUG/Felix(2365): Could not create framework:
java.lang.ClassCastException: tutorial.example2b.Activator$DictionaryImpl
I'm sorry. I know that it is maybe an OSGi problem...but I think that maybe
someone here could help me.
I continue with this. Thank you for answer,
Pablo.
Karl Pauls wrote:
>
> You are trying to cast a servicereference to a service object. That
> doesn't work. You need to first get the real service by:
>
> bc.getService(sb[j]);
>
> Nothing to do with android btw. - just osgi.
> regards,
>
> Karl
>
> On Mon, Feb 22, 2010 at 4:28 PM, pablomj wrote:
>>
>> Good day, I trying embedding Felix in Android. I installed some bundles
>> (English Dictionary, French Dictionary, Spellchecker...). Well, the
>> program
>> compiles but I can't instanciate a DictionaryService for use for example
>> d.checkword("the");
>>
>> The code is:
>>
>>
>> try {
>> m_felix.start();
>>
>> BundleContext bc=m_felix.getBundleContext();
>> bc.installBundle("file:/data/felix/EnglishDictionary.jar");
>> bc.installBundle("file:/data/felix/FrenchDictionary.jar");
>> bc.installBundle("file:/data/felix/SpellChecker.jar");
>>
>> //start all bundles
>> org.osgi.framework.Bundle[] bs=bc.getBundles();
>> for(int i=0; i>
>> //get registered services
>> ServiceReference[]
>> sb=bc.getAllServiceReferences("tutorial.example2.service.DictionaryService","(Language=*)");
>>
>> ServiceReference[]
>> sb=bc.getAllServiceReferences("tutorial.example2.service.DictionaryService","(Language=*)");
>>
>> if(sb !=null)
>> {
>> for(int j=0;j> {
>> Log.d("FELIX","registered services:
>> "+sb[j].toString());
>> ERROR --->DictionaryService d=(DictionaryService) sb[j];
>> boolean b=d.checkWord("the");
>> }
>> }
>> else
>> {
>> Log.d("FELIX","No registered services");
>> }
>> }
>> catch { ... }
>>
>>
>> The log is:
>> 02-22 15:06:30.734: DEBUG/FELIX(759): registered services:
>> [tutorial.example2.service.DictionaryService]
>> 02-22 15:09:51.754: DEBUG/Felix(863): Could not create framework:
>> java.lang.ClassCastException:
>> org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl
>>
>>
>> Somebody can help me for make an instance of a service? I don't know how
>> I
>> can obtain it. Thanks,
>> Pablo
>>
>> --
>> View this message in context:
>> http://old.nabble.com/Felix-embeded-in-Android---problem-for-instantiate-a-Service.-tp27688984p27688984.html
>> Sent from the Apache Felix - Dev mailing list archive at Nabble.com.
>>
>>
>
>
>
> --
> Karl Pauls
> karlpa...@gmail.com
>
>
--
View this message in context:
http://old.nabble.com/Felix-embeded-in-Android---problem-for-instantiate-a-Service.-tp27688984p27690380.html
Sent from the Apache Felix - Dev mailing list archive at Nabble.com.
[jira] Commented: (FELIX-2108) The log4j from felix launcher is messing up felix osgi container
[
https://issues.apache.org/jira/browse/FELIX-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12836712#action_12836712
]
Shrini Joshi commented on FELIX-2108:
-
Karl,
Please give it a go and share your findings.
Thanks
> The log4j from felix launcher is messing up felix osgi container
> -
>
> Key: FELIX-2108
> URL: https://issues.apache.org/jira/browse/FELIX-2108
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: felix-1.4.1
>Reporter: Shrini Joshi
> Attachments: felix-launcher.zip, log4jconfig_1.0.0.jar,
> osgi-simple-service.zip
>
>
> This issue is not type question rather than a bug
> I have created a launcher programme which is responsible for laoding the
> config values and instantiating the felix container (1.4.1).
> Everything is working fine except for one small glitch. Please take a look
> for following error message thrown by the log4j bundle.
> The launcher programme is using log4j for logging. But when it starts the
> felix container, log4j bundle is installed since it is used by the
> application itself.
> I have listed deployed bundles further below.
> My view is, the log4j library loaded by launcher is visible to felix
> container and hence log4j bundle fails to start cleanly. This is going to be
> a big problem for dpeloyment.
> I am using felix 1.4.1, is that too old to be good?
> Is there any setting that I need to pass to instruct the felix to create
> comepletly new classloader as system-classloader? Being a OSGI container I
> expected it to create new class-loader as system-classloader but now I feel
> it does not.
> Can someome please help me understand?
> Shrini
> ===
> log4j: reset attribute= "false".
> log4j: Threshold ="null".
> log4j: Level value for root is [DEBUG].
> log4j: root level set to DEBUG
> log4j: Class name: [org.apache.log4j.RollingFileAppender]
> log4j: Setting property [file] to [**/launcher.log].
> log4j: Setting property [append] to [true].
> log4j: Setting property [maxFileSize] to [10MB].
> log4j: Setting property [maxBackupIndex] to [15].
> log4j: Parsing layout of class: "org.apache.log4j.PatternLayout"
> log4j: Setting property [conversionPattern] to [%d{dd MMM HH:mm:ss,SSS}
> %t %-5p %c{2} - %m%n].
> log4j: setFile called: **/launcher.log, true
> log4j: setFile ended
> log4j: Adding appender named [FILE] to category [root].
> -> log4j:ERROR A "org.apache.log4j.xml.DOMConfigurator" object is not
> assignable to a "org.apache.log4j.spi.Configurator" variable.
> log4j:ERROR The class "org.apache.log4j.spi.Configurator" was loaded by
> log4j:ERROR [6.0] whereas object of type
> log4j:ERROR "org.apache.log4j.xml.DOMConfigurator" was loaded by
> [sun.misc.launcher$appclassloa...@17182c1].
> log4j:ERROR Could not instantiate configurator
> [org.apache.log4j.xml.DOMConfigurator].
> log4j:WARN No appenders could be found for logger
> (org.springframework.osgi.extender.internal.activator.ContextLoaderListener).
> log4j:WARN Please initialize the log4j system properly.
> =
> [ 0] [Active ] [0] System Bundle (2.0.1)
> [ 1] [Active ] [5] AOP Alliance API (1.0.0)
> [ 2] [Active ] [5] Apache Commons Collections (3.2.0)
> [ 3] [Active ] [5] Apache Commons Lang (2.4.0)
> [ 4] [Active ] [5] Apache Commons Logging (1.1.1)
> [ 5] [Active ] [5] Apache Commons Pool (1.3.0)
> [ 6] [Active ] [5] Apache Log4J (1.2.15)
> [ 7] [Active ] [5] Apache Felix Bundle Repository (1.4.2)
> [ 8] [Active ] [5] Apache Felix Shell Service (1.4.1)
> [ 9] [Active ] [5] Apache Felix Shell TUI (1.4.1)
> [ 10] [Active ] [5] Spring AOP (2.5.6)
> [ 11] [Active ] [5] Spring Beans (2.5.6)
> [ 12] [Active ] [5] Spring Context (2.5.6)
> [ 13] [Active ] [5] Spring Context Support (2.5.6)
> [ 14] [Active ] [5] Spring Core (2.5.6)
> [ 15] [Active ] [5] spring-osgi-core (1.2.1)
> [ 16] [Active ] [5] spring-osgi-extender (1.2.1)
> [ 17] [Active ] [5] spring-osgi-io (1.2.1)
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2108) The log4j from felix launcher is messing up felix osgi container
[
https://issues.apache.org/jira/browse/FELIX-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shrini Joshi updated FELIX-2108:
Attachment: log4jconfig_1.0.0.jar
log4j config fragment bundle
> The log4j from felix launcher is messing up felix osgi container
> -
>
> Key: FELIX-2108
> URL: https://issues.apache.org/jira/browse/FELIX-2108
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: felix-1.4.1
>Reporter: Shrini Joshi
> Attachments: felix-launcher.zip, log4jconfig_1.0.0.jar,
> osgi-simple-service.zip
>
>
> This issue is not type question rather than a bug
> I have created a launcher programme which is responsible for laoding the
> config values and instantiating the felix container (1.4.1).
> Everything is working fine except for one small glitch. Please take a look
> for following error message thrown by the log4j bundle.
> The launcher programme is using log4j for logging. But when it starts the
> felix container, log4j bundle is installed since it is used by the
> application itself.
> I have listed deployed bundles further below.
> My view is, the log4j library loaded by launcher is visible to felix
> container and hence log4j bundle fails to start cleanly. This is going to be
> a big problem for dpeloyment.
> I am using felix 1.4.1, is that too old to be good?
> Is there any setting that I need to pass to instruct the felix to create
> comepletly new classloader as system-classloader? Being a OSGI container I
> expected it to create new class-loader as system-classloader but now I feel
> it does not.
> Can someome please help me understand?
> Shrini
> ===
> log4j: reset attribute= "false".
> log4j: Threshold ="null".
> log4j: Level value for root is [DEBUG].
> log4j: root level set to DEBUG
> log4j: Class name: [org.apache.log4j.RollingFileAppender]
> log4j: Setting property [file] to [**/launcher.log].
> log4j: Setting property [append] to [true].
> log4j: Setting property [maxFileSize] to [10MB].
> log4j: Setting property [maxBackupIndex] to [15].
> log4j: Parsing layout of class: "org.apache.log4j.PatternLayout"
> log4j: Setting property [conversionPattern] to [%d{dd MMM HH:mm:ss,SSS}
> %t %-5p %c{2} - %m%n].
> log4j: setFile called: **/launcher.log, true
> log4j: setFile ended
> log4j: Adding appender named [FILE] to category [root].
> -> log4j:ERROR A "org.apache.log4j.xml.DOMConfigurator" object is not
> assignable to a "org.apache.log4j.spi.Configurator" variable.
> log4j:ERROR The class "org.apache.log4j.spi.Configurator" was loaded by
> log4j:ERROR [6.0] whereas object of type
> log4j:ERROR "org.apache.log4j.xml.DOMConfigurator" was loaded by
> [sun.misc.launcher$appclassloa...@17182c1].
> log4j:ERROR Could not instantiate configurator
> [org.apache.log4j.xml.DOMConfigurator].
> log4j:WARN No appenders could be found for logger
> (org.springframework.osgi.extender.internal.activator.ContextLoaderListener).
> log4j:WARN Please initialize the log4j system properly.
> =
> [ 0] [Active ] [0] System Bundle (2.0.1)
> [ 1] [Active ] [5] AOP Alliance API (1.0.0)
> [ 2] [Active ] [5] Apache Commons Collections (3.2.0)
> [ 3] [Active ] [5] Apache Commons Lang (2.4.0)
> [ 4] [Active ] [5] Apache Commons Logging (1.1.1)
> [ 5] [Active ] [5] Apache Commons Pool (1.3.0)
> [ 6] [Active ] [5] Apache Log4J (1.2.15)
> [ 7] [Active ] [5] Apache Felix Bundle Repository (1.4.2)
> [ 8] [Active ] [5] Apache Felix Shell Service (1.4.1)
> [ 9] [Active ] [5] Apache Felix Shell TUI (1.4.1)
> [ 10] [Active ] [5] Spring AOP (2.5.6)
> [ 11] [Active ] [5] Spring Beans (2.5.6)
> [ 12] [Active ] [5] Spring Context (2.5.6)
> [ 13] [Active ] [5] Spring Context Support (2.5.6)
> [ 14] [Active ] [5] Spring Core (2.5.6)
> [ 15] [Active ] [5] spring-osgi-core (1.2.1)
> [ 16] [Active ] [5] spring-osgi-extender (1.2.1)
> [ 17] [Active ] [5] spring-osgi-io (1.2.1)
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2108) The log4j from felix launcher is messing up felix osgi container
[
https://issues.apache.org/jira/browse/FELIX-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shrini Joshi updated FELIX-2108:
Attachment: felix-launcher.zip
osgi-simple-service.zip
I have attached two projects.
felix-launcher: This is a launcher project. it contains the complete project
with dependencies.
osgi-simple-service: This is a simple project that creates two servic bundles
both using log4j
> The log4j from felix launcher is messing up felix osgi container
> -
>
> Key: FELIX-2108
> URL: https://issues.apache.org/jira/browse/FELIX-2108
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: felix-1.4.1
>Reporter: Shrini Joshi
> Attachments: felix-launcher.zip, osgi-simple-service.zip
>
>
> This issue is not type question rather than a bug
> I have created a launcher programme which is responsible for laoding the
> config values and instantiating the felix container (1.4.1).
> Everything is working fine except for one small glitch. Please take a look
> for following error message thrown by the log4j bundle.
> The launcher programme is using log4j for logging. But when it starts the
> felix container, log4j bundle is installed since it is used by the
> application itself.
> I have listed deployed bundles further below.
> My view is, the log4j library loaded by launcher is visible to felix
> container and hence log4j bundle fails to start cleanly. This is going to be
> a big problem for dpeloyment.
> I am using felix 1.4.1, is that too old to be good?
> Is there any setting that I need to pass to instruct the felix to create
> comepletly new classloader as system-classloader? Being a OSGI container I
> expected it to create new class-loader as system-classloader but now I feel
> it does not.
> Can someome please help me understand?
> Shrini
> ===
> log4j: reset attribute= "false".
> log4j: Threshold ="null".
> log4j: Level value for root is [DEBUG].
> log4j: root level set to DEBUG
> log4j: Class name: [org.apache.log4j.RollingFileAppender]
> log4j: Setting property [file] to [**/launcher.log].
> log4j: Setting property [append] to [true].
> log4j: Setting property [maxFileSize] to [10MB].
> log4j: Setting property [maxBackupIndex] to [15].
> log4j: Parsing layout of class: "org.apache.log4j.PatternLayout"
> log4j: Setting property [conversionPattern] to [%d{dd MMM HH:mm:ss,SSS}
> %t %-5p %c{2} - %m%n].
> log4j: setFile called: **/launcher.log, true
> log4j: setFile ended
> log4j: Adding appender named [FILE] to category [root].
> -> log4j:ERROR A "org.apache.log4j.xml.DOMConfigurator" object is not
> assignable to a "org.apache.log4j.spi.Configurator" variable.
> log4j:ERROR The class "org.apache.log4j.spi.Configurator" was loaded by
> log4j:ERROR [6.0] whereas object of type
> log4j:ERROR "org.apache.log4j.xml.DOMConfigurator" was loaded by
> [sun.misc.launcher$appclassloa...@17182c1].
> log4j:ERROR Could not instantiate configurator
> [org.apache.log4j.xml.DOMConfigurator].
> log4j:WARN No appenders could be found for logger
> (org.springframework.osgi.extender.internal.activator.ContextLoaderListener).
> log4j:WARN Please initialize the log4j system properly.
> =
> [ 0] [Active ] [0] System Bundle (2.0.1)
> [ 1] [Active ] [5] AOP Alliance API (1.0.0)
> [ 2] [Active ] [5] Apache Commons Collections (3.2.0)
> [ 3] [Active ] [5] Apache Commons Lang (2.4.0)
> [ 4] [Active ] [5] Apache Commons Logging (1.1.1)
> [ 5] [Active ] [5] Apache Commons Pool (1.3.0)
> [ 6] [Active ] [5] Apache Log4J (1.2.15)
> [ 7] [Active ] [5] Apache Felix Bundle Repository (1.4.2)
> [ 8] [Active ] [5] Apache Felix Shell Service (1.4.1)
> [ 9] [Active ] [5] Apache Felix Shell TUI (1.4.1)
> [ 10] [Active ] [5] Spring AOP (2.5.6)
> [ 11] [Active ] [5] Spring Beans (2.5.6)
> [ 12] [Active ] [5] Spring Context (2.5.6)
> [ 13] [Active ] [5] Spring Context Support (2.5.6)
> [ 14] [Active ] [5] Spring Core (2.5.6)
> [ 15] [Active ] [5] spring-osgi-core (1.2.1)
> [ 16] [Active ] [5] spring-osgi-extender (1.2.1)
> [ 17] [Active ] [5] spring-osgi-io (1.2.1)
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Felix embeded in Android - problem for instantiate a Service.
You are trying to cast a servicereference to a service object. That
doesn't work. You need to first get the real service by:
bc.getService(sb[j]);
Nothing to do with android btw. - just osgi.
regards,
Karl
On Mon, Feb 22, 2010 at 4:28 PM, pablomj wrote:
>
> Good day, I trying embedding Felix in Android. I installed some bundles
> (English Dictionary, French Dictionary, Spellchecker...). Well, the program
> compiles but I can't instanciate a DictionaryService for use for example
> d.checkword("the");
>
> The code is:
>
>
> try {
> m_felix.start();
>
> BundleContext bc=m_felix.getBundleContext();
> bc.installBundle("file:/data/felix/EnglishDictionary.jar");
> bc.installBundle("file:/data/felix/FrenchDictionary.jar");
> bc.installBundle("file:/data/felix/SpellChecker.jar");
>
> //start all bundles
> org.osgi.framework.Bundle[] bs=bc.getBundles();
> for(int i=0; i
> //get registered services
> ServiceReference[]
> sb=bc.getAllServiceReferences("tutorial.example2.service.DictionaryService","(Language=*)");
>
> ServiceReference[]
> sb=bc.getAllServiceReferences("tutorial.example2.service.DictionaryService","(Language=*)");
>
> if(sb !=null)
> {
> for(int j=0;j {
> Log.d("FELIX","registered services:
> "+sb[j].toString());
> ERROR --->DictionaryService d=(DictionaryService) sb[j];
> boolean b=d.checkWord("the");
> }
> }
> else
> {
> Log.d("FELIX","No registered services");
> }
> }
> catch { ... }
>
>
> The log is:
> 02-22 15:06:30.734: DEBUG/FELIX(759): registered services:
> [tutorial.example2.service.DictionaryService]
> 02-22 15:09:51.754: DEBUG/Felix(863): Could not create framework:
> java.lang.ClassCastException:
> org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl
>
>
> Somebody can help me for make an instance of a service? I don't know how I
> can obtain it. Thanks,
> Pablo
>
> --
> View this message in context:
> http://old.nabble.com/Felix-embeded-in-Android---problem-for-instantiate-a-Service.-tp27688984p27688984.html
> Sent from the Apache Felix - Dev mailing list archive at Nabble.com.
>
>
--
Karl Pauls
karlpa...@gmail.com
[jira] Created: (FELIX-2121) ProSyst donation of UPnP plugin for the web console
ProSyst donation of UPnP plugin for the web console --- Key: FELIX-2121 URL: https://issues.apache.org/jira/browse/FELIX-2121 Project: Felix Issue Type: Improvement Components: Web Console Reporter: Valentin Valchev Attachments: upnp_plugin.zip This plugin is similar to the UPnP Test application but developed as a plugin for the Web Console. It is developed as standalone plugin - e.g. not build-into the Apache Web Console but is separate bundle. This allows the plugin to dynamically register/unregister itself. This way the plugin is available only when UPnP Service is active. Unfortunately I'm not quite aware with maven since most of our projects use ANT. Otherwise I was going to create the full maven structure required to build it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2121) ProSyst donation of UPnP plugin for the web console
[ https://issues.apache.org/jira/browse/FELIX-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Valchev updated FELIX-2121: Attachment: upnp_plugin.zip > ProSyst donation of UPnP plugin for the web console > --- > > Key: FELIX-2121 > URL: https://issues.apache.org/jira/browse/FELIX-2121 > Project: Felix > Issue Type: Improvement > Components: Web Console >Reporter: Valentin Valchev > Attachments: upnp_plugin.zip > > > This plugin is similar to the UPnP Test application but developed as a plugin > for the Web Console. > It is developed as standalone plugin - e.g. not build-into the Apache Web > Console but is separate bundle. > This allows the plugin to dynamically register/unregister itself. This way > the plugin is available only when UPnP Service is active. > Unfortunately I'm not quite aware with maven since most of our projects use > ANT. Otherwise I was going to create the full maven structure required to > build it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2120) OBR plugin should hide the repository table, if OBR service is not available
[ https://issues.apache.org/jira/browse/FELIX-2120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Valchev updated FELIX-2120: Attachment: obr_hide.patch > OBR plugin should hide the repository table, if OBR service is not available > > > Key: FELIX-2120 > URL: https://issues.apache.org/jira/browse/FELIX-2120 > Project: Felix > Issue Type: Bug > Components: Web Console >Reporter: Valentin Valchev > Attachments: obr_hide.patch > > > patch attached -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2120) OBR plugin should hide the repository table, if OBR service is not available
OBR plugin should hide the repository table, if OBR service is not available Key: FELIX-2120 URL: https://issues.apache.org/jira/browse/FELIX-2120 Project: Felix Issue Type: Bug Components: Web Console Reporter: Valentin Valchev Attachments: obr_hide.patch patch attached -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2119) Bundle update fails, if OBR is not installed
Bundle update fails, if OBR is not installed Key: FELIX-2119 URL: https://issues.apache.org/jira/browse/FELIX-2119 Project: Felix Issue Type: Bug Components: Web Console Reporter: Valentin Valchev The reason for this is that UpdateHelper depends on OBR service API. While OBR is not a core service, its absence shouldn't disallow execution of normal bundle life-cycle commands. Stack trace: Exception: java.lang.NoClassDefFoundError: [Lorg/osgi/service/obr/Resource; at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Unknown Source) at java.lang.Class.getDeclaredMethod(Unknown Source) at java.lang.Thread$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.lang.Thread.auditSubclass(Unknown Source) at java.lang.Thread.isCCLOverridden(Unknown Source) at java.lang.Thread.init(Unknown Source) at java.lang.Thread.(Unknown Source) at org.apache.felix.webconsole.internal.core.BaseUpdateInstallHelper.(BaseUpdateInstallHelper.java:45) at org.apache.felix.webconsole.internal.core.UpdateHelper.(UpdateHelper.java:52) at org.apache.felix.webconsole.internal.core.UpdateHelper.(UpdateHelper.java:46) at org.apache.felix.webconsole.internal.core.BundlesServlet$4.(BundlesServlet.java:1283) at org.apache.felix.webconsole.internal.core.BundlesServlet.update(BundlesServlet.java:1282) at org.apache.felix.webconsole.internal.core.BundlesServlet.doPost(BundlesServlet.java:312) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at javax.servlet.http.HttpServlet.service(HttpServlet.java:815) at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:372) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Felix embeded in Android - problem for instantiate a Service.
Good day, I trying embedding Felix in Android. I installed some bundles
(English Dictionary, French Dictionary, Spellchecker...). Well, the program
compiles but I can't instanciate a DictionaryService for use for example
d.checkword("the");
The code is:
try {
m_felix.start();
BundleContext bc=m_felix.getBundleContext();
bc.installBundle("file:/data/felix/EnglishDictionary.jar");
bc.installBundle("file:/data/felix/FrenchDictionary.jar");
bc.installBundle("file:/data/felix/SpellChecker.jar");
//start all bundles
org.osgi.framework.Bundle[] bs=bc.getBundles();
for(int i=0; iDictionaryService d=(DictionaryService) sb[j];
boolean b=d.checkWord("the");
}
}
else
{
Log.d("FELIX","No registered services");
}
}
catch { ... }
The log is:
02-22 15:06:30.734: DEBUG/FELIX(759): registered services:
[tutorial.example2.service.DictionaryService]
02-22 15:09:51.754: DEBUG/Felix(863): Could not create framework:
java.lang.ClassCastException:
org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl
Somebody can help me for make an instance of a service? I don't know how I
can obtain it. Thanks,
Pablo
--
View this message in context:
http://old.nabble.com/Felix-embeded-in-Android---problem-for-instantiate-a-Service.-tp27688984p27688984.html
Sent from the Apache Felix - Dev mailing list archive at Nabble.com.
Re: Felix on Android
Great, thanks Karl. On 22/02/2010 12:04, "Karl Pauls" wrote: > That was just the plain android adb logcat output. It works even if > you start your own vm. > > regards, > > Karl > > On Mon, Feb 22, 2010 at 12:09 PM, Jackson, Bruce wrote: >> When I was discussing with Karl the other day, he provided me with the debug >> output below showing the classloading behaviour. Does anyone know if this >> came from Felix or Dalvik debug tools, and whether I can see the >> classloading behavior in Felix? >> >> >> On 17/02/2010 16:49, "Karl Pauls" wrote: >> >>> As I said, it will only happen if you have the importing classes and >>> the exporting classes dexed into the same classes.dex. In your jdom >>> case that should not happen as the embedded jar will have it's own >>> classes.dex so that the "root" classes.dex of your bundle is different >>> from the embedded one (again, that is the hack you can use to work >>> around this issue in general). >>> >>> regards, >>> >>> Karl >>> >>> On Wed, Feb 17, 2010 at 5:32 PM, Jackson, Bruce wrote: Hi Karl That's great, thanks! I've got it working too now. Obviously the classloading mechanism in Dalvik is different to a regular jvm, as you don't see this problem in Felix on the JVM. Is this likely to cause a similar problem in bundles which have been built with an embedded jar (imagine I place something like jdom into a bundle) and the framework also has a jdom bundle installed? Thanks again Bruce On 16/02/2010 23:40, "Karl Pauls" wrote: > Wait, i got it working (i.e., i get to the point where your example > fails). The reason is this: > > W/dalvikvm( 326): Class resolved by unexpected DEX: > Lorg/mortbay/jetty/servlet/ServletHandler$Context;(0x400a0288):0x68578 > ref [Ljavax/servlet/ServletContext;] > Ljavax/servlet/ServletContext;(0x4002eec0):0x5ef48 > W/dalvikvm( 326): (Lorg/mortbay/jetty/servlet/ServletHandler$Context; > had used a different Ljavax/servlet/ServletContext; during > pre-verification) > I/dalvikvm( 326): Failed resolving > Lorg/mortbay/jetty/servlet/ServletHandler$Context; interface 195 > 'Ljavax/servlet/ServletContext;' > W/dalvikvm( 326): Link of class > 'Lorg/mortbay/jetty/servlet/ServletHandler$Context;' failed > E/dalvikvm( 326): ERROR: defineClass(0x400a0288, > org.mortbay.jetty.servlet.ServletHandler$Context, 0x401d6268, 0, 6067, > 0x401b4b28) > > The problem is as follows: the http jetty bundle contains its own > version of the javax.servlet packages. When you are dexing that > bundle. You are including this version inside the classes.dex. Now, in > your set-up, you are importing them at runtime from the javax.servlet > bundle. That causes the above problem (as the dex is already bound). > If you uninstall the javax.servlet bundle (and change the import > version constraint inside your test bundle for the javax.servlet* > packages to be 2.3.0 instead of 2.4.0 - in which case it will resolve > to the http bundle). Then it works: > > -> ps > START LEVEL 1 > ID State Level Name > [ 0] [Active ] [ 0] System Bundle (2.0.3) > [ 1] [Active ] [ 1] Apache Felix Shell Service (1.0.2) > [ 2] [Active ] [ 1] Apache Felix Shell TUI (1.0.2) > [ 5] [Active ] [ 1] Apache Felix Log Service (1.0.0) > [ 6] [Active ] [ 1] HTTP Service (0.8.0.SNAPSHOT) > [ 7] [Active ] [ 1] Apache Felix Configuration Admin Service > (1.2.4) > [ 10] [Installed ] [ 1] Httptest (1.0.0.201002151713) > -> start 10 > Feb 16, 2010 11:29:22 PM java.io.BufferedWriter > INFO: Default buffer size used in BufferedWriter constructor. It would > be better to be explicit if an 8k-char buffer is required. > DEBUG: WIRE: 10.0 -> javax.servlet -> 6.0 > DEBUG: WIRE: 10.0 -> org.osgi.service.http -> 6.0 > DEBUG: WIRE: 10.0 -> org.osgi.framework -> 0 > DEBUG: WIRE: 10.0 -> javax.servlet.http -> 6.0 > DEBUG: javax/servlet/http/LocalStrings_en_US.properties > DEBUG: javax/servlet/http/LocalStrings_en.properties > DEBUG: org/mortbay/http/mime_en_US.properties > DEBUG: org/mortbay/http/mime_en.properties > DEBUG: org/mortbay/http/encoding_en_US.properties > DEBUG: org/mortbay/http/encoding_en.properties > 23:29:23.644 EVENT Started ServletHttpContext[/] > > The point is this: if you are dexing a bunch of classes, they will > already know about each other and then can't be imported from some > place else. The workaround in this case would be to remove the > javax.servlet* packages from the http bundle in the first place or (in > case you need the optionality) make them a separate jar, dex it, and > put it on the bundleclasspath of the http bundle (this way, the rest > of the ht
[jira] Resolved: (FELIX-1988) Integrate jQuery UI integration into the Web Console Trunk
[ https://issues.apache.org/jira/browse/FELIX-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-1988. -- Resolution: Fixed Having applied the last patch, I think we can now resolve this issue fixed. I would like to thank Valentin Valchev very much for the great work he put into the production of these patches and for the resulting JQuery UI based web console. > Integrate jQuery UI integration into the Web Console Trunk > -- > > Key: FELIX-1988 > URL: https://issues.apache.org/jira/browse/FELIX-1988 > Project: Felix > Issue Type: Task > Components: Web Console >Affects Versions: webconsole-2.0.4 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: webconsole-3.0.0 > > Attachments: 10.deployment_plugin.patch, 11.shell_plugin.patch, > 12.bundles_plugin.patch, 13.components_plugin.patch, > 14.configmgr_plugin.patch, 15.config_render_plugin.patch, > 16.license_plugin.patch, 17.finishing_touches.patch, > 18.configuration_printer_load_on_demand.patch, 19.assorted1.patch, > 2.use-utility-methods.patch, 20.obr_plugin.patch, 21.assorted2.patch, > 22.assorted3.patch, 3.javadoc-public-api.patch, > 4.webconsole_src_main_resources_res_lib.zip, 5.main_template.patch, > 6.vmstat.patch, 7.services.patch, 8.abstractconsolefix_and_props.patch, > 9.logs_plugin.patch, abstr-simple-web-console2.patch, > bundle_bg.raw_properties, src.zip > > > Valentin Valchev has implemented jQuery UI support in the web console. This > issue is to keep track of this migration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-1959) Move towards unified L&F and extended branding support
[ https://issues.apache.org/jira/browse/FELIX-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-1959. -- Resolution: Fixed Fix Version/s: webconsole-3.0.0 Assignee: Felix Meschberger (was: Carsten Ziegeler) This can be considered implemented/fixed as of FELIX-1988 > Move towards unified L&F and extended branding support > -- > > Key: FELIX-1959 > URL: https://issues.apache.org/jira/browse/FELIX-1959 > Project: Felix > Issue Type: New Feature > Components: Web Console >Reporter: Valentin Valchev >Assignee: Felix Meschberger >Priority: Minor > Fix For: webconsole-3.0.0 > > Attachments: jqueryui-vs-default-lnf.png, tb6.jar, tb6_1.0.1.jar > > > Currently the Web Console uses heavily on the JQuery framework. Using a > unified JavaScript framework simplifies development of all plugins and > unifies the used approach. > However, when talking about visual styling, there are number of differences > because each plugin developer uses own styles. > My suggestion is to adopt the JQuery UI . The benefits of using it as unified > widget/css framework are: > - no time to spend on writing widgets already in the library > - clean CSS visual styling > - easy way to change the L&F by changing the theme (extended branding > support!) > - improved cross-browser support (JQuery UI takes care of CSS differences) > Using the JQuery UI framework the developer shouldn't care about color but > only for layout - components position; and for data being displayed. > To illustrate the benefits I've saved the "Log Service" page, modified it to > use JQuery UI, took screen-shot, modified the theme CSS only, and again took > screen-shot, and finally added the original L&F for reference, so you can > easily compare the result. > The attached image contains the combined screen-shots. > " -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-1956) Collect duplicate & reusable code in WebConsoleUtil
[ https://issues.apache.org/jira/browse/FELIX-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-1956. -- Resolution: Fixed As part of FELIX-1988 duplicate code has now been cleaned up and collected in the WebConsoleUtil class. > Collect duplicate & reusable code in WebConsoleUtil > --- > > Key: FELIX-1956 > URL: https://issues.apache.org/jira/browse/FELIX-1956 > Project: Felix > Issue Type: Improvement > Components: Web Console >Affects Versions: webconsole-2.0.4 >Reporter: Valentin Valchev >Assignee: Felix Meschberger >Priority: Trivial > Fix For: webconsole-3.0.0 > > Attachments: eclipse-warnings-duplicate-code.patch > > > I've looked at the Web Console code and found some common methods that are > used in the plugins. These methods can be reused by third party plugins and > it would be nice, if they are exported as new class WebConsoleUtil. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1988) Integrate jQuery UI integration into the Web Console Trunk
[ https://issues.apache.org/jira/browse/FELIX-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12836638#action_12836638 ] Felix Meschberger commented on FELIX-1988: -- Applied 22.assorted3.patch in Rev. 912577. > Integrate jQuery UI integration into the Web Console Trunk > -- > > Key: FELIX-1988 > URL: https://issues.apache.org/jira/browse/FELIX-1988 > Project: Felix > Issue Type: Task > Components: Web Console >Affects Versions: webconsole-2.0.4 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: webconsole-3.0.0 > > Attachments: 10.deployment_plugin.patch, 11.shell_plugin.patch, > 12.bundles_plugin.patch, 13.components_plugin.patch, > 14.configmgr_plugin.patch, 15.config_render_plugin.patch, > 16.license_plugin.patch, 17.finishing_touches.patch, > 18.configuration_printer_load_on_demand.patch, 19.assorted1.patch, > 2.use-utility-methods.patch, 20.obr_plugin.patch, 21.assorted2.patch, > 22.assorted3.patch, 3.javadoc-public-api.patch, > 4.webconsole_src_main_resources_res_lib.zip, 5.main_template.patch, > 6.vmstat.patch, 7.services.patch, 8.abstractconsolefix_and_props.patch, > 9.logs_plugin.patch, abstr-simple-web-console2.patch, > bundle_bg.raw_properties, src.zip > > > Valentin Valchev has implemented jQuery UI support in the web console. This > issue is to keep track of this migration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-957) Migrate Bundle Repository Page to JQuery
[ https://issues.apache.org/jira/browse/FELIX-957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-957. - Resolution: Fixed Fix Version/s: webconsole-3.0.0 Assignee: Felix Meschberger As part of FELIX-1988 the bundle repository page has been migrated to using JQuery UI > Migrate Bundle Repository Page to JQuery > > > Key: FELIX-957 > URL: https://issues.apache.org/jira/browse/FELIX-957 > Project: Felix > Issue Type: Improvement > Components: Web Console >Affects Versions: webconsole-1.2.2 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: webconsole-3.0.0 > > > It looks like JQuery is becoming the client side tool of choice for the web > console. Consequently the bundle repository page should also be migrated to > JQuery. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1988) Integrate jQuery UI integration into the Web Console Trunk
[ https://issues.apache.org/jira/browse/FELIX-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12836637#action_12836637 ] Felix Meschberger commented on FELIX-1988: -- Committed the bulgarian tranlations in Rev. 912575 along with pom.xml setup to automatically convert to ISO-8859-1. The file itself has its mime type property set such, that it should check-out as UTF-8 > Integrate jQuery UI integration into the Web Console Trunk > -- > > Key: FELIX-1988 > URL: https://issues.apache.org/jira/browse/FELIX-1988 > Project: Felix > Issue Type: Task > Components: Web Console >Affects Versions: webconsole-2.0.4 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: webconsole-3.0.0 > > Attachments: 10.deployment_plugin.patch, 11.shell_plugin.patch, > 12.bundles_plugin.patch, 13.components_plugin.patch, > 14.configmgr_plugin.patch, 15.config_render_plugin.patch, > 16.license_plugin.patch, 17.finishing_touches.patch, > 18.configuration_printer_load_on_demand.patch, 19.assorted1.patch, > 2.use-utility-methods.patch, 20.obr_plugin.patch, 21.assorted2.patch, > 22.assorted3.patch, 3.javadoc-public-api.patch, > 4.webconsole_src_main_resources_res_lib.zip, 5.main_template.patch, > 6.vmstat.patch, 7.services.patch, 8.abstractconsolefix_and_props.patch, > 9.logs_plugin.patch, abstr-simple-web-console2.patch, > bundle_bg.raw_properties, src.zip > > > Valentin Valchev has implemented jQuery UI support in the web console. This > issue is to keep track of this migration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FELIX-1007) OBR search doesn't take 'categories' into account
[ https://issues.apache.org/jira/browse/FELIX-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned FELIX-1007: -- Assignee: Guillaume Nodet > OBR search doesn't take 'categories' into account > - > > Key: FELIX-1007 > URL: https://issues.apache.org/jira/browse/FELIX-1007 > Project: Felix > Issue Type: Bug > Components: Bundle Repository (OBR) >Reporter: Kristian Koehler >Assignee: Guillaume Nodet > Attachments: categoriesQueryPatch_2009_03_27.txt > > > Hi > the RFC-0112 Bundle Repository document says: "The element defines > a category. The purpose is to easy the discovery." and the description of the > method org.osgi.servicex.obr. RepositoryAdmin#discoverResources says "The > attributes that can be checked are: [...] category" but filtering resources > with a given category doesn't work. The following filter is "meaningless": > "(category:*>sampleCategory)" > Kristian -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-1421) Filter bundles within OBR lacks support for capabilities/services
[ https://issues.apache.org/jira/browse/FELIX-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved FELIX-1421. Resolution: Duplicate Assignee: Guillaume Nodet I'm closing this issue as a duplicate of FELIX-2109 as I think your use case is solved. Please reopen and provide more informations if that's not the case. > Filter bundles within OBR lacks support for capabilities/services > - > > Key: FELIX-1421 > URL: https://issues.apache.org/jira/browse/FELIX-1421 > Project: Felix > Issue Type: Bug > Components: Bundle Repository (OBR) >Reporter: Kristian Koehler >Assignee: Guillaume Nodet > Attachments: FELIX-1421_29_07_2009.txt > > > Hi > as described on the mailing list > (http://www.mail-archive.com/us...@felix.apache.org/msg05122.html) the filter > mechanism for OBR doesn't support "capability filtering". > Defining a filter like: > --- 8< --- > '(service=org.apache.felix.shell.Command)' > --- 8< --- > doesn't work for bundles with such meta data: > --- 8< --- > > > > --- 8< --- > Kristian -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2115) The api offers no way to have a timeout or cancel the resolution if it takes too long
[ https://issues.apache.org/jira/browse/FELIX-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved FELIX-2115. Resolution: Fixed Fix Version/s: bundlerepository-1.6.0 Assignee: Guillaume Nodet Committing to https://svn.apache.org/repos/asf/felix/trunk ... M bundlerepository/src/main/java/org/apache/felix/bundlerepository/ResolverImpl.java M bundlerepository/src/test/java/org/apache/felix/bundlerepository/ResolverImplTest.java A org.osgi.service.obr/src/main/java/org/osgi/service/obr/InterrupteResolutionException.java M org.osgi.service.obr/src/main/java/org/osgi/service/obr/Resolver.java Committed r912549 I've added an exception instead of throwing a RuntimeException so that users can handle that one correctly. > The api offers no way to have a timeout or cancel the resolution if it takes > too long > - > > Key: FELIX-2115 > URL: https://issues.apache.org/jira/browse/FELIX-2115 > Project: Felix > Issue Type: Improvement > Components: Bundle Repository (OBR) >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet > Fix For: bundlerepository-1.6.0 > > > One way would be either to add some methods to the Resolver such as: >boolean resolve(long timeout) >void cancel(); > I'd be much happier if we could use a Future instead. >Future resolve(); > This would make it easier for the user because he doesn't have to start a > thread on its own. > However this breaks compatibility. > We could therefore use something like: >Future startResolve(); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2108) The log4j from felix launcher is messing up felix osgi container
[
https://issues.apache.org/jira/browse/FELIX-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12836592#action_12836592
]
Karl Pauls commented on FELIX-2108:
---
can you attach your project to the issue?
> The log4j from felix launcher is messing up felix osgi container
> -
>
> Key: FELIX-2108
> URL: https://issues.apache.org/jira/browse/FELIX-2108
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: felix-1.4.1
>Reporter: Shrini Joshi
>
> This issue is not type question rather than a bug
> I have created a launcher programme which is responsible for laoding the
> config values and instantiating the felix container (1.4.1).
> Everything is working fine except for one small glitch. Please take a look
> for following error message thrown by the log4j bundle.
> The launcher programme is using log4j for logging. But when it starts the
> felix container, log4j bundle is installed since it is used by the
> application itself.
> I have listed deployed bundles further below.
> My view is, the log4j library loaded by launcher is visible to felix
> container and hence log4j bundle fails to start cleanly. This is going to be
> a big problem for dpeloyment.
> I am using felix 1.4.1, is that too old to be good?
> Is there any setting that I need to pass to instruct the felix to create
> comepletly new classloader as system-classloader? Being a OSGI container I
> expected it to create new class-loader as system-classloader but now I feel
> it does not.
> Can someome please help me understand?
> Shrini
> ===
> log4j: reset attribute= "false".
> log4j: Threshold ="null".
> log4j: Level value for root is [DEBUG].
> log4j: root level set to DEBUG
> log4j: Class name: [org.apache.log4j.RollingFileAppender]
> log4j: Setting property [file] to [**/launcher.log].
> log4j: Setting property [append] to [true].
> log4j: Setting property [maxFileSize] to [10MB].
> log4j: Setting property [maxBackupIndex] to [15].
> log4j: Parsing layout of class: "org.apache.log4j.PatternLayout"
> log4j: Setting property [conversionPattern] to [%d{dd MMM HH:mm:ss,SSS}
> %t %-5p %c{2} - %m%n].
> log4j: setFile called: **/launcher.log, true
> log4j: setFile ended
> log4j: Adding appender named [FILE] to category [root].
> -> log4j:ERROR A "org.apache.log4j.xml.DOMConfigurator" object is not
> assignable to a "org.apache.log4j.spi.Configurator" variable.
> log4j:ERROR The class "org.apache.log4j.spi.Configurator" was loaded by
> log4j:ERROR [6.0] whereas object of type
> log4j:ERROR "org.apache.log4j.xml.DOMConfigurator" was loaded by
> [sun.misc.launcher$appclassloa...@17182c1].
> log4j:ERROR Could not instantiate configurator
> [org.apache.log4j.xml.DOMConfigurator].
> log4j:WARN No appenders could be found for logger
> (org.springframework.osgi.extender.internal.activator.ContextLoaderListener).
> log4j:WARN Please initialize the log4j system properly.
> =
> [ 0] [Active ] [0] System Bundle (2.0.1)
> [ 1] [Active ] [5] AOP Alliance API (1.0.0)
> [ 2] [Active ] [5] Apache Commons Collections (3.2.0)
> [ 3] [Active ] [5] Apache Commons Lang (2.4.0)
> [ 4] [Active ] [5] Apache Commons Logging (1.1.1)
> [ 5] [Active ] [5] Apache Commons Pool (1.3.0)
> [ 6] [Active ] [5] Apache Log4J (1.2.15)
> [ 7] [Active ] [5] Apache Felix Bundle Repository (1.4.2)
> [ 8] [Active ] [5] Apache Felix Shell Service (1.4.1)
> [ 9] [Active ] [5] Apache Felix Shell TUI (1.4.1)
> [ 10] [Active ] [5] Spring AOP (2.5.6)
> [ 11] [Active ] [5] Spring Beans (2.5.6)
> [ 12] [Active ] [5] Spring Context (2.5.6)
> [ 13] [Active ] [5] Spring Context Support (2.5.6)
> [ 14] [Active ] [5] Spring Core (2.5.6)
> [ 15] [Active ] [5] spring-osgi-core (1.2.1)
> [ 16] [Active ] [5] spring-osgi-extender (1.2.1)
> [ 17] [Active ] [5] spring-osgi-io (1.2.1)
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Felix on Android
That was just the plain android adb logcat output. It works even if you start your own vm. regards, Karl On Mon, Feb 22, 2010 at 12:09 PM, Jackson, Bruce wrote: > When I was discussing with Karl the other day, he provided me with the debug > output below showing the classloading behaviour. Does anyone know if this > came from Felix or Dalvik debug tools, and whether I can see the > classloading behavior in Felix? > > > On 17/02/2010 16:49, "Karl Pauls" wrote: > >> As I said, it will only happen if you have the importing classes and >> the exporting classes dexed into the same classes.dex. In your jdom >> case that should not happen as the embedded jar will have it's own >> classes.dex so that the "root" classes.dex of your bundle is different >> from the embedded one (again, that is the hack you can use to work >> around this issue in general). >> >> regards, >> >> Karl >> >> On Wed, Feb 17, 2010 at 5:32 PM, Jackson, Bruce wrote: >>> Hi Karl >>> >>> That's great, thanks! I've got it working too now. Obviously the >>> classloading mechanism in Dalvik is different to a regular jvm, as you don't >>> see this problem in Felix on the JVM. >>> >>> Is this likely to cause a similar problem in bundles which have been built >>> with an embedded jar (imagine I place something like jdom into a bundle) and >>> the framework also has a jdom bundle installed? >>> >>> Thanks again >>> >>> Bruce >>> >>> On 16/02/2010 23:40, "Karl Pauls" wrote: >>> Wait, i got it working (i.e., i get to the point where your example fails). The reason is this: W/dalvikvm( 326): Class resolved by unexpected DEX: Lorg/mortbay/jetty/servlet/ServletHandler$Context;(0x400a0288):0x68578 ref [Ljavax/servlet/ServletContext;] Ljavax/servlet/ServletContext;(0x4002eec0):0x5ef48 W/dalvikvm( 326): (Lorg/mortbay/jetty/servlet/ServletHandler$Context; had used a different Ljavax/servlet/ServletContext; during pre-verification) I/dalvikvm( 326): Failed resolving Lorg/mortbay/jetty/servlet/ServletHandler$Context; interface 195 'Ljavax/servlet/ServletContext;' W/dalvikvm( 326): Link of class 'Lorg/mortbay/jetty/servlet/ServletHandler$Context;' failed E/dalvikvm( 326): ERROR: defineClass(0x400a0288, org.mortbay.jetty.servlet.ServletHandler$Context, 0x401d6268, 0, 6067, 0x401b4b28) The problem is as follows: the http jetty bundle contains its own version of the javax.servlet packages. When you are dexing that bundle. You are including this version inside the classes.dex. Now, in your set-up, you are importing them at runtime from the javax.servlet bundle. That causes the above problem (as the dex is already bound). If you uninstall the javax.servlet bundle (and change the import version constraint inside your test bundle for the javax.servlet* packages to be 2.3.0 instead of 2.4.0 - in which case it will resolve to the http bundle). Then it works: -> ps START LEVEL 1 ID State Level Name [ 0] [Active ] [ 0] System Bundle (2.0.3) [ 1] [Active ] [ 1] Apache Felix Shell Service (1.0.2) [ 2] [Active ] [ 1] Apache Felix Shell TUI (1.0.2) [ 5] [Active ] [ 1] Apache Felix Log Service (1.0.0) [ 6] [Active ] [ 1] HTTP Service (0.8.0.SNAPSHOT) [ 7] [Active ] [ 1] Apache Felix Configuration Admin Service (1.2.4) [ 10] [Installed ] [ 1] Httptest (1.0.0.201002151713) -> start 10 Feb 16, 2010 11:29:22 PM java.io.BufferedWriter INFO: Default buffer size used in BufferedWriter constructor. It would be better to be explicit if an 8k-char buffer is required. DEBUG: WIRE: 10.0 -> javax.servlet -> 6.0 DEBUG: WIRE: 10.0 -> org.osgi.service.http -> 6.0 DEBUG: WIRE: 10.0 -> org.osgi.framework -> 0 DEBUG: WIRE: 10.0 -> javax.servlet.http -> 6.0 DEBUG: javax/servlet/http/LocalStrings_en_US.properties DEBUG: javax/servlet/http/LocalStrings_en.properties DEBUG: org/mortbay/http/mime_en_US.properties DEBUG: org/mortbay/http/mime_en.properties DEBUG: org/mortbay/http/encoding_en_US.properties DEBUG: org/mortbay/http/encoding_en.properties 23:29:23.644 EVENT Started ServletHttpContext[/] The point is this: if you are dexing a bunch of classes, they will already know about each other and then can't be imported from some place else. The workaround in this case would be to remove the javax.servlet* packages from the http bundle in the first place or (in case you need the optionality) make them a separate jar, dex it, and put it on the bundleclasspath of the http bundle (this way, the rest of the http bundle classes are not dexed together with the imported javax.servlet classes in the same dex). No bug in felix or a problem with the complier level. Its just one of the points where
[jira] Commented: (FELIX-2108) The log4j from felix launcher is messing up felix osgi container
[
https://issues.apache.org/jira/browse/FELIX-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12836589#action_12836589
]
Shrini Joshi commented on FELIX-2108:
-
Is this issues liked to FELIX-962 ?
> The log4j from felix launcher is messing up felix osgi container
> -
>
> Key: FELIX-2108
> URL: https://issues.apache.org/jira/browse/FELIX-2108
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: felix-1.4.1
>Reporter: Shrini Joshi
>
> This issue is not type question rather than a bug
> I have created a launcher programme which is responsible for laoding the
> config values and instantiating the felix container (1.4.1).
> Everything is working fine except for one small glitch. Please take a look
> for following error message thrown by the log4j bundle.
> The launcher programme is using log4j for logging. But when it starts the
> felix container, log4j bundle is installed since it is used by the
> application itself.
> I have listed deployed bundles further below.
> My view is, the log4j library loaded by launcher is visible to felix
> container and hence log4j bundle fails to start cleanly. This is going to be
> a big problem for dpeloyment.
> I am using felix 1.4.1, is that too old to be good?
> Is there any setting that I need to pass to instruct the felix to create
> comepletly new classloader as system-classloader? Being a OSGI container I
> expected it to create new class-loader as system-classloader but now I feel
> it does not.
> Can someome please help me understand?
> Shrini
> ===
> log4j: reset attribute= "false".
> log4j: Threshold ="null".
> log4j: Level value for root is [DEBUG].
> log4j: root level set to DEBUG
> log4j: Class name: [org.apache.log4j.RollingFileAppender]
> log4j: Setting property [file] to [**/launcher.log].
> log4j: Setting property [append] to [true].
> log4j: Setting property [maxFileSize] to [10MB].
> log4j: Setting property [maxBackupIndex] to [15].
> log4j: Parsing layout of class: "org.apache.log4j.PatternLayout"
> log4j: Setting property [conversionPattern] to [%d{dd MMM HH:mm:ss,SSS}
> %t %-5p %c{2} - %m%n].
> log4j: setFile called: **/launcher.log, true
> log4j: setFile ended
> log4j: Adding appender named [FILE] to category [root].
> -> log4j:ERROR A "org.apache.log4j.xml.DOMConfigurator" object is not
> assignable to a "org.apache.log4j.spi.Configurator" variable.
> log4j:ERROR The class "org.apache.log4j.spi.Configurator" was loaded by
> log4j:ERROR [6.0] whereas object of type
> log4j:ERROR "org.apache.log4j.xml.DOMConfigurator" was loaded by
> [sun.misc.launcher$appclassloa...@17182c1].
> log4j:ERROR Could not instantiate configurator
> [org.apache.log4j.xml.DOMConfigurator].
> log4j:WARN No appenders could be found for logger
> (org.springframework.osgi.extender.internal.activator.ContextLoaderListener).
> log4j:WARN Please initialize the log4j system properly.
> =
> [ 0] [Active ] [0] System Bundle (2.0.1)
> [ 1] [Active ] [5] AOP Alliance API (1.0.0)
> [ 2] [Active ] [5] Apache Commons Collections (3.2.0)
> [ 3] [Active ] [5] Apache Commons Lang (2.4.0)
> [ 4] [Active ] [5] Apache Commons Logging (1.1.1)
> [ 5] [Active ] [5] Apache Commons Pool (1.3.0)
> [ 6] [Active ] [5] Apache Log4J (1.2.15)
> [ 7] [Active ] [5] Apache Felix Bundle Repository (1.4.2)
> [ 8] [Active ] [5] Apache Felix Shell Service (1.4.1)
> [ 9] [Active ] [5] Apache Felix Shell TUI (1.4.1)
> [ 10] [Active ] [5] Spring AOP (2.5.6)
> [ 11] [Active ] [5] Spring Beans (2.5.6)
> [ 12] [Active ] [5] Spring Context (2.5.6)
> [ 13] [Active ] [5] Spring Context Support (2.5.6)
> [ 14] [Active ] [5] Spring Core (2.5.6)
> [ 15] [Active ] [5] spring-osgi-core (1.2.1)
> [ 16] [Active ] [5] spring-osgi-extender (1.2.1)
> [ 17] [Active ] [5] spring-osgi-io (1.2.1)
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (FELIX-2108) The log4j from felix launcher is messing up felix osgi container
[
https://issues.apache.org/jira/browse/FELIX-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12836589#action_12836589
]
Shrini Joshi edited comment on FELIX-2108 at 2/22/10 12:02 PM:
---
Is this issues linked to FELIX-962 ?
was (Author: shreeneewas):
Is this issues liked to FELIX-962 ?
> The log4j from felix launcher is messing up felix osgi container
> -
>
> Key: FELIX-2108
> URL: https://issues.apache.org/jira/browse/FELIX-2108
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: felix-1.4.1
>Reporter: Shrini Joshi
>
> This issue is not type question rather than a bug
> I have created a launcher programme which is responsible for laoding the
> config values and instantiating the felix container (1.4.1).
> Everything is working fine except for one small glitch. Please take a look
> for following error message thrown by the log4j bundle.
> The launcher programme is using log4j for logging. But when it starts the
> felix container, log4j bundle is installed since it is used by the
> application itself.
> I have listed deployed bundles further below.
> My view is, the log4j library loaded by launcher is visible to felix
> container and hence log4j bundle fails to start cleanly. This is going to be
> a big problem for dpeloyment.
> I am using felix 1.4.1, is that too old to be good?
> Is there any setting that I need to pass to instruct the felix to create
> comepletly new classloader as system-classloader? Being a OSGI container I
> expected it to create new class-loader as system-classloader but now I feel
> it does not.
> Can someome please help me understand?
> Shrini
> ===
> log4j: reset attribute= "false".
> log4j: Threshold ="null".
> log4j: Level value for root is [DEBUG].
> log4j: root level set to DEBUG
> log4j: Class name: [org.apache.log4j.RollingFileAppender]
> log4j: Setting property [file] to [**/launcher.log].
> log4j: Setting property [append] to [true].
> log4j: Setting property [maxFileSize] to [10MB].
> log4j: Setting property [maxBackupIndex] to [15].
> log4j: Parsing layout of class: "org.apache.log4j.PatternLayout"
> log4j: Setting property [conversionPattern] to [%d{dd MMM HH:mm:ss,SSS}
> %t %-5p %c{2} - %m%n].
> log4j: setFile called: **/launcher.log, true
> log4j: setFile ended
> log4j: Adding appender named [FILE] to category [root].
> -> log4j:ERROR A "org.apache.log4j.xml.DOMConfigurator" object is not
> assignable to a "org.apache.log4j.spi.Configurator" variable.
> log4j:ERROR The class "org.apache.log4j.spi.Configurator" was loaded by
> log4j:ERROR [6.0] whereas object of type
> log4j:ERROR "org.apache.log4j.xml.DOMConfigurator" was loaded by
> [sun.misc.launcher$appclassloa...@17182c1].
> log4j:ERROR Could not instantiate configurator
> [org.apache.log4j.xml.DOMConfigurator].
> log4j:WARN No appenders could be found for logger
> (org.springframework.osgi.extender.internal.activator.ContextLoaderListener).
> log4j:WARN Please initialize the log4j system properly.
> =
> [ 0] [Active ] [0] System Bundle (2.0.1)
> [ 1] [Active ] [5] AOP Alliance API (1.0.0)
> [ 2] [Active ] [5] Apache Commons Collections (3.2.0)
> [ 3] [Active ] [5] Apache Commons Lang (2.4.0)
> [ 4] [Active ] [5] Apache Commons Logging (1.1.1)
> [ 5] [Active ] [5] Apache Commons Pool (1.3.0)
> [ 6] [Active ] [5] Apache Log4J (1.2.15)
> [ 7] [Active ] [5] Apache Felix Bundle Repository (1.4.2)
> [ 8] [Active ] [5] Apache Felix Shell Service (1.4.1)
> [ 9] [Active ] [5] Apache Felix Shell TUI (1.4.1)
> [ 10] [Active ] [5] Spring AOP (2.5.6)
> [ 11] [Active ] [5] Spring Beans (2.5.6)
> [ 12] [Active ] [5] Spring Context (2.5.6)
> [ 13] [Active ] [5] Spring Context Support (2.5.6)
> [ 14] [Active ] [5] Spring Core (2.5.6)
> [ 15] [Active ] [5] spring-osgi-core (1.2.1)
> [ 16] [Active ] [5] spring-osgi-extender (1.2.1)
> [ 17] [Active ] [5] spring-osgi-io (1.2.1)
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2116) JRE packages & org.osgi.framework.BundleException: Unresolved constraint
[ https://issues.apache.org/jira/browse/FELIX-2116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charles Moulliard resolved FELIX-2116. -- Resolution: Fixed As we have a workaround and that it is not related to an issue with the framework of felix, I propose to close it. > JRE packages & org.osgi.framework.BundleException: Unresolved constraint > > > Key: FELIX-2116 > URL: https://issues.apache.org/jira/browse/FELIX-2116 > Project: Felix > Issue Type: Bug > Components: Karaf >Affects Versions: karaf-1.2.0 >Reporter: Charles Moulliard > > Here is more details about the unresolved constraint > Here is what the bundle import : > ka...@root> headers 117 > MAESTRO :: SOA Fw :: WebServices (117) > -- > Bnd-LastModified = 1266589733099 > Build-Jdk = 1.6.0_16 > Built-By = T0106319 > Bundle-ManifestVersion = 2 > Bundle-Name = MAESTRO :: SOA Fw :: WebServices > Bundle-SymbolicName = maestro_SOAFw_WebServices > Bundle-Version = 0.4.0.migr-42-SNAPSHOT > Created-By = Apache Maven Bundle Plugin > DynamicImport-Package = javax.*,org.w3c.*,org.xml.* > Export-Package = > com.thalesgroup.maestro.wsdl.system.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.event;uses:="javax.jws.soap,javax.jws,javax.xml.bind.annotation,com.thalesgroup.maestro.wsdl.event.xsd,javax.xml.ws,javax.xml.namespace",com.thalesgroup.maestro.wsdl.sop.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",wsdl,com.thalesgroup.maestro.wsdl.status.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.alarm.x > sd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.alarm;uses:="javax.jws.soap,javax.jws,com.thalesgroup.maestro.wsdl.alarm.xsd,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace",com.thalesgroup.maestro.wsdl.event.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.system;uses:="javax.jws.soap,com.thalesgroup.maestro.wsdl.system.xsd,javax.jws,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace",com.thalesgroup.ma > estro.wsdl.command.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.status;uses:="javax.jws.soap,javax.jws,com.thalesgroup.maestro.wsdl.status.xsd,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace",com.thalesgroup.maestro.wsdl.command;uses:="javax.jws.soap,javax.jws,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace,com.thalesgroup.maestro.wsdl.command.xsd",com.thalesgroup.maestro.wsdl.sop;uses:="javax.jws.soap,com.thalesgroup.maestro.wsdl.so > p.xsd,javax.jws,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace" > Import-Package = > com.thalesgroup.maestro.wsdl.alarm,com.thalesgroup.maestro.wsdl.alarm.xsd,com.thalesgroup.maestro.wsdl.command,com.thalesgroup.maestro.wsdl.command.xsd,com.thalesgroup.maestro.wsdl.event,com.thalesgroup.maestro.wsdl.event.xsd,com.thalesgroup.maestro.wsdl.sop,com.thalesgroup.maestro.wsdl.sop.xsd,com.thalesgroup.maestro.wsdl.status,com.thalesgroup.maestro.wsdl.status.xsd,com.thalesgroup.maestro.wsdl.system,com.thalesgroup.maestro.wsdl.system.xsd,javax.jws;version="2.0",javax.jws.s > oap;version="2.0",javax.xml.bind.annotation;version="2.1",javax.xml.datatype;version="1.4",javax.xml.namespace;version="1.4",javax.xml.ws;version="2.1",wsdl > Manifest-Version = 1.0 > Tool = Bnd-0.0.238 > ka...@root> > So we see that the bundle import the following package : > javax.xml.datatype;version="1.4" and that > DynamicImport-Package = javax.*,org.w3c.*,org.xml.* has been defined > And the error generated : > DEBUG: DYNAMIC WIRE: 114.0 -> org.apache.camel.spi -> 44.0 > DEBUG: META-INF/services/javax.xml.parsers.DocumentBuilderFactory > DEBUG: META-INF/services/javax.xml.parsers.DocumentBuilderFactory > ERROR: Error starting > file:/D:/Dev/apache-servicemix-4.2.0-fuse-01-00/deploy/maestro-webservices-0.4.0-migr-4.2-SNAPSHOT.jar > (org.osgi.framework.BundleException: Unresolved constraint in bundle > maestro_SOAFw_WebServices [117]: package; > (&(package=javax.xml.datatype)(version>=1.4.0))) > org.osgi.framework.BundleException: Unresolved constraint in bundle > maestro_SOAFw_WebServices [117]: package; > (&(package=javax.xml.datatype)(version>=1.4.0)) > DEBUG: DYNAMIC WIRE: 114.0 -> com.sun.org.apache.xerces.internal.jaxp -> 0 > DEBUG: DYNAMIC WIRE: 114.0 -> org.xml.sax -> 0 at > org.apache.felix.framework.Felix.resolveBundle(Felix.java:3263) > at org.apache.felix.framework.Felix.startBundle(Felix.java:1597) > at > org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1077) > at > org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264) > at java.lang.Thread.run(Thread.java:619) > If we ch
[jira] Commented: (FELIX-2116) JRE packages & org.osgi.framework.BundleException: Unresolved constraint
[ https://issues.apache.org/jira/browse/FELIX-2116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12836579#action_12836579 ] Richard S. Hall commented on FELIX-2116: I don't recall if you are creating this bundle. If so, you could use "javax.*;version=0.0.0,*" in your BND import-package instruction to remove the version. > JRE packages & org.osgi.framework.BundleException: Unresolved constraint > > > Key: FELIX-2116 > URL: https://issues.apache.org/jira/browse/FELIX-2116 > Project: Felix > Issue Type: Bug > Components: Karaf >Affects Versions: karaf-1.2.0 >Reporter: Charles Moulliard > > Here is more details about the unresolved constraint > Here is what the bundle import : > ka...@root> headers 117 > MAESTRO :: SOA Fw :: WebServices (117) > -- > Bnd-LastModified = 1266589733099 > Build-Jdk = 1.6.0_16 > Built-By = T0106319 > Bundle-ManifestVersion = 2 > Bundle-Name = MAESTRO :: SOA Fw :: WebServices > Bundle-SymbolicName = maestro_SOAFw_WebServices > Bundle-Version = 0.4.0.migr-42-SNAPSHOT > Created-By = Apache Maven Bundle Plugin > DynamicImport-Package = javax.*,org.w3c.*,org.xml.* > Export-Package = > com.thalesgroup.maestro.wsdl.system.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.event;uses:="javax.jws.soap,javax.jws,javax.xml.bind.annotation,com.thalesgroup.maestro.wsdl.event.xsd,javax.xml.ws,javax.xml.namespace",com.thalesgroup.maestro.wsdl.sop.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",wsdl,com.thalesgroup.maestro.wsdl.status.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.alarm.x > sd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.alarm;uses:="javax.jws.soap,javax.jws,com.thalesgroup.maestro.wsdl.alarm.xsd,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace",com.thalesgroup.maestro.wsdl.event.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.system;uses:="javax.jws.soap,com.thalesgroup.maestro.wsdl.system.xsd,javax.jws,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace",com.thalesgroup.ma > estro.wsdl.command.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.status;uses:="javax.jws.soap,javax.jws,com.thalesgroup.maestro.wsdl.status.xsd,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace",com.thalesgroup.maestro.wsdl.command;uses:="javax.jws.soap,javax.jws,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace,com.thalesgroup.maestro.wsdl.command.xsd",com.thalesgroup.maestro.wsdl.sop;uses:="javax.jws.soap,com.thalesgroup.maestro.wsdl.so > p.xsd,javax.jws,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace" > Import-Package = > com.thalesgroup.maestro.wsdl.alarm,com.thalesgroup.maestro.wsdl.alarm.xsd,com.thalesgroup.maestro.wsdl.command,com.thalesgroup.maestro.wsdl.command.xsd,com.thalesgroup.maestro.wsdl.event,com.thalesgroup.maestro.wsdl.event.xsd,com.thalesgroup.maestro.wsdl.sop,com.thalesgroup.maestro.wsdl.sop.xsd,com.thalesgroup.maestro.wsdl.status,com.thalesgroup.maestro.wsdl.status.xsd,com.thalesgroup.maestro.wsdl.system,com.thalesgroup.maestro.wsdl.system.xsd,javax.jws;version="2.0",javax.jws.s > oap;version="2.0",javax.xml.bind.annotation;version="2.1",javax.xml.datatype;version="1.4",javax.xml.namespace;version="1.4",javax.xml.ws;version="2.1",wsdl > Manifest-Version = 1.0 > Tool = Bnd-0.0.238 > ka...@root> > So we see that the bundle import the following package : > javax.xml.datatype;version="1.4" and that > DynamicImport-Package = javax.*,org.w3c.*,org.xml.* has been defined > And the error generated : > DEBUG: DYNAMIC WIRE: 114.0 -> org.apache.camel.spi -> 44.0 > DEBUG: META-INF/services/javax.xml.parsers.DocumentBuilderFactory > DEBUG: META-INF/services/javax.xml.parsers.DocumentBuilderFactory > ERROR: Error starting > file:/D:/Dev/apache-servicemix-4.2.0-fuse-01-00/deploy/maestro-webservices-0.4.0-migr-4.2-SNAPSHOT.jar > (org.osgi.framework.BundleException: Unresolved constraint in bundle > maestro_SOAFw_WebServices [117]: package; > (&(package=javax.xml.datatype)(version>=1.4.0))) > org.osgi.framework.BundleException: Unresolved constraint in bundle > maestro_SOAFw_WebServices [117]: package; > (&(package=javax.xml.datatype)(version>=1.4.0)) > DEBUG: DYNAMIC WIRE: 114.0 -> com.sun.org.apache.xerces.internal.jaxp -> 0 > DEBUG: DYNAMIC WIRE: 114.0 -> org.xml.sax -> 0 at > org.apache.felix.framework.Felix.resolveBundle(Felix.java:3263) > at org.apache.felix.framework.Felix.startBundle(Felix.java:1597) > at > org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1077) > at > org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.j
Re: Felix on Android
When I was discussing with Karl the other day, he provided me with the debug output below showing the classloading behaviour. Does anyone know if this came from Felix or Dalvik debug tools, and whether I can see the classloading behavior in Felix? On 17/02/2010 16:49, "Karl Pauls" wrote: > As I said, it will only happen if you have the importing classes and > the exporting classes dexed into the same classes.dex. In your jdom > case that should not happen as the embedded jar will have it's own > classes.dex so that the "root" classes.dex of your bundle is different > from the embedded one (again, that is the hack you can use to work > around this issue in general). > > regards, > > Karl > > On Wed, Feb 17, 2010 at 5:32 PM, Jackson, Bruce wrote: >> Hi Karl >> >> That's great, thanks! I've got it working too now. Obviously the >> classloading mechanism in Dalvik is different to a regular jvm, as you don't >> see this problem in Felix on the JVM. >> >> Is this likely to cause a similar problem in bundles which have been built >> with an embedded jar (imagine I place something like jdom into a bundle) and >> the framework also has a jdom bundle installed? >> >> Thanks again >> >> Bruce >> >> On 16/02/2010 23:40, "Karl Pauls" wrote: >> >>> Wait, i got it working (i.e., i get to the point where your example >>> fails). The reason is this: >>> >>> W/dalvikvm( 326): Class resolved by unexpected DEX: >>> Lorg/mortbay/jetty/servlet/ServletHandler$Context;(0x400a0288):0x68578 >>> ref [Ljavax/servlet/ServletContext;] >>> Ljavax/servlet/ServletContext;(0x4002eec0):0x5ef48 >>> W/dalvikvm( 326): (Lorg/mortbay/jetty/servlet/ServletHandler$Context; >>> had used a different Ljavax/servlet/ServletContext; during >>> pre-verification) >>> I/dalvikvm( 326): Failed resolving >>> Lorg/mortbay/jetty/servlet/ServletHandler$Context; interface 195 >>> 'Ljavax/servlet/ServletContext;' >>> W/dalvikvm( 326): Link of class >>> 'Lorg/mortbay/jetty/servlet/ServletHandler$Context;' failed >>> E/dalvikvm( 326): ERROR: defineClass(0x400a0288, >>> org.mortbay.jetty.servlet.ServletHandler$Context, 0x401d6268, 0, 6067, >>> 0x401b4b28) >>> >>> The problem is as follows: the http jetty bundle contains its own >>> version of the javax.servlet packages. When you are dexing that >>> bundle. You are including this version inside the classes.dex. Now, in >>> your set-up, you are importing them at runtime from the javax.servlet >>> bundle. That causes the above problem (as the dex is already bound). >>> If you uninstall the javax.servlet bundle (and change the import >>> version constraint inside your test bundle for the javax.servlet* >>> packages to be 2.3.0 instead of 2.4.0 - in which case it will resolve >>> to the http bundle). Then it works: >>> >>> -> ps >>> START LEVEL 1 >>> ID State Level Name >>> [ 0] [Active ] [ 0] System Bundle (2.0.3) >>> [ 1] [Active ] [ 1] Apache Felix Shell Service (1.0.2) >>> [ 2] [Active ] [ 1] Apache Felix Shell TUI (1.0.2) >>> [ 5] [Active ] [ 1] Apache Felix Log Service (1.0.0) >>> [ 6] [Active ] [ 1] HTTP Service (0.8.0.SNAPSHOT) >>> [ 7] [Active ] [ 1] Apache Felix Configuration Admin Service >>> (1.2.4) >>> [ 10] [Installed ] [ 1] Httptest (1.0.0.201002151713) >>> -> start 10 >>> Feb 16, 2010 11:29:22 PM java.io.BufferedWriter >>> INFO: Default buffer size used in BufferedWriter constructor. It would >>> be better to be explicit if an 8k-char buffer is required. >>> DEBUG: WIRE: 10.0 -> javax.servlet -> 6.0 >>> DEBUG: WIRE: 10.0 -> org.osgi.service.http -> 6.0 >>> DEBUG: WIRE: 10.0 -> org.osgi.framework -> 0 >>> DEBUG: WIRE: 10.0 -> javax.servlet.http -> 6.0 >>> DEBUG: javax/servlet/http/LocalStrings_en_US.properties >>> DEBUG: javax/servlet/http/LocalStrings_en.properties >>> DEBUG: org/mortbay/http/mime_en_US.properties >>> DEBUG: org/mortbay/http/mime_en.properties >>> DEBUG: org/mortbay/http/encoding_en_US.properties >>> DEBUG: org/mortbay/http/encoding_en.properties >>> 23:29:23.644 EVENT Started ServletHttpContext[/] >>> >>> The point is this: if you are dexing a bunch of classes, they will >>> already know about each other and then can't be imported from some >>> place else. The workaround in this case would be to remove the >>> javax.servlet* packages from the http bundle in the first place or (in >>> case you need the optionality) make them a separate jar, dex it, and >>> put it on the bundleclasspath of the http bundle (this way, the rest >>> of the http bundle classes are not dexed together with the imported >>> javax.servlet classes in the same dex). >>> >>> No bug in felix or a problem with the complier level. Its just one of >>> the points where dalvik is working differently than java... sorry, >>> nothing i can do about that. You will need to be careful when you are >>> dexing bundles to not dex classes inside the bundle that can be >>> substituted by an import together with the other classes of the
[jira] Commented: (FELIX-2108) The log4j from felix launcher is messing up felix osgi container
[
https://issues.apache.org/jira/browse/FELIX-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12836572#action_12836572
]
Shrini Joshi commented on FELIX-2108:
-
The launcher I mentioned above is a normal java programme which uses log4j for
its own use. It starts the felix container by passing configuration map to
felix framework and auto processor. (This is based on felix manual).
In short laucher does not deal with class-loader at all.
Hope this answers your question.
> The log4j from felix launcher is messing up felix osgi container
> -
>
> Key: FELIX-2108
> URL: https://issues.apache.org/jira/browse/FELIX-2108
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: felix-1.4.1
>Reporter: Shrini Joshi
>
> This issue is not type question rather than a bug
> I have created a launcher programme which is responsible for laoding the
> config values and instantiating the felix container (1.4.1).
> Everything is working fine except for one small glitch. Please take a look
> for following error message thrown by the log4j bundle.
> The launcher programme is using log4j for logging. But when it starts the
> felix container, log4j bundle is installed since it is used by the
> application itself.
> I have listed deployed bundles further below.
> My view is, the log4j library loaded by launcher is visible to felix
> container and hence log4j bundle fails to start cleanly. This is going to be
> a big problem for dpeloyment.
> I am using felix 1.4.1, is that too old to be good?
> Is there any setting that I need to pass to instruct the felix to create
> comepletly new classloader as system-classloader? Being a OSGI container I
> expected it to create new class-loader as system-classloader but now I feel
> it does not.
> Can someome please help me understand?
> Shrini
> ===
> log4j: reset attribute= "false".
> log4j: Threshold ="null".
> log4j: Level value for root is [DEBUG].
> log4j: root level set to DEBUG
> log4j: Class name: [org.apache.log4j.RollingFileAppender]
> log4j: Setting property [file] to [**/launcher.log].
> log4j: Setting property [append] to [true].
> log4j: Setting property [maxFileSize] to [10MB].
> log4j: Setting property [maxBackupIndex] to [15].
> log4j: Parsing layout of class: "org.apache.log4j.PatternLayout"
> log4j: Setting property [conversionPattern] to [%d{dd MMM HH:mm:ss,SSS}
> %t %-5p %c{2} - %m%n].
> log4j: setFile called: **/launcher.log, true
> log4j: setFile ended
> log4j: Adding appender named [FILE] to category [root].
> -> log4j:ERROR A "org.apache.log4j.xml.DOMConfigurator" object is not
> assignable to a "org.apache.log4j.spi.Configurator" variable.
> log4j:ERROR The class "org.apache.log4j.spi.Configurator" was loaded by
> log4j:ERROR [6.0] whereas object of type
> log4j:ERROR "org.apache.log4j.xml.DOMConfigurator" was loaded by
> [sun.misc.launcher$appclassloa...@17182c1].
> log4j:ERROR Could not instantiate configurator
> [org.apache.log4j.xml.DOMConfigurator].
> log4j:WARN No appenders could be found for logger
> (org.springframework.osgi.extender.internal.activator.ContextLoaderListener).
> log4j:WARN Please initialize the log4j system properly.
> =
> [ 0] [Active ] [0] System Bundle (2.0.1)
> [ 1] [Active ] [5] AOP Alliance API (1.0.0)
> [ 2] [Active ] [5] Apache Commons Collections (3.2.0)
> [ 3] [Active ] [5] Apache Commons Lang (2.4.0)
> [ 4] [Active ] [5] Apache Commons Logging (1.1.1)
> [ 5] [Active ] [5] Apache Commons Pool (1.3.0)
> [ 6] [Active ] [5] Apache Log4J (1.2.15)
> [ 7] [Active ] [5] Apache Felix Bundle Repository (1.4.2)
> [ 8] [Active ] [5] Apache Felix Shell Service (1.4.1)
> [ 9] [Active ] [5] Apache Felix Shell TUI (1.4.1)
> [ 10] [Active ] [5] Spring AOP (2.5.6)
> [ 11] [Active ] [5] Spring Beans (2.5.6)
> [ 12] [Active ] [5] Spring Context (2.5.6)
> [ 13] [Active ] [5] Spring Context Support (2.5.6)
> [ 14] [Active ] [5] Spring Core (2.5.6)
> [ 15] [Active ] [5] spring-osgi-core (1.2.1)
> [ 16] [Active ] [5] spring-osgi-extender (1.2.1)
> [ 17] [Active ] [5] spring-osgi-io (1.2.1)
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1988) Integrate jQuery UI integration into the Web Console Trunk
[ https://issues.apache.org/jira/browse/FELIX-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12836571#action_12836571 ] Felix Meschberger commented on FELIX-1988: -- > The only problem is in IE7 - the Licenses are not shown as a but in one > line. I remember once having had issues with loading stuff into a element with IE. Will look at this issue as FELIX-2118. Thanks for the last patch. As soon as I have applied your last patch and fixed the build to properly include your bulgarian translations, I will resolve this issues. Further issues should then be reported in new issues. Thanks alot. > Integrate jQuery UI integration into the Web Console Trunk > -- > > Key: FELIX-1988 > URL: https://issues.apache.org/jira/browse/FELIX-1988 > Project: Felix > Issue Type: Task > Components: Web Console >Affects Versions: webconsole-2.0.4 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: webconsole-3.0.0 > > Attachments: 10.deployment_plugin.patch, 11.shell_plugin.patch, > 12.bundles_plugin.patch, 13.components_plugin.patch, > 14.configmgr_plugin.patch, 15.config_render_plugin.patch, > 16.license_plugin.patch, 17.finishing_touches.patch, > 18.configuration_printer_load_on_demand.patch, 19.assorted1.patch, > 2.use-utility-methods.patch, 20.obr_plugin.patch, 21.assorted2.patch, > 22.assorted3.patch, 3.javadoc-public-api.patch, > 4.webconsole_src_main_resources_res_lib.zip, 5.main_template.patch, > 6.vmstat.patch, 7.services.patch, 8.abstractconsolefix_and_props.patch, > 9.logs_plugin.patch, abstr-simple-web-console2.patch, > bundle_bg.raw_properties, src.zip > > > Valentin Valchev has implemented jQuery UI support in the web console. This > issue is to keep track of this migration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2118) IE7 does not properly load license files into element
IE7 does not properly load license files into element --- Key: FELIX-2118 URL: https://issues.apache.org/jira/browse/FELIX-2118 Project: Felix Issue Type: Bug Components: Web Console Affects Versions: webconsole-3.0.0 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: webconsole-3.0.0 As of Rev. 912186 the LicenseServlet loads the license file data into a element using the JQuery load() function. This seems to not properly work in IE7. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1988) Integrate jQuery UI integration into the Web Console Trunk
[ https://issues.apache.org/jira/browse/FELIX-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12836560#action_12836560 ] Valentin Valchev commented on FELIX-1988: - By the way, now it looks almost the same way in IE7, Opera 10, Chromium and Firefox It looks really well in Chromium & Firefox - with rounded corners and nicer-looking buttons. but ... is damn fast in Opera. The only problem is in IE7 - the Licenses are not shown as a but in one line. > Integrate jQuery UI integration into the Web Console Trunk > -- > > Key: FELIX-1988 > URL: https://issues.apache.org/jira/browse/FELIX-1988 > Project: Felix > Issue Type: Task > Components: Web Console >Affects Versions: webconsole-2.0.4 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: webconsole-3.0.0 > > Attachments: 10.deployment_plugin.patch, 11.shell_plugin.patch, > 12.bundles_plugin.patch, 13.components_plugin.patch, > 14.configmgr_plugin.patch, 15.config_render_plugin.patch, > 16.license_plugin.patch, 17.finishing_touches.patch, > 18.configuration_printer_load_on_demand.patch, 19.assorted1.patch, > 2.use-utility-methods.patch, 20.obr_plugin.patch, 21.assorted2.patch, > 22.assorted3.patch, 3.javadoc-public-api.patch, > 4.webconsole_src_main_resources_res_lib.zip, 5.main_template.patch, > 6.vmstat.patch, 7.services.patch, 8.abstractconsolefix_and_props.patch, > 9.logs_plugin.patch, abstr-simple-web-console2.patch, > bundle_bg.raw_properties, src.zip > > > Valentin Valchev has implemented jQuery UI support in the web console. This > issue is to keep track of this migration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2116) JRE packages & org.osgi.framework.BundleException: Unresolved constraint
[ https://issues.apache.org/jira/browse/FELIX-2116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12836559#action_12836559 ] Charles Moulliard commented on FELIX-2116: -- @Richard, You are right. The DynamicImport statement is not used at all during the dependency resolution by Felix and the issue is related to the fact that Karaf exports all the JRE packages with version = '0.0.0'. In the example that I report here, the client uses the '*' in the Import-Package instruction to add automatically the packages. The plugin/bnd tool discovers maven transversal dependencies and add them as I mention with a version number. To solve this problem, I propose to the user to check which packages must be imported and add them manually. If he prefers to continue to work with '*' instruction, then he must parameter it like that : *;resolution:=optional > JRE packages & org.osgi.framework.BundleException: Unresolved constraint > > > Key: FELIX-2116 > URL: https://issues.apache.org/jira/browse/FELIX-2116 > Project: Felix > Issue Type: Bug > Components: Karaf >Affects Versions: karaf-1.2.0 >Reporter: Charles Moulliard > > Here is more details about the unresolved constraint > Here is what the bundle import : > ka...@root> headers 117 > MAESTRO :: SOA Fw :: WebServices (117) > -- > Bnd-LastModified = 1266589733099 > Build-Jdk = 1.6.0_16 > Built-By = T0106319 > Bundle-ManifestVersion = 2 > Bundle-Name = MAESTRO :: SOA Fw :: WebServices > Bundle-SymbolicName = maestro_SOAFw_WebServices > Bundle-Version = 0.4.0.migr-42-SNAPSHOT > Created-By = Apache Maven Bundle Plugin > DynamicImport-Package = javax.*,org.w3c.*,org.xml.* > Export-Package = > com.thalesgroup.maestro.wsdl.system.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.event;uses:="javax.jws.soap,javax.jws,javax.xml.bind.annotation,com.thalesgroup.maestro.wsdl.event.xsd,javax.xml.ws,javax.xml.namespace",com.thalesgroup.maestro.wsdl.sop.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",wsdl,com.thalesgroup.maestro.wsdl.status.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.alarm.x > sd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.alarm;uses:="javax.jws.soap,javax.jws,com.thalesgroup.maestro.wsdl.alarm.xsd,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace",com.thalesgroup.maestro.wsdl.event.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.system;uses:="javax.jws.soap,com.thalesgroup.maestro.wsdl.system.xsd,javax.jws,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace",com.thalesgroup.ma > estro.wsdl.command.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.status;uses:="javax.jws.soap,javax.jws,com.thalesgroup.maestro.wsdl.status.xsd,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace",com.thalesgroup.maestro.wsdl.command;uses:="javax.jws.soap,javax.jws,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace,com.thalesgroup.maestro.wsdl.command.xsd",com.thalesgroup.maestro.wsdl.sop;uses:="javax.jws.soap,com.thalesgroup.maestro.wsdl.so > p.xsd,javax.jws,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace" > Import-Package = > com.thalesgroup.maestro.wsdl.alarm,com.thalesgroup.maestro.wsdl.alarm.xsd,com.thalesgroup.maestro.wsdl.command,com.thalesgroup.maestro.wsdl.command.xsd,com.thalesgroup.maestro.wsdl.event,com.thalesgroup.maestro.wsdl.event.xsd,com.thalesgroup.maestro.wsdl.sop,com.thalesgroup.maestro.wsdl.sop.xsd,com.thalesgroup.maestro.wsdl.status,com.thalesgroup.maestro.wsdl.status.xsd,com.thalesgroup.maestro.wsdl.system,com.thalesgroup.maestro.wsdl.system.xsd,javax.jws;version="2.0",javax.jws.s > oap;version="2.0",javax.xml.bind.annotation;version="2.1",javax.xml.datatype;version="1.4",javax.xml.namespace;version="1.4",javax.xml.ws;version="2.1",wsdl > Manifest-Version = 1.0 > Tool = Bnd-0.0.238 > ka...@root> > So we see that the bundle import the following package : > javax.xml.datatype;version="1.4" and that > DynamicImport-Package = javax.*,org.w3c.*,org.xml.* has been defined > And the error generated : > DEBUG: DYNAMIC WIRE: 114.0 -> org.apache.camel.spi -> 44.0 > DEBUG: META-INF/services/javax.xml.parsers.DocumentBuilderFactory > DEBUG: META-INF/services/javax.xml.parsers.DocumentBuilderFactory > ERROR: Error starting > file:/D:/Dev/apache-servicemix-4.2.0-fuse-01-00/deploy/maestro-webservices-0.4.0-migr-4.2-SNAPSHOT.jar > (org.osgi.framework.BundleException: Unresolved constraint in bundle > maestro_SOAFw_WebServices [117]: package; > (&(package=javax.xml.datatype)(version>=1.4.0))) > org.osgi.framework.BundleException: Unresolved constraint in bund
[jira] Commented: (FELIX-2116) JRE packages & org.osgi.framework.BundleException: Unresolved constraint
[ https://issues.apache.org/jira/browse/FELIX-2116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12836554#action_12836554 ] Richard S. Hall commented on FELIX-2116: Not sure what you mean. Dynamic imports are not considered by the resolver at all, they are a run-time issue. Further, since your bundle imports javax.xml.datatype, it is not eligible for dynamic importation. The issue is, the bundle in question imports javax.xml.datatype;version=1.4.0, but there is no provider of this package with that version. > JRE packages & org.osgi.framework.BundleException: Unresolved constraint > > > Key: FELIX-2116 > URL: https://issues.apache.org/jira/browse/FELIX-2116 > Project: Felix > Issue Type: Bug > Components: Karaf >Affects Versions: karaf-1.2.0 >Reporter: Charles Moulliard > > Here is more details about the unresolved constraint > Here is what the bundle import : > ka...@root> headers 117 > MAESTRO :: SOA Fw :: WebServices (117) > -- > Bnd-LastModified = 1266589733099 > Build-Jdk = 1.6.0_16 > Built-By = T0106319 > Bundle-ManifestVersion = 2 > Bundle-Name = MAESTRO :: SOA Fw :: WebServices > Bundle-SymbolicName = maestro_SOAFw_WebServices > Bundle-Version = 0.4.0.migr-42-SNAPSHOT > Created-By = Apache Maven Bundle Plugin > DynamicImport-Package = javax.*,org.w3c.*,org.xml.* > Export-Package = > com.thalesgroup.maestro.wsdl.system.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.event;uses:="javax.jws.soap,javax.jws,javax.xml.bind.annotation,com.thalesgroup.maestro.wsdl.event.xsd,javax.xml.ws,javax.xml.namespace",com.thalesgroup.maestro.wsdl.sop.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",wsdl,com.thalesgroup.maestro.wsdl.status.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.alarm.x > sd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.alarm;uses:="javax.jws.soap,javax.jws,com.thalesgroup.maestro.wsdl.alarm.xsd,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace",com.thalesgroup.maestro.wsdl.event.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.system;uses:="javax.jws.soap,com.thalesgroup.maestro.wsdl.system.xsd,javax.jws,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace",com.thalesgroup.ma > estro.wsdl.command.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.status;uses:="javax.jws.soap,javax.jws,com.thalesgroup.maestro.wsdl.status.xsd,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace",com.thalesgroup.maestro.wsdl.command;uses:="javax.jws.soap,javax.jws,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace,com.thalesgroup.maestro.wsdl.command.xsd",com.thalesgroup.maestro.wsdl.sop;uses:="javax.jws.soap,com.thalesgroup.maestro.wsdl.so > p.xsd,javax.jws,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace" > Import-Package = > com.thalesgroup.maestro.wsdl.alarm,com.thalesgroup.maestro.wsdl.alarm.xsd,com.thalesgroup.maestro.wsdl.command,com.thalesgroup.maestro.wsdl.command.xsd,com.thalesgroup.maestro.wsdl.event,com.thalesgroup.maestro.wsdl.event.xsd,com.thalesgroup.maestro.wsdl.sop,com.thalesgroup.maestro.wsdl.sop.xsd,com.thalesgroup.maestro.wsdl.status,com.thalesgroup.maestro.wsdl.status.xsd,com.thalesgroup.maestro.wsdl.system,com.thalesgroup.maestro.wsdl.system.xsd,javax.jws;version="2.0",javax.jws.s > oap;version="2.0",javax.xml.bind.annotation;version="2.1",javax.xml.datatype;version="1.4",javax.xml.namespace;version="1.4",javax.xml.ws;version="2.1",wsdl > Manifest-Version = 1.0 > Tool = Bnd-0.0.238 > ka...@root> > So we see that the bundle import the following package : > javax.xml.datatype;version="1.4" and that > DynamicImport-Package = javax.*,org.w3c.*,org.xml.* has been defined > And the error generated : > DEBUG: DYNAMIC WIRE: 114.0 -> org.apache.camel.spi -> 44.0 > DEBUG: META-INF/services/javax.xml.parsers.DocumentBuilderFactory > DEBUG: META-INF/services/javax.xml.parsers.DocumentBuilderFactory > ERROR: Error starting > file:/D:/Dev/apache-servicemix-4.2.0-fuse-01-00/deploy/maestro-webservices-0.4.0-migr-4.2-SNAPSHOT.jar > (org.osgi.framework.BundleException: Unresolved constraint in bundle > maestro_SOAFw_WebServices [117]: package; > (&(package=javax.xml.datatype)(version>=1.4.0))) > org.osgi.framework.BundleException: Unresolved constraint in bundle > maestro_SOAFw_WebServices [117]: package; > (&(package=javax.xml.datatype)(version>=1.4.0)) > DEBUG: DYNAMIC WIRE: 114.0 -> com.sun.org.apache.xerces.internal.jaxp -> 0 > DEBUG: DYNAMIC WIRE: 114.0 -> org.xml.sax -> 0 at > org.apache.felix.framework.Felix.resolveBundle(Felix.java:3263) > at org.apache.felix.framework.Felix
[jira] Created: (FELIX-2117) Use DynamicImport instead of Optional Packages
Use DynamicImport instead of Optional Packages -- Key: FELIX-2117 URL: https://issues.apache.org/jira/browse/FELIX-2117 Project: Felix Issue Type: Improvement Components: Web Console Reporter: Valentin Valchev Currently the web console uses optional packages for some plugins. Unfortunately an 'optional' import is wired when the bundle is resolved. DynamicImport however is wired when the package is accessed. This means, that currently, you - install webconsole - install scr = scr plugin is not available - resolve webconsole (again) = scr plugin is available after 1 additional step However if DynamicImport is used, the SCR plugin will become available immediately after it is being installed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1988) Integrate jQuery UI integration into the Web Console Trunk
[ https://issues.apache.org/jira/browse/FELIX-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Valchev updated FELIX-1988: Attachment: 22.assorted3.patch 22.assorted3.patch: - mostly and a lot of javadoc cleanup (and make Eclipse happy - now yellow block ;) - remove BaseWebConsolePlugin (it became unused) - removed unused methods from Util class (some were inlined in ConfigurationRender, since they were used only there) - some private methods made static & final - faster execution if JIT is enabled - obr.DeployerThread - doesn't use Exception.getCause() anymore, since this method is JDK 1.4+ - mostly and a lot of javadoc cleanup (and make Eclipse happy - now yellow block ;) - remove BaseWebConsolePlugin (it became unused) - removed unused methods from Util class (some were inlined in ConfigurationRender, since they were used only there) - some private methods made static & final - faster execution if JIT is enabled - obr.DeployerThread - doesn't use Exception.getCause() anymore, since this method is JDK 1.4+ Now we can also consider the following issues resolved : FELIX-1959 Move towards unified L&F and extended branding support FELIX-957 Migrate Bundle Repository Page to JQuery FELIX-1956 Collect duplicate & reusable code in WebConsoleUtil > Integrate jQuery UI integration into the Web Console Trunk > -- > > Key: FELIX-1988 > URL: https://issues.apache.org/jira/browse/FELIX-1988 > Project: Felix > Issue Type: Task > Components: Web Console >Affects Versions: webconsole-2.0.4 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: webconsole-3.0.0 > > Attachments: 10.deployment_plugin.patch, 11.shell_plugin.patch, > 12.bundles_plugin.patch, 13.components_plugin.patch, > 14.configmgr_plugin.patch, 15.config_render_plugin.patch, > 16.license_plugin.patch, 17.finishing_touches.patch, > 18.configuration_printer_load_on_demand.patch, 19.assorted1.patch, > 2.use-utility-methods.patch, 20.obr_plugin.patch, 21.assorted2.patch, > 22.assorted3.patch, 3.javadoc-public-api.patch, > 4.webconsole_src_main_resources_res_lib.zip, 5.main_template.patch, > 6.vmstat.patch, 7.services.patch, 8.abstractconsolefix_and_props.patch, > 9.logs_plugin.patch, abstr-simple-web-console2.patch, > bundle_bg.raw_properties, src.zip > > > Valentin Valchev has implemented jQuery UI support in the web console. This > issue is to keep track of this migration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2116) JRE packages & org.osgi.framework.BundleException: Unresolved constraint
[ https://issues.apache.org/jira/browse/FELIX-2116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12836549#action_12836549 ] Charles Moulliard commented on FELIX-2116: -- Does this command "DynamicImport-Package = javax.*,org.w3c.*,org.xml.*" will resolve "bundle constraint" or not ? > JRE packages & org.osgi.framework.BundleException: Unresolved constraint > > > Key: FELIX-2116 > URL: https://issues.apache.org/jira/browse/FELIX-2116 > Project: Felix > Issue Type: Bug > Components: Karaf >Affects Versions: karaf-1.2.0 >Reporter: Charles Moulliard > > Here is more details about the unresolved constraint > Here is what the bundle import : > ka...@root> headers 117 > MAESTRO :: SOA Fw :: WebServices (117) > -- > Bnd-LastModified = 1266589733099 > Build-Jdk = 1.6.0_16 > Built-By = T0106319 > Bundle-ManifestVersion = 2 > Bundle-Name = MAESTRO :: SOA Fw :: WebServices > Bundle-SymbolicName = maestro_SOAFw_WebServices > Bundle-Version = 0.4.0.migr-42-SNAPSHOT > Created-By = Apache Maven Bundle Plugin > DynamicImport-Package = javax.*,org.w3c.*,org.xml.* > Export-Package = > com.thalesgroup.maestro.wsdl.system.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.event;uses:="javax.jws.soap,javax.jws,javax.xml.bind.annotation,com.thalesgroup.maestro.wsdl.event.xsd,javax.xml.ws,javax.xml.namespace",com.thalesgroup.maestro.wsdl.sop.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",wsdl,com.thalesgroup.maestro.wsdl.status.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.alarm.x > sd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.alarm;uses:="javax.jws.soap,javax.jws,com.thalesgroup.maestro.wsdl.alarm.xsd,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace",com.thalesgroup.maestro.wsdl.event.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.system;uses:="javax.jws.soap,com.thalesgroup.maestro.wsdl.system.xsd,javax.jws,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace",com.thalesgroup.ma > estro.wsdl.command.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.status;uses:="javax.jws.soap,javax.jws,com.thalesgroup.maestro.wsdl.status.xsd,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace",com.thalesgroup.maestro.wsdl.command;uses:="javax.jws.soap,javax.jws,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace,com.thalesgroup.maestro.wsdl.command.xsd",com.thalesgroup.maestro.wsdl.sop;uses:="javax.jws.soap,com.thalesgroup.maestro.wsdl.so > p.xsd,javax.jws,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace" > Import-Package = > com.thalesgroup.maestro.wsdl.alarm,com.thalesgroup.maestro.wsdl.alarm.xsd,com.thalesgroup.maestro.wsdl.command,com.thalesgroup.maestro.wsdl.command.xsd,com.thalesgroup.maestro.wsdl.event,com.thalesgroup.maestro.wsdl.event.xsd,com.thalesgroup.maestro.wsdl.sop,com.thalesgroup.maestro.wsdl.sop.xsd,com.thalesgroup.maestro.wsdl.status,com.thalesgroup.maestro.wsdl.status.xsd,com.thalesgroup.maestro.wsdl.system,com.thalesgroup.maestro.wsdl.system.xsd,javax.jws;version="2.0",javax.jws.s > oap;version="2.0",javax.xml.bind.annotation;version="2.1",javax.xml.datatype;version="1.4",javax.xml.namespace;version="1.4",javax.xml.ws;version="2.1",wsdl > Manifest-Version = 1.0 > Tool = Bnd-0.0.238 > ka...@root> > So we see that the bundle import the following package : > javax.xml.datatype;version="1.4" and that > DynamicImport-Package = javax.*,org.w3c.*,org.xml.* has been defined > And the error generated : > DEBUG: DYNAMIC WIRE: 114.0 -> org.apache.camel.spi -> 44.0 > DEBUG: META-INF/services/javax.xml.parsers.DocumentBuilderFactory > DEBUG: META-INF/services/javax.xml.parsers.DocumentBuilderFactory > ERROR: Error starting > file:/D:/Dev/apache-servicemix-4.2.0-fuse-01-00/deploy/maestro-webservices-0.4.0-migr-4.2-SNAPSHOT.jar > (org.osgi.framework.BundleException: Unresolved constraint in bundle > maestro_SOAFw_WebServices [117]: package; > (&(package=javax.xml.datatype)(version>=1.4.0))) > org.osgi.framework.BundleException: Unresolved constraint in bundle > maestro_SOAFw_WebServices [117]: package; > (&(package=javax.xml.datatype)(version>=1.4.0)) > DEBUG: DYNAMIC WIRE: 114.0 -> com.sun.org.apache.xerces.internal.jaxp -> 0 > DEBUG: DYNAMIC WIRE: 114.0 -> org.xml.sax -> 0 at > org.apache.felix.framework.Felix.resolveBundle(Felix.java:3263) > at org.apache.felix.framework.Felix.startBundle(Felix.java:1597) > at > org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1077) > at > org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264) > at java.lang.Thread.r
[jira] Updated: (FELIX-2116) JRE packages & org.osgi.framework.BundleException: Unresolved constraint
[ https://issues.apache.org/jira/browse/FELIX-2116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall updated FELIX-2116: --- Component/s: Karaf Affects Version/s: (was: felix-2.0.1) karaf-1.2.0 > JRE packages & org.osgi.framework.BundleException: Unresolved constraint > > > Key: FELIX-2116 > URL: https://issues.apache.org/jira/browse/FELIX-2116 > Project: Felix > Issue Type: Bug > Components: Karaf >Affects Versions: karaf-1.2.0 >Reporter: Charles Moulliard > > Here is more details about the unresolved constraint > Here is what the bundle import : > ka...@root> headers 117 > MAESTRO :: SOA Fw :: WebServices (117) > -- > Bnd-LastModified = 1266589733099 > Build-Jdk = 1.6.0_16 > Built-By = T0106319 > Bundle-ManifestVersion = 2 > Bundle-Name = MAESTRO :: SOA Fw :: WebServices > Bundle-SymbolicName = maestro_SOAFw_WebServices > Bundle-Version = 0.4.0.migr-42-SNAPSHOT > Created-By = Apache Maven Bundle Plugin > DynamicImport-Package = javax.*,org.w3c.*,org.xml.* > Export-Package = > com.thalesgroup.maestro.wsdl.system.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.event;uses:="javax.jws.soap,javax.jws,javax.xml.bind.annotation,com.thalesgroup.maestro.wsdl.event.xsd,javax.xml.ws,javax.xml.namespace",com.thalesgroup.maestro.wsdl.sop.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",wsdl,com.thalesgroup.maestro.wsdl.status.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.alarm.x > sd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.alarm;uses:="javax.jws.soap,javax.jws,com.thalesgroup.maestro.wsdl.alarm.xsd,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace",com.thalesgroup.maestro.wsdl.event.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.system;uses:="javax.jws.soap,com.thalesgroup.maestro.wsdl.system.xsd,javax.jws,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace",com.thalesgroup.ma > estro.wsdl.command.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.status;uses:="javax.jws.soap,javax.jws,com.thalesgroup.maestro.wsdl.status.xsd,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace",com.thalesgroup.maestro.wsdl.command;uses:="javax.jws.soap,javax.jws,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace,com.thalesgroup.maestro.wsdl.command.xsd",com.thalesgroup.maestro.wsdl.sop;uses:="javax.jws.soap,com.thalesgroup.maestro.wsdl.so > p.xsd,javax.jws,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace" > Import-Package = > com.thalesgroup.maestro.wsdl.alarm,com.thalesgroup.maestro.wsdl.alarm.xsd,com.thalesgroup.maestro.wsdl.command,com.thalesgroup.maestro.wsdl.command.xsd,com.thalesgroup.maestro.wsdl.event,com.thalesgroup.maestro.wsdl.event.xsd,com.thalesgroup.maestro.wsdl.sop,com.thalesgroup.maestro.wsdl.sop.xsd,com.thalesgroup.maestro.wsdl.status,com.thalesgroup.maestro.wsdl.status.xsd,com.thalesgroup.maestro.wsdl.system,com.thalesgroup.maestro.wsdl.system.xsd,javax.jws;version="2.0",javax.jws.s > oap;version="2.0",javax.xml.bind.annotation;version="2.1",javax.xml.datatype;version="1.4",javax.xml.namespace;version="1.4",javax.xml.ws;version="2.1",wsdl > Manifest-Version = 1.0 > Tool = Bnd-0.0.238 > ka...@root> > So we see that the bundle import the following package : > javax.xml.datatype;version="1.4" and that > DynamicImport-Package = javax.*,org.w3c.*,org.xml.* has been defined > And the error generated : > DEBUG: DYNAMIC WIRE: 114.0 -> org.apache.camel.spi -> 44.0 > DEBUG: META-INF/services/javax.xml.parsers.DocumentBuilderFactory > DEBUG: META-INF/services/javax.xml.parsers.DocumentBuilderFactory > ERROR: Error starting > file:/D:/Dev/apache-servicemix-4.2.0-fuse-01-00/deploy/maestro-webservices-0.4.0-migr-4.2-SNAPSHOT.jar > (org.osgi.framework.BundleException: Unresolved constraint in bundle > maestro_SOAFw_WebServices [117]: package; > (&(package=javax.xml.datatype)(version>=1.4.0))) > org.osgi.framework.BundleException: Unresolved constraint in bundle > maestro_SOAFw_WebServices [117]: package; > (&(package=javax.xml.datatype)(version>=1.4.0)) > DEBUG: DYNAMIC WIRE: 114.0 -> com.sun.org.apache.xerces.internal.jaxp -> 0 > DEBUG: DYNAMIC WIRE: 114.0 -> org.xml.sax -> 0 at > org.apache.felix.framework.Felix.resolveBundle(Felix.java:3263) > at org.apache.felix.framework.Felix.startBundle(Felix.java:1597) > at > org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1077) > at > org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264) > at java.lang.Thread.run(Thread.java:619) > If we check what is exported by the bundle
[jira] Commented: (FELIX-2116) JRE packages & org.osgi.framework.BundleException: Unresolved constraint
[ https://issues.apache.org/jira/browse/FELIX-2116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12836548#action_12836548 ] Richard S. Hall commented on FELIX-2116: I don't believe this is an issue with the Felix framework, it sounds like a configuration issue with Karaf to me. I will assign this to Karaf for now. > JRE packages & org.osgi.framework.BundleException: Unresolved constraint > > > Key: FELIX-2116 > URL: https://issues.apache.org/jira/browse/FELIX-2116 > Project: Felix > Issue Type: Bug >Affects Versions: felix-2.0.1 >Reporter: Charles Moulliard > > Here is more details about the unresolved constraint > Here is what the bundle import : > ka...@root> headers 117 > MAESTRO :: SOA Fw :: WebServices (117) > -- > Bnd-LastModified = 1266589733099 > Build-Jdk = 1.6.0_16 > Built-By = T0106319 > Bundle-ManifestVersion = 2 > Bundle-Name = MAESTRO :: SOA Fw :: WebServices > Bundle-SymbolicName = maestro_SOAFw_WebServices > Bundle-Version = 0.4.0.migr-42-SNAPSHOT > Created-By = Apache Maven Bundle Plugin > DynamicImport-Package = javax.*,org.w3c.*,org.xml.* > Export-Package = > com.thalesgroup.maestro.wsdl.system.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.event;uses:="javax.jws.soap,javax.jws,javax.xml.bind.annotation,com.thalesgroup.maestro.wsdl.event.xsd,javax.xml.ws,javax.xml.namespace",com.thalesgroup.maestro.wsdl.sop.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",wsdl,com.thalesgroup.maestro.wsdl.status.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.alarm.x > sd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.alarm;uses:="javax.jws.soap,javax.jws,com.thalesgroup.maestro.wsdl.alarm.xsd,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace",com.thalesgroup.maestro.wsdl.event.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.system;uses:="javax.jws.soap,com.thalesgroup.maestro.wsdl.system.xsd,javax.jws,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace",com.thalesgroup.ma > estro.wsdl.command.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.status;uses:="javax.jws.soap,javax.jws,com.thalesgroup.maestro.wsdl.status.xsd,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace",com.thalesgroup.maestro.wsdl.command;uses:="javax.jws.soap,javax.jws,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace,com.thalesgroup.maestro.wsdl.command.xsd",com.thalesgroup.maestro.wsdl.sop;uses:="javax.jws.soap,com.thalesgroup.maestro.wsdl.so > p.xsd,javax.jws,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace" > Import-Package = > com.thalesgroup.maestro.wsdl.alarm,com.thalesgroup.maestro.wsdl.alarm.xsd,com.thalesgroup.maestro.wsdl.command,com.thalesgroup.maestro.wsdl.command.xsd,com.thalesgroup.maestro.wsdl.event,com.thalesgroup.maestro.wsdl.event.xsd,com.thalesgroup.maestro.wsdl.sop,com.thalesgroup.maestro.wsdl.sop.xsd,com.thalesgroup.maestro.wsdl.status,com.thalesgroup.maestro.wsdl.status.xsd,com.thalesgroup.maestro.wsdl.system,com.thalesgroup.maestro.wsdl.system.xsd,javax.jws;version="2.0",javax.jws.s > oap;version="2.0",javax.xml.bind.annotation;version="2.1",javax.xml.datatype;version="1.4",javax.xml.namespace;version="1.4",javax.xml.ws;version="2.1",wsdl > Manifest-Version = 1.0 > Tool = Bnd-0.0.238 > ka...@root> > So we see that the bundle import the following package : > javax.xml.datatype;version="1.4" and that > DynamicImport-Package = javax.*,org.w3c.*,org.xml.* has been defined > And the error generated : > DEBUG: DYNAMIC WIRE: 114.0 -> org.apache.camel.spi -> 44.0 > DEBUG: META-INF/services/javax.xml.parsers.DocumentBuilderFactory > DEBUG: META-INF/services/javax.xml.parsers.DocumentBuilderFactory > ERROR: Error starting > file:/D:/Dev/apache-servicemix-4.2.0-fuse-01-00/deploy/maestro-webservices-0.4.0-migr-4.2-SNAPSHOT.jar > (org.osgi.framework.BundleException: Unresolved constraint in bundle > maestro_SOAFw_WebServices [117]: package; > (&(package=javax.xml.datatype)(version>=1.4.0))) > org.osgi.framework.BundleException: Unresolved constraint in bundle > maestro_SOAFw_WebServices [117]: package; > (&(package=javax.xml.datatype)(version>=1.4.0)) > DEBUG: DYNAMIC WIRE: 114.0 -> com.sun.org.apache.xerces.internal.jaxp -> 0 > DEBUG: DYNAMIC WIRE: 114.0 -> org.xml.sax -> 0 at > org.apache.felix.framework.Felix.resolveBundle(Felix.java:3263) > at org.apache.felix.framework.Felix.startBundle(Felix.java:1597) > at > org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1077) > at > org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264) > at java.lang.Thre
[jira] Created: (FELIX-2116) JRE packages & org.osgi.framework.BundleException: Unresolved constraint
JRE packages & org.osgi.framework.BundleException: Unresolved constraint Key: FELIX-2116 URL: https://issues.apache.org/jira/browse/FELIX-2116 Project: Felix Issue Type: Bug Affects Versions: felix-2.0.1 Reporter: Charles Moulliard Here is more details about the unresolved constraint Here is what the bundle import : ka...@root> headers 117 MAESTRO :: SOA Fw :: WebServices (117) -- Bnd-LastModified = 1266589733099 Build-Jdk = 1.6.0_16 Built-By = T0106319 Bundle-ManifestVersion = 2 Bundle-Name = MAESTRO :: SOA Fw :: WebServices Bundle-SymbolicName = maestro_SOAFw_WebServices Bundle-Version = 0.4.0.migr-42-SNAPSHOT Created-By = Apache Maven Bundle Plugin DynamicImport-Package = javax.*,org.w3c.*,org.xml.* Export-Package = com.thalesgroup.maestro.wsdl.system.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.event;uses:="javax.jws.soap,javax.jws,javax.xml.bind.annotation,com.thalesgroup.maestro.wsdl.event.xsd,javax.xml.ws,javax.xml.namespace",com.thalesgroup.maestro.wsdl.sop.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",wsdl,com.thalesgroup.maestro.wsdl.status.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.alarm.x sd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.alarm;uses:="javax.jws.soap,javax.jws,com.thalesgroup.maestro.wsdl.alarm.xsd,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace",com.thalesgroup.maestro.wsdl.event.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.system;uses:="javax.jws.soap,com.thalesgroup.maestro.wsdl.system.xsd,javax.jws,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace",com.thalesgroup.ma estro.wsdl.command.xsd;uses:="javax.xml.bind.annotation,javax.xml.datatype",com.thalesgroup.maestro.wsdl.status;uses:="javax.jws.soap,javax.jws,com.thalesgroup.maestro.wsdl.status.xsd,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace",com.thalesgroup.maestro.wsdl.command;uses:="javax.jws.soap,javax.jws,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace,com.thalesgroup.maestro.wsdl.command.xsd",com.thalesgroup.maestro.wsdl.sop;uses:="javax.jws.soap,com.thalesgroup.maestro.wsdl.so p.xsd,javax.jws,javax.xml.bind.annotation,javax.xml.ws,javax.xml.namespace" Import-Package = com.thalesgroup.maestro.wsdl.alarm,com.thalesgroup.maestro.wsdl.alarm.xsd,com.thalesgroup.maestro.wsdl.command,com.thalesgroup.maestro.wsdl.command.xsd,com.thalesgroup.maestro.wsdl.event,com.thalesgroup.maestro.wsdl.event.xsd,com.thalesgroup.maestro.wsdl.sop,com.thalesgroup.maestro.wsdl.sop.xsd,com.thalesgroup.maestro.wsdl.status,com.thalesgroup.maestro.wsdl.status.xsd,com.thalesgroup.maestro.wsdl.system,com.thalesgroup.maestro.wsdl.system.xsd,javax.jws;version="2.0",javax.jws.s oap;version="2.0",javax.xml.bind.annotation;version="2.1",javax.xml.datatype;version="1.4",javax.xml.namespace;version="1.4",javax.xml.ws;version="2.1",wsdl Manifest-Version = 1.0 Tool = Bnd-0.0.238 ka...@root> So we see that the bundle import the following package : javax.xml.datatype;version="1.4" and that DynamicImport-Package = javax.*,org.w3c.*,org.xml.* has been defined And the error generated : DEBUG: DYNAMIC WIRE: 114.0 -> org.apache.camel.spi -> 44.0 DEBUG: META-INF/services/javax.xml.parsers.DocumentBuilderFactory DEBUG: META-INF/services/javax.xml.parsers.DocumentBuilderFactory ERROR: Error starting file:/D:/Dev/apache-servicemix-4.2.0-fuse-01-00/deploy/maestro-webservices-0.4.0-migr-4.2-SNAPSHOT.jar (org.osgi.framework.BundleException: Unresolved constraint in bundle maestro_SOAFw_WebServices [117]: package; (&(package=javax.xml.datatype)(version>=1.4.0))) org.osgi.framework.BundleException: Unresolved constraint in bundle maestro_SOAFw_WebServices [117]: package; (&(package=javax.xml.datatype)(version>=1.4.0)) DEBUG: DYNAMIC WIRE: 114.0 -> com.sun.org.apache.xerces.internal.jaxp -> 0 DEBUG: DYNAMIC WIRE: 114.0 -> org.xml.sax -> 0 at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3263) at org.apache.felix.framework.Felix.startBundle(Felix.java:1597) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1077) at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264) at java.lang.Thread.run(Thread.java:619) If we check what is exported by the bundle 0 (=jre) of Felix, we see that datatype is exported : System Bundle (0): javax.xml.datatype; version=0.0.0 Can someone tell me what is wrong ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2115) The api offers no way to have a timeout or cancel the resolution if it takes too long
[ https://issues.apache.org/jira/browse/FELIX-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12836541#action_12836541 ] Richard S. Hall commented on FELIX-2115: Seems like the easiest way to get it done. > The api offers no way to have a timeout or cancel the resolution if it takes > too long > - > > Key: FELIX-2115 > URL: https://issues.apache.org/jira/browse/FELIX-2115 > Project: Felix > Issue Type: Improvement > Components: Bundle Repository (OBR) >Reporter: Guillaume Nodet > > One way would be either to add some methods to the Resolver such as: >boolean resolve(long timeout) >void cancel(); > I'd be much happier if we could use a Future instead. >Future resolve(); > This would make it easier for the user because he doesn't have to start a > thread on its own. > However this breaks compatibility. > We could therefore use something like: >Future startResolve(); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2115) The api offers no way to have a timeout or cancel the resolution if it takes too long
[ https://issues.apache.org/jira/browse/FELIX-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12836540#action_12836540 ] Guillaume Nodet commented on FELIX-2115: Yeah, I suppose so too. I was gonna propose something even more disruptive, which is to split the outcome of the resolution from the Resolver and have something like Future resolve(); But that might be a bit too disruptive. Unless, there is some problems, I'm gonna go for the minimal api changes, i.e. just modify the resolve() method in this way: boolean resolve() throws InterruptedException; To cancel a resolution, the user would have to call Thread#interrupt() on the resolution thread and this would abort the resolution and throw an InterruptedException. > The api offers no way to have a timeout or cancel the resolution if it takes > too long > - > > Key: FELIX-2115 > URL: https://issues.apache.org/jira/browse/FELIX-2115 > Project: Felix > Issue Type: Improvement > Components: Bundle Repository (OBR) >Reporter: Guillaume Nodet > > One way would be either to add some methods to the Resolver such as: >boolean resolve(long timeout) >void cancel(); > I'd be much happier if we could use a Future instead. >Future resolve(); > This would make it easier for the user because he doesn't have to start a > thread on its own. > However this breaks compatibility. > We could therefore use something like: >Future startResolve(); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
