[jira] Commented: (FELIX-1573) Occasional NPE in URLHandlersBundleStreamHandler

2009-09-08 Thread Don Brown (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752950#action_12752950
 ] 

Don Brown commented on FELIX-1573:
--

While there does seem to be a race condition here, there is fallback code that 
should handle the situation.  In URLHandlers.getFrameworkFromContext(), if it 
can't determine the framework, it should go through the callstack to find a 
class loaded by the bundle class loader.  Unfortunately, it matches based on 
the class name, which it mistakenly thinks should be 
"org.apache.felix.framework.searchpolicy.ModuleImpl.ModuleClassLoader".  After 
much debugging, I realized the actual class name that will be returned from the 
classloader is 
"org.apache.felix.framework.searchpolicy.ModuleImpl$ModuleClassLoader".  Since 
changing this string, I haven't seen the error occur again.

> Occasional NPE in URLHandlersBundleStreamHandler
> 
>
> Key: FELIX-1573
> URL: https://issues.apache.org/jira/browse/FELIX-1573
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: felix-1.8.1, felix-2.0.0
>Reporter: Don Brown
>
> I'm occasionally seeing startup failures in my integration tests due to an 
> NPE in URLHandlersBundleStreamHandler that looks like some sort of race 
> condition: 
> - Started bundle org.springframework (5)
> 08-Sep-2009 02:54:37  - Loading XML bean definitions from OSGi 
> resource[bundle://6.0:0/META-INF/spring/extender/spring-event-bridge.xml|bnd.id=6|bnd.sym=org.springframework.osgi.extender]
> 08-Sep-2009 02:54:37  - Unable to process extender configuration
> 08-Sep-2009 02:54:37  
> org.springframework.beans.factory.BeanDefinitionStoreException: IOException 
> parsing XML document from OSGi 
> resource[bundle://6.0:0/META-INF/spring/extender/spring-event-bridge.xml|bnd.id=6|bnd.sym=org.springframework.osgi.extender];
>  nested exception is java.io.IOException: No framework context found
> 08-Sep-2009 02:54:37  at 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:349)
> 08-Sep-2009 02:54:37  at 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:310)
> 08-Sep-2009 02:54:37  at 
> org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:143)
> 08-Sep-2009 02:54:37  at 
> org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:178)
> 08-Sep-2009 02:54:37  at 
> org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:149)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext.loadBeanDefinitions(OsgiBundleXmlApplicationContext.java:176)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext.loadBeanDefinitions(OsgiBundleXmlApplicationContext.java:142)
> 08-Sep-2009 02:54:37  at 
> org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:123)
> 08-Sep-2009 02:54:37  at 
> org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:422)
> 08-Sep-2009 02:54:37  at 
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:352)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.access$301(AbstractDelegatedExecutionApplicationContext.java:69)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$1.run(AbstractDelegatedExecutionApplicationContext.java:186)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.normalRefresh(AbstractDelegatedExecutionApplicationContext.java:182)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$NoDependenciesWaitRefreshExecutor.refresh(AbstractDelegatedExecutionApplicationContext.java:89)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.refresh(AbstractDelegatedExecutionApplicationContext.java:175)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.extender.internal.support.ExtenderConfiguration.(ExtenderC

[jira] Updated: (FELIX-1573) Occasional NPE in URLHandlersBundleStreamHandler

2009-09-08 Thread Don Brown (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Don Brown updated FELIX-1573:
-

Affects Version/s: felix-2.0.0

> Occasional NPE in URLHandlersBundleStreamHandler
> 
>
> Key: FELIX-1573
> URL: https://issues.apache.org/jira/browse/FELIX-1573
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: felix-1.8.1, felix-2.0.0
>Reporter: Don Brown
>
> I'm occasionally seeing startup failures in my integration tests due to an 
> NPE in URLHandlersBundleStreamHandler that looks like some sort of race 
> condition: 
> - Started bundle org.springframework (5)
> 08-Sep-2009 02:54:37  - Loading XML bean definitions from OSGi 
> resource[bundle://6.0:0/META-INF/spring/extender/spring-event-bridge.xml|bnd.id=6|bnd.sym=org.springframework.osgi.extender]
> 08-Sep-2009 02:54:37  - Unable to process extender configuration
> 08-Sep-2009 02:54:37  
> org.springframework.beans.factory.BeanDefinitionStoreException: IOException 
> parsing XML document from OSGi 
> resource[bundle://6.0:0/META-INF/spring/extender/spring-event-bridge.xml|bnd.id=6|bnd.sym=org.springframework.osgi.extender];
>  nested exception is java.io.IOException: No framework context found
> 08-Sep-2009 02:54:37  at 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:349)
> 08-Sep-2009 02:54:37  at 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:310)
> 08-Sep-2009 02:54:37  at 
> org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:143)
> 08-Sep-2009 02:54:37  at 
> org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:178)
> 08-Sep-2009 02:54:37  at 
> org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:149)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext.loadBeanDefinitions(OsgiBundleXmlApplicationContext.java:176)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext.loadBeanDefinitions(OsgiBundleXmlApplicationContext.java:142)
> 08-Sep-2009 02:54:37  at 
> org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:123)
> 08-Sep-2009 02:54:37  at 
> org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:422)
> 08-Sep-2009 02:54:37  at 
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:352)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.access$301(AbstractDelegatedExecutionApplicationContext.java:69)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$1.run(AbstractDelegatedExecutionApplicationContext.java:186)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.normalRefresh(AbstractDelegatedExecutionApplicationContext.java:182)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$NoDependenciesWaitRefreshExecutor.refresh(AbstractDelegatedExecutionApplicationContext.java:89)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.refresh(AbstractDelegatedExecutionApplicationContext.java:175)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.extender.internal.support.ExtenderConfiguration.(ExtenderConfiguration.java:169)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.extender.internal.activator.ContextLoaderListener.start(ContextLoaderListener.java:380)
> 08-Sep-2009 02:54:37  at 
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:589)
> 08-Sep-2009 02:54:37  at 
> org.apache.felix.framework.Felix.startBundle(Felix.java:1461)
> 08-Sep-2009 02:54:37  at 
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:984)
> 08-Sep-2009 02:54:37  at 
> org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:263)
> 08-Sep-2009 02:54:37  at java.lang.Thread.run(Thread.java:595)
> 08-Sep-2009 02:54:37

[jira] Resolved: (FELIX-1455) OSGi Storage is hardcoded to be data/cache

2009-09-08 Thread Guillaume Nodet (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet resolved FELIX-1455.


   Resolution: Fixed
Fix Version/s: karaf-1.0.0
 Assignee: Guillaume Nodet

URL: http://svn.apache.org/viewvc?rev=812785&view=rev


> OSGi Storage is hardcoded to be data/cache
> --
>
> Key: FELIX-1455
> URL: https://issues.apache.org/jira/browse/FELIX-1455
> Project: Felix
>  Issue Type: Improvement
>  Components: Karaf
>Affects Versions: karaf-1.0.0
>Reporter: David Bosschaert
>Assignee: Guillaume Nodet
> Fix For: karaf-1.0.0
>
>
> In Karaf, there is the following code (in the Main class):
> File storage = new File(karafBase.getPath(), "data/cache");
> storage.mkdirs();
> configProps.setProperty(Constants.FRAMEWORK_STORAGE, 
> storage.getAbsolutePath());
> This basically always sets the framework storage to the same thing. It would 
> be better if this property was only set if it wasn't already there, so that 
> users can override it.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



Re: [VOTE] Release gogo 0.2.0

2009-09-08 Thread Freeman Fang

+1

Freeman
On 2009-9-9, at 上午4:33, Guillaume Nodet wrote:


I've uploaded a first release of gogo.

Staging repository:
https://repository.apache.org/content/repositories/felix-staging-048/

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 48 /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.

--
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Open Source SOA
http://fusesource.com



--
Freeman Fang

Open Source SOA: http://fusesource.com



[jira] Issue Comment Edited: (FELIX-1573) Occasional NPE in URLHandlersBundleStreamHandler

2009-09-08 Thread Don Brown (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752872#action_12752872
 ] 

Don Brown edited comment on FELIX-1573 at 9/8/09 7:46 PM:
--

I can't reproduce this on OSX (1.5 or 1.6), but can reliably on Linux (1.6.0_13)

  was (Author: mrdon):
I can't reproduce this on OSX, but can reliably on Linux, 1.5 JVM.
  
> Occasional NPE in URLHandlersBundleStreamHandler
> 
>
> Key: FELIX-1573
> URL: https://issues.apache.org/jira/browse/FELIX-1573
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: felix-1.8.1
>Reporter: Don Brown
>
> I'm occasionally seeing startup failures in my integration tests due to an 
> NPE in URLHandlersBundleStreamHandler that looks like some sort of race 
> condition: 
> - Started bundle org.springframework (5)
> 08-Sep-2009 02:54:37  - Loading XML bean definitions from OSGi 
> resource[bundle://6.0:0/META-INF/spring/extender/spring-event-bridge.xml|bnd.id=6|bnd.sym=org.springframework.osgi.extender]
> 08-Sep-2009 02:54:37  - Unable to process extender configuration
> 08-Sep-2009 02:54:37  
> org.springframework.beans.factory.BeanDefinitionStoreException: IOException 
> parsing XML document from OSGi 
> resource[bundle://6.0:0/META-INF/spring/extender/spring-event-bridge.xml|bnd.id=6|bnd.sym=org.springframework.osgi.extender];
>  nested exception is java.io.IOException: No framework context found
> 08-Sep-2009 02:54:37  at 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:349)
> 08-Sep-2009 02:54:37  at 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:310)
> 08-Sep-2009 02:54:37  at 
> org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:143)
> 08-Sep-2009 02:54:37  at 
> org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:178)
> 08-Sep-2009 02:54:37  at 
> org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:149)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext.loadBeanDefinitions(OsgiBundleXmlApplicationContext.java:176)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext.loadBeanDefinitions(OsgiBundleXmlApplicationContext.java:142)
> 08-Sep-2009 02:54:37  at 
> org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:123)
> 08-Sep-2009 02:54:37  at 
> org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:422)
> 08-Sep-2009 02:54:37  at 
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:352)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.access$301(AbstractDelegatedExecutionApplicationContext.java:69)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$1.run(AbstractDelegatedExecutionApplicationContext.java:186)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.normalRefresh(AbstractDelegatedExecutionApplicationContext.java:182)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$NoDependenciesWaitRefreshExecutor.refresh(AbstractDelegatedExecutionApplicationContext.java:89)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.refresh(AbstractDelegatedExecutionApplicationContext.java:175)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.extender.internal.support.ExtenderConfiguration.(ExtenderConfiguration.java:169)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.extender.internal.activator.ContextLoaderListener.start(ContextLoaderListener.java:380)
> 08-Sep-2009 02:54:37  at 
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:589)
> 08-Sep-2009 02:54:37  at 
> org.apache.felix.framework.Felix.startBundle(Felix.java:1461)
> 08-Sep-2009 02:54:37  at 
> org.apache.felix.framework.Felix.set

[jira] Commented: (FELIX-1573) Occasional NPE in URLHandlersBundleStreamHandler

2009-09-08 Thread Don Brown (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752872#action_12752872
 ] 

Don Brown commented on FELIX-1573:
--

I can't reproduce this on OSX, but can reliably on Linux, 1.5 JVM.

> Occasional NPE in URLHandlersBundleStreamHandler
> 
>
> Key: FELIX-1573
> URL: https://issues.apache.org/jira/browse/FELIX-1573
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: felix-1.8.1
>Reporter: Don Brown
>
> I'm occasionally seeing startup failures in my integration tests due to an 
> NPE in URLHandlersBundleStreamHandler that looks like some sort of race 
> condition: 
> - Started bundle org.springframework (5)
> 08-Sep-2009 02:54:37  - Loading XML bean definitions from OSGi 
> resource[bundle://6.0:0/META-INF/spring/extender/spring-event-bridge.xml|bnd.id=6|bnd.sym=org.springframework.osgi.extender]
> 08-Sep-2009 02:54:37  - Unable to process extender configuration
> 08-Sep-2009 02:54:37  
> org.springframework.beans.factory.BeanDefinitionStoreException: IOException 
> parsing XML document from OSGi 
> resource[bundle://6.0:0/META-INF/spring/extender/spring-event-bridge.xml|bnd.id=6|bnd.sym=org.springframework.osgi.extender];
>  nested exception is java.io.IOException: No framework context found
> 08-Sep-2009 02:54:37  at 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:349)
> 08-Sep-2009 02:54:37  at 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:310)
> 08-Sep-2009 02:54:37  at 
> org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:143)
> 08-Sep-2009 02:54:37  at 
> org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:178)
> 08-Sep-2009 02:54:37  at 
> org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:149)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext.loadBeanDefinitions(OsgiBundleXmlApplicationContext.java:176)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext.loadBeanDefinitions(OsgiBundleXmlApplicationContext.java:142)
> 08-Sep-2009 02:54:37  at 
> org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:123)
> 08-Sep-2009 02:54:37  at 
> org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:422)
> 08-Sep-2009 02:54:37  at 
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:352)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.access$301(AbstractDelegatedExecutionApplicationContext.java:69)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$1.run(AbstractDelegatedExecutionApplicationContext.java:186)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.normalRefresh(AbstractDelegatedExecutionApplicationContext.java:182)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$NoDependenciesWaitRefreshExecutor.refresh(AbstractDelegatedExecutionApplicationContext.java:89)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.refresh(AbstractDelegatedExecutionApplicationContext.java:175)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.extender.internal.support.ExtenderConfiguration.(ExtenderConfiguration.java:169)
> 08-Sep-2009 02:54:37  at 
> org.springframework.osgi.extender.internal.activator.ContextLoaderListener.start(ContextLoaderListener.java:380)
> 08-Sep-2009 02:54:37  at 
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:589)
> 08-Sep-2009 02:54:37  at 
> org.apache.felix.framework.Felix.startBundle(Felix.java:1461)
> 08-Sep-2009 02:54:37  at 
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:984)
> 08-Sep-2009 02:54:37  at 
> org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:263)
> 08-Sep-2009 02:54:

[jira] Commented: (FELIX-1370) Sometimes the configuration for org.apache.felix.webconsole.internal.servlet.OsgiManager is ignored

2009-09-08 Thread Tim Moloney (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752865#action_12752865
 ] 

Tim Moloney commented on FELIX-1370:


Would it be a good idea to update configadmin to 1.2.4 that was just released?  
I can start testing with that.  I don't think I saw any problems with 
1.2.3-SNAPSHOT.

> Sometimes the configuration for 
> org.apache.felix.webconsole.internal.servlet.OsgiManager is ignored
> ---
>
> Key: FELIX-1370
> URL: https://issues.apache.org/jira/browse/FELIX-1370
> Project: Felix
>  Issue Type: Bug
>  Components: Karaf
>Reporter: Tim Moloney
>
> About half of the time, I can access the webconsole as expected using the 
> username/password karaf/karaf.  The other times it appears that the 
> configuration for org.apache.felix.webconsole.internal.servlet.OsgiManager is 
> ignored and I have to log in as admin/admin (the default webconsole 
> username/password).
> This can happen after a fresh start of karaf and loading the webconsole using 
> "features:install webconsole".  It also happens when reloading the webconsole 
> using "features:uninstall webconsole" and "features:install webconsole".

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (FELIX-1419) Add support for nested/inner classes in SCR Plugins (QDox+Annotations)

2009-09-08 Thread Stefan Seifert (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-1419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752853#action_12752853
 ] 

Stefan Seifert commented on FELIX-1419:
---

yes, no problem. i'm in vacation the next two weeks, i will do it after that.

> Add support for nested/inner classes in SCR Plugins (QDox+Annotations)
> --
>
> Key: FELIX-1419
> URL: https://issues.apache.org/jira/browse/FELIX-1419
> Project: Felix
>  Issue Type: Improvement
>  Components: Maven SCR Plugin
>Affects Versions: maven-scr-plugin-1.2.0
>Reporter: Stefan Seifert
>Assignee: Carsten Ziegeler
> Fix For: maven-scr-plugin-1.4.0
>
> Attachments: 090728_innerclasssupport.patch
>
>
> the current scr plugin implementation ignores inner classes, even if they 
> have SCR plugin annotations or QDox tags.
> the attached patch solves this problem.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



Re: Concurrency problems in latest Felix

2009-09-08 Thread Richard S. Hall

On 9/8/09 7:53 PM, Don Brown wrote:

As you may have noticed from the issues, I'm getting several
concurrency failures in the rewritten URLHandlers code after upgrading
from 1.2.1.  These bugs are keeping my plugin builds red about 95% of
the time, which is basically a showstopper.  I see Karl has a fix for
the deadlock [1], and I just filed the race condition [2], so assuming
they get fixed on trunk soon, how soon could I get a Felix 2.0.1?
Alternatively, I could rollback to my fork of 1.2.1, but I'd hate to
do that due to some bugs in class resolution that were fixed in later
releases.  I guess I could also fork 1.8.1 or 2.0.0, but I'd really
rather not.
   


Well, if we come up with patch against trunk, then it seems forking 
2.0.0 would make more sense until there is an official release including 
them.



Also, I'm surprised no one else has seen this deadlock before as it
seems to have been in the code for a while.  Am I the only one that
has heaps of integration tests bringing Felix up and down?
   


Well, you are just reporting them, no? :-)

The URL Handlers section of code is quite terrible with respect to 
concurrency handling...the code is super complicated and has to deal 
with a lot of concurrency issues within the JVM and how class loading 
happens during URL resolution...this was exacerbated by the fact that 
the OSGi spec was changed to specifically allow built-in stream handler 
overloading.


As you say, these bugs apparently aren't new, just undiscovered, so we 
will address them as they are found. Thanks for reporting them.


-> richard

Don

[1] https://issues.apache.org/jira/browse/FELIX-1565
[2] https://issues.apache.org/jira/browse/FELIX-1573
   


Re: [VOTE] Felix framework 2.0.0 and related subprojects releases

2009-09-08 Thread Don Brown
-0 Due to the concurrency issues I'm seeing in Felix.  Not -1 because
these issues are in 1.8.1 as well, so I guess it is no worse then that
GA release.

Don

On Mon, Sep 7, 2009 at 9:53 AM, Karl Pauls wrote:
> I would like to call a vote on the following subproject releases:
>
> org.osgi.core 1.4.0 *
> org.osgi.compendium 1.4.0 *
> shell 1.4.0
> shell.tui 1.4.0
> bundlerepository 1.4.1
> framework  2.0.0
> main 2.0.0
>
> Staging repository:
> https://repository.apache.org/content/repositories/felix-staging-044//
>
> 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 44 /tmp/felix-staging
>
> Additionally, a convenience binary release is provided at:
>
> http://people.apache.org/~pauls/2.0.0/
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
>
> * The core and compendium subprojects are being released because
> framework depends on them, but they will not be published.
>


Concurrency problems in latest Felix

2009-09-08 Thread Don Brown
As you may have noticed from the issues, I'm getting several
concurrency failures in the rewritten URLHandlers code after upgrading
from 1.2.1.  These bugs are keeping my plugin builds red about 95% of
the time, which is basically a showstopper.  I see Karl has a fix for
the deadlock [1], and I just filed the race condition [2], so assuming
they get fixed on trunk soon, how soon could I get a Felix 2.0.1?
Alternatively, I could rollback to my fork of 1.2.1, but I'd hate to
do that due to some bugs in class resolution that were fixed in later
releases.  I guess I could also fork 1.8.1 or 2.0.0, but I'd really
rather not.

Also, I'm surprised no one else has seen this deadlock before as it
seems to have been in the code for a while.  Am I the only one that
has heaps of integration tests bringing Felix up and down?

Don

[1] https://issues.apache.org/jira/browse/FELIX-1565
[2] https://issues.apache.org/jira/browse/FELIX-1573


[jira] Created: (FELIX-1573) Occasional NPE in URLHandlersBundleStreamHandler

2009-09-08 Thread Don Brown (JIRA)
Occasional NPE in URLHandlersBundleStreamHandler


 Key: FELIX-1573
 URL: https://issues.apache.org/jira/browse/FELIX-1573
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: felix-1.8.1
Reporter: Don Brown


I'm occasionally seeing startup failures in my integration tests due to an NPE 
in URLHandlersBundleStreamHandler that looks like some sort of race condition: 

- Started bundle org.springframework (5)
08-Sep-2009 02:54:37- Loading XML bean definitions from OSGi 
resource[bundle://6.0:0/META-INF/spring/extender/spring-event-bridge.xml|bnd.id=6|bnd.sym=org.springframework.osgi.extender]
08-Sep-2009 02:54:37- Unable to process extender configuration
08-Sep-2009 02:54:37
org.springframework.beans.factory.BeanDefinitionStoreException: IOException 
parsing XML document from OSGi 
resource[bundle://6.0:0/META-INF/spring/extender/spring-event-bridge.xml|bnd.id=6|bnd.sym=org.springframework.osgi.extender];
 nested exception is java.io.IOException: No framework context found
08-Sep-2009 02:54:37at 
org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:349)
08-Sep-2009 02:54:37at 
org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:310)
08-Sep-2009 02:54:37at 
org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:143)
08-Sep-2009 02:54:37at 
org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:178)
08-Sep-2009 02:54:37at 
org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:149)
08-Sep-2009 02:54:37at 
org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext.loadBeanDefinitions(OsgiBundleXmlApplicationContext.java:176)
08-Sep-2009 02:54:37at 
org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext.loadBeanDefinitions(OsgiBundleXmlApplicationContext.java:142)
08-Sep-2009 02:54:37at 
org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:123)
08-Sep-2009 02:54:37at 
org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:422)
08-Sep-2009 02:54:37at 
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:352)
08-Sep-2009 02:54:37at 
org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.access$301(AbstractDelegatedExecutionApplicationContext.java:69)
08-Sep-2009 02:54:37at 
org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$1.run(AbstractDelegatedExecutionApplicationContext.java:186)
08-Sep-2009 02:54:37at 
org.springframework.osgi.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85)
08-Sep-2009 02:54:37at 
org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.normalRefresh(AbstractDelegatedExecutionApplicationContext.java:182)
08-Sep-2009 02:54:37at 
org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$NoDependenciesWaitRefreshExecutor.refresh(AbstractDelegatedExecutionApplicationContext.java:89)
08-Sep-2009 02:54:37at 
org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.refresh(AbstractDelegatedExecutionApplicationContext.java:175)
08-Sep-2009 02:54:37at 
org.springframework.osgi.extender.internal.support.ExtenderConfiguration.(ExtenderConfiguration.java:169)
08-Sep-2009 02:54:37at 
org.springframework.osgi.extender.internal.activator.ContextLoaderListener.start(ContextLoaderListener.java:380)
08-Sep-2009 02:54:37at 
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:589)
08-Sep-2009 02:54:37at 
org.apache.felix.framework.Felix.startBundle(Felix.java:1461)
08-Sep-2009 02:54:37at 
org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:984)
08-Sep-2009 02:54:37at 
org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:263)
08-Sep-2009 02:54:37at java.lang.Thread.run(Thread.java:595)
08-Sep-2009 02:54:37Caused by: java.io.IOException: No framework context 
found
08-Sep-2009 02:54:37at 
org.apache.felix.framework.URLHandlersBundleStreamHandler.openConnection(URLHandlersBundleStreamHandler.java:72)
08-Sep-2009 02:54:37at java.net.URL.openConnection(URL.java:943)
08-Sep-2009 02:54:37

Re: [VOTE] Release gogo 0.2.0

2009-09-08 Thread Chris Custine
+1
--
Chris Custine
FUSESource :: http://fusesource.com
My Blog :: http://blog.organicelement.com
Apache ServiceMix :: http://servicemix.apache.org
Apache Directory Server :: http://directory.apache.org


On Tue, Sep 8, 2009 at 2:33 PM, Guillaume Nodet  wrote:

> I've uploaded a first release of gogo.
>
> Staging repository:
> https://repository.apache.org/content/repositories/felix-staging-048/
>
> 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 48 /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.
>
> --
> Cheers,
> Guillaume Nodet
> 
> Blog: http://gnodet.blogspot.com/
> 
> Open Source SOA
> http://fusesource.com
>


Re: [VOTE] Release gogo 0.2.0

2009-09-08 Thread Alin Dreghiciu
+1 (non binding)

On Tue, Sep 8, 2009 at 11:33 PM, Guillaume Nodet  wrote:

> I've uploaded a first release of gogo.
>
> Staging repository:
> https://repository.apache.org/content/repositories/felix-staging-048/
>
> 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 48 /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.
>
> --
> Cheers,
> Guillaume Nodet
> 
> Blog: http://gnodet.blogspot.com/
> 
> Open Source SOA
> http://fusesource.com
>



-- 
Alin Dreghiciu
Software Developer
My profile: http://www.linkedin.com/in/alindreghiciu
My blog: http://adreghiciu.blogspot.com
http://www.ops4j.org - New Energy for OSS Communities - Open Participation
Software.
http://www.qi4j.org - New Energy for Java - Domain Driven Development.


Re: [VOTE] Release Felix iPOJO 1.4.2

2009-09-08 Thread Chris Custine
+1
--
Chris Custine
FUSESource :: http://fusesource.com
My Blog :: http://blog.organicelement.com
Apache ServiceMix :: http://servicemix.apache.org
Apache Directory Server :: http://directory.apache.org


On Fri, Sep 4, 2009 at 3:00 AM, Clement Escoffier <
clement.escoff...@gmail.com> wrote:

> Hi,
>
> It's time to restart the iPOJO release. We recently fix 3 critical issues
> affecting iPOJO 1.4.0.
> - FELIX-1411 Directory manipulation does not find components on windows
> - FELIX-1497 iPOJO Web Console plugin NPE when the service reference list
> is null
> - FELIX-1518 iPOJO manipulator is really slow even when annotation are
> ignored
> There are still some outstanding issues but they will be solved in the new
> version (1.6.0)
> Five artifacts are released:
> - the manipulator
> - the Ant task
> - the Maven plugin
> - the online-manipulator
> - the web console plugin
>
> Staging repository:
> https://repository.apache.org/content/repositories/felix-staging-042/
>
> 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 042 /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 1 week.
>
> Thanks and regards,
>
> Clement


Re: [VOTE] Felix framework 2.0.0 and related subprojects releases

2009-09-08 Thread Chris Custine
+1
--
Chris Custine
FUSESource :: http://fusesource.com
My Blog :: http://blog.organicelement.com
Apache ServiceMix :: http://servicemix.apache.org
Apache Directory Server :: http://directory.apache.org


On Sun, Sep 6, 2009 at 5:53 PM, Karl Pauls  wrote:

> I would like to call a vote on the following subproject releases:
>
> org.osgi.core 1.4.0 *
> org.osgi.compendium 1.4.0 *
> shell 1.4.0
> shell.tui 1.4.0
> bundlerepository 1.4.1
> framework  2.0.0
> main 2.0.0
>
> Staging repository:
> https://repository.apache.org/content/repositories/felix-staging-044//
>
> 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 44 /tmp/felix-staging
>
> Additionally, a convenience binary release is provided at:
>
> http://people.apache.org/~pauls/2.0.0/
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
>
> * The core and compendium subprojects are being released because
> framework depends on them, but they will not be published.
>


[jira] Commented: (FELIX-1563) Felix latest bundle repository cannot be started for some reason

2009-09-08 Thread Richard S. Hall (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752764#action_12752764
 ] 

Richard S. Hall commented on FELIX-1563:


Yes, that is what I am saying.

> Felix latest bundle repository cannot be started for some reason
> 
>
> Key: FELIX-1563
> URL: https://issues.apache.org/jira/browse/FELIX-1563
> Project: Felix
>  Issue Type: Bug
>  Components: Bundle Repository (OBR)
>Affects Versions: felix-1.8.0
>Reporter: david small99
>
> I tried to use the org.apache.felix.bundlerepository-1.4.0.jar. The bundle 
> cannot be started.
> org.osgi.framework.BundleException: Exception in 
> org.apache.felix.bundlerepository.Activator.start() of bundle 
> org.apache.felix.bundlerepository.
> at 
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1010)
> at 
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:966)
> at 
> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:317)
> at 
> org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:256)
> at 
> org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._start(FrameworkCommandProvider.java:239)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:599)
> at 
> org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(FrameworkCommandInterpreter.java:145)
> at 
> org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(FrameworkConsole.java:293)
> at 
> org.eclipse.osgi.framework.internal.core.FrameworkConsole.console(FrameworkConsole.java:278)
> at 
> org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(FrameworkConsole.java:213)
> at java.lang.Thread.run(Thread.java:735)
> Caused by: java.lang.NoSuchMethodError: 
> org/osgi/framework/Bundle.getBundleContext()Lorg/osgi/framework/BundleContext;
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl$LocalResourceImpl.initialize(LocalRepositoryImpl.java:222)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl$LocalResourceImpl.(LocalRepositoryImpl.java:190)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl$LocalResourceImpl.(LocalRepositoryImpl.java:182)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl.addBundle(LocalRepositoryImpl.java:104)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl.initialize(LocalRepositoryImpl.java:169)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl.(LocalRepositoryImpl.java:56)
> at 
> org.apache.felix.bundlerepository.RepositoryAdminImpl.(RepositoryAdminImpl.java:58)
> at 
> org.apache.felix.bundlerepository.Activator.start(Activator.java:35)
> at 
> org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:991)
> at 
> java.security.AccessController.doPrivileged(AccessController.java:251)
> at 
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:985)
> ... 13 more
> Nested Exception:
> java.lang.NoSuchMethodError: 
> org/osgi/framework/Bundle.getBundleContext()Lorg/osgi/framework/BundleContext;
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl$LocalResourceImpl.initialize(LocalRepositoryImpl.java:222)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl$LocalResourceImpl.(LocalRepositoryImpl.java:190)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl$LocalResourceImpl.(LocalRepositoryImpl.java:182)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl.addBundle(LocalRepositoryImpl.java:104)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl.initialize(LocalRepositoryImpl.java:169)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl.(LocalRepositoryImpl.java:56)
> at 
> org.apache.felix.bundlerepository.RepositoryAdminImpl.(RepositoryAdminImpl.java:58)
> at 
> org.apache.felix.bundlerepository.Activator.start(Activator.java:35)
> at 
> org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:991)
> at 
> java.security.AccessController.doPrivileged(AccessController.java:251)
> at 
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.j

[jira] Commented: (FELIX-1563) Felix latest bundle repository cannot be started for some reason

2009-09-08 Thread david small99 (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752747#action_12752747
 ] 

david small99 commented on FELIX-1563:
--

Does it mean that the felix bundleRepository's import-Package is wrong? Am I 
right to say the bundle org.apache.felix.bundlerepository-1.4.0.jar needs 
org.osgi.framework version 1.4 or above?
Thanks

> Felix latest bundle repository cannot be started for some reason
> 
>
> Key: FELIX-1563
> URL: https://issues.apache.org/jira/browse/FELIX-1563
> Project: Felix
>  Issue Type: Bug
>  Components: Bundle Repository (OBR)
>Affects Versions: felix-1.8.0
>Reporter: david small99
>
> I tried to use the org.apache.felix.bundlerepository-1.4.0.jar. The bundle 
> cannot be started.
> org.osgi.framework.BundleException: Exception in 
> org.apache.felix.bundlerepository.Activator.start() of bundle 
> org.apache.felix.bundlerepository.
> at 
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1010)
> at 
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:966)
> at 
> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:317)
> at 
> org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:256)
> at 
> org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._start(FrameworkCommandProvider.java:239)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:599)
> at 
> org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(FrameworkCommandInterpreter.java:145)
> at 
> org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(FrameworkConsole.java:293)
> at 
> org.eclipse.osgi.framework.internal.core.FrameworkConsole.console(FrameworkConsole.java:278)
> at 
> org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(FrameworkConsole.java:213)
> at java.lang.Thread.run(Thread.java:735)
> Caused by: java.lang.NoSuchMethodError: 
> org/osgi/framework/Bundle.getBundleContext()Lorg/osgi/framework/BundleContext;
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl$LocalResourceImpl.initialize(LocalRepositoryImpl.java:222)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl$LocalResourceImpl.(LocalRepositoryImpl.java:190)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl$LocalResourceImpl.(LocalRepositoryImpl.java:182)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl.addBundle(LocalRepositoryImpl.java:104)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl.initialize(LocalRepositoryImpl.java:169)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl.(LocalRepositoryImpl.java:56)
> at 
> org.apache.felix.bundlerepository.RepositoryAdminImpl.(RepositoryAdminImpl.java:58)
> at 
> org.apache.felix.bundlerepository.Activator.start(Activator.java:35)
> at 
> org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:991)
> at 
> java.security.AccessController.doPrivileged(AccessController.java:251)
> at 
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:985)
> ... 13 more
> Nested Exception:
> java.lang.NoSuchMethodError: 
> org/osgi/framework/Bundle.getBundleContext()Lorg/osgi/framework/BundleContext;
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl$LocalResourceImpl.initialize(LocalRepositoryImpl.java:222)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl$LocalResourceImpl.(LocalRepositoryImpl.java:190)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl$LocalResourceImpl.(LocalRepositoryImpl.java:182)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl.addBundle(LocalRepositoryImpl.java:104)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl.initialize(LocalRepositoryImpl.java:169)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl.(LocalRepositoryImpl.java:56)
> at 
> org.apache.felix.bundlerepository.RepositoryAdminImpl.(RepositoryAdminImpl.java:58)
> at 
> org.apache.felix.bundlerepository.Activator.start(Activator.java:35)
> at 
> org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:991)
> at 
> java.security.

[jira] Created: (FELIX-1572) File Install running in an infinite loop while watching multiple directories, once of which is itself

2009-09-08 Thread Ajay Kumar (JIRA)
File Install running in an infinite loop while watching multiple directories, 
once of which is itself
-

 Key: FELIX-1572
 URL: https://issues.apache.org/jira/browse/FELIX-1572
 Project: Felix
  Issue Type: Bug
  Components: File Install
Affects Versions: fileinstall-2.0.0, fileinstall-1.2.0,  fileinstall-1.0.0
 Environment: generic
Reporter: Ajay Kumar


Felix File install runs in an infinite loop, if you put a configuration file to 
watch itself

Steps to reproduce
1. Configure file install to watch /foo/bar directory
2. Put a new configuration file e.g org.apache.felix.fileinstall-.cfg in 
/foo/bar directory in order to watch multiple directories. If the value of 
felix.fileinstall.dir inside the configuration file  is anything but /foo/bar, 
it works great. 
However if you modify the value of felix.fileinstall.dir  to /foo/bar (meaning 
the same directory which file install is watching), it runs in an infinite loop


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



Re: [VOTE] Release Felix iPOJO 1.4.2

2009-09-08 Thread Karl Pauls
+1

regards,

Karl

On Tue, Sep 8, 2009 at 4:00 PM, Richard S. Hall wrote:
> +1
>
> However, I think there is an issue with the web console plugin, since it
> doesn't include any classes, so you might need to do another maintenance
> release for it.
>
> -> richard
>
> On 9/4/09 5:00, Clement Escoffier wrote:
>>
>> Hi,
>>
>> It's time to restart the iPOJO release. We recently fix 3 critical issues
>> affecting iPOJO 1.4.0.
>> - FELIX-1411 Directory manipulation does not find components on windows
>> - FELIX-1497 iPOJO Web Console plugin NPE when the service reference list
>> is null
>> - FELIX-1518 iPOJO manipulator is really slow even when annotation are
>> ignored
>> There are still some outstanding issues but they will be solved in the new
>> version (1.6.0)
>> Five artifacts are released:
>> - the manipulator
>> - the Ant task
>> - the Maven plugin
>> - the online-manipulator
>> - the web console plugin
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/felix-staging-042/
>>
>> 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 042 /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 1 week.
>>
>> Thanks and regards,
>>
>> Clement
>



-- 
Karl Pauls
karlpa...@gmail.com


[VOTE] Release gogo 0.2.0

2009-09-08 Thread Guillaume Nodet
I've uploaded a first release of gogo.

Staging repository:
https://repository.apache.org/content/repositories/felix-staging-048/

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 48 /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.

--
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Open Source SOA
http://fusesource.com


[jira] Updated: (FELIX-1565) Deadlock UrlHandlers

2009-09-08 Thread Karl Pauls (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Pauls updated FELIX-1565:
--

Affects Version/s: felix-2.0.0

I can confirm that this affects 2.0.0 as well. Fix needs to go into the next 
release then.

> Deadlock UrlHandlers
> 
>
> Key: FELIX-1565
> URL: https://issues.apache.org/jira/browse/FELIX-1565
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: felix-1.8.1, felix-2.0.0
> Environment: java version "1.6.0_14"
> Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
> Java HotSpot(TM) Server VM (build 14.0-b16, mixed mode)
> Linux
>Reporter: Don Brown
>Assignee: Karl Pauls
> Fix For: felix-2.2.0
>
>
> I'm getting a deadlock quite frequently in the URLHandlers class during our 
> unit tests:
> build 07-Sep-2009 23:13:49Java stack information for the threads listed 
> above:
> build 07-Sep-2009 23:13:49
> ===
> build 07-Sep-2009 23:13:49"FelixShutdown":
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.URLHandlers.unregisterFrameworkListsForContextSearch(URLHandlers.java:265)
> build 07-Sep-2009 23:13:49- waiting to lock <0xb41335e0> (a 
> java.util.HashMap)
> build 07-Sep-2009 23:13:49- locked <0xb00fd0e8> (a 
> java.lang.Class for java.net.URL)
> build 07-Sep-2009 23:13:49at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> build 07-Sep-2009 23:13:49at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> build 07-Sep-2009 23:13:49at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> build 07-Sep-2009 23:13:49at 
> java.lang.reflect.Method.invoke(Method.java:597)
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.util.SecureAction.invoke(SecureAction.java:763)
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.URLHandlers.unregisterFrameworkInstance(URLHandlers.java:533)
> build 07-Sep-2009 23:13:49- locked <0xb4133590> (a 
> java.util.ArrayList)
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.URLHandlersActivator.stop(URLHandlersActivator.java:63)
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:611)
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.Felix$SystemBundleActivator.run(Felix.java:4041)
> build 07-Sep-2009 23:13:49at java.lang.Thread.run(Thread.java:619)
> build 07-Sep-2009 23:13:49"main":
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.URLHandlers.getFrameworkFromContext(URLHandlers.java:571)
> build 07-Sep-2009 23:13:49- waiting to lock <0xb4133590> (a 
> java.util.ArrayList)
> build 07-Sep-2009 23:13:49- locked <0xb41335e0> (a 
> java.util.HashMap)
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.getStreamHandlerService(URLHandlersStreamHandlerProxy.java:465)
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.hashCode(URLHandlersStreamHandlerProxy.java:225)
> build 07-Sep-2009 23:13:49at java.net.URL.hashCode(URL.java:857)
> build 07-Sep-2009 23:13:49- locked <0xefb8c0a8> (a java.net.URL)
> build 07-Sep-2009 23:13:49at 
> java.util.HashMap.get(HashMap.java:300)
> build 07-Sep-2009 23:13:49at 
> sun.net.www.protocol.jar.JarFileFactory.getCachedJarFile(JarFileFactory.java:90)
> build 07-Sep-2009 23:13:49at 
> sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:50)
> build 07-Sep-2009 23:13:49- locked <0xb40027d8> (a 
> sun.net.www.protocol.jar.JarFileFactory)
> build 07-Sep-2009 23:13:49at 
> sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:104)
> build 07-Sep-2009 23:13:49at 
> sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:132)
> build 07-Sep-2009 23:13:49at 
> java.net.URL.openStream(URL.java:1009)
> build 07-Sep-2009 23:13:49at 
> aQute.lib.osgi.Analyzer.getBndManifest(Analyzer.java:591)
> build 07-Sep-2009 23:13:49at 
> aQute.lib.osgi.Analyzer.getVersion(Analyzer.java:554)
> build 07-Sep-2009 23:13:49at 
> aQute.lib.osgi.Analyzer.calcManifest(Analyzer.java:303)
> build 07-Sep-2009 23:13:49at 
> com.atlassian.plugin.osgi.container.felix.ExportsBuilder.determineExports(ExportsBuilder.java:84)
> build 07-Sep-2009 23:13:49at 
> com.atlassian.plugin.osgi.container.felix.TestExportsBuilder.testDetermineExportsInclu

Re: [VOTE] Felix framework 2.0.0 and related subprojects releases

2009-09-08 Thread Richard S. Hall
This should still work. If you have a test case, then create an issue. I 
will also try to do something similar soon too, so I will try to see if 
it works for me.


-> richard


On 09/08/2009 11:01 AM, Clement Escoffier wrote:

+1,

Just a strange behavior (ClassCastException) when a host publishes a 
log service to an embedded Felix. Might be a bug, but I need to 
investigate a little bit more.


Regards,

Clement


On 08.09.2009, at 08:37, Toni Menzel wrote:


+1 (not binding)

2009/9/8 Carsten Ziegeler 


+1

Carsten


--
Carsten Ziegeler
cziege...@apache.org





--
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.




[jira] Updated: (FELIX-1565) Deadlock UrlHandlers

2009-09-08 Thread Richard S. Hall (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall updated FELIX-1565:
---

Fix Version/s: felix-2.2.0

> Deadlock UrlHandlers
> 
>
> Key: FELIX-1565
> URL: https://issues.apache.org/jira/browse/FELIX-1565
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: felix-1.8.1
> Environment: java version "1.6.0_14"
> Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
> Java HotSpot(TM) Server VM (build 14.0-b16, mixed mode)
> Linux
>Reporter: Don Brown
>Assignee: Karl Pauls
> Fix For: felix-2.2.0
>
>
> I'm getting a deadlock quite frequently in the URLHandlers class during our 
> unit tests:
> build 07-Sep-2009 23:13:49Java stack information for the threads listed 
> above:
> build 07-Sep-2009 23:13:49
> ===
> build 07-Sep-2009 23:13:49"FelixShutdown":
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.URLHandlers.unregisterFrameworkListsForContextSearch(URLHandlers.java:265)
> build 07-Sep-2009 23:13:49- waiting to lock <0xb41335e0> (a 
> java.util.HashMap)
> build 07-Sep-2009 23:13:49- locked <0xb00fd0e8> (a 
> java.lang.Class for java.net.URL)
> build 07-Sep-2009 23:13:49at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> build 07-Sep-2009 23:13:49at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> build 07-Sep-2009 23:13:49at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> build 07-Sep-2009 23:13:49at 
> java.lang.reflect.Method.invoke(Method.java:597)
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.util.SecureAction.invoke(SecureAction.java:763)
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.URLHandlers.unregisterFrameworkInstance(URLHandlers.java:533)
> build 07-Sep-2009 23:13:49- locked <0xb4133590> (a 
> java.util.ArrayList)
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.URLHandlersActivator.stop(URLHandlersActivator.java:63)
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:611)
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.Felix$SystemBundleActivator.run(Felix.java:4041)
> build 07-Sep-2009 23:13:49at java.lang.Thread.run(Thread.java:619)
> build 07-Sep-2009 23:13:49"main":
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.URLHandlers.getFrameworkFromContext(URLHandlers.java:571)
> build 07-Sep-2009 23:13:49- waiting to lock <0xb4133590> (a 
> java.util.ArrayList)
> build 07-Sep-2009 23:13:49- locked <0xb41335e0> (a 
> java.util.HashMap)
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.getStreamHandlerService(URLHandlersStreamHandlerProxy.java:465)
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.hashCode(URLHandlersStreamHandlerProxy.java:225)
> build 07-Sep-2009 23:13:49at java.net.URL.hashCode(URL.java:857)
> build 07-Sep-2009 23:13:49- locked <0xefb8c0a8> (a java.net.URL)
> build 07-Sep-2009 23:13:49at 
> java.util.HashMap.get(HashMap.java:300)
> build 07-Sep-2009 23:13:49at 
> sun.net.www.protocol.jar.JarFileFactory.getCachedJarFile(JarFileFactory.java:90)
> build 07-Sep-2009 23:13:49at 
> sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:50)
> build 07-Sep-2009 23:13:49- locked <0xb40027d8> (a 
> sun.net.www.protocol.jar.JarFileFactory)
> build 07-Sep-2009 23:13:49at 
> sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:104)
> build 07-Sep-2009 23:13:49at 
> sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:132)
> build 07-Sep-2009 23:13:49at 
> java.net.URL.openStream(URL.java:1009)
> build 07-Sep-2009 23:13:49at 
> aQute.lib.osgi.Analyzer.getBndManifest(Analyzer.java:591)
> build 07-Sep-2009 23:13:49at 
> aQute.lib.osgi.Analyzer.getVersion(Analyzer.java:554)
> build 07-Sep-2009 23:13:49at 
> aQute.lib.osgi.Analyzer.calcManifest(Analyzer.java:303)
> build 07-Sep-2009 23:13:49at 
> com.atlassian.plugin.osgi.container.felix.ExportsBuilder.determineExports(ExportsBuilder.java:84)
> build 07-Sep-2009 23:13:49at 
> com.atlassian.plugin.osgi.container.felix.TestExportsBuilder.testDetermineExportsIncludeServiceInterfaces(TestExportsBuilder.java:68)
> build 07-Sep-2009 23:13:49at 
> sun.re

[jira] Commented: (FELIX-1565) Deadlock UrlHandlers

2009-09-08 Thread Karl Pauls (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752717#action_12752717
 ] 

Karl Pauls commented on FELIX-1565:
---

Yes, there is a possibility for deadlock if a Url is created/used while the 
framework is shutdown. While your simple fix would solve that it introduces 
another possibility for a different deadlock. 

However, I can see a fix for this - I will test it tomorrow and come back to 
this issue asap.

> Deadlock UrlHandlers
> 
>
> Key: FELIX-1565
> URL: https://issues.apache.org/jira/browse/FELIX-1565
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: felix-1.8.1
> Environment: java version "1.6.0_14"
> Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
> Java HotSpot(TM) Server VM (build 14.0-b16, mixed mode)
> Linux
>Reporter: Don Brown
>Assignee: Karl Pauls
> Fix For: felix-2.2.0
>
>
> I'm getting a deadlock quite frequently in the URLHandlers class during our 
> unit tests:
> build 07-Sep-2009 23:13:49Java stack information for the threads listed 
> above:
> build 07-Sep-2009 23:13:49
> ===
> build 07-Sep-2009 23:13:49"FelixShutdown":
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.URLHandlers.unregisterFrameworkListsForContextSearch(URLHandlers.java:265)
> build 07-Sep-2009 23:13:49- waiting to lock <0xb41335e0> (a 
> java.util.HashMap)
> build 07-Sep-2009 23:13:49- locked <0xb00fd0e8> (a 
> java.lang.Class for java.net.URL)
> build 07-Sep-2009 23:13:49at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> build 07-Sep-2009 23:13:49at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> build 07-Sep-2009 23:13:49at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> build 07-Sep-2009 23:13:49at 
> java.lang.reflect.Method.invoke(Method.java:597)
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.util.SecureAction.invoke(SecureAction.java:763)
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.URLHandlers.unregisterFrameworkInstance(URLHandlers.java:533)
> build 07-Sep-2009 23:13:49- locked <0xb4133590> (a 
> java.util.ArrayList)
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.URLHandlersActivator.stop(URLHandlersActivator.java:63)
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:611)
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.Felix$SystemBundleActivator.run(Felix.java:4041)
> build 07-Sep-2009 23:13:49at java.lang.Thread.run(Thread.java:619)
> build 07-Sep-2009 23:13:49"main":
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.URLHandlers.getFrameworkFromContext(URLHandlers.java:571)
> build 07-Sep-2009 23:13:49- waiting to lock <0xb4133590> (a 
> java.util.ArrayList)
> build 07-Sep-2009 23:13:49- locked <0xb41335e0> (a 
> java.util.HashMap)
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.getStreamHandlerService(URLHandlersStreamHandlerProxy.java:465)
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.hashCode(URLHandlersStreamHandlerProxy.java:225)
> build 07-Sep-2009 23:13:49at java.net.URL.hashCode(URL.java:857)
> build 07-Sep-2009 23:13:49- locked <0xefb8c0a8> (a java.net.URL)
> build 07-Sep-2009 23:13:49at 
> java.util.HashMap.get(HashMap.java:300)
> build 07-Sep-2009 23:13:49at 
> sun.net.www.protocol.jar.JarFileFactory.getCachedJarFile(JarFileFactory.java:90)
> build 07-Sep-2009 23:13:49at 
> sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:50)
> build 07-Sep-2009 23:13:49- locked <0xb40027d8> (a 
> sun.net.www.protocol.jar.JarFileFactory)
> build 07-Sep-2009 23:13:49at 
> sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:104)
> build 07-Sep-2009 23:13:49at 
> sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:132)
> build 07-Sep-2009 23:13:49at 
> java.net.URL.openStream(URL.java:1009)
> build 07-Sep-2009 23:13:49at 
> aQute.lib.osgi.Analyzer.getBndManifest(Analyzer.java:591)
> build 07-Sep-2009 23:13:49at 
> aQute.lib.osgi.Analyzer.getVersion(Analyzer.java:554)
> build 07-Sep-2009 23:13:49at 
> aQute.lib.osgi.Analyzer.calcManifest(Analyzer.java:303)
> build 07-Sep-2009 23:13:49at 
> com.atlassian.plug

[jira] Assigned: (FELIX-1565) Deadlock UrlHandlers

2009-09-08 Thread Karl Pauls (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Pauls reassigned FELIX-1565:
-

Assignee: Karl Pauls

> Deadlock UrlHandlers
> 
>
> Key: FELIX-1565
> URL: https://issues.apache.org/jira/browse/FELIX-1565
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: felix-1.8.1
> Environment: java version "1.6.0_14"
> Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
> Java HotSpot(TM) Server VM (build 14.0-b16, mixed mode)
> Linux
>Reporter: Don Brown
>Assignee: Karl Pauls
>
> I'm getting a deadlock quite frequently in the URLHandlers class during our 
> unit tests:
> build 07-Sep-2009 23:13:49Java stack information for the threads listed 
> above:
> build 07-Sep-2009 23:13:49
> ===
> build 07-Sep-2009 23:13:49"FelixShutdown":
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.URLHandlers.unregisterFrameworkListsForContextSearch(URLHandlers.java:265)
> build 07-Sep-2009 23:13:49- waiting to lock <0xb41335e0> (a 
> java.util.HashMap)
> build 07-Sep-2009 23:13:49- locked <0xb00fd0e8> (a 
> java.lang.Class for java.net.URL)
> build 07-Sep-2009 23:13:49at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> build 07-Sep-2009 23:13:49at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> build 07-Sep-2009 23:13:49at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> build 07-Sep-2009 23:13:49at 
> java.lang.reflect.Method.invoke(Method.java:597)
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.util.SecureAction.invoke(SecureAction.java:763)
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.URLHandlers.unregisterFrameworkInstance(URLHandlers.java:533)
> build 07-Sep-2009 23:13:49- locked <0xb4133590> (a 
> java.util.ArrayList)
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.URLHandlersActivator.stop(URLHandlersActivator.java:63)
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:611)
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.Felix$SystemBundleActivator.run(Felix.java:4041)
> build 07-Sep-2009 23:13:49at java.lang.Thread.run(Thread.java:619)
> build 07-Sep-2009 23:13:49"main":
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.URLHandlers.getFrameworkFromContext(URLHandlers.java:571)
> build 07-Sep-2009 23:13:49- waiting to lock <0xb4133590> (a 
> java.util.ArrayList)
> build 07-Sep-2009 23:13:49- locked <0xb41335e0> (a 
> java.util.HashMap)
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.getStreamHandlerService(URLHandlersStreamHandlerProxy.java:465)
> build 07-Sep-2009 23:13:49at 
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.hashCode(URLHandlersStreamHandlerProxy.java:225)
> build 07-Sep-2009 23:13:49at java.net.URL.hashCode(URL.java:857)
> build 07-Sep-2009 23:13:49- locked <0xefb8c0a8> (a java.net.URL)
> build 07-Sep-2009 23:13:49at 
> java.util.HashMap.get(HashMap.java:300)
> build 07-Sep-2009 23:13:49at 
> sun.net.www.protocol.jar.JarFileFactory.getCachedJarFile(JarFileFactory.java:90)
> build 07-Sep-2009 23:13:49at 
> sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:50)
> build 07-Sep-2009 23:13:49- locked <0xb40027d8> (a 
> sun.net.www.protocol.jar.JarFileFactory)
> build 07-Sep-2009 23:13:49at 
> sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:104)
> build 07-Sep-2009 23:13:49at 
> sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:132)
> build 07-Sep-2009 23:13:49at 
> java.net.URL.openStream(URL.java:1009)
> build 07-Sep-2009 23:13:49at 
> aQute.lib.osgi.Analyzer.getBndManifest(Analyzer.java:591)
> build 07-Sep-2009 23:13:49at 
> aQute.lib.osgi.Analyzer.getVersion(Analyzer.java:554)
> build 07-Sep-2009 23:13:49at 
> aQute.lib.osgi.Analyzer.calcManifest(Analyzer.java:303)
> build 07-Sep-2009 23:13:49at 
> com.atlassian.plugin.osgi.container.felix.ExportsBuilder.determineExports(ExportsBuilder.java:84)
> build 07-Sep-2009 23:13:49at 
> com.atlassian.plugin.osgi.container.felix.TestExportsBuilder.testDetermineExportsIncludeServiceInterfaces(TestExportsBuilder.java:68)
> build 07-Sep-2009 23:13:49at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native M

Re: Well-known property name for induced factory configuration

2009-09-08 Thread Guillaume Nodet
I don't think there is any real *need* for that, but being consistent when
possible never hurts.
In addition to providing a single key for a human readable factory pid, it
would also allow using different locations as input for such configurations
while enabling those to work together.

On Tue, Sep 8, 2009 at 21:21, Filippo Diotalevi  wrote:

> On Tue, Sep 8, 2009 at 8:54 PM, Felix Meschberger
> wrote:
> > Hi all
> >
> > In a comment to FELIX-1221 [1] Tim Moloney proposes the definition of a
> > well-known configuration property, which may act as kind of an alias for
> > the service.pid property automatically generated by the Configuration
> > Admin Service upon factory configuration creation.
> >
> > Such a property would serve multiple purposes:
> >
> >  * Provide a human readable identifaction of a factory
> >configuration (at least more human readable than the generated PID)
> >
> >  * Provide an alias for tools match factory configurations to external
> >data for synchronization. Candidates of such tools are:
> >- File Install
> >- Karaf Features
> >- Sling JCR Install (similar to File Install)
> >- Web Console
> >
> >
> > Currently each tool uses its own approach and its own name. Having a
> > common name would simplify things probably and would allow the Web
> > Console to better identify configurations etc.
> >
>
> Yes, if I understand correctly, it is what we have called in File
> Install "felix.fileinstall.filename"; in that case, we needed a way to
> remember the file generating the configuration dictionary (to retrieve
> it later), so we introduced that constant.
>
> What I don't understand is, is there any benefit in having a unified
> property name (besides the one you mention for the Web Console)?
>
> --
> Filippo Diotalevi
>



-- 
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Open Source SOA
http://fusesource.com


Re: Well-known property name for induced factory configuration

2009-09-08 Thread Filippo Diotalevi
On Tue, Sep 8, 2009 at 8:54 PM, Felix Meschberger wrote:
> Hi all
>
> In a comment to FELIX-1221 [1] Tim Moloney proposes the definition of a
> well-known configuration property, which may act as kind of an alias for
> the service.pid property automatically generated by the Configuration
> Admin Service upon factory configuration creation.
>
> Such a property would serve multiple purposes:
>
>  * Provide a human readable identifaction of a factory
>    configuration (at least more human readable than the generated PID)
>
>  * Provide an alias for tools match factory configurations to external
>    data for synchronization. Candidates of such tools are:
>            - File Install
>            - Karaf Features
>            - Sling JCR Install (similar to File Install)
>            - Web Console
>
>
> Currently each tool uses its own approach and its own name. Having a
> common name would simplify things probably and would allow the Web
> Console to better identify configurations etc.
>

Yes, if I understand correctly, it is what we have called in File
Install "felix.fileinstall.filename"; in that case, we needed a way to
remember the file generating the configuration dictionary (to retrieve
it later), so we introduced that constant.

What I don't understand is, is there any benefit in having a unified
property name (besides the one you mention for the Web Console)?

-- 
Filippo Diotalevi


Well-known property name for induced factory configuration

2009-09-08 Thread Felix Meschberger
Hi all

In a comment to FELIX-1221 [1] Tim Moloney proposes the definition of a
well-known configuration property, which may act as kind of an alias for
the service.pid property automatically generated by the Configuration
Admin Service upon factory configuration creation.

Such a property would serve multiple purposes:

  * Provide a human readable identifaction of a factory
configuration (at least more human readable than the generated PID)

  * Provide an alias for tools match factory configurations to external
data for synchronization. Candidates of such tools are:
- File Install
- Karaf Features
- Sling JCR Install (similar to File Install)
- Web Console


Currently each tool uses its own approach and its own name. Having a
common name would simplify things probably and would allow the Web
Console to better identify configurations etc.

The name could be something like felix.servicePid or so

WDYT ?

Regards
Felix


[1]https://issues.apache.org/jira/browse/FELIX-1221?focusedCommentId=12752588&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12752588


[jira] Resolved: (FELIX-1547) OS shell level admin commands for Karaf

2009-09-08 Thread Guillaume Nodet (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet resolved FELIX-1547.


Resolution: Fixed
  Assignee: Guillaume Nodet

Patch applied with many thanks.

URL: http://svn.apache.org/viewvc?rev=812616&view=rev


I've slightly modified the shell scripts when creating a new instance and 
instead of a karaf script, we now have two scripts named start and stop which 
delegate to the admin script (i renamed it from karaf-admin).  This will keep 
the list of instances consistent whichever way is used to create the instance.

Please close or reopen this issue if you have any problems.

> OS shell level admin commands for Karaf
> ---
>
> Key: FELIX-1547
> URL: https://issues.apache.org/jira/browse/FELIX-1547
> Project: Felix
>  Issue Type: New Feature
>  Components: Karaf
>Reporter: David Bosschaert
>Assignee: Guillaume Nodet
> Fix For: karaf-1.0.0
>
> Attachments: karaf-admin-8.patch
>
>
> Karaf has admin commands to create new instances from within its shell. 
> Examples are
>   admin:create
>   admin:list
>   admin:start
> etc...
> It would be good if (some of) these commands were available from the OS-level 
> command line - outside of the Karaf container.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



Re: [ANN] Apache Felix Configuration Admin Service version 1.2.4 Released

2009-09-08 Thread Felix Meschberger
Hi,

Clement Escoffier schrieb:
> 
> On 08.09.2009, at 16:44, Richard S. Hall wrote:
> 
>> On 9/8/09 10:13, Moloney, Tim M wrote:
>>> I'm confused about the versions of config admin service.
>>>
>>> 1.2.4 was just released but the trunk has 1.2.7-SNAPSHOT.
>>>
>>> What happened to 1.2.5 and 1.2.6?
> 
> 
> Maybe, I'm wrong but the tag org.apache.felix.configadmin-1.2.6 exists
> in felix releases.
> So, this one is still surviving :-)

No, it just died two minutes ago ;-) R.I.P

The tag was the remains of an attempt to have quick-shot fix for a nasty
bug (FELIX-1545, only occurring under kind of extreme conditions). The
fix did not have the expected result and so the release candidate was
declared a failure. I just forgot to remove the tag in the aftermath

So there will not be a 1.2.6.

Regards
Felix

> 
> Clement
> 
>>>
>>
>> Don't ask... ;-)
>>
>> -> richard
>>
>>>
>>> Tim Moloney The  reasonable  man adapts  himself  to
>>> MRSLthe world; the unreasonable one persists
>>> 2015 Cattlemen Road in trying to adapt the world to himself.
>>> Sarasota, FL  34232 Therefore  all progress  depends on  the
>>> (941) 377-6775 x208 unreasonable man.George Bernard Shaw
>>>
>>>
>>>
>>>
 -Original Message-
 From: Richard S. Hall [mailto:he...@ungoverned.org]
 Sent: Tuesday, September 08, 2009 09:56
 To: dev@felix.apache.org
 Subject: Re: [ANN] Apache Felix Configuration Admin Service
 version 1.2.4 Released

 I think these announcements are only really necessary on the
 users list,
 since we vote on it and see the vote result message here on
 the dev list...

 I think the release docs mention this.

 ->  richard

 On 9/8/09 9:14, Felix Meschberger wrote:

> The Felix team is pleased to announce the release of Apache Felix
> Configuration Admin Service version 1.2.4
>
> The Apache Felix Configuration Admin Service is an
>
 implementation of the

> upcoming OSGi Configuration Admin Service Specification 1.3
>
>
>
 http://felix.apache.org/site/apache-felix-configuration-admin-
 service.html

> This release is available from
> http://felix.apache.org/site/downloads.cgi and Maven:
>
>
>  org.apache.felix
>  org.apache.felix.configadmin
>  1.2.4
>
>
> Release Notes:
>
> ** Bug
>  * [FELIX-1535] - Permission is checked against the using bundle
>   instead of the access control context
>
 (call stack)

>  * [FELIX-1542] - Configuration may be supplied twice in certain
>   situations
>
> ** Improvement
>  * [FELIX-1541] - Include latest CM 1.3 (Compendium R
>
 4.2) package

>   export
>
>
> Enjoy!
>
> -The Felix team
>
>

> 
> 


Re: [VOTE] Release fileinstall 2.0.0

2009-09-08 Thread Chris Custine
+1
--
Chris Custine
FUSESource :: http://fusesource.com
My Blog :: http://blog.organicelement.com
Apache ServiceMix :: http://servicemix.apache.org
Apache Directory Server :: http://directory.apache.org


On Tue, Sep 8, 2009 at 7:14 AM, Guillaume Nodet  wrote:

> This release includes
>   * fileinstall 2.0.0
>
> Staging repository:
>   https://repository.apache.org/content/repositories/felix-staging-046/
>
> 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 46 /tmp/felix-staging
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
>
> --
> Cheers,
> Guillaume Nodet
> 
> Blog: http://gnodet.blogspot.com/
> 
> Open Source SOA
> http://fusesource.com
>


[jira] Updated: (FELIX-1571) Bundle-ClassPath without "." while using maven-bundle-plugin in a war project confuses the plugin

2009-09-08 Thread Sahoo (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sahoo updated FELIX-1571:
-

Attachment: test.zip

Simple test case.

> Bundle-ClassPath without "." while using maven-bundle-plugin in a war project 
> confuses the plugin
> -
>
> Key: FELIX-1571
> URL: https://issues.apache.org/jira/browse/FELIX-1571
> Project: Felix
>  Issue Type: Bug
>  Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-2.0.0
>Reporter: Sahoo
> Attachments: test.zip
>
>
> I am using a war type project, so the packaging is governed by
> maven-war-plugin. For the OSGi meta data in the war, I am using manifest
> goal of maven-bundle-plugin in process-classes phase. Yes, I have already
> looked at the excellent examples on this use case at [1]. However, my use
> case has one difference. I don't want "." in Bundle-ClassPath. Why? Because,
> it should never be. Files at the root level of .war file is never used
> directly by class loaders in web container; WEB-INF/classes and
> WEB-INF/lib/*.jar are used instead. As soon as I remove the "." from
> Bundle-ClassPath settings, bundle plugin is confused. I don't know why  "."
> is necessary for bundle plugin to generate meta data? My guess is without
> it, it does not find any classes in the target dir? 
> Please see the attached test case. I want to know two things:
> 1. How to configure bundle plugin to generate Bundle-ClassPath that contains 
> WEB-INF/classes and WEB-INF/lib/*.jar, but "." should not be part of the 
> classpath?
> 2. How to configure bundle plugin to generate Import-Package statements for 
> classes packaged in WEB-INF/lib/*.jar?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Created: (FELIX-1571) Bundle-ClassPath without "." while using maven-bundle-plugin in a war project confuses the plugin

2009-09-08 Thread Sahoo (JIRA)
Bundle-ClassPath without "." while using maven-bundle-plugin in a war project 
confuses the plugin
-

 Key: FELIX-1571
 URL: https://issues.apache.org/jira/browse/FELIX-1571
 Project: Felix
  Issue Type: Bug
  Components: Maven Bundle Plugin
Affects Versions: maven-bundle-plugin-2.0.0
Reporter: Sahoo


I am using a war type project, so the packaging is governed by
maven-war-plugin. For the OSGi meta data in the war, I am using manifest
goal of maven-bundle-plugin in process-classes phase. Yes, I have already
looked at the excellent examples on this use case at [1]. However, my use
case has one difference. I don't want "." in Bundle-ClassPath. Why? Because,
it should never be. Files at the root level of .war file is never used
directly by class loaders in web container; WEB-INF/classes and
WEB-INF/lib/*.jar are used instead. As soon as I remove the "." from
Bundle-ClassPath settings, bundle plugin is confused. I don't know why  "."
is necessary for bundle plugin to generate meta data? My guess is without
it, it does not find any classes in the target dir? 

Please see the attached test case. I want to know two things:
1. How to configure bundle plugin to generate Bundle-ClassPath that contains 
WEB-INF/classes and WEB-INF/lib/*.jar, but "." should not be part of the 
classpath?
2. How to configure bundle plugin to generate Import-Package statements for 
classes packaged in WEB-INF/lib/*.jar?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (FELIX-1221) Display the alias ID created by Karaf Features when showing service details

2009-09-08 Thread Tim Moloney (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752588#action_12752588
 ] 

Tim Moloney commented on FELIX-1221:


True, it only works for bundles installed via features.

I know that servicePid is generated dynamically by the framework to guarantee 
uniqueness.  However, it's pretty much useless to humans.  Can there be a 
Felix-wide standard for a human-defined service PID property that features, 
fileinstall, etc. can all use for consistency?  This property is "supposed" to 
be unique but it won't break anything if it isn't.  Good idea or bad idea?


> Display the alias ID created by Karaf Features when showing service details
> ---
>
> Key: FELIX-1221
> URL: https://issues.apache.org/jira/browse/FELIX-1221
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Tim Moloney
>Priority: Minor
> Fix For: webconsole-1.2.12
>
> Attachments: FELIX-1221-FeaturePid.patch
>
>
> Display the alias ID for services configured via Karaf Features.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (FELIX-1221) Display the alias ID created by Karaf Features when showing service details

2009-09-08 Thread Guillaume Nodet (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet resolved FELIX-1221.


   Resolution: Fixed
Fix Version/s: webconsole-1.2.12

Committing to https://svn.apache.org/repos/asf/felix/trunk ...
M   
webconsole/src/main/java/org/apache/felix/webconsole/internal/core/BundlesServlet.java
Committed r812566


> Display the alias ID created by Karaf Features when showing service details
> ---
>
> Key: FELIX-1221
> URL: https://issues.apache.org/jira/browse/FELIX-1221
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Tim Moloney
>Priority: Minor
> Fix For: webconsole-1.2.12
>
> Attachments: FELIX-1221-FeaturePid.patch
>
>
> Display the alias ID for services configured via Karaf Features.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (FELIX-1221) Display the alias ID created by Karaf Features when showing service details

2009-09-08 Thread Guillaume Nodet (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752581#action_12752581
 ] 

Guillaume Nodet commented on FELIX-1221:


Ah, now I understand, it comes from the way your ManagedServiceFactory is 
written.
I guess I'm a bit reluctant because this only works for configurations defined 
by features.  If you go through fileinstall, the key would be different.  And 
the key name is really an implementation detail, not a public interface ...

I'll apply your patch given there's no other solution.  Well the only other 
solution I can think about is to display all the properties.

> Display the alias ID created by Karaf Features when showing service details
> ---
>
> Key: FELIX-1221
> URL: https://issues.apache.org/jira/browse/FELIX-1221
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Tim Moloney
>Priority: Minor
> Attachments: FELIX-1221-FeaturePid.patch
>
>
> Display the alias ID for services configured via Karaf Features.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (FELIX-1221) Display the alias ID created by Karaf Features when showing service details

2009-09-08 Thread Tim Moloney (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tim Moloney updated FELIX-1221:
---

Attachment: (was: FELIX-1221-bundles-aliasId.patch)

> Display the alias ID created by Karaf Features when showing service details
> ---
>
> Key: FELIX-1221
> URL: https://issues.apache.org/jira/browse/FELIX-1221
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Tim Moloney
>Priority: Minor
> Attachments: FELIX-1221-FeaturePid.patch
>
>
> Display the alias ID for services configured via Karaf Features.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (FELIX-1221) Display the alias ID created by Karaf Features when showing service details

2009-09-08 Thread Tim Moloney (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tim Moloney updated FELIX-1221:
---

Attachment: FELIX-1221-FeaturePid.patch

> Display the alias ID created by Karaf Features when showing service details
> ---
>
> Key: FELIX-1221
> URL: https://issues.apache.org/jira/browse/FELIX-1221
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Tim Moloney
>Priority: Minor
> Attachments: FELIX-1221-FeaturePid.patch
>
>
> Display the alias ID for services configured via Karaf Features.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (FELIX-1221) Display the alias ID created by Karaf Features when showing service details

2009-09-08 Thread Tim Moloney (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tim Moloney updated FELIX-1221:
---

Attachment: (was: FELIX-1221-FeaturePid.patch)

> Display the alias ID created by Karaf Features when showing service details
> ---
>
> Key: FELIX-1221
> URL: https://issues.apache.org/jira/browse/FELIX-1221
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Tim Moloney
>Priority: Minor
> Attachments: FELIX-1221-FeaturePid.patch
>
>
> Display the alias ID for services configured via Karaf Features.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



Re: [VOTE] Felix framework 2.0.0 and related subprojects releases

2009-09-08 Thread Clement Escoffier

+1,

Just a strange behavior (ClassCastException) when a host publishes a  
log service to an embedded Felix. Might be a bug, but I need to  
investigate a little bit more.


Regards,

Clement


On 08.09.2009, at 08:37, Toni Menzel wrote:


+1 (not binding)

2009/9/8 Carsten Ziegeler 


+1

Carsten


--
Carsten Ziegeler
cziege...@apache.org





--
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.




[jira] Updated: (FELIX-1547) OS shell level admin commands for Karaf

2009-09-08 Thread David Bosschaert (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Bosschaert updated FELIX-1547:


Attachment: karaf-admin-8.patch

Hi Guillaume, the attached patch now has the unix script as well and I moved 
the Execute class & test to the gshell-admin module. 
Hope this works for you.

David

> OS shell level admin commands for Karaf
> ---
>
> Key: FELIX-1547
> URL: https://issues.apache.org/jira/browse/FELIX-1547
> Project: Felix
>  Issue Type: New Feature
>  Components: Karaf
>Reporter: David Bosschaert
> Fix For: karaf-1.0.0
>
> Attachments: karaf-admin-8.patch
>
>
> Karaf has admin commands to create new instances from within its shell. 
> Examples are
>   admin:create
>   admin:list
>   admin:start
> etc...
> It would be good if (some of) these commands were available from the OS-level 
> command line - outside of the Karaf container.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



Re: [ANN] Apache Felix Configuration Admin Service version 1.2.4 Released

2009-09-08 Thread Clement Escoffier


On 08.09.2009, at 16:44, Richard S. Hall wrote:


On 9/8/09 10:13, Moloney, Tim M wrote:

I'm confused about the versions of config admin service.

1.2.4 was just released but the trunk has 1.2.7-SNAPSHOT.

What happened to 1.2.5 and 1.2.6?



Maybe, I'm wrong but the tag org.apache.felix.configadmin-1.2.6 exists  
in felix releases.

So, this one is still surviving :-)

Clement





Don't ask... ;-)

-> richard



Tim Moloney The  reasonable  man adapts  himself  to
MRSLthe world; the unreasonable one persists
2015 Cattlemen Road in trying to adapt the world to himself.
Sarasota, FL  34232 Therefore  all progress  depends on  the
(941) 377-6775 x208 unreasonable man.George Bernard Shaw





-Original Message-
From: Richard S. Hall [mailto:he...@ungoverned.org]
Sent: Tuesday, September 08, 2009 09:56
To: dev@felix.apache.org
Subject: Re: [ANN] Apache Felix Configuration Admin Service
version 1.2.4 Released

I think these announcements are only really necessary on the
users list,
since we vote on it and see the vote result message here on
the dev list...

I think the release docs mention this.

->  richard

On 9/8/09 9:14, Felix Meschberger wrote:


The Felix team is pleased to announce the release of Apache Felix
Configuration Admin Service version 1.2.4

The Apache Felix Configuration Admin Service is an


implementation of the


upcoming OSGi Configuration Admin Service Specification 1.3




http://felix.apache.org/site/apache-felix-configuration-admin-
service.html


This release is available from
http://felix.apache.org/site/downloads.cgi and Maven:

   
 org.apache.felix
 org.apache.felix.configadmin
 1.2.4
   

Release Notes:

** Bug
 * [FELIX-1535] - Permission is checked against the using  
bundle

  instead of the access control context


(call stack)

 * [FELIX-1542] - Configuration may be supplied twice in  
certain

  situations

** Improvement
 * [FELIX-1541] - Include latest CM 1.3 (Compendium R


4.2) package


  export


Enjoy!

-The Felix team








[jira] Commented: (FELIX-1221) Display the alias ID created by Karaf Features when showing service details

2009-09-08 Thread Tim Moloney (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752551#action_12752551
 ] 

Tim Moloney commented on FELIX-1221:


As I mentioned before, if you follow the suggestions in the OSGi Compendium 
(section 104.4.3, "Property Propagation" section of the Configuration Admin 
Service), the ManagedServiceFactory will copy the configuration properties to 
the service properties (including the factory PID, 
"org.apache.felix.karaf.features.configKey").  Then my patch makes the bundles 
webconsole plugin display the Feature PID.  The end result is that you can map 
which service was created by which configuration in the features repository.

> Display the alias ID created by Karaf Features when showing service details
> ---
>
> Key: FELIX-1221
> URL: https://issues.apache.org/jira/browse/FELIX-1221
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Tim Moloney
>Priority: Minor
> Attachments: FELIX-1221-bundles-aliasId.patch, 
> FELIX-1221-FeaturePid.patch
>
>
> Display the alias ID for services configured via Karaf Features.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



Re: [ANN] Apache Felix Configuration Admin Service version 1.2.4 Released

2009-09-08 Thread Guillaume Nodet
Fwiw, all the odd numbers are skipped in releases to make sure that in OSGi
   1.2.7-SNAPSHOT < 1.2.8
If 1.2.7 was to be releases, the OSGi framework would choose 1.2.7.SNAPSHOT
instead of 1.2.7 if both were availables.


On Tue, Sep 8, 2009 at 16:44, Richard S. Hall  wrote:

> On 9/8/09 10:13, Moloney, Tim M wrote:
>
>> I'm confused about the versions of config admin service.
>>
>> 1.2.4 was just released but the trunk has 1.2.7-SNAPSHOT.
>>
>> What happened to 1.2.5 and 1.2.6?
>>
>>
>
> Don't ask... ;-)
>
> -> richard
>
>
>
>> Tim Moloney The  reasonable  man adapts  himself  to
>> MRSLthe world; the unreasonable one persists
>> 2015 Cattlemen Road in trying to adapt the world to himself.
>> Sarasota, FL  34232 Therefore  all progress  depends on  the
>> (941) 377-6775 x208 unreasonable man.George Bernard Shaw
>>
>>
>>
>>
>>
>>> -Original Message-
>>> From: Richard S. Hall [mailto:he...@ungoverned.org]
>>> Sent: Tuesday, September 08, 2009 09:56
>>> To: dev@felix.apache.org
>>> Subject: Re: [ANN] Apache Felix Configuration Admin Service
>>> version 1.2.4 Released
>>>
>>> I think these announcements are only really necessary on the
>>> users list,
>>> since we vote on it and see the vote result message here on
>>> the dev list...
>>>
>>> I think the release docs mention this.
>>>
>>> ->  richard
>>>
>>> On 9/8/09 9:14, Felix Meschberger wrote:
>>>
>>>
 The Felix team is pleased to announce the release of Apache Felix
 Configuration Admin Service version 1.2.4

 The Apache Felix Configuration Admin Service is an


>>> implementation of the
>>>
>>>
 upcoming OSGi Configuration Admin Service Specification 1.3




>>> http://felix.apache.org/site/apache-felix-configuration-admin-
>>> service.html
>>>
>>>
 This release is available from
 http://felix.apache.org/site/downloads.cgi and Maven:


  org.apache.felix
  org.apache.felix.configadmin
  1.2.4


 Release Notes:

 ** Bug
  * [FELIX-1535] - Permission is checked against the using bundle
   instead of the access control context


>>> (call stack)
>>>
>>>
  * [FELIX-1542] - Configuration may be supplied twice in certain
   situations

 ** Improvement
  * [FELIX-1541] - Include latest CM 1.3 (Compendium R


>>> 4.2) package
>>>
>>>
   export


 Enjoy!

 -The Felix team



>>>
>>>
>>


-- 
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Open Source SOA
http://fusesource.com


Re: [ANN] Apache Felix Configuration Admin Service version 1.2.4 Released

2009-09-08 Thread Richard S. Hall

On 9/8/09 10:13, Moloney, Tim M wrote:

I'm confused about the versions of config admin service.

1.2.4 was just released but the trunk has 1.2.7-SNAPSHOT.

What happened to 1.2.5 and 1.2.6?
   


Don't ask... ;-)

-> richard



Tim Moloney The  reasonable  man adapts  himself  to
MRSLthe world; the unreasonable one persists
2015 Cattlemen Road in trying to adapt the world to himself.
Sarasota, FL  34232 Therefore  all progress  depends on  the
(941) 377-6775 x208 unreasonable man.George Bernard Shaw



   

-Original Message-
From: Richard S. Hall [mailto:he...@ungoverned.org]
Sent: Tuesday, September 08, 2009 09:56
To: dev@felix.apache.org
Subject: Re: [ANN] Apache Felix Configuration Admin Service
version 1.2.4 Released

I think these announcements are only really necessary on the
users list,
since we vote on it and see the vote result message here on
the dev list...

I think the release docs mention this.

->  richard

On 9/8/09 9:14, Felix Meschberger wrote:
 

The Felix team is pleased to announce the release of Apache Felix
Configuration Admin Service version 1.2.4

The Apache Felix Configuration Admin Service is an
   

implementation of the
 

upcoming OSGi Configuration Admin Service Specification 1.3


   

http://felix.apache.org/site/apache-felix-configuration-admin-
service.html
 

This release is available from
http://felix.apache.org/site/downloads.cgi and Maven:


  org.apache.felix
  org.apache.felix.configadmin
  1.2.4


Release Notes:

** Bug
  * [FELIX-1535] - Permission is checked against the using bundle
   instead of the access control context
   

(call stack)
 

  * [FELIX-1542] - Configuration may be supplied twice in certain
   situations

** Improvement
  * [FELIX-1541] - Include latest CM 1.3 (Compendium R
   

4.2) package
 

   export


Enjoy!

-The Felix team

   
 


RE: [ANN] Apache Felix Configuration Admin Service version 1.2.4 Released

2009-09-08 Thread Moloney, Tim M

I'm confused about the versions of config admin service.

1.2.4 was just released but the trunk has 1.2.7-SNAPSHOT.

What happened to 1.2.5 and 1.2.6?


Tim Moloney The  reasonable  man adapts  himself  to
MRSLthe world; the unreasonable one persists
2015 Cattlemen Road in trying to adapt the world to himself.
Sarasota, FL  34232 Therefore  all progress  depends on  the
(941) 377-6775 x208 unreasonable man.George Bernard Shaw

 

> -Original Message-
> From: Richard S. Hall [mailto:he...@ungoverned.org] 
> Sent: Tuesday, September 08, 2009 09:56
> To: dev@felix.apache.org
> Subject: Re: [ANN] Apache Felix Configuration Admin Service 
> version 1.2.4 Released
> 
> I think these announcements are only really necessary on the 
> users list, 
> since we vote on it and see the vote result message here on 
> the dev list...
> 
> I think the release docs mention this.
> 
> -> richard
> 
> On 9/8/09 9:14, Felix Meschberger wrote:
> > The Felix team is pleased to announce the release of Apache Felix
> > Configuration Admin Service version 1.2.4
> >
> > The Apache Felix Configuration Admin Service is an 
> implementation of the
> > upcoming OSGi Configuration Admin Service Specification 1.3
> >
> > 
> http://felix.apache.org/site/apache-felix-configuration-admin-
> service.html
> >
> > This release is available from
> > http://felix.apache.org/site/downloads.cgi and Maven:
> >
> >
> >  org.apache.felix
> >  org.apache.felix.configadmin
> >  1.2.4
> >
> >
> > Release Notes:
> >
> > ** Bug
> >  * [FELIX-1535] - Permission is checked against the using bundle
> >   instead of the access control context 
> (call stack)
> >  * [FELIX-1542] - Configuration may be supplied twice in certain
> >   situations
> >
> > ** Improvement
> >  * [FELIX-1541] - Include latest CM 1.3 (Compendium R 
> 4.2) package
> >   export
> >
> >
> > Enjoy!
> >
> > -The Felix team
> >
> 


Re: [ANN] Apache Felix Configuration Admin Service version 1.2.4 Released

2009-09-08 Thread Felix Meschberger
Hi Richard,

Richard S. Hall schrieb:
> I think these announcements are only really necessary on the users list,
> since we vote on it and see the vote result message here on the dev list...
> 
> I think the release docs mention this.

Ehrm, you are right, of course. Sorry, will not send the announcement to
d...@felix any more.

Regards
Felix

> 
> -> richard
> 
> On 9/8/09 9:14, Felix Meschberger wrote:
>> The Felix team is pleased to announce the release of Apache Felix
>> Configuration Admin Service version 1.2.4
>>
>> The Apache Felix Configuration Admin Service is an implementation of the
>> upcoming OSGi Configuration Admin Service Specification 1.3
>>
>> http://felix.apache.org/site/apache-felix-configuration-admin-service.html
>>
>>
>> This release is available from
>> http://felix.apache.org/site/downloads.cgi and Maven:
>>
>>
>>  org.apache.felix
>>  org.apache.felix.configadmin
>>  1.2.4
>>
>>
>> Release Notes:
>>
>> ** Bug
>>  * [FELIX-1535] - Permission is checked against the using bundle
>>   instead of the access control context (call stack)
>>  * [FELIX-1542] - Configuration may be supplied twice in certain
>>   situations
>>
>> ** Improvement
>>  * [FELIX-1541] - Include latest CM 1.3 (Compendium R 4.2) package
>>   export
>>
>>
>> Enjoy!
>>
>> -The Felix team
>>
> 


[jira] Resolved: (FELIX-1013) Improve console extensibility

2009-09-08 Thread Felix Meschberger (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felix Meschberger resolved FELIX-1013.
--

   Resolution: Fixed
Fix Version/s: webconsole-1.2.12

All sub tasks have been resolved. I assume this issue can be resolved, then.

> Improve console extensibility
> -
>
> Key: FELIX-1013
> URL: https://issues.apache.org/jira/browse/FELIX-1013
> Project: Felix
>  Issue Type: Task
>  Components: Web Console
>Affects Versions: webconsole-1.2.8
>Reporter: Thomas Diesler
> Fix For: webconsole-1.2.12
>
>
> Currently, the JBossOSGi project uses the Felix Web Console for OSGi 
> framework management.
> http://www.jboss.org/community/docs/DOC-13457
> http://jbossosgi.blogspot.com/2009/03/jbossosgi-getting-started.html
> We would like to be able to extend the set of console plugins and modify the 
> generated html header/footer. 
> With webconsole-1.2.8 this cannot be done by extending the binary 
> distribution, instead we need to duplicate and modify a number of webconsole 
> source files
> For details please see the associated sub-tasks

-- 
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-1014) Hardcoded list of webconsole plugins in OSGiManager

2009-09-08 Thread Felix Meschberger (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752526#action_12752526
 ] 

Felix Meschberger edited comment on FELIX-1014 at 9/8/09 7:00 AM:
--

Added support to disable select console plugins provided by the Web Console 
bundle itself in Rev. 812513.

The ConfigurationListener now also implements the MetaTypeProvider interface to 
provide the ObjectClassDefinition for the configurtion on demand based on the 
actual list of configured plugin classes.

For this reason the SCR plugin and meta type XML file generation are not 
required any more.

By default, all plugins are enabled, of course.

Thomas, can you please confirm this suits your needs ? Thanks.

  was (Author: fmeschbe):
Added support to disable select console plugins provided by the Web Console 
bundle itself in Rev. 812513.

The ConfigurationListener now also implements the MetaTypeProvider interface to 
provide the ObjectClassDefinition for the configurtion on demand based on the 
actual list of configured plugin classes.

For this reason the SCR plugin and meta type XML file generation are not 
required any more.

By default, all plugins are enabled, of course.
  
> Hardcoded list of webconsole plugins in OSGiManager
> ---
>
> Key: FELIX-1014
> URL: https://issues.apache.org/jira/browse/FELIX-1014
> Project: Felix
>  Issue Type: Sub-task
>  Components: Web Console
>Affects Versions: webconsole-1.2.8
>Reporter: Thomas Diesler
>Assignee: Felix Meschberger
> Fix For: webconsole-1.2.12
>
>
> Instead of 
> private static final String[] PLUGIN_CLASSES =
> { 
> "org.apache.felix.webconsole.internal.compendium.ComponentConfigurationPrinter",
> 
> "org.apache.felix.webconsole.internal.compendium.ComponentsServlet",
> "org.apache.felix.webconsole.internal.compendium.ConfigManager",
> "org.apache.felix.webconsole.internal.core.BundlesServlet",
> "org.apache.felix.webconsole.internal.core.InstallAction",
> "org.apache.felix.webconsole.internal.core.SetStartLevelAction",
> "org.apache.felix.webconsole.internal.deppack.DepPackServlet",
> "org.apache.felix.webconsole.internal.misc.EventAdminServlet",
> "org.apache.felix.webconsole.internal.misc.LicenseServlet",
> "org.apache.felix.webconsole.internal.misc.ConfigurationRender",
> "org.apache.felix.webconsole.internal.misc.ShellServlet",
> "org.apache.felix.webconsole.internal.obr.BundleRepositoryRender",
> "org.apache.felix.webconsole.internal.obr.InstallFromRepoAction",
> "org.apache.felix.webconsole.internal.obr.RefreshRepoAction",
> "org.apache.felix.webconsole.internal.system.GCAction",
> "org.apache.felix.webconsole.internal.system.VMStatPlugin" };
> we propose
> protected String[] getPluginClasses() 
> {
>return new String[] { 
>
> "org.apache.felix.webconsole.internal.compendium.ComponentConfigurationPrinter",
>
> "org.apache.felix.webconsole.internal.compendium.ComponentsServlet",
>"org.apache.felix.webconsole.internal.compendium.ConfigManager",
>"org.apache.felix.webconsole.internal.core.BundlesServlet",
>"org.apache.felix.webconsole.internal.core.InstallAction",
>"org.apache.felix.webconsole.internal.core.SetStartLevelAction",
>"org.apache.felix.webconsole.internal.deppack.DepPackServlet",
>"org.apache.felix.webconsole.internal.misc.EventAdminServlet",
>"org.apache.felix.webconsole.internal.misc.LicenseServlet",
>"org.apache.felix.webconsole.internal.misc.ConfigurationRender",
>"org.apache.felix.webconsole.internal.misc.ShellServlet",
>"org.apache.felix.webconsole.internal.obr.BundleRepositoryRender",
>"org.apache.felix.webconsole.internal.obr.InstallFromRepoAction",
>"org.apache.felix.webconsole.internal.obr.RefreshRepoAction",
>"org.apache.felix.webconsole.internal.system.GCAction",
>"org.apache.felix.webconsole.internal.system.ShutdownAction",
>"org.apache.felix.webconsole.internal.system.ShutdownRender",
>"org.apache.felix.webconsole.internal.system.VMStatRender", };
> }
> 
> /**
>  * The default value for the {...@link #PROP_MANAGER_ROOT} configuration
>  * property (value is "/system/console").
>  */
> protected String getDefaultManagerRoot()
> {
>return DEFAULT_MANAGER_ROOT;
> }
> --
> 
> public void init()
> {
> // base class initialization not needed, since the GenericServlet.ini

Re: [VOTE] Release Felix iPOJO 1.4.2

2009-09-08 Thread Richard S. Hall

+1

However, I think there is an issue with the web console plugin, since it 
doesn't include any classes, so you might need to do another maintenance 
release for it.


-> richard

On 9/4/09 5:00, Clement Escoffier wrote:

Hi,

It's time to restart the iPOJO release. We recently fix 3 critical 
issues affecting iPOJO 1.4.0.

- FELIX-1411 Directory manipulation does not find components on windows
- FELIX-1497 iPOJO Web Console plugin NPE when the service reference 
list is null
- FELIX-1518 iPOJO manipulator is really slow even when annotation are 
ignored
There are still some outstanding issues but they will be solved in the 
new version (1.6.0)

Five artifacts are released:
- the manipulator
- the Ant task
- the Maven plugin
- the online-manipulator
- the web console plugin

Staging repository:
https://repository.apache.org/content/repositories/felix-staging-042/

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 042 /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 1 week.

Thanks and regards,

Clement


[jira] Resolved: (FELIX-1014) Hardcoded list of webconsole plugins in OSGiManager

2009-09-08 Thread Felix Meschberger (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felix Meschberger resolved FELIX-1014.
--

   Resolution: Fixed
Fix Version/s: webconsole-1.2.12

Added support to disable select console plugins provided by the Web Console 
bundle itself in Rev. 812513.

The ConfigurationListener now also implements the MetaTypeProvider interface to 
provide the ObjectClassDefinition for the configurtion on demand based on the 
actual list of configured plugin classes.

For this reason the SCR plugin and meta type XML file generation are not 
required any more.

By default, all plugins are enabled, of course.

> Hardcoded list of webconsole plugins in OSGiManager
> ---
>
> Key: FELIX-1014
> URL: https://issues.apache.org/jira/browse/FELIX-1014
> Project: Felix
>  Issue Type: Sub-task
>  Components: Web Console
>Affects Versions: webconsole-1.2.8
>Reporter: Thomas Diesler
>Assignee: Felix Meschberger
> Fix For: webconsole-1.2.12
>
>
> Instead of 
> private static final String[] PLUGIN_CLASSES =
> { 
> "org.apache.felix.webconsole.internal.compendium.ComponentConfigurationPrinter",
> 
> "org.apache.felix.webconsole.internal.compendium.ComponentsServlet",
> "org.apache.felix.webconsole.internal.compendium.ConfigManager",
> "org.apache.felix.webconsole.internal.core.BundlesServlet",
> "org.apache.felix.webconsole.internal.core.InstallAction",
> "org.apache.felix.webconsole.internal.core.SetStartLevelAction",
> "org.apache.felix.webconsole.internal.deppack.DepPackServlet",
> "org.apache.felix.webconsole.internal.misc.EventAdminServlet",
> "org.apache.felix.webconsole.internal.misc.LicenseServlet",
> "org.apache.felix.webconsole.internal.misc.ConfigurationRender",
> "org.apache.felix.webconsole.internal.misc.ShellServlet",
> "org.apache.felix.webconsole.internal.obr.BundleRepositoryRender",
> "org.apache.felix.webconsole.internal.obr.InstallFromRepoAction",
> "org.apache.felix.webconsole.internal.obr.RefreshRepoAction",
> "org.apache.felix.webconsole.internal.system.GCAction",
> "org.apache.felix.webconsole.internal.system.VMStatPlugin" };
> we propose
> protected String[] getPluginClasses() 
> {
>return new String[] { 
>
> "org.apache.felix.webconsole.internal.compendium.ComponentConfigurationPrinter",
>
> "org.apache.felix.webconsole.internal.compendium.ComponentsServlet",
>"org.apache.felix.webconsole.internal.compendium.ConfigManager",
>"org.apache.felix.webconsole.internal.core.BundlesServlet",
>"org.apache.felix.webconsole.internal.core.InstallAction",
>"org.apache.felix.webconsole.internal.core.SetStartLevelAction",
>"org.apache.felix.webconsole.internal.deppack.DepPackServlet",
>"org.apache.felix.webconsole.internal.misc.EventAdminServlet",
>"org.apache.felix.webconsole.internal.misc.LicenseServlet",
>"org.apache.felix.webconsole.internal.misc.ConfigurationRender",
>"org.apache.felix.webconsole.internal.misc.ShellServlet",
>"org.apache.felix.webconsole.internal.obr.BundleRepositoryRender",
>"org.apache.felix.webconsole.internal.obr.InstallFromRepoAction",
>"org.apache.felix.webconsole.internal.obr.RefreshRepoAction",
>"org.apache.felix.webconsole.internal.system.GCAction",
>"org.apache.felix.webconsole.internal.system.ShutdownAction",
>"org.apache.felix.webconsole.internal.system.ShutdownRender",
>"org.apache.felix.webconsole.internal.system.VMStatRender", };
> }
> 
> /**
>  * The default value for the {...@link #PROP_MANAGER_ROOT} configuration
>  * property (value is "/system/console").
>  */
> protected String getDefaultManagerRoot()
> {
>return DEFAULT_MANAGER_ROOT;
> }
> --
> 
> public void init()
> {
> // base class initialization not needed, since the GenericServlet.init
> // is an empty method
> // get the installed plugin classes 
> String[] pluginClasses = getPluginClasses();
>
> // setup the included plugins
> ClassLoader classLoader = getClass().getClassLoader();
> for ( int i = 0; i < pluginClasses.length; i++ )
> {
> String pluginClassName = pluginClasses[i];
> try
> {
> ---
> void updateConfiguration( Dictionary config )
> {
> // get the web manager root path
> webManagerRoot = this.getProperty( config, P

Re: Releasing Gogo ?

2009-09-08 Thread Guillaume Nodet
Would it be possible to release the plugin asap ?
I'd really like to push a gogo release this week.
Else, I can revert to version 1.4.3 of the maven bundle plugin.

On Wed, Sep 2, 2009 at 15:25, Stuart McCulloch  wrote:

> 2009/9/2 Guillaume Nodet 
>
> > The latest bnd version is now available in central:
> > http://repo1.maven.org/maven2/biz/aQute/bndlib/0.0.357/
> >
>
> excellent, thanks
>
>
> > On Wed, Sep 2, 2009 at 11:03, Stuart McCulloch 
> wrote:
> >
> > > 2009/9/2 Guillaume Nodet 
> > >
> > > > Why is there a need to wait for bnd to be in central given that the
> > > source
> > > > code is included in the bundle plugin project ?
> > > > Is that just temporary ?
> > >
> > >
> > > yes - Peter has his own Maven repo for Bnd, but unfortunately this is
> not
> > > sync'd to central
> > > (I've suggested he sets up sync'ing a number of times, but this is not
> > high
> > > on his todo list)
> > >
> > > we don't use Peter's repository in the bundleplugin pom.xml because
> it's
> > > not
> > > good practice
> > > (the additional repository would then get hit for all maven artifacts,
> > not
> > > just the bnd groupId)
> > >
> > > previously I've got Carlos to upload the artifact manually, but this
> gets
> > > very tiresome during
> > > development which is why I decided to just put a copy of the source
> there
> > > at
> > > the moment
> > >
> > > if we released the plugin with this source then you wouldn't be able to
> > > override the bnd
> > > version during the build (because there's no dependency) and it makes
> > > things
> > > messy
> > >
> > >
> > > > Also did anyone asked for the new version to be
> > > > put in central already ?
> > > >
> > >
> > > I was just about to - there's been a few regressions in the recent
> > builds,
> > > but Peter has
> > > just blessed 0.0.356 as a good build. Bear in mind that a manual upload
> > to
> > > central can
> > > take a while, depending who's available to do the upload (which is why
> > sync
> > > is better).
> > >
> > > On Wed, Sep 2, 2009 at 10:36, Stuart McCulloch 
> > wrote:
> > > >
> > > > > 2009/9/2 Guillaume Nodet 
> > > > >
> > > > > > I've tried to release gogo this morning and after fixing a few
> > > things,
> > > > > i've
> > > > > > badly hit FELIX-1262 which is actually fixed in the latest
> snapshot
> > > of
> > > > > the
> > > > > > maven bundle plugin.
> > > > > > Is this plugin in a state to be released now ?
> > > > > >
> > > > >
> > > > > no it's not in a state to be released - for one we want to move to
> > the
> > > > > latest bndlib (and first we need that available on central)
> > > > >
> > > > >
> > > > > > I can try to release it unless somebody is willing to do it.
>  What
> > > > would
> > > > > be
> > > > > > the version to use ?  2.0.1, 2.0.2 ? Not sure to have a good
> > > > > understanding
> > > > > > of the version scheme with odd/even numbers for minor releases.
> > > > > >
> > > > > > On Tue, Sep 1, 2009 at 08:25, Guillaume Nodet 
> > > > wrote:
> > > > > >
> > > > > > > I'd like to release a first version of Gogo.
> > > > > > > However, given the RFC is bound to change and that we might
> > > introduce
> > > > > > > other changes that will break the syntax, I wonder if we should
> > use
> > > a
> > > > > > > 0.2.0 version instead of 1.0.0.
> > > > > > > In addition, we will release the org.osgi.service.command
> package
> > > > > > > which is not official, so I think keeping a version < 1.0.0
> makes
> > > > > > > sense until a spec is released for that.
> > > > > > > Thoughts ?
> > > > > > >
> > > > > > > --
> > > > > > > Cheers,
> > > > > > > Guillaume Nodet
> > > > > > > 
> > > > > > > Blog: http://gnodet.blogspot.com/
> > > > > > > 
> > > > > > > Open Source SOA
> > > > > > > http://fusesource.com
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Cheers,
> > > > > > Guillaume Nodet
> > > > > > 
> > > > > > Blog: http://gnodet.blogspot.com/
> > > > > > 
> > > > > > Open Source SOA
> > > > > > http://fusesource.com
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Cheers, Stuart
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Cheers,
> > > > Guillaume Nodet
> > > > 
> > > > Blog: http://gnodet.blogspot.com/
> > > > 
> > > > Open Source SOA
> > > > http://fusesource.com
> > > >
> > >
> > >
> > >
> > > --
> > > Cheers, Stuart
> > >
> >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > 
> > Blog: http://gnodet.blogspot.com/
> > 
> > Open Source SOA
> > http://fusesource.com
> >
>
>
>
> --
> Cheers, Stuart
>



-- 
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Open Source SOA
http://fusesource.com


Re: [ANN] Apache Felix Configuration Admin Service version 1.2.4 Released

2009-09-08 Thread Richard S. Hall
I think these announcements are only really necessary on the users list, 
since we vote on it and see the vote result message here on the dev list...


I think the release docs mention this.

-> richard

On 9/8/09 9:14, Felix Meschberger wrote:

The Felix team is pleased to announce the release of Apache Felix
Configuration Admin Service version 1.2.4

The Apache Felix Configuration Admin Service is an implementation of the
upcoming OSGi Configuration Admin Service Specification 1.3

http://felix.apache.org/site/apache-felix-configuration-admin-service.html

This release is available from
http://felix.apache.org/site/downloads.cgi and Maven:

   
 org.apache.felix
 org.apache.felix.configadmin
 1.2.4
   

Release Notes:

** Bug
 * [FELIX-1535] - Permission is checked against the using bundle
  instead of the access control context (call stack)
 * [FELIX-1542] - Configuration may be supplied twice in certain
  situations

** Improvement
 * [FELIX-1541] - Include latest CM 1.3 (Compendium R 4.2) package
  export


Enjoy!

-The Felix team
   


[ANN] Apache Felix Configuration Admin Service version 1.2.4 Released

2009-09-08 Thread Felix Meschberger
The Felix team is pleased to announce the release of Apache Felix
Configuration Admin Service version 1.2.4

The Apache Felix Configuration Admin Service is an implementation of the
upcoming OSGi Configuration Admin Service Specification 1.3

http://felix.apache.org/site/apache-felix-configuration-admin-service.html

This release is available from
http://felix.apache.org/site/downloads.cgi and Maven:

  
org.apache.felix
org.apache.felix.configadmin
1.2.4
  

Release Notes:

** Bug
* [FELIX-1535] - Permission is checked against the using bundle
 instead of the access control context (call stack)
* [FELIX-1542] - Configuration may be supplied twice in certain
 situations

** Improvement
* [FELIX-1541] - Include latest CM 1.3 (Compendium R 4.2) package
 export


Enjoy!

-The Felix team


[jira] Resolved: (FELIX-1569) Remove deprecated Render interface

2009-09-08 Thread Felix Meschberger (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felix Meschberger resolved FELIX-1569.
--

Resolution: Fixed

The Render interface has completely been removed.

> Remove deprecated Render interface
> --
>
> Key: FELIX-1569
> URL: https://issues.apache.org/jira/browse/FELIX-1569
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Affects Versions: webconsole-1.2.10
>Reporter: Felix Meschberger
>Assignee: Felix Meschberger
> Fix For: webconsole-1.2.12
>
>
> The Render interface has been deprecated for quite some time now. It should 
> therefore be removed as always indictaed in the deprecation message:
>This interface will be removed when FELIX-574 will be implemented.
> A long time and a few web console releases have passed by since then, so it 
> is about time to remove this interface for the next release.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (FELIX-1253) Cursor is blocked when the correct syntax is not displaed

2009-09-08 Thread Guillaume Nodet (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet resolved FELIX-1253.


Resolution: Fixed

> Cursor is blocked when the correct syntax is not displaed
> -
>
> Key: FELIX-1253
> URL: https://issues.apache.org/jira/browse/FELIX-1253
> Project: Felix
>  Issue Type: Bug
>  Components: Karaf
> Environment: WINDOWS
>Reporter: Charles Moulliard
> Fix For: karaf-1.0.0
>
> Attachments: update_screen_karaf.GIF
>
>
> When I try to update one of the bundle on Apache Karaf Snapshot (running on a 
> windows 2000 machine) where level is beside 60, a question is displayed on 
> the screen :
> You are about to access system bundle 44.  Do you want to continue (yes/no):
> If you enter 'yes' or 'no', the cursor moves to the next line otherwise no 
> and no error is reported on the screen (see attachment). You cannot use 
> 'enter key' and the server is waiting that you enter 'yes or no' instead of y 
> or n by example

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (FELIX-1563) Felix latest bundle repository cannot be started for some reason

2009-09-08 Thread Richard S. Hall (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752520#action_12752520
 ] 

Richard S. Hall commented on FELIX-1563:


I think the imports are wrong for the repository bundle, they should be for 1.4 
or greater, since it uses Bundle.getBundleContext(), which wasn't introduced 
until 1.4.

> Felix latest bundle repository cannot be started for some reason
> 
>
> Key: FELIX-1563
> URL: https://issues.apache.org/jira/browse/FELIX-1563
> Project: Felix
>  Issue Type: Bug
>  Components: Bundle Repository (OBR)
>Affects Versions: felix-1.8.0
>Reporter: david small99
>
> I tried to use the org.apache.felix.bundlerepository-1.4.0.jar. The bundle 
> cannot be started.
> org.osgi.framework.BundleException: Exception in 
> org.apache.felix.bundlerepository.Activator.start() of bundle 
> org.apache.felix.bundlerepository.
> at 
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1010)
> at 
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:966)
> at 
> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:317)
> at 
> org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:256)
> at 
> org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._start(FrameworkCommandProvider.java:239)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:599)
> at 
> org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(FrameworkCommandInterpreter.java:145)
> at 
> org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(FrameworkConsole.java:293)
> at 
> org.eclipse.osgi.framework.internal.core.FrameworkConsole.console(FrameworkConsole.java:278)
> at 
> org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(FrameworkConsole.java:213)
> at java.lang.Thread.run(Thread.java:735)
> Caused by: java.lang.NoSuchMethodError: 
> org/osgi/framework/Bundle.getBundleContext()Lorg/osgi/framework/BundleContext;
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl$LocalResourceImpl.initialize(LocalRepositoryImpl.java:222)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl$LocalResourceImpl.(LocalRepositoryImpl.java:190)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl$LocalResourceImpl.(LocalRepositoryImpl.java:182)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl.addBundle(LocalRepositoryImpl.java:104)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl.initialize(LocalRepositoryImpl.java:169)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl.(LocalRepositoryImpl.java:56)
> at 
> org.apache.felix.bundlerepository.RepositoryAdminImpl.(RepositoryAdminImpl.java:58)
> at 
> org.apache.felix.bundlerepository.Activator.start(Activator.java:35)
> at 
> org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:991)
> at 
> java.security.AccessController.doPrivileged(AccessController.java:251)
> at 
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:985)
> ... 13 more
> Nested Exception:
> java.lang.NoSuchMethodError: 
> org/osgi/framework/Bundle.getBundleContext()Lorg/osgi/framework/BundleContext;
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl$LocalResourceImpl.initialize(LocalRepositoryImpl.java:222)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl$LocalResourceImpl.(LocalRepositoryImpl.java:190)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl$LocalResourceImpl.(LocalRepositoryImpl.java:182)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl.addBundle(LocalRepositoryImpl.java:104)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl.initialize(LocalRepositoryImpl.java:169)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl.(LocalRepositoryImpl.java:56)
> at 
> org.apache.felix.bundlerepository.RepositoryAdminImpl.(RepositoryAdminImpl.java:58)
> at 
> org.apache.felix.bundlerepository.Activator.start(Activator.java:35)
> at 
> org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:991)
> at 
> java.security.AccessController.doPrivileg

[jira] Commented: (FELIX-1569) Remove deprecated Render interface

2009-09-08 Thread Felix Meschberger (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752521#action_12752521
 ] 

Felix Meschberger commented on FELIX-1569:
--

Removed the Render interface in Rev. 812507

and adapted the OsgiManager to not use it anymore in Rev. 812509

> Remove deprecated Render interface
> --
>
> Key: FELIX-1569
> URL: https://issues.apache.org/jira/browse/FELIX-1569
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Affects Versions: webconsole-1.2.10
>Reporter: Felix Meschberger
>Assignee: Felix Meschberger
> Fix For: webconsole-1.2.12
>
>
> The Render interface has been deprecated for quite some time now. It should 
> therefore be removed as always indictaed in the deprecation message:
>This interface will be removed when FELIX-574 will be implemented.
> A long time and a few web console releases have passed by since then, so it 
> is about time to remove this interface for the next release.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Work started: (FELIX-1569) Remove deprecated Render interface

2009-09-08 Thread Felix Meschberger (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on FELIX-1569 started by Felix Meschberger.

> Remove deprecated Render interface
> --
>
> Key: FELIX-1569
> URL: https://issues.apache.org/jira/browse/FELIX-1569
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Affects Versions: webconsole-1.2.10
>Reporter: Felix Meschberger
>Assignee: Felix Meschberger
> Fix For: webconsole-1.2.12
>
>
> The Render interface has been deprecated for quite some time now. It should 
> therefore be removed as always indictaed in the deprecation message:
>This interface will be removed when FELIX-574 will be implemented.
> A long time and a few web console releases have passed by since then, so it 
> is about time to remove this interface for the next release.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Created: (FELIX-1570) Inherited methods are ignored when searching for bind/unbind methods

2009-09-08 Thread Geert Schuring (JIRA)
Inherited methods are ignored when searching for bind/unbind methods


 Key: FELIX-1570
 URL: https://issues.apache.org/jira/browse/FELIX-1570
 Project: Felix
  Issue Type: Bug
  Components: Maven SCR Plugin
Affects Versions: maven-scr-plugin-1.2.0
Reporter: Geert Schuring


I have a class that inherits 2 protected methods from its parent class and I 
want to use these methods to bind and unbind the LogService. I've set the 
following annotation:

@Reference(
name="LogService",
referenceInterface=LogService.class,
cardinality=ReferenceCardinality.MANDATORY_UNARY,
policy=ReferencePolicy.DYNAMIC,
bind="setLogService",
unbind="unsetLogService")

The maven src plugin comes with the following messages:

[INFO] [scr:scr {execution: generate-scr-scrdescriptor}]
[WARNING] @scr.reference: Method setLogService should be declared protected 
(Java annotations in nl.interact911.ipds.connector.xmpp.XMPPConnector)
[ERROR] @scr.reference: Missing method unsetLogService for reference LogService 
(Java annotations in nl.interact911.ipds.connector.xmpp.XMPPConnector)

The SCR plugin apparently ignores inherited methods, because i have no problem 
calling the mentioned methods from within the annotated class.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Created: (FELIX-1569) Remove deprecated Render interface

2009-09-08 Thread Felix Meschberger (JIRA)
Remove deprecated Render interface
--

 Key: FELIX-1569
 URL: https://issues.apache.org/jira/browse/FELIX-1569
 Project: Felix
  Issue Type: Improvement
  Components: Web Console
Affects Versions: webconsole-1.2.10
Reporter: Felix Meschberger
Assignee: Felix Meschberger
 Fix For: webconsole-1.2.12


The Render interface has been deprecated for quite some time now. It should 
therefore be removed as always indictaed in the deprecation message:

   This interface will be removed when FELIX-574 will be implemented.

A long time and a few web console releases have passed by since then, so it is 
about time to remove this interface for the next release.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (FELIX-1555) The osgi:list command should print spring-dm bundle state if spring-dm has been deployed

2009-09-08 Thread Guillaume Nodet (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet resolved FELIX-1555.


Resolution: Fixed
  Assignee: Guillaume Nodet

Committing to https://svn.apache.org/repos/asf/felix/trunk ...
M   karaf/gshell/gshell-osgi/pom.xml
M   
karaf/gshell/gshell-osgi/src/main/java/org/apache/felix/karaf/gshell/osgi/BlueprintListener.java
A   
karaf/gshell/gshell-osgi/src/main/java/org/apache/felix/karaf/gshell/osgi/BundleStateListener.java
M   
karaf/gshell/gshell-osgi/src/main/java/org/apache/felix/karaf/gshell/osgi/ListBundles.java
A   
karaf/gshell/gshell-osgi/src/main/java/org/apache/felix/karaf/gshell/osgi/SpringStateListenerFactory.java
M   
karaf/gshell/gshell-osgi/src/main/resources/OSGI-INF/blueprint/gshell-osgi.xml
Committed r812501


> The osgi:list command should print spring-dm bundle state if spring-dm has 
> been deployed
> 
>
> Key: FELIX-1555
> URL: https://issues.apache.org/jira/browse/FELIX-1555
> Project: Felix
>  Issue Type: Improvement
>  Components: Karaf
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: karaf-1.0.0
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (FELIX-1481) When performing variable substitution, fileinstall throws an exception if there is a start or stop delimiter without the other one

2009-09-08 Thread Guillaume Nodet (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet closed FELIX-1481.
--


> When performing variable substitution, fileinstall throws an exception if 
> there is a start or stop delimiter without the other one
> --
>
> Key: FELIX-1481
> URL: https://issues.apache.org/jira/browse/FELIX-1481
> Project: Felix
>  Issue Type: Bug
>  Components: File Install
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: fileinstall-2.0.0
>
> Attachments: FELIX-1481.patch
>
>
> This is a real problem as there is no way to escape the delimiters currently.
> I think silently discard any malformed substitution would be much better, 
> else any value containing a '}' will cause the config to not be loaded at all.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (FELIX-1483) Fileinstall should support exploded artifacts

2009-09-08 Thread Guillaume Nodet (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet closed FELIX-1483.
--


> Fileinstall should support exploded artifacts
> -
>
> Key: FELIX-1483
> URL: https://issues.apache.org/jira/browse/FELIX-1483
> Project: Felix
>  Issue Type: New Feature
>  Components: File Install
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: fileinstall-2.0.0
>
>
> At development time, one would create a folder inside the watched directory 
> with the content of the jar inside.
> Any changes to one file would make fileinstall to recreate the bundle and 
> update it.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (FELIX-1554) fileinstall should not export org.apache.felix.fileinstall and org.apache.felix.fileinstall.utils packages

2009-09-08 Thread Guillaume Nodet (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet closed FELIX-1554.
--


> fileinstall should not export org.apache.felix.fileinstall and 
> org.apache.felix.fileinstall.utils packages
> --
>
> Key: FELIX-1554
> URL: https://issues.apache.org/jira/browse/FELIX-1554
> Project: Felix
>  Issue Type: Improvement
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: fileinstall-2.0.0
>
>
> Those packages only contain implementation classes and should not exported

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (FELIX-1475) Add a file filter for a given watched directory

2009-09-08 Thread Guillaume Nodet (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet closed FELIX-1475.
--


> Add a file filter for a given watched directory
> ---
>
> Key: FELIX-1475
> URL: https://issues.apache.org/jira/browse/FELIX-1475
> Project: Felix
>  Issue Type: Improvement
>  Components: File Install
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: fileinstall-2.0.0
>
> Attachments: FELIX-1475.patch, FELIX-1475.patch
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (FELIX-1553) fileinstall bundle should have an optional import on org.osgi.service.log instead of exporting it

2009-09-08 Thread Guillaume Nodet (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet closed FELIX-1553.
--


> fileinstall bundle should have an optional import on org.osgi.service.log 
> instead of exporting it
> -
>
> Key: FELIX-1553
> URL: https://issues.apache.org/jira/browse/FELIX-1553
> Project: Felix
>  Issue Type: Improvement
>  Components: File Install
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: fileinstall-2.0.0
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (FELIX-1476) Allow system property substitution while loading configurations from files

2009-09-08 Thread Guillaume Nodet (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet closed FELIX-1476.
--


> Allow system property substitution while loading configurations from files
> --
>
> Key: FELIX-1476
> URL: https://issues.apache.org/jira/browse/FELIX-1476
> Project: Felix
>  Issue Type: Improvement
>  Components: File Install
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: fileinstall-2.0.0
>
> Attachments: FELIX-1476.patch, FELIX-1476.patch
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (FELIX-1377) fileinstall tries to process files which are not fully copied yet

2009-09-08 Thread Guillaume Nodet (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet closed FELIX-1377.
--


> fileinstall tries to process files which are not fully copied yet 
> --
>
> Key: FELIX-1377
> URL: https://issues.apache.org/jira/browse/FELIX-1377
> Project: Felix
>  Issue Type: Bug
>  Components: File Install, Karaf
>Affects Versions: karaf-1.0.0
>Reporter: Lars Heinemann
>Assignee: Guillaume Nodet
> Fix For: fileinstall-2.0.0
>
> Attachments: Karaf.FileMonitor.java.patch
>
>
> The file monitor tries to deploy files which are not fully copied yet and 
> throw an IOException trying this. Afterwards this file is not processed again 
> until it somehow changes or is copied again.
> This issue is related to:
> https://issues.apache.org/activemq/browse/SMX4-322

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (FELIX-1269) MalformedURLException for bundle locations installed by FileInstall

2009-09-08 Thread Guillaume Nodet (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet closed FELIX-1269.
--


> MalformedURLException for bundle locations installed by FileInstall
> ---
>
> Key: FELIX-1269
> URL: https://issues.apache.org/jira/browse/FELIX-1269
> Project: Felix
>  Issue Type: Bug
>  Components: File Install
>Affects Versions:  fileinstall-1.0.0
> Environment: FileInstall 1.1.0 
> Felix 1.8.0 
> Windows XP
>Reporter: Thilo Planz
>Assignee: Filippo Diotalevi
>Priority: Minor
> Fix For: fileinstall-2.0.0
>
> Attachments: Felix-1269.patch
>
>
> Bundles installed by FileInstall have a bundle location that does not include 
> a protocol:
> -> ps -l
> START LEVEL 1
>ID   State Level  Location
> [   0] [Active ] [0] System Bundle
> [   1] [Active ] [1] 
> file:/e:/osgi/org.apache.felix.fileinstall-1.0.0.jar   <= "normal"
> [   2] [Active ] [1] /C:/bundles/org.osgi.compendium-1.2.0.jar   <=  
> file-installed
> As a result such a bundle cannot be updated using the shell command:
> -> update 2
> ERROR: Unable to update the bundle. (java.net.MalformedURLException: no 
> protocol: /C:/bundles/org.osgi.compendium-1.2.0.jar)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (FELIX-1301) Limit FileInstall configuration information to one line in the output

2009-09-08 Thread Guillaume Nodet (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet closed FELIX-1301.
--


> Limit FileInstall configuration information to one line in the output
> -
>
> Key: FELIX-1301
> URL: https://issues.apache.org/jira/browse/FELIX-1301
> Project: Felix
>  Issue Type: Improvement
>  Components: File Install
>Affects Versions: fileinstall-1.2.0
> Environment: generic
>Reporter: Sahoo
>Assignee: Filippo Diotalevi
> Fix For: fileinstall-2.0.0
>
> Attachments: Felix-1301.patch
>
>
> Currently fileinstall prints the configuration information as four (4) 
> separate log messages as shown below:
> Jul 5, 2009 5:49:40 PM  
> INFO: felix.fileinstall.poll  (ms)   5000
> Jul 5, 2009 5:49:40 PM  
> INFO: felix.fileinstall.dir
> /space/ss141213/WS/gf/v3.trunk.new/publish/glassfishv3/glassfish/domains/domain1/autodeploy-bundles
> Jul 5, 2009 5:49:40 PM  
> INFO: felix.fileinstall.debug  1
> Jul 5, 2009 5:49:40 PM  
> INFO: felix.fileinstall.bundles.new.start  true
> It works fine most of the time, but in a multithreaded environment, sometimes 
> these four log messages get interspersed with other log messages and that 
> affects readability. So, we should concatenate the messages into one message 
> with proper formatting.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (FELIX-922) File Install bundle should be extensible to support new artifact type

2009-09-08 Thread Guillaume Nodet (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet closed FELIX-922.
-


> File Install bundle should be extensible to support new artifact type
> -
>
> Key: FELIX-922
> URL: https://issues.apache.org/jira/browse/FELIX-922
> Project: Felix
>  Issue Type: New Feature
>  Components: File Install
> Environment: generic
>Reporter: Sahoo
>Assignee: Guillaume Nodet
> Fix For: fileinstall-2.0.0
>
> Attachments: FELIX-922.patch, FELIX-922.patch, FELIX-922.patch, 
> FELIX-922.patch
>
>
> Currently File Install recognizes only jar files and cfg files. It tries to 
> install jar files as OSGi bundles and cfg files as configuration entries. It 
> should be possible to extend it to add support for new artifact types, e.g., 
> deployment packages.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (FELIX-938) FileInstall starts a stopped bundles even if it is stopped transiently by user

2009-09-08 Thread Guillaume Nodet (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet closed FELIX-938.
-


> FileInstall starts a stopped bundles even if it is stopped transiently by user
> --
>
> Key: FELIX-938
> URL: https://issues.apache.org/jira/browse/FELIX-938
> Project: Felix
>  Issue Type: Bug
>  Components: File Install
> Environment: generic
>Reporter: Sahoo
>Assignee: Guillaume Nodet
> Fix For: fileinstall-0.9.2, fileinstall-2.0.0
>
>
> Configure File Install to watch a directory. Add some bundles there. File 
> Install will install and start them. Now, using Felix shell or some other 
> utility, stop one of these bundles, wait for File Install to loop again. You 
> shall notice that File Install will start the bundle again. I think this 
> behavior is not desirable. if user has explicitly stopped a bundle, why 
> should File Install start it immediately? In act, there is no way to stop a 
> bundle other than removing it from watched directory. Removing a bundle from 
> watched dir may not always be practical because of file system permission 
> issues. So, I think File Install should not automatically restart a stopped 
> bundle, at least not in the same framework instance.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (FELIX-1386) Updating fileinstall bundle in watched directory causes IllegalsStateException

2009-09-08 Thread Guillaume Nodet (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet updated FELIX-1386:
---

Fix Version/s: (was: fileinstall-2.0.0)
   fileinstall-2.0.1

> Updating fileinstall bundle in watched directory causes IllegalsStateException
> --
>
> Key: FELIX-1386
> URL: https://issues.apache.org/jira/browse/FELIX-1386
> Project: Felix
>  Issue Type: Bug
>  Components: File Install
>Affects Versions: fileinstall-1.2.0
> Environment: generic
>Reporter: Sahoo
>Assignee: Filippo Diotalevi
> Fix For: fileinstall-2.0.1
>
> Attachments: FELIX-1386.txt
>
>
> In my environment, fileinstall is installed via autostart properties, but it 
> is located in a directory watched by fileinstall. When I updated fileinstall 
> bundle, I get the following exception:
> Jul 20, 2009 11:52:04 AM  
> SEVERE: Exception in thread "{felix.fileinstall.poll=5000, 
> felix.fileinstall.bundles.new.start=false, 
> felix.fileinstall.dir=/space/ss141213/WS/gf/v3.trunk.new/publish/glassfishv3/glassfish/modules/,
>  felix.fileinstall.debug=1}" 
> Jul 20, 2009 11:52:20 AM  
> SEVERE: java.lang.IllegalStateException: Invalid BundleContext.
> Jul 20, 2009 11:52:20 AM  
> SEVERE: at 
> org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:393)
> Jul 20, 2009 11:52:20 AM  
> SEVERE: at 
> org.apache.felix.framework.BundleContextImpl.getServiceReference(BundleContextImpl.java:257)
> Jul 20, 2009 11:52:20 AM  
> SEVERE: at 
> org.apache.felix.fileinstall.DirectoryWatcher.getLogService(DirectoryWatcher.java:449)
> Jul 20, 2009 11:52:20 AM  
> SEVERE: at 
> org.apache.felix.fileinstall.DirectoryWatcher.log(DirectoryWatcher.java:416)
> Jul 20, 2009 11:52:20 AM  
> SEVERE: at 
> org.apache.felix.fileinstall.DirectoryWatcher.run(DirectoryWatcher.java:133)
> Jul 20, 2009 11:52:04 AM  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (FELIX-1450) Karaf branding and plugins for Felix webconsole

2009-09-08 Thread Marcin Wilkos (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcin Wilkos closed FELIX-1450.



It's ok for me, closing...

> Karaf branding and plugins for Felix webconsole
> ---
>
> Key: FELIX-1450
> URL: https://issues.apache.org/jira/browse/FELIX-1450
> Project: Felix
>  Issue Type: Improvement
>  Components: Karaf
>Reporter: Marcin Wilkos
>Assignee: Gert Vanthienen
>Priority: Minor
> Fix For: karaf-1.0.0
>
> Attachments: webconsole.patch
>
>
> Karaf/webconsole contains one webconsole plugin for Karaf Features. We need 
> place for branding bundle and other plugins, so let's change dir structure to:
>  - Karaf/webconsole/plugins/features
>  - Karaf/webconsole/branding

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (FELIX-1196) Felix Web Console can't list Karaf features

2009-09-08 Thread Marcin Wilkos (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcin Wilkos closed FELIX-1196.



It's ok for me, closing...

> Felix Web Console can't list Karaf features
> ---
>
> Key: FELIX-1196
> URL: https://issues.apache.org/jira/browse/FELIX-1196
> Project: Felix
>  Issue Type: Improvement
>  Components: Karaf
>Reporter: Marcin Wilkos
>Assignee: Gert Vanthienen
> Fix For: karaf-1.0.0
>
> Attachments: webconsole.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> Web console should be extended by plugin, which will make possible listing 
> Karaf features. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (FELIX-1535) Permission is checked against the using bundle instead of the access control context (call stack)

2009-09-08 Thread Felix Meschberger (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felix Meschberger closed FELIX-1535.



Released with configadmin 1.2.4

> Permission is checked against the using bundle instead of the access control 
> context (call stack)
> -
>
> Key: FELIX-1535
> URL: https://issues.apache.org/jira/browse/FELIX-1535
> Project: Felix
>  Issue Type: Bug
>  Components: Configuration Admin, Specification compliance
>Affects Versions: configadmin-1.2.0
>Reporter: Felix Meschberger
>Assignee: Felix Meschberger
> Fix For:  configadmin-1.2.4
>
>
> A bug in the ConfigAdmin permission checks been discovered in the final 
> tests: Instead of checking the permission of the current access control 
> context (call stack) the permissions are checked against the bundle using the 
> ConfigurationAdmin service.
> According to the JavaDoc the permissions must be checked against the caller.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (FELIX-1541) Include latest CM 1.3 (Compendium R 4.2) package export

2009-09-08 Thread Felix Meschberger (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felix Meschberger closed FELIX-1541.



Released with configadmin 1.2.4

> Include latest CM 1.3 (Compendium R 4.2) package export
> ---
>
> Key: FELIX-1541
> URL: https://issues.apache.org/jira/browse/FELIX-1541
> Project: Felix
>  Issue Type: Improvement
>  Components: Configuration Admin, Specification compliance
>Affects Versions: configadmin-1.2.0
>Reporter: Felix Meschberger
>Assignee: Felix Meschberger
> Fix For:  configadmin-1.2.4
>
>
> The currently exported org.osgi.service.cm is relatively old and should be 
> replaced with the offical packages from the R 4.2 release
> JAR file.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (FELIX-1485) Admin commands support in Karaf webconsole

2009-09-08 Thread Marcin Wilkos (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcin Wilkos closed FELIX-1485.



It's ok for me, closing...

> Admin commands support in Karaf webconsole
> --
>
> Key: FELIX-1485
> URL: https://issues.apache.org/jira/browse/FELIX-1485
> Project: Felix
>  Issue Type: New Feature
>  Components: Karaf
>Reporter: Marcin Wilkos
>Assignee: Gert Vanthienen
> Fix For: karaf-1.0.0
>
> Attachments: FELIX-1485.patch
>
>
> We need a new tab in the console for the admin commands 
> (create/destroy/start/stop).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (FELIX-1261) Install/Uninstall Karaf Features from Felix WebConsole

2009-09-08 Thread Marcin Wilkos (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcin Wilkos closed FELIX-1261.



It's ok for me, closing...

> Install/Uninstall Karaf Features from Felix WebConsole
> --
>
> Key: FELIX-1261
> URL: https://issues.apache.org/jira/browse/FELIX-1261
> Project: Felix
>  Issue Type: New Feature
>  Components: Karaf
>Reporter: Marcin Wilkos
>Assignee: Gert Vanthienen
> Fix For: karaf-1.0.0
>
> Attachments: FELIX-1261-ExtendedFeaturesPlugin.patch, 
> FELIX-1261-mwilkos.patch, webconsole.patch
>
>
> Currently we can't Install/Uninstall Karaf Features from Felix WebConsole. In 
> my Google Summer of Code project I created an Extension Plugin for web 
> console, which lists Karaf Features and gives admin ability to manage them.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (FELIX-1542) Configuration may be supplied twice in certain situations

2009-09-08 Thread Felix Meschberger (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felix Meschberger closed FELIX-1542.



Released with configadmin 1.2.4

> Configuration may be supplied twice in certain situations
> -
>
> Key: FELIX-1542
> URL: https://issues.apache.org/jira/browse/FELIX-1542
> Project: Felix
>  Issue Type: Bug
>  Components: Configuration Admin
>Affects Versions: configadmin-1.2.0
>Reporter: Felix Meschberger
>Assignee: Felix Meschberger
> Fix For:  configadmin-1.2.4
>
>
> An issue reported in FELIX-1146 and presumably fixed in configadmin 1.2.0 is 
> not really fixed: With the fix for 1.2.0 in Rev. 805668 the window for the 
> race condition is much smaller than before, but it still exists:
> Consider this:
>T1. create and update configuration
> ConfigurationImpl.update persists configuration and sets field
> Thread preempted
>T2. ManagedServiceUpdate constructor reads configuration
> Uses configuration already persisted by T1 for update
> Schedules task to update service with the configuration
>T1. Runs again creating the UpdateConfiguration task with the
>  configuration persisted earlier
>  Schedules task to update service
>UpdateTask:
>  updates ManagedService with configuration prepared by T2
>  updates ManagedService with configuration prepared by T1
> In this small window a race condition occurred, which caused the 
> ManagedService to be supplied with the same configuration twice. It would 
> have been ok for the ManagedService to first get null (for the service 
> registration and configuration not available yet) and in a second call to get 
> the configuration. But it is not ok to get the same configuration twice.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (FELIX-1541) Include latest CM 1.3 (Compendium R 4.2) package export

2009-09-08 Thread Felix Meschberger (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felix Meschberger updated FELIX-1541:
-

Summary: Include latest CM 1.3 (Compendium R 4.2) package export  (was: 
Include official CM 1.3 (Compendium R 4.2) package export)

> Include latest CM 1.3 (Compendium R 4.2) package export
> ---
>
> Key: FELIX-1541
> URL: https://issues.apache.org/jira/browse/FELIX-1541
> Project: Felix
>  Issue Type: Improvement
>  Components: Configuration Admin, Specification compliance
>Affects Versions: configadmin-1.2.0
>Reporter: Felix Meschberger
>Assignee: Felix Meschberger
> Fix For:  configadmin-1.2.4
>
>
> The currently exported org.osgi.service.cm is relatively old and should be 
> replaced with the offical packages from the R 4.2 release
> JAR file.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[VOTE] Release fileinstall 2.0.0

2009-09-08 Thread Guillaume Nodet
This release includes
   * fileinstall 2.0.0

Staging repository:
   https://repository.apache.org/content/repositories/felix-staging-046/

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 46 /tmp/felix-staging

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

-- 
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Open Source SOA
http://fusesource.com


[jira] Work started: (FELIX-1014) Hardcoded list of webconsole plugins in OSGiManager

2009-09-08 Thread Felix Meschberger (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on FELIX-1014 started by Felix Meschberger.

> Hardcoded list of webconsole plugins in OSGiManager
> ---
>
> Key: FELIX-1014
> URL: https://issues.apache.org/jira/browse/FELIX-1014
> Project: Felix
>  Issue Type: Sub-task
>  Components: Web Console
>Affects Versions: webconsole-1.2.8
>Reporter: Thomas Diesler
>Assignee: Felix Meschberger
>
> Instead of 
> private static final String[] PLUGIN_CLASSES =
> { 
> "org.apache.felix.webconsole.internal.compendium.ComponentConfigurationPrinter",
> 
> "org.apache.felix.webconsole.internal.compendium.ComponentsServlet",
> "org.apache.felix.webconsole.internal.compendium.ConfigManager",
> "org.apache.felix.webconsole.internal.core.BundlesServlet",
> "org.apache.felix.webconsole.internal.core.InstallAction",
> "org.apache.felix.webconsole.internal.core.SetStartLevelAction",
> "org.apache.felix.webconsole.internal.deppack.DepPackServlet",
> "org.apache.felix.webconsole.internal.misc.EventAdminServlet",
> "org.apache.felix.webconsole.internal.misc.LicenseServlet",
> "org.apache.felix.webconsole.internal.misc.ConfigurationRender",
> "org.apache.felix.webconsole.internal.misc.ShellServlet",
> "org.apache.felix.webconsole.internal.obr.BundleRepositoryRender",
> "org.apache.felix.webconsole.internal.obr.InstallFromRepoAction",
> "org.apache.felix.webconsole.internal.obr.RefreshRepoAction",
> "org.apache.felix.webconsole.internal.system.GCAction",
> "org.apache.felix.webconsole.internal.system.VMStatPlugin" };
> we propose
> protected String[] getPluginClasses() 
> {
>return new String[] { 
>
> "org.apache.felix.webconsole.internal.compendium.ComponentConfigurationPrinter",
>
> "org.apache.felix.webconsole.internal.compendium.ComponentsServlet",
>"org.apache.felix.webconsole.internal.compendium.ConfigManager",
>"org.apache.felix.webconsole.internal.core.BundlesServlet",
>"org.apache.felix.webconsole.internal.core.InstallAction",
>"org.apache.felix.webconsole.internal.core.SetStartLevelAction",
>"org.apache.felix.webconsole.internal.deppack.DepPackServlet",
>"org.apache.felix.webconsole.internal.misc.EventAdminServlet",
>"org.apache.felix.webconsole.internal.misc.LicenseServlet",
>"org.apache.felix.webconsole.internal.misc.ConfigurationRender",
>"org.apache.felix.webconsole.internal.misc.ShellServlet",
>"org.apache.felix.webconsole.internal.obr.BundleRepositoryRender",
>"org.apache.felix.webconsole.internal.obr.InstallFromRepoAction",
>"org.apache.felix.webconsole.internal.obr.RefreshRepoAction",
>"org.apache.felix.webconsole.internal.system.GCAction",
>"org.apache.felix.webconsole.internal.system.ShutdownAction",
>"org.apache.felix.webconsole.internal.system.ShutdownRender",
>"org.apache.felix.webconsole.internal.system.VMStatRender", };
> }
> 
> /**
>  * The default value for the {...@link #PROP_MANAGER_ROOT} configuration
>  * property (value is "/system/console").
>  */
> protected String getDefaultManagerRoot()
> {
>return DEFAULT_MANAGER_ROOT;
> }
> --
> 
> public void init()
> {
> // base class initialization not needed, since the GenericServlet.init
> // is an empty method
> // get the installed plugin classes 
> String[] pluginClasses = getPluginClasses();
>
> // setup the included plugins
> ClassLoader classLoader = getClass().getClassLoader();
> for ( int i = 0; i < pluginClasses.length; i++ )
> {
> String pluginClassName = pluginClasses[i];
> try
> {
> ---
> void updateConfiguration( Dictionary config )
> {
> // get the web manager root path
> webManagerRoot = this.getProperty( config, PROP_MANAGER_ROOT, 
> getDefaultManagerRoot() );

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (FELIX-1014) Hardcoded list of webconsole plugins in OSGiManager

2009-09-08 Thread Felix Meschberger (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felix Meschberger reassigned FELIX-1014:


Assignee: Felix Meschberger

> Hardcoded list of webconsole plugins in OSGiManager
> ---
>
> Key: FELIX-1014
> URL: https://issues.apache.org/jira/browse/FELIX-1014
> Project: Felix
>  Issue Type: Sub-task
>  Components: Web Console
>Affects Versions: webconsole-1.2.8
>Reporter: Thomas Diesler
>Assignee: Felix Meschberger
>
> Instead of 
> private static final String[] PLUGIN_CLASSES =
> { 
> "org.apache.felix.webconsole.internal.compendium.ComponentConfigurationPrinter",
> 
> "org.apache.felix.webconsole.internal.compendium.ComponentsServlet",
> "org.apache.felix.webconsole.internal.compendium.ConfigManager",
> "org.apache.felix.webconsole.internal.core.BundlesServlet",
> "org.apache.felix.webconsole.internal.core.InstallAction",
> "org.apache.felix.webconsole.internal.core.SetStartLevelAction",
> "org.apache.felix.webconsole.internal.deppack.DepPackServlet",
> "org.apache.felix.webconsole.internal.misc.EventAdminServlet",
> "org.apache.felix.webconsole.internal.misc.LicenseServlet",
> "org.apache.felix.webconsole.internal.misc.ConfigurationRender",
> "org.apache.felix.webconsole.internal.misc.ShellServlet",
> "org.apache.felix.webconsole.internal.obr.BundleRepositoryRender",
> "org.apache.felix.webconsole.internal.obr.InstallFromRepoAction",
> "org.apache.felix.webconsole.internal.obr.RefreshRepoAction",
> "org.apache.felix.webconsole.internal.system.GCAction",
> "org.apache.felix.webconsole.internal.system.VMStatPlugin" };
> we propose
> protected String[] getPluginClasses() 
> {
>return new String[] { 
>
> "org.apache.felix.webconsole.internal.compendium.ComponentConfigurationPrinter",
>
> "org.apache.felix.webconsole.internal.compendium.ComponentsServlet",
>"org.apache.felix.webconsole.internal.compendium.ConfigManager",
>"org.apache.felix.webconsole.internal.core.BundlesServlet",
>"org.apache.felix.webconsole.internal.core.InstallAction",
>"org.apache.felix.webconsole.internal.core.SetStartLevelAction",
>"org.apache.felix.webconsole.internal.deppack.DepPackServlet",
>"org.apache.felix.webconsole.internal.misc.EventAdminServlet",
>"org.apache.felix.webconsole.internal.misc.LicenseServlet",
>"org.apache.felix.webconsole.internal.misc.ConfigurationRender",
>"org.apache.felix.webconsole.internal.misc.ShellServlet",
>"org.apache.felix.webconsole.internal.obr.BundleRepositoryRender",
>"org.apache.felix.webconsole.internal.obr.InstallFromRepoAction",
>"org.apache.felix.webconsole.internal.obr.RefreshRepoAction",
>"org.apache.felix.webconsole.internal.system.GCAction",
>"org.apache.felix.webconsole.internal.system.ShutdownAction",
>"org.apache.felix.webconsole.internal.system.ShutdownRender",
>"org.apache.felix.webconsole.internal.system.VMStatRender", };
> }
> 
> /**
>  * The default value for the {...@link #PROP_MANAGER_ROOT} configuration
>  * property (value is "/system/console").
>  */
> protected String getDefaultManagerRoot()
> {
>return DEFAULT_MANAGER_ROOT;
> }
> --
> 
> public void init()
> {
> // base class initialization not needed, since the GenericServlet.init
> // is an empty method
> // get the installed plugin classes 
> String[] pluginClasses = getPluginClasses();
>
> // setup the included plugins
> ClassLoader classLoader = getClass().getClassLoader();
> for ( int i = 0; i < pluginClasses.length; i++ )
> {
> String pluginClassName = pluginClasses[i];
> try
> {
> ---
> void updateConfiguration( Dictionary config )
> {
> // get the web manager root path
> webManagerRoot = this.getProperty( config, PROP_MANAGER_ROOT, 
> getDefaultManagerRoot() );

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (FELIX-1547) OS shell level admin commands for Karaf

2009-09-08 Thread David Bosschaert (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Bosschaert updated FELIX-1547:


Attachment: (was: karaf-admin-3.patch)

> OS shell level admin commands for Karaf
> ---
>
> Key: FELIX-1547
> URL: https://issues.apache.org/jira/browse/FELIX-1547
> Project: Felix
>  Issue Type: New Feature
>  Components: Karaf
>Reporter: David Bosschaert
> Fix For: karaf-1.0.0
>
>
> Karaf has admin commands to create new instances from within its shell. 
> Examples are
>   admin:create
>   admin:list
>   admin:start
> etc...
> It would be good if (some of) these commands were available from the OS-level 
> command line - outside of the Karaf container.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (FELIX-1547) OS shell level admin commands for Karaf

2009-09-08 Thread David Bosschaert (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752425#action_12752425
 ] 

David Bosschaert commented on FELIX-1547:
-

That might make sense. When I started this work off I was thinking that it 
would be more, but since so much could be reused it turned out to be quite 
small.

I will remove the attached patch for the moment and provide an updated one 
where the Execute class is part of the gshell-admin module.

> OS shell level admin commands for Karaf
> ---
>
> Key: FELIX-1547
> URL: https://issues.apache.org/jira/browse/FELIX-1547
> Project: Felix
>  Issue Type: New Feature
>  Components: Karaf
>Reporter: David Bosschaert
> Fix For: karaf-1.0.0
>
> Attachments: karaf-admin-3.patch
>
>
> Karaf has admin commands to create new instances from within its shell. 
> Examples are
>   admin:create
>   admin:list
>   admin:start
> etc...
> It would be good if (some of) these commands were available from the OS-level 
> command line - outside of the Karaf container.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (FELIX-1555) The osgi:list command should print spring-dm bundle state if spring-dm has been deployed

2009-09-08 Thread Guillaume Nodet (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet updated FELIX-1555:
---

Component/s: Karaf

> The osgi:list command should print spring-dm bundle state if spring-dm has 
> been deployed
> 
>
> Key: FELIX-1555
> URL: https://issues.apache.org/jira/browse/FELIX-1555
> Project: Felix
>  Issue Type: Improvement
>  Components: Karaf
>Reporter: Guillaume Nodet
> Fix For: karaf-1.0.0
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (FELIX-1547) OS shell level admin commands for Karaf

2009-09-08 Thread Guillaume Nodet (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752416#action_12752416
 ] 

Guillaume Nodet commented on FELIX-1547:


I wonder if creating a new module for just the Execute class is really 
necessary.
What would you think of moving this class inside the existing gshell-admin 
bundle ?

> OS shell level admin commands for Karaf
> ---
>
> Key: FELIX-1547
> URL: https://issues.apache.org/jira/browse/FELIX-1547
> Project: Felix
>  Issue Type: New Feature
>  Components: Karaf
>Reporter: David Bosschaert
> Fix For: karaf-1.0.0
>
> Attachments: karaf-admin-3.patch
>
>
> Karaf has admin commands to create new instances from within its shell. 
> Examples are
>   admin:create
>   admin:list
>   admin:start
> etc...
> It would be good if (some of) these commands were available from the OS-level 
> command line - outside of the Karaf container.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (FELIX-1564) Authentication failed when using admin:connect to connect to a newly created instance

2009-09-08 Thread Guillaume Nodet (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet resolved FELIX-1564.


Resolution: Fixed
  Assignee: Guillaume Nodet

Committing to https://svn.apache.org/repos/asf/felix/trunk ...
M   karaf/gshell/gshell-admin/pom.xml
Committed r812412


> Authentication failed when using admin:connect to connect to a newly created 
> instance
> -
>
> Key: FELIX-1564
> URL: https://issues.apache.org/jira/browse/FELIX-1564
> Project: Felix
>  Issue Type: Bug
>  Components: Karaf
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: karaf-1.0.0
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Created: (FELIX-1568) Goal to transform a maven version into an OSGi version

2009-09-08 Thread Guillaume Nodet (JIRA)
Goal to transform a maven version into an OSGi version
--

 Key: FELIX-1568
 URL: https://issues.apache.org/jira/browse/FELIX-1568
 Project: Felix
  Issue Type: New Feature
  Components: Maven Bundle Plugin
Reporter: Guillaume Nodet
 Fix For: maven-bundle-plugin-2.1.0


I found a workaround which is the following xml snippet, but a built-in goal 
would be way easier ;-)


org.apache.maven.plugins
maven-antrun-plugin
1.2


create-prop
generate-resources





















run





ant-contrib
ant-contrib
1.0b3


ant
ant-optional
1.5.3-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-1419) Add support for nested/inner classes in SCR Plugins (QDox+Annotations)

2009-09-08 Thread Carsten Ziegeler (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-1419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752405#action_12752405
 ] 

Carsten Ziegeler commented on FELIX-1419:
-

Hi Stefan, the class has changed in svn in the meantime. Could you please redo 
your patch against latest trunk?

Thanks

> Add support for nested/inner classes in SCR Plugins (QDox+Annotations)
> --
>
> Key: FELIX-1419
> URL: https://issues.apache.org/jira/browse/FELIX-1419
> Project: Felix
>  Issue Type: Improvement
>  Components: Maven SCR Plugin
>Affects Versions: maven-scr-plugin-1.2.0
>Reporter: Stefan Seifert
>Assignee: Carsten Ziegeler
> Fix For: maven-scr-plugin-1.4.0
>
> Attachments: 090728_innerclasssupport.patch
>
>
> the current scr plugin implementation ignores inner classes, even if they 
> have SCR plugin annotations or QDox tags.
> the attached patch solves this problem.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (FELIX-1563) Felix latest bundle repository cannot be started for some reason

2009-09-08 Thread david small99 (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752403#action_12752403
 ] 

david small99 commented on FELIX-1563:
--

Hi Richard,
The bundle org.apache.felix.bundlerepository-1.4.0.jar should be able to cope 
with org.osgi.framework 1.3 as its import package is shown below.
Manifest-Version: 1.0
Built-By: pauls
Bundle-Activator: org.apache.felix.bundlerepository.Activator
Created-By: Apache Maven Bundle Plugin
Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.txt
Import-Package: org.osgi.framework;version="1.3",org.osgi.service.log;
 resolution:=optional;version="1.3.0",org.osgi.service.obr;version="1.
 0"
Bnd-LastModified: 1238533562871
Export-Package: org.osgi.service.obr;uses:="org.osgi.framework";versio
 n="1.0"
Bundle-Version: 1.4.0
Ignore-Package: org.xml.sax,javax.xml.parsers
Bundle-Name: Apache Felix Bundle Repository
Bundle-Description: Bundle repository service.
Bundle-Url: http://felix.apache.org/site/downloads.cgi
Build-Jdk: 1.5.0_16
Bundle-DocURL: http://felix.apache.org/site/apache-felix-osgi-bundle-r
 epository.html
Private-Package: org.apache.felix.bundlerepository,org.apache.felix.bu
 ndlerepository.metadataparser,org.apache.felix.bundlerepository.metad
 ataparser.kxmlsax,org.kxml2.io,org.kxml2.kdom,org.kxml2.wap,org.kxml2
 .wap.syncml,org.kxml2.wap.wml,org.kxml2.wap.wv,org.xmlpull.v1
Bundle-ManifestVersion: 2
Export-Service: org.osgi.service.obr.RepositoryAdmin
Bundle-Vendor: The Apache Software Foundation
Bundle-SymbolicName: org.apache.felix.bundlerepository
Tool: Bnd-0.0.255
Bundle-Source: http://felix.apache.org/site/downloads.cgi
DynamicImport-Package: org.apache.felix.shell


> Felix latest bundle repository cannot be started for some reason
> 
>
> Key: FELIX-1563
> URL: https://issues.apache.org/jira/browse/FELIX-1563
> Project: Felix
>  Issue Type: Bug
>  Components: Bundle Repository (OBR)
>Affects Versions: felix-1.8.0
>Reporter: david small99
>
> I tried to use the org.apache.felix.bundlerepository-1.4.0.jar. The bundle 
> cannot be started.
> org.osgi.framework.BundleException: Exception in 
> org.apache.felix.bundlerepository.Activator.start() of bundle 
> org.apache.felix.bundlerepository.
> at 
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1010)
> at 
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:966)
> at 
> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:317)
> at 
> org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:256)
> at 
> org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._start(FrameworkCommandProvider.java:239)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:599)
> at 
> org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(FrameworkCommandInterpreter.java:145)
> at 
> org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(FrameworkConsole.java:293)
> at 
> org.eclipse.osgi.framework.internal.core.FrameworkConsole.console(FrameworkConsole.java:278)
> at 
> org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(FrameworkConsole.java:213)
> at java.lang.Thread.run(Thread.java:735)
> Caused by: java.lang.NoSuchMethodError: 
> org/osgi/framework/Bundle.getBundleContext()Lorg/osgi/framework/BundleContext;
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl$LocalResourceImpl.initialize(LocalRepositoryImpl.java:222)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl$LocalResourceImpl.(LocalRepositoryImpl.java:190)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl$LocalResourceImpl.(LocalRepositoryImpl.java:182)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl.addBundle(LocalRepositoryImpl.java:104)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl.initialize(LocalRepositoryImpl.java:169)
> at 
> org.apache.felix.bundlerepository.LocalRepositoryImpl.(LocalRepositoryImpl.java:56)
> at 
> org.apache.felix.bundlerepository.RepositoryAdminImpl.(RepositoryAdminImpl.java:58)
> at 
> org.apache.felix.bundlerepository.Activator.start(Activator.java:35)
> at 
> org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:991)
> at 
> java.security.AccessController.doPrivile

[jira] Resolved: (FELIX-1567) When dropping an empty xml file (i.e. just an empty file with an xml extension) in the deploy folder, errors are printed to the console

2009-09-08 Thread Guillaume Nodet (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet resolved FELIX-1567.


   Resolution: Fixed
Fix Version/s: karaf-1.0.0
 Assignee: Guillaume Nodet

Committing to https://svn.apache.org/repos/asf/felix/trunk ...
M   
karaf/deployer/blueprint/src/main/java/org/apache/felix/karaf/deployer/blueprint/BlueprintDeploymentListener.java
M   
karaf/deployer/features/src/main/java/org/apache/felix/karaf/deployer/features/FeatureDeploymentListener.java
M   
karaf/deployer/spring/src/main/java/org/apache/felix/karaf/deployer/spring/SpringDeploymentListener.java
Committed r812397


> When dropping an empty xml file (i.e. just an empty file with an xml 
> extension) in the deploy folder, errors are printed to the console
> ---
>
> Key: FELIX-1567
> URL: https://issues.apache.org/jira/browse/FELIX-1567
> Project: Felix
>  Issue Type: Bug
>  Components: Karaf
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: karaf-1.0.0
>
>
> [Fatal Error] audit.xml:1:1: Premature end of file.
> [Fatal Error] audit.xml:1:1: Premature end of file.
> [Fatal Error] audit.xml:1:1: Premature end of file.
> [Fatal Error] audit.xml:1:1: Premature end of file.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (FELIX-1566) Possible NPE when uninstalling a feature

2009-09-08 Thread Guillaume Nodet (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet resolved FELIX-1566.


Resolution: Fixed
  Assignee: Guillaume Nodet

Committing to https://svn.apache.org/repos/asf/felix/trunk ...
M   
karaf/features/core/src/main/java/org/apache/felix/karaf/features/internal/FeaturesServiceImpl.java
Committed r812386


> Possible NPE when uninstalling a feature
> 
>
> Key: FELIX-1566
> URL: https://issues.apache.org/jira/browse/FELIX-1566
> Project: Felix
>  Issue Type: Bug
>  Components: Karaf
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: karaf-1.0.0
>
>
> ka...@root> features:uninstall nmr-audit 
> java.lang.NullPointerException
>   at 
> org.apache.felix.karaf.features.internal.FeaturesServiceImpl.uninstallFeature(FeaturesServiceImpl.java:304)
>   at 
> org.apache.felix.karaf.features.internal.FeaturesServiceImpl.uninstallFeature(FeaturesServiceImpl.java:287)
>   at 
> org.apache.felix.karaf.features.command.UninstallFeatureCommand.doExecute(UninstallFeatureCommand.java:35)
>   at 
> org.apache.felix.karaf.features.command.FeaturesCommandSupport.doExecute(FeaturesCommandSupport.java:39)
>   at 
> org.apache.felix.karaf.gshell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:41)
>   at 
> org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:34)
>   at 
> org.apache.felix.gogo.runtime.shell.CommandProxy.execute(CommandProxy.java:45)
>   at org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:211)
>   at 
> org.apache.felix.gogo.runtime.shell.Closure.executeStatement(Closure.java:146)
>   at org.apache.felix.gogo.runtime.shell.Pipe.run(Pipe.java:91)
>   at org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:75)
>   at 
> org.apache.felix.gogo.runtime.shell.CommandSessionImpl.execute(CommandSessionImpl.java:71)
>   at 
> org.apache.felix.karaf.gshell.console.jline.Console.run(Console.java:115)
>   at java.lang.Thread.run(Thread.java:637)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Created: (FELIX-1567) When dropping an empty xml file (i.e. just an empty file with an xml extension) in the deploy folder, errors are printed to the console

2009-09-08 Thread Guillaume Nodet (JIRA)
When dropping an empty xml file (i.e. just an empty file with an xml extension) 
in the deploy folder, errors are printed to the console
---

 Key: FELIX-1567
 URL: https://issues.apache.org/jira/browse/FELIX-1567
 Project: Felix
  Issue Type: Bug
  Components: Karaf
Reporter: Guillaume Nodet


[Fatal Error] audit.xml:1:1: Premature end of file.
[Fatal Error] audit.xml:1:1: Premature end of file.
[Fatal Error] audit.xml:1:1: Premature end of file.
[Fatal Error] audit.xml:1:1: Premature end of file.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (FELIX-1460) Can't view installed but unresolved bundle details page

2009-09-08 Thread Felix Meschberger (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felix Meschberger resolved FELIX-1460.
--

   Resolution: Fixed
Fix Version/s: webconsole-1.2.12

Thanks for reporting and providing the patch.

I have applied it in  Rev. 812375

> Can't view installed but unresolved bundle details page
> ---
>
> Key: FELIX-1460
> URL: https://issues.apache.org/jira/browse/FELIX-1460
> Project: Felix
>  Issue Type: Bug
>  Components: Web Console
>Affects Versions: webconsole-1.2.12
>Reporter: Victor Antonovich
>Assignee: Felix Meschberger
> Fix For: webconsole-1.2.12
>
>
> Trying to view details page about installed but unresolved bundle causes 
> exception 'java.lang.NoClassDefFoundError: 
> org/apache/felix/bundlerepository/Util'. Patch below fixes this:
> Index: pom.xml
> ===
> --- pom.xml   (revision 801916)
> +++ pom.xml   (working copy)
> @@ -95,8 +95,10 @@
>  
>  
>  
> -
> org.apache.felix.bundlerepository;inline=org/apache/felix/bundlerepository/R4*.class,
> -
> +
> org.apache.felix.bundlerepository;inline=org/apache/felix/bundlerepository/R4*.class
> +| 
> org/apache/felix/bundlerepository/Util.class
> +| 
> org/apache/felix/bundlerepository/VersionRange.class,
> +
>  
>  json,
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (FELIX-1015) Hardcoded HTML Header/Footer in AbstractWebConsolePlugin

2009-09-08 Thread Felix Meschberger (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felix Meschberger resolved FELIX-1015.
--

   Resolution: Fixed
Fix Version/s: webconsole-1.2.12

Implemented branding support as described in [1] in Rev. 812372



[1] http://felix.apache.org/site/branding-the-web-console.html

> Hardcoded HTML Header/Footer in AbstractWebConsolePlugin
> 
>
> Key: FELIX-1015
> URL: https://issues.apache.org/jira/browse/FELIX-1015
> Project: Felix
>  Issue Type: Sub-task
>  Components: Web Console
>Affects Versions: webconsole-1.2.8
>Reporter: Thomas Diesler
>Assignee: Felix Meschberger
> Fix For: webconsole-1.2.12
>
> Attachments: branding.patch, branding2.patch, 
> FELIX-1015-fmeschbe.patch
>
>
> Instead of 
> private static final String HEADER = " encoding=\"UTF-8\" ?>"
> + " \"xhtml1-transitional.dtd\">"
> + "http://www.w3.org/1999/xhtml\";>"
> + ""
> + ""
> + ""
> + "{0} - {2}"
> + " language=\"JavaScript\">"
> + " language=\"JavaScript\">"
> + " language=\"JavaScript\">"
> + ""
> + ""
> + "appRoot = \"{5}\";"
> + "pluginRoot = appRoot + \"/{6}\";"
> + ""
> + " type=\"text/css\">"
> + ""
> + ""
> + ""
> + ""
> + ""
> + "{0}{2}"
> + ""
> + ""
> + " src=\"{5}/res/imgs/logo.png\" width=\"165\" height=\"63\" border=\"0\">"
> + "" + "";
> we propose 
> protected String getHeader()
> {
>String HEADER = ""
> + " \"xhtml1-transitional.dtd\">"
> + "http://www.w3.org/1999/xhtml\";>"
> + ""
> + ""
> + ""
> + "{0} - {2}"
> + " language=\"JavaScript\">"
> + " language=\"JavaScript\">"
> + " language=\"JavaScript\">"
> + ""
> + ""
> + "appRoot = \"{5}\";"
> + "pluginRoot = appRoot + \"/{6}\";"
> + ""
> + " type=\"text/css\">"
> + ""
> + ""
> + ""
> + ""
> + ""
> + "{0}{2}"
> + ""
> + ""
> + " src=\"{5}/res/imgs/logo.png\" width=\"165\" height=\"63\" border=\"0\">"
> + "" + "";
>return HEADER;
> }
> -
> protected PrintWriter startResponse( HttpServletRequest request, 
> HttpServletResponse response ) throws IOException
> {
> ...
> String header = MessageFormat.format( getHeader(), new Object[]
> }
> protected void endResponse( HttpServletRequest request, PrintWriter pw )
> {
> pw.println( "" );
> pw.println( "" );
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (FELIX-1460) Can't view installed but unresolved bundle details page

2009-09-08 Thread Felix Meschberger (JIRA)

 [ 
https://issues.apache.org/jira/browse/FELIX-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felix Meschberger reassigned FELIX-1460:


Assignee: Felix Meschberger

> Can't view installed but unresolved bundle details page
> ---
>
> Key: FELIX-1460
> URL: https://issues.apache.org/jira/browse/FELIX-1460
> Project: Felix
>  Issue Type: Bug
>  Components: Web Console
>Affects Versions: webconsole-1.2.12
>Reporter: Victor Antonovich
>Assignee: Felix Meschberger
>
> Trying to view details page about installed but unresolved bundle causes 
> exception 'java.lang.NoClassDefFoundError: 
> org/apache/felix/bundlerepository/Util'. Patch below fixes this:
> Index: pom.xml
> ===
> --- pom.xml   (revision 801916)
> +++ pom.xml   (working copy)
> @@ -95,8 +95,10 @@
>  
>  
>  
> -
> org.apache.felix.bundlerepository;inline=org/apache/felix/bundlerepository/R4*.class,
> -
> +
> org.apache.felix.bundlerepository;inline=org/apache/felix/bundlerepository/R4*.class
> +| 
> org/apache/felix/bundlerepository/Util.class
> +| 
> org/apache/felix/bundlerepository/VersionRange.class,
> +
>  
>  json,
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



  1   2   >