[jira] [Updated] (FELIX-2945) SCR plugin: Parsing of "options" for property tag broken for java annotations
[ https://issues.apache.org/jira/browse/FELIX-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated FELIX-2945: Affects Version/s: scr ant task 1.1.0 Fix Version/s: scr ant task 1.1.2 > SCR plugin: Parsing of "options" for property tag broken for java annotations > - > > Key: FELIX-2945 > URL: https://issues.apache.org/jira/browse/FELIX-2945 > Project: Felix > Issue Type: Bug > Components: Maven SCR Plugin >Affects Versions: maven-scr-plugin-1.6.0, maven-scr-plugin-1.7.0, scr ant > task 1.1.0, scr generator 1.0.0, scr generator 1.1.0 >Reporter: Stefan Seifert >Assignee: Carsten Ziegeler > Fix For: maven-scr-plugin-1.7.2, scr ant task 1.1.2, scr > generator 1.1.2 > > Attachments: 110509_FELIX-2945_propetyoptions.patch > > > since rev. 1072066 (see FELIX-2835) parsing "options" from *java* annotations > (not javadoc annotations) is broken. > the PropertyHandler implementation was changed, and it did not match any > longer with the parameter format used by the java annotations PropertyTag > implementation. > i'll attach a patch which should handle both cases (though it tested it only > with java annotations). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2945) SCR plugin: Parsing of "options" for property tag broken for java annotations
[ https://issues.apache.org/jira/browse/FELIX-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13032260#comment-13032260 ] Carsten Ziegeler commented on FELIX-2945: - Hi Stefan thanks for your patch - I've applied a slightly modified version in revision 1102170 Can you please give it a test? > SCR plugin: Parsing of "options" for property tag broken for java annotations > - > > Key: FELIX-2945 > URL: https://issues.apache.org/jira/browse/FELIX-2945 > Project: Felix > Issue Type: Bug > Components: Maven SCR Plugin >Affects Versions: maven-scr-plugin-1.6.0, maven-scr-plugin-1.7.0, scr > generator 1.0.0, scr generator 1.1.0 >Reporter: Stefan Seifert >Assignee: Carsten Ziegeler > Fix For: maven-scr-plugin-1.7.2, scr generator 1.1.2 > > Attachments: 110509_FELIX-2945_propetyoptions.patch > > > since rev. 1072066 (see FELIX-2835) parsing "options" from *java* annotations > (not javadoc annotations) is broken. > the PropertyHandler implementation was changed, and it did not match any > longer with the parameter format used by the java annotations PropertyTag > implementation. > i'll attach a patch which should handle both cases (though it tested it only > with java annotations). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[VOTE] framework 3.2.2 and related subproject releases
I would like to call a vote on the following subproject releases: framework 3.2.2 main 3.2.2 main.distribution 3.2.2 Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-005/ 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 005 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments)
[VOTE] iPOJO Event Admin Handler 1.8.0 release
Hi, It's time to cut a release of the iPOJO Event Admin Handler 1.8.0. We solved 4 issues in this release: ** Bug * [FELIX-2718] - EventHandler are invoked one by one when using the @Subscribe handler ** Improvement * [FELIX-2631] - Rename @Publisher and @Subscriber attributes to follow the java naming conventions * [FELIX-2634] - Rename the @Publisher annotation into @Publishes annotation to avoid collision * [FELIX-2711] - The event admin handler should provides a Handler Description Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-006/ 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 006 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) Regards, Clement
[jira] [Updated] (FELIX-2941) Felix Framework 3.2.0 and Framework Security 1.4.2 fails OSGI Conditional Permission Admin CT when running on IBM JVM 5 and 6.
[ https://issues.apache.org/jira/browse/FELIX-2941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall updated FELIX-2941: --- Fix Version/s: (was: framework-4.0.0) framework-3.2.2 > Felix Framework 3.2.0 and Framework Security 1.4.2 fails OSGI Conditional > Permission Admin CT when running on IBM JVM 5 and 6. > -- > > Key: FELIX-2941 > URL: https://issues.apache.org/jira/browse/FELIX-2941 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-3.2.0 > Environment: java version "1.6.0" > Java(TM) SE Runtime Environment (build pwi3260sr9-20101125_01(SR9)) > IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Windows XP x86-32 > jvmwi3260sr9-20101124_69295 (JIT enabled, AOT enabled) > J9VM - 20101124_069295 > JIT - r9_20101028_17488ifx2 > GC - 20101027_AA) > JCL - 20101119_01 > java version "1.5.0" > Java(TM) 2 Runtime Environment, Standard Edition (build pwi32devifx-20070725 > (SR5a)) > IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 > j9vmwi3223-20070426 (JIT enabled) > J9VM - 20070420_12448_lHdSMR > JIT - 20070419_1806_r8 > GC - 200704_19) > JCL - 20070725 >Reporter: John Ross >Assignee: Karl Pauls > Fix For: framework-3.2.2 > > Attachments: felix.jar > > > I was executing the ConditionalTestControl.testMultipleBundlesOnStack() test > case of the org.osgi.test.cases.condpermadmin CT using > org.apache.felix.framework-3.2.0.jar and > org.apache.felix.framework.security-1.4.2.jar but ran into the following > issue using IBM JVM 5 and 6. Ran fine on Oracle JVM 6 and IBM JVM 4.2. > org.osgi.framework.BundleException: Activator start error in bundle > org.osgi.test.cases.condpermadmin.tb2 [5]. > at org.apache.felix.framework.Felix.activateBundle(Felix.java:1899) > at org.apache.felix.framework.Felix.startBundle(Felix.java:1769) > at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:927) > at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:914) > at > org.osgi.test.support.compatibility.DefaultTestBundleControl.installBundle(DefaultTestBundleControl.java:510) > at > org.osgi.test.support.compatibility.DefaultTestBundleControl.installBundle(DefaultTestBundleControl.java:496) > at > org.osgi.test.cases.condpermadmin.junit.ConditionalTestControl.setState(ConditionalTestControl.java:823) > at > org.osgi.test.support.compatibility.DefaultTestBundleControl.setUp(DefaultTestBundleControl.java:51) > at junit.framework.TestCase.runBare(TestCase.java:128) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:120) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at aQute.junit.Activator.test(Activator.java:200) > at aQute.junit.Activator.run(Activator.java:51) > Caused by: java.lang.SecurityException: java.security.AccessControlException: > Access denied (java.lang.RuntimePermission getClassLoader) > at org.apache.felix.framework.Felix$1.checkPermission(Felix.java:560) > at java.lang.ClassLoader.getParent(ClassLoader.java:420) > at > org.apache.felix.framework.ModuleImpl.getBootDelegationClassLoader(ModuleImpl.java:1684) > at > org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:722) > at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:72) > at > org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1801) > at java.lang.ClassLoader.loadClass(ClassLoader.java:619) > at > org.osgi.test.cases.condpermadmin.tb2.Activator.start(Activator.java:44) > at > org.apache.felix.framework.util.SecureAction$Actions.run(SecureAction.java:1243) > at > java.security.AccessController.doPrivileged(AccessController.java:284) > at > org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:620) > at org.apache.felix.framework.Felix.activateBundle(Felix.java:1852) > ... 16 more > Caused by: java.security.AccessControlException: Access denied > (java.lang.RuntimePermission getClassLoader) > at > java.security.AccessController.checkPermission(AccessController.java:108) > at java.lang.SecurityManager.checkPermission(SecurityManager.java:544) > at org.apache.felix.framework.Felix$1.checkPermission(Felix.java:556) > ... 27 more > # add error to > testMultipleBundlesOnStack(org.osgi
[jira] [Updated] (FELIX-2942) Bundles with higher start level get activated even before framework reaches that start level
[
https://issues.apache.org/jira/browse/FELIX-2942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard S. Hall updated FELIX-2942:
---
Fix Version/s: (was: framework-4.0.0)
framework-3.2.2
> Bundles with higher start level get activated even before framework reaches
> that start level
>
>
> Key: FELIX-2942
> URL: https://issues.apache.org/jira/browse/FELIX-2942
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-3.0.8
>Reporter: Sahoo
>Assignee: Richard S. Hall
>Priority: Critical
> Fix For: framework-3.2.2
>
>
> In my environment, this is what's going on:
> 1. framework is started with start level 1.
> 2. bundles are installed and assigned start level varying from 2 to 4.
> 3. framework's start level is set to 5.
> 4. another bundle is installed and is assigned start level 5. This bundle is
> then started.
> Immediately I see Bundle.STARTED event for the last bundle with start level 5
> is fired. While trying to understand why certain bundles are getting started
> earlier than bundles with lower start levels, I stepped into Felix and found
> the following code:
> // Check to see if the bundle's start level is greater than the
> // the framework's active start level.
> // TODO: STARTLEVEL - Technically, this is not correct since we could be in
> the
> // middle of a framework start level change and we might not have yet
> // reached the target start level, but we will activate the bundle
> anyway.
> // This means the bundle will be running in a higher start level
> temporarily
> // until the start level thread catches up.
> if (bundle.getStartLevel(getInitialBundleStartLevel()) >
> m_targetStartLevel)
> {
> // Throw an exception for transient starts.
> if ((options & Bundle.START_TRANSIENT) != 0)
> {
> throw new BundleException(
> "Cannot start bundle " + bundle + " because its start
> level is "
> + bundle.getStartLevel(getInitialBundleStartLevel())
> + ", which is greater than the framework's start
> level of "
> + m_targetStartLevel + ".");
> }
> // Ignore persistent starts.
> return;
> }
> The above code compares against "target start level" as opposed to the
> "currently active start level". The comment indicates that it is a known
> issue, so if there is already a bug filed to this extent, please close this
> one as duplicate. It pretty much makes it difficult to use start level
> service reliably.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-2935) Bundle.getEntryPaths and findEntries are returning META-INF/ multiple times
[
https://issues.apache.org/jira/browse/FELIX-2935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard S. Hall updated FELIX-2935:
---
Fix Version/s: (was: framework-4.0.0)
framework-3.2.2
> Bundle.getEntryPaths and findEntries are returning META-INF/ multiple times
> ---
>
> Key: FELIX-2935
> URL: https://issues.apache.org/jira/browse/FELIX-2935
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-3.0.8
>Reporter: Sahoo
>Assignee: Richard S. Hall
> Fix For: framework-3.2.2
>
> Attachments: FELIX-2935.zip
>
>
> Bundle.getEntryPaths("/") and Bundle.findEntries("/", "*", true) return
> META-INF/ twice. There is no fragment attached, so there is no reason for
> findEntries to return twice.
> My code looks like this:
> void printEntryPaths(Bundle b, String s) {
> Enumeration e = b.getEntryPaths(s);
> if (e!=null) {
> while (e.hasMoreElements()) {
> String next = (String)e.nextElement();
> System.out.println(next);
> printEntryPaths(b, next);
> }
> }
> }
> void printEntryPaths2(Bundle b, String s) {
> Enumeration e = b.findEntries(s, "*", true);
> if (e != null) {
> while (e.hasMoreElements()) {
> URL next = (URL)e.nextElement();
> System.out.println(next.getPath());
> }
> }
> }
> This seems to be a regression.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-2942) Bundles with higher start level get activated even before framework reaches that start level
[
https://issues.apache.org/jira/browse/FELIX-2942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard S. Hall resolved FELIX-2942.
Resolution: Fixed
Assignee: Richard S. Hall
I have committed a patch that creates a shared set of bundles being processed
by the start level thread so that concurrent calls to start a bundle can be
queued for the start level thread to avoid bundles starting out of the proper
start level.
> Bundles with higher start level get activated even before framework reaches
> that start level
>
>
> Key: FELIX-2942
> URL: https://issues.apache.org/jira/browse/FELIX-2942
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-3.0.8
>Reporter: Sahoo
>Assignee: Richard S. Hall
>Priority: Critical
> Fix For: framework-4.0.0
>
>
> In my environment, this is what's going on:
> 1. framework is started with start level 1.
> 2. bundles are installed and assigned start level varying from 2 to 4.
> 3. framework's start level is set to 5.
> 4. another bundle is installed and is assigned start level 5. This bundle is
> then started.
> Immediately I see Bundle.STARTED event for the last bundle with start level 5
> is fired. While trying to understand why certain bundles are getting started
> earlier than bundles with lower start levels, I stepped into Felix and found
> the following code:
> // Check to see if the bundle's start level is greater than the
> // the framework's active start level.
> // TODO: STARTLEVEL - Technically, this is not correct since we could be in
> the
> // middle of a framework start level change and we might not have yet
> // reached the target start level, but we will activate the bundle
> anyway.
> // This means the bundle will be running in a higher start level
> temporarily
> // until the start level thread catches up.
> if (bundle.getStartLevel(getInitialBundleStartLevel()) >
> m_targetStartLevel)
> {
> // Throw an exception for transient starts.
> if ((options & Bundle.START_TRANSIENT) != 0)
> {
> throw new BundleException(
> "Cannot start bundle " + bundle + " because its start
> level is "
> + bundle.getStartLevel(getInitialBundleStartLevel())
> + ", which is greater than the framework's start
> level of "
> + m_targetStartLevel + ".");
> }
> // Ignore persistent starts.
> return;
> }
> The above code compares against "target start level" as opposed to the
> "currently active start level". The comment indicates that it is a known
> issue, so if there is already a bug filed to this extent, please close this
> one as duplicate. It pretty much makes it difficult to use start level
> service reliably.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2878) scr- and bundle-plugin in multimodule project fails with goal "test"
[
https://issues.apache.org/jira/browse/FELIX-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13031755#comment-13031755
]
Andrei Pozolotin commented on FELIX-2878:
-
http://felix.apache.org/site/apache-felix-maven-scr-plugin-use.html
currently does not document this plugin property:
/**
* @parameter expression="${project.build.directory}/scr-plugin-generated"
* @required
* @readonly
*/
private File outputDirectory;
> scr- and bundle-plugin in multimodule project fails with goal "test"
>
>
> Key: FELIX-2878
> URL: https://issues.apache.org/jira/browse/FELIX-2878
> Project: Felix
> Issue Type: Bug
> Components: Maven SCR Plugin
>Affects Versions: maven-scr-plugin-1.6.0, scr generator 1.1.0
>Reporter: Konrad Windszus
>Assignee: Carsten Ziegeler
> Fix For: maven-scr-plugin-1.7.2, scr generator 1.1.2
>
> Attachments: multimoduleosgi.zip, out.log
>
>
> If I have a multimodule project with several OSGi bundles, which all use the
> scr plugin, there is an error during "mvn test". This is due to the scr
> plugin being bound to the phase "generate-resources" and maven-bundle plugin
> generating the manifest only in the package phase. If I have modules A and B
> (both packaging "bundle"), B depends upon A and building the multimodule with
> "mvn test" there is an error, because during the scr goal of B, it looks for
> the manifest of A, which is apparently not there, since it is not
> constructed with "test".
> The error message is as follows:
> ..
> [INFO] [compiler:compile {execution: default-compile}]
> [INFO] Compiling 13 source files to\target\classes
> [INFO] [scr:scr {execution: generate-scr-descriptor}]
> [ERROR] Unable to get manifest from artifact at A>\target\classes:0
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] SCR Descriptor parsing had failures (see log)
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 44 seconds
> [INFO] Finished at: Thu Mar 10 10:43:58 CET 2011
> [INFO] Final Memory: 93M/237M
> [INFO]
>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FELIX-2912) Host name is lost in exceptions when dealing with Windows shared drives
[ https://issues.apache.org/jira/browse/FELIX-2912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor closed FELIX-2912. -- Looks good. Thank you! > Host name is lost in exceptions when dealing with Windows shared drives > --- > > Key: FELIX-2912 > URL: https://issues.apache.org/jira/browse/FELIX-2912 > Project: Felix > Issue Type: Bug > Components: Bundle Repository (OBR) >Affects Versions: bundlerepository-1.6.4 >Reporter: Jarek Gawor >Assignee: Richard S. Hall > Fix For: bundlerepository-1.6.6 > > Attachments: FELIX-2912.2.patch, FELIX-2912.patch > > > When OBR repository URL specifies a Windows shared drive for example: > file://myhost/mydir/myrepo.xml and the myrepo.xml specifies a relative uri to > a mybundle.jar that does not exist in that location, OBR will throw the > following exception (during Resolver.deploy()): > java.io.FileNotFoundException: mydir/mybundle.jar > at > sun.net.www.protocol.ftp.FtpURLConnection.getInputStream(FtpURLConnection.java:441) > at > org.apache.felix.bundlerepository.impl.FileUtil.openURL(FileUtil.java:203) > at > org.apache.felix.bundlerepository.impl.FileUtil.openURL(FileUtil.java:196) > at > org.apache.felix.bundlerepository.impl.ResolverImpl.deploy(ResolverImpl.java:598) > > The hostname part of the repository url is lost in the exception. > The root cause of this is probably somewhere in the JDK but OBR could handle > this case a bit better. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: OBR - FELIX-2912
On 5/11/11 10:42, Jarek Gawor wrote: On Wed, May 4, 2011 at 4:02 PM, Richard S. Hall wrote: On 5/4/11 15:39, Jarek Gawor wrote: I was wondering if somebody could review&possibly commit the patch attached to FELIX-2912 for the bundlerepository module. The patch in and of itself seems ok, but generally speaking it seems like a specific special case for a situation that could have lots of similar special cases. What if there are other types of exceptions that get thrown and similarly provide inadequate reporting. Will we need a bunch of different catch clauses converting them into something more meaningful? Is there a more general approach to solve this issue? What always catching any IOException and rethrowing another IOException that includes the full URL of what we were trying to open in its message along with the exception that caused this in the first place? Would that give you enough of the information you want in this case? Just wondering... Sure. I just attached another patch for FELIX-2912 that follows your suggestion to catch any IOException. Let me know if that works for you. I committed it. Please close this issue if you are happy. Thanks! -> richard Thanks, Jarek
[jira] [Resolved] (FELIX-2912) Host name is lost in exceptions when dealing with Windows shared drives
[ https://issues.apache.org/jira/browse/FELIX-2912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall resolved FELIX-2912. Resolution: Fixed Fix Version/s: bundlerepository-1.6.6 Assignee: Richard S. Hall I applied the patch. Please close this issue if satisfied, thanks! > Host name is lost in exceptions when dealing with Windows shared drives > --- > > Key: FELIX-2912 > URL: https://issues.apache.org/jira/browse/FELIX-2912 > Project: Felix > Issue Type: Bug > Components: Bundle Repository (OBR) >Affects Versions: bundlerepository-1.6.4 >Reporter: Jarek Gawor >Assignee: Richard S. Hall > Fix For: bundlerepository-1.6.6 > > Attachments: FELIX-2912.2.patch, FELIX-2912.patch > > > When OBR repository URL specifies a Windows shared drive for example: > file://myhost/mydir/myrepo.xml and the myrepo.xml specifies a relative uri to > a mybundle.jar that does not exist in that location, OBR will throw the > following exception (during Resolver.deploy()): > java.io.FileNotFoundException: mydir/mybundle.jar > at > sun.net.www.protocol.ftp.FtpURLConnection.getInputStream(FtpURLConnection.java:441) > at > org.apache.felix.bundlerepository.impl.FileUtil.openURL(FileUtil.java:203) > at > org.apache.felix.bundlerepository.impl.FileUtil.openURL(FileUtil.java:196) > at > org.apache.felix.bundlerepository.impl.ResolverImpl.deploy(ResolverImpl.java:598) > > The hostname part of the repository url is lost in the exception. > The root cause of this is probably somewhere in the JDK but OBR could handle > this case a bit better. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: OBR - FELIX-2912
On Wed, May 4, 2011 at 4:02 PM, Richard S. Hall wrote: > On 5/4/11 15:39, Jarek Gawor wrote: >> >> I was wondering if somebody could review& possibly commit the patch >> attached to FELIX-2912 for the bundlerepository module. > > The patch in and of itself seems ok, but generally speaking it seems like a > specific special case for a situation that could have lots of similar > special cases. What if there are other types of exceptions that get thrown > and similarly provide inadequate reporting. Will we need a bunch of > different catch clauses converting them into something more meaningful? > > Is there a more general approach to solve this issue? What always catching > any IOException and rethrowing another IOException that includes the full > URL of what we were trying to open in its message along with the exception > that caused this in the first place? > > Would that give you enough of the information you want in this case? Just > wondering... Sure. I just attached another patch for FELIX-2912 that follows your suggestion to catch any IOException. Let me know if that works for you. Thanks, Jarek
[jira] [Updated] (FELIX-2912) Host name is lost in exceptions when dealing with Windows shared drives
[ https://issues.apache.org/jira/browse/FELIX-2912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated FELIX-2912: --- Attachment: FELIX-2912.2.patch Attached another version of the patch that is more generic. > Host name is lost in exceptions when dealing with Windows shared drives > --- > > Key: FELIX-2912 > URL: https://issues.apache.org/jira/browse/FELIX-2912 > Project: Felix > Issue Type: Bug > Components: Bundle Repository (OBR) >Affects Versions: bundlerepository-1.6.4 >Reporter: Jarek Gawor > Attachments: FELIX-2912.2.patch, FELIX-2912.patch > > > When OBR repository URL specifies a Windows shared drive for example: > file://myhost/mydir/myrepo.xml and the myrepo.xml specifies a relative uri to > a mybundle.jar that does not exist in that location, OBR will throw the > following exception (during Resolver.deploy()): > java.io.FileNotFoundException: mydir/mybundle.jar > at > sun.net.www.protocol.ftp.FtpURLConnection.getInputStream(FtpURLConnection.java:441) > at > org.apache.felix.bundlerepository.impl.FileUtil.openURL(FileUtil.java:203) > at > org.apache.felix.bundlerepository.impl.FileUtil.openURL(FileUtil.java:196) > at > org.apache.felix.bundlerepository.impl.ResolverImpl.deploy(ResolverImpl.java:598) > > The hostname part of the repository url is lost in the exception. > The root cause of this is probably somewhere in the JDK but OBR could handle > this case a bit better. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2921) [Framework] Improve property substitution handling in build process
[
https://issues.apache.org/jira/browse/FELIX-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13031738#comment-13031738
]
Richard S. Hall commented on FELIX-2921:
I looked into updating the build according to the suggested approach. I got it
to work, but then I tried to update main to use the same approach for
consistency reasons. It didn't work for main, because it actually has a file
where we do want some properties substituted, but not all. So the
all-or-nothing approach of the proposed patch is not sufficient.
I then looked into specifying different delimiters for maven-resources-plugin.
At first, this appeared to not be working, but then I realized we were having
issues between maven and bnd both processing the resources. Maven would first
copy and filter the resources, but then bnd would then overwrite the resources
with the original unfiltered versions when creating the JAR file. So, the
solution would be to only let Maven handle the resources.
Such an approach would work, but it is a little more complicated than that,
since bnd will only copy resources into the resulting JAR file if they are in a
private or exported package. So, any resources not in a package must be
explicitly included in the Include-Resource command for bnd so they end up in
the JAR file. Importantly, these resources must be the ones copied into the
output directory by maven-resources-plugin, not the originals, otherwise any
property filtering will not be retained.
So, in short, this approach would work, but it seems somewhat ugly to me, so
I'm holding off on it for now. Perhaps someone with better knowledge in this
area can help me find a better way.
> [Framework] Improve property substitution handling in build process
> ---
>
> Key: FELIX-2921
> URL: https://issues.apache.org/jira/browse/FELIX-2921
> Project: Felix
> Issue Type: Improvement
> Components: Framework
>Affects Versions: framework-3.2.0
> Environment: apple
>Reporter: Stephane Chomat
>Priority: Minor
> Fix For: framework-4.0.0
>
> Attachments: BadPropertiesTest.java
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> The properties like FRAMEWORK_SYSTEMPACKAGES are bad substituted by the
> method Util.getDefaultProperty.
> The properties dollar is missing and the value is '' returned by
> System.getProperty.
> The bad default value for FRAMEWORK_SYSTEMPACKAGES is
> org.osgi.framework; version=1.5.0, org.osgi.framework.launch; version=1.0.0,
> org.osgi.framework.hooks.service; version=1.0.0,
> org.osgi.service.packageadmin; version=1.2.0, org.osgi.service.startlevel;
> version=1.1.0, org.osgi.service.url; version=1.0.0, org.osgi.util.tracker;
> version=1.4.0 {jre-{java.specification.version}}
> You can add this test :
> public void testDefaultProperty() {
>Logger logger = new Logger();
>
>String jsv = System.getProperty("java.specification.version");
>String jre = Util.getDefaultProperty(logger, "jre-"+jsv);
>
>String actual = Util.getDefaultProperty(logger,
> Constants.FRAMEWORK_SYSTEMPACKAGES);
>
>assertEquals("org.osgi.framework; version=1.5.0,
> org.osgi.framework.launch; version=1.0.0, org.osgi.framework.hooks.service;
> version=1.0.0, org.osgi.service.packageadmin; version=1.2.0,
> org.osgi.service.startlevel; version=1.1.0, org.osgi.service.url;
> version=1.0.0, org.osgi.util.tracker; version=1.4.0 "+jre, actual);
> }
> If you add this line before test, the test works
> System.setProperty("dollar","$");
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2434) DispatchQueue, StartLevel and PacakageAdmin threads holding VM up.
[ https://issues.apache.org/jira/browse/FELIX-2434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13031699#comment-13031699 ] Emmanuel Lecharny commented on FELIX-2434: -- Works just fine ! Clever, indeed :) Thanks Karl ! > DispatchQueue, StartLevel and PacakageAdmin threads holding VM up. > -- > > Key: FELIX-2434 > URL: https://issues.apache.org/jira/browse/FELIX-2434 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-2.0.5 > Environment: Linux (RHEL 4 32Bit), java 1.6 server vm (14-b08) > Linux (RHEL 5 32bit & 64Bit) java 1.6 server vm (13) >Reporter: Martin Ritchie > Fix For: framework-4.0.0 > > Attachments: FELIX-EventDispatcher-setDaemon.patch > > > Hi, In Qpid we started using Felix more for managing our broker plugins. > However we are having random lockups occur during our test broker shutdown. > Our PluginManager > (https://svn.apache.org/repos/asf/qpid/trunk/qpid/java/broker/src/main/java/org/apache/qpid/server/plugins/PluginManager.java) > is shutdown via a VM ShutdownHook where it closes Service Trackers and then > calls stop() on Felix followed by a waitForStop(). > We are frequently seeing the following three Felix threads in a WAITING state > that could be holding the VM up. Looking at the 2.0.5 code the > EventDispatcher does not use a Daemon thread could this be what is holding > our VM open? > Name: FelixDispatchQueue > State: WAITING on java.util.ArrayList@dc904a > Total blocked: 21 Total waited: 22 > Stack trace: > java.lang.Object.wait(Native Method) > java.lang.Object.wait(Object.java:485) > org.apache.felix.framework.util.EventDispatcher.run(EventDispatcher.java:917) > org.apache.felix.framework.util.EventDispatcher.access$000(EventDispatcher.java:54) > org.apache.felix.framework.util.EventDispatcher$1.run(EventDispatcher.java:106) > java.lang.Thread.run(Thread.java:619) > Name: FelixStartLevel > State: WAITING on java.util.ArrayList@1c68b20 > Total blocked: 7 Total waited: 8 > Stack trace: > java.lang.Object.wait(Native Method) > java.lang.Object.wait(Object.java:485) > org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:242) > java.lang.Thread.run(Thread.java:619) > Name: FelixPackageAdmin > State: WAITING on org.apache.felix.framework.PackageAdminImpl@1d4ab05 > Total blocked: 0 Total waited: 1 > Stack trace: > java.lang.Object.wait(Native Method) > java.lang.Object.wait(Object.java:485) > org.apache.felix.framework.PackageAdminImpl.run(PackageAdminImpl.java:316) > java.lang.Thread.run(Thread.java:619) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2434) DispatchQueue, StartLevel and PacakageAdmin threads holding VM up.
[ https://issues.apache.org/jira/browse/FELIX-2434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13031691#comment-13031691 ] Emmanuel Lecharny commented on FELIX-2434: -- Right : if we start Felix in a daemon thread, then all the threads Felix will start will be daemon threads. I will test that. Thanks for the trick ! > DispatchQueue, StartLevel and PacakageAdmin threads holding VM up. > -- > > Key: FELIX-2434 > URL: https://issues.apache.org/jira/browse/FELIX-2434 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-2.0.5 > Environment: Linux (RHEL 4 32Bit), java 1.6 server vm (14-b08) > Linux (RHEL 5 32bit & 64Bit) java 1.6 server vm (13) >Reporter: Martin Ritchie > Fix For: framework-4.0.0 > > Attachments: FELIX-EventDispatcher-setDaemon.patch > > > Hi, In Qpid we started using Felix more for managing our broker plugins. > However we are having random lockups occur during our test broker shutdown. > Our PluginManager > (https://svn.apache.org/repos/asf/qpid/trunk/qpid/java/broker/src/main/java/org/apache/qpid/server/plugins/PluginManager.java) > is shutdown via a VM ShutdownHook where it closes Service Trackers and then > calls stop() on Felix followed by a waitForStop(). > We are frequently seeing the following three Felix threads in a WAITING state > that could be holding the VM up. Looking at the 2.0.5 code the > EventDispatcher does not use a Daemon thread could this be what is holding > our VM open? > Name: FelixDispatchQueue > State: WAITING on java.util.ArrayList@dc904a > Total blocked: 21 Total waited: 22 > Stack trace: > java.lang.Object.wait(Native Method) > java.lang.Object.wait(Object.java:485) > org.apache.felix.framework.util.EventDispatcher.run(EventDispatcher.java:917) > org.apache.felix.framework.util.EventDispatcher.access$000(EventDispatcher.java:54) > org.apache.felix.framework.util.EventDispatcher$1.run(EventDispatcher.java:106) > java.lang.Thread.run(Thread.java:619) > Name: FelixStartLevel > State: WAITING on java.util.ArrayList@1c68b20 > Total blocked: 7 Total waited: 8 > Stack trace: > java.lang.Object.wait(Native Method) > java.lang.Object.wait(Object.java:485) > org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:242) > java.lang.Thread.run(Thread.java:619) > Name: FelixPackageAdmin > State: WAITING on org.apache.felix.framework.PackageAdminImpl@1d4ab05 > Total blocked: 0 Total waited: 1 > Stack trace: > java.lang.Object.wait(Native Method) > java.lang.Object.wait(Object.java:485) > org.apache.felix.framework.PackageAdminImpl.run(PackageAdminImpl.java:316) > java.lang.Thread.run(Thread.java:619) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2878) scr- and bundle-plugin in multimodule project fails with goal "test"
[
https://issues.apache.org/jira/browse/FELIX-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13031689#comment-13031689
]
Carsten Ziegeler commented on FELIX-2878:
-
Hi,
the snapshots should be available from
https://repository.apache.org/content/repositories/snapshots/
> scr- and bundle-plugin in multimodule project fails with goal "test"
>
>
> Key: FELIX-2878
> URL: https://issues.apache.org/jira/browse/FELIX-2878
> Project: Felix
> Issue Type: Bug
> Components: Maven SCR Plugin
>Affects Versions: maven-scr-plugin-1.6.0, scr generator 1.1.0
>Reporter: Konrad Windszus
>Assignee: Carsten Ziegeler
> Fix For: maven-scr-plugin-1.7.2, scr generator 1.1.2
>
> Attachments: multimoduleosgi.zip, out.log
>
>
> If I have a multimodule project with several OSGi bundles, which all use the
> scr plugin, there is an error during "mvn test". This is due to the scr
> plugin being bound to the phase "generate-resources" and maven-bundle plugin
> generating the manifest only in the package phase. If I have modules A and B
> (both packaging "bundle"), B depends upon A and building the multimodule with
> "mvn test" there is an error, because during the scr goal of B, it looks for
> the manifest of A, which is apparently not there, since it is not
> constructed with "test".
> The error message is as follows:
> ..
> [INFO] [compiler:compile {execution: default-compile}]
> [INFO] Compiling 13 source files to\target\classes
> [INFO] [scr:scr {execution: generate-scr-descriptor}]
> [ERROR] Unable to get manifest from artifact at A>\target\classes:0
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] SCR Descriptor parsing had failures (see log)
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 44 seconds
> [INFO] Finished at: Thu Mar 10 10:43:58 CET 2011
> [INFO] Final Memory: 93M/237M
> [INFO]
>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2434) DispatchQueue, StartLevel and PacakageAdmin threads holding VM up.
[ https://issues.apache.org/jira/browse/FELIX-2434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13031681#comment-13031681 ] Richard S. Hall commented on FELIX-2434: Karl reminds me that we don't explicitly set daemon status, we inherit it from the thread starting the framework, which is normally the main thread (i.e., non-daemon). So, you could achieve what you want by starting the framework with a daemon thread, which would cause the event dispatcher thread to inherit the daemon status. > DispatchQueue, StartLevel and PacakageAdmin threads holding VM up. > -- > > Key: FELIX-2434 > URL: https://issues.apache.org/jira/browse/FELIX-2434 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-2.0.5 > Environment: Linux (RHEL 4 32Bit), java 1.6 server vm (14-b08) > Linux (RHEL 5 32bit & 64Bit) java 1.6 server vm (13) >Reporter: Martin Ritchie > Fix For: framework-4.0.0 > > Attachments: FELIX-EventDispatcher-setDaemon.patch > > > Hi, In Qpid we started using Felix more for managing our broker plugins. > However we are having random lockups occur during our test broker shutdown. > Our PluginManager > (https://svn.apache.org/repos/asf/qpid/trunk/qpid/java/broker/src/main/java/org/apache/qpid/server/plugins/PluginManager.java) > is shutdown via a VM ShutdownHook where it closes Service Trackers and then > calls stop() on Felix followed by a waitForStop(). > We are frequently seeing the following three Felix threads in a WAITING state > that could be holding the VM up. Looking at the 2.0.5 code the > EventDispatcher does not use a Daemon thread could this be what is holding > our VM open? > Name: FelixDispatchQueue > State: WAITING on java.util.ArrayList@dc904a > Total blocked: 21 Total waited: 22 > Stack trace: > java.lang.Object.wait(Native Method) > java.lang.Object.wait(Object.java:485) > org.apache.felix.framework.util.EventDispatcher.run(EventDispatcher.java:917) > org.apache.felix.framework.util.EventDispatcher.access$000(EventDispatcher.java:54) > org.apache.felix.framework.util.EventDispatcher$1.run(EventDispatcher.java:106) > java.lang.Thread.run(Thread.java:619) > Name: FelixStartLevel > State: WAITING on java.util.ArrayList@1c68b20 > Total blocked: 7 Total waited: 8 > Stack trace: > java.lang.Object.wait(Native Method) > java.lang.Object.wait(Object.java:485) > org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:242) > java.lang.Thread.run(Thread.java:619) > Name: FelixPackageAdmin > State: WAITING on org.apache.felix.framework.PackageAdminImpl@1d4ab05 > Total blocked: 0 Total waited: 1 > Stack trace: > java.lang.Object.wait(Native Method) > java.lang.Object.wait(Object.java:485) > org.apache.felix.framework.PackageAdminImpl.run(PackageAdminImpl.java:316) > java.lang.Thread.run(Thread.java:619) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
