[jira] Commented: (FELIX-721) NPE in FilterImpl.toString()

2008-09-12 Thread Karl Pauls (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12630501#action_12630501
 ] 

Karl Pauls commented on FELIX-721:
--

Do you think it is possible to get me the filter that fails?

 NPE in FilterImpl.toString()
 

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

 We see this NPE occasionally, probably 10% of the time on application startup:
  [java] java.lang.NullPointerException
  [java] at 
 org.apache.felix.framework.util.ldap.Parser$AndOperator.toStringInfix(Parser.java:601)
  [java] at 
 org.apache.felix.framework.util.ldap.Evaluator.toStringInfix(Evaluator.java:184)
  [java] at 
 org.apache.felix.framework.FilterImpl.toString(FilterImpl.java:242)
  [java] at java.lang.String.valueOf(String.java:2615)
  [java] at java.lang.StringBuffer.append(StringBuffer.java:220)
  [java] at 
 org.springframework.osgi.service.importer.DefaultOsgiServiceDependency.init(DefaultOsgiServiceDependency.java:52)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.MandatoryImporterDependencyFactory.getServiceDependencies(MandatoryImporterDependencyFactory.java:69)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.DependencyServiceManager.findServiceDependencies(DependencyServiceManager.java:233)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.stageOne(DependencyWaiterApplicationContextExecutor.java:248)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.refresh(DependencyWaiterApplicationContextExecutor.java:172)
  [java] at 
 org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.refresh(AbstractDelegatedExecutionApplicationContext.java:136)
  [java] at 
 org.springframework.osgi.extender.internal.activator.ContextLoaderListener$2.run(ContextLoaderListener.java:746)
  [java] at java.lang.Thread.run(Thread.java:613)
 My first guess would be we are constructing a filter improperly in our Spring 
 config, but the fact that it only happens some of the time is strange.  If 
 nothing else, it would be nice if this bit of code was a bit more defensive.

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



[jira] Created: (FELIX-722) Can't manage split packages with Require-Bundle header

2008-09-12 Thread Pierre De Rop (JIRA)
Can't manage split packages with Require-Bundle header
--

 Key: FELIX-722
 URL: https://issues.apache.org/jira/browse/FELIX-722
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: felix-1.2.1

 Environment: Linux
Reporter: Pierre De Rop
Priority: Minor
 Fix For: felix-1.2.1



Attached to this post a sample code which tries to manage split packages with 
the
Require-Bundle header. 
It does not work with felix 1.2.1 (but sounds like working with knoperfish).

Please have a look at the following felix forum post:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg02044.html


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



[jira] Updated: (FELIX-722) Can't manage split packages with Require-Bundle header

2008-09-12 Thread Pierre De Rop (JIRA)

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

Pierre De Rop updated FELIX-722:


Attachment: test-splitpackage.tgz

In this archive, you will find the three bundles (generated under 
test-splitpackages/bundles/ dir).
(it's already compiled, but there is a build.xml ni test-splitpackages/ dir).


 Can't manage split packages with Require-Bundle header
 --

 Key: FELIX-722
 URL: https://issues.apache.org/jira/browse/FELIX-722
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: felix-1.2.1

 Environment: Linux
Reporter: Pierre De Rop
Priority: Minor
 Fix For: felix-1.2.1


 Attachments: test-splitpackage.tgz


 Attached to this post a sample code which tries to manage split packages with 
 the
 Require-Bundle header. 
 It does not work with felix 1.2.1 (but sounds like working with knoperfish).
 Please have a look at the following felix forum post:
 http://www.mail-archive.com/[EMAIL PROTECTED]/msg02044.html

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



[jira] Commented: (FELIX-721) NPE in FilterImpl.toString()

2008-09-12 Thread Stuart McCulloch (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12630502#action_12630502
 ] 

Stuart McCulloch commented on FELIX-721:


Another option (if it is truly random) would be to locally build the FilterImpl 
with additional instrumentation to capture the original string used to build 
the filter - then when it failed with the NPE you could dump the string along 
with various other fields from the filter object...


 NPE in FilterImpl.toString()
 

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

 We see this NPE occasionally, probably 10% of the time on application startup:
  [java] java.lang.NullPointerException
  [java] at 
 org.apache.felix.framework.util.ldap.Parser$AndOperator.toStringInfix(Parser.java:601)
  [java] at 
 org.apache.felix.framework.util.ldap.Evaluator.toStringInfix(Evaluator.java:184)
  [java] at 
 org.apache.felix.framework.FilterImpl.toString(FilterImpl.java:242)
  [java] at java.lang.String.valueOf(String.java:2615)
  [java] at java.lang.StringBuffer.append(StringBuffer.java:220)
  [java] at 
 org.springframework.osgi.service.importer.DefaultOsgiServiceDependency.init(DefaultOsgiServiceDependency.java:52)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.MandatoryImporterDependencyFactory.getServiceDependencies(MandatoryImporterDependencyFactory.java:69)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.DependencyServiceManager.findServiceDependencies(DependencyServiceManager.java:233)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.stageOne(DependencyWaiterApplicationContextExecutor.java:248)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.refresh(DependencyWaiterApplicationContextExecutor.java:172)
  [java] at 
 org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.refresh(AbstractDelegatedExecutionApplicationContext.java:136)
  [java] at 
 org.springframework.osgi.extender.internal.activator.ContextLoaderListener$2.run(ContextLoaderListener.java:746)
  [java] at java.lang.Thread.run(Thread.java:613)
 My first guess would be we are constructing a filter improperly in our Spring 
 config, but the fact that it only happens some of the time is strange.  If 
 nothing else, it would be nice if this bit of code was a bit more defensive.

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



[jira] Commented: (FELIX-721) NPE in FilterImpl.toString()

2008-09-12 Thread Stuart McCulloch (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12630509#action_12630509
 ] 

Stuart McCulloch commented on FELIX-721:


simplest fix would be to make FilterImpl.toString() synchronized, but this would
affect performance in all cases, even when the result has already been cached.

otherwise the Operator.children field somehow needs to be made thread-local

 NPE in FilterImpl.toString()
 

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

 We see this NPE occasionally, probably 10% of the time on application startup:
  [java] java.lang.NullPointerException
  [java] at 
 org.apache.felix.framework.util.ldap.Parser$AndOperator.toStringInfix(Parser.java:601)
  [java] at 
 org.apache.felix.framework.util.ldap.Evaluator.toStringInfix(Evaluator.java:184)
  [java] at 
 org.apache.felix.framework.FilterImpl.toString(FilterImpl.java:242)
  [java] at java.lang.String.valueOf(String.java:2615)
  [java] at java.lang.StringBuffer.append(StringBuffer.java:220)
  [java] at 
 org.springframework.osgi.service.importer.DefaultOsgiServiceDependency.init(DefaultOsgiServiceDependency.java:52)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.MandatoryImporterDependencyFactory.getServiceDependencies(MandatoryImporterDependencyFactory.java:69)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.DependencyServiceManager.findServiceDependencies(DependencyServiceManager.java:233)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.stageOne(DependencyWaiterApplicationContextExecutor.java:248)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.refresh(DependencyWaiterApplicationContextExecutor.java:172)
  [java] at 
 org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.refresh(AbstractDelegatedExecutionApplicationContext.java:136)
  [java] at 
 org.springframework.osgi.extender.internal.activator.ContextLoaderListener$2.run(ContextLoaderListener.java:746)
  [java] at java.lang.Thread.run(Thread.java:613)
 My first guess would be we are constructing a filter improperly in our Spring 
 config, but the fact that it only happens some of the time is strange.  If 
 nothing else, it would be nice if this bit of code was a bit more defensive.

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



[jira] Commented: (FELIX-722) Can't manage split packages with Require-Bundle header

2008-09-12 Thread Stuart McCulloch (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12630511#action_12630511
 ] 

Stuart McCulloch commented on FELIX-722:


FYI, I've also confirmed this works in Equinox using a similar setup

 Can't manage split packages with Require-Bundle header
 --

 Key: FELIX-722
 URL: https://issues.apache.org/jira/browse/FELIX-722
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: felix-1.2.1

 Environment: Linux
Reporter: Pierre De Rop
Priority: Minor
 Fix For: felix-1.2.1


 Attachments: test-splitpackage.tgz


 Attached to this post a sample code which tries to manage split packages with 
 the
 Require-Bundle header. 
 It does not work with felix 1.2.1 (but sounds like working with knoperfish).
 Please have a look at the following felix forum post:
 http://www.mail-archive.com/[EMAIL PROTECTED]/msg02044.html

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



[jira] Commented: (FELIX-721) NPE in FilterImpl.toString()

2008-09-12 Thread Karl Pauls (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12630512#action_12630512
 ] 

Karl Pauls commented on FELIX-721:
--

Hi Stuart,

yes, this makes sense. It seems to be the children member. Would it be enough 
to make buildTree look like this:

public void buildTree(Stack operands)
{
Operator[] tmp = new Operator[operandCount];
// need to preserve stack order
for (int i = 0; i  operandCount; i++)
{
tmp[(operandCount - 1) - i] =
(Operator) operands.pop();
}
children = tmp;
operands.push(this);
}

this way we don't need sync and are optimistic (i.e., it might be that we do 
some work twice but we assume thats cheaper then to always sync). 

 NPE in FilterImpl.toString()
 

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

 We see this NPE occasionally, probably 10% of the time on application startup:
  [java] java.lang.NullPointerException
  [java] at 
 org.apache.felix.framework.util.ldap.Parser$AndOperator.toStringInfix(Parser.java:601)
  [java] at 
 org.apache.felix.framework.util.ldap.Evaluator.toStringInfix(Evaluator.java:184)
  [java] at 
 org.apache.felix.framework.FilterImpl.toString(FilterImpl.java:242)
  [java] at java.lang.String.valueOf(String.java:2615)
  [java] at java.lang.StringBuffer.append(StringBuffer.java:220)
  [java] at 
 org.springframework.osgi.service.importer.DefaultOsgiServiceDependency.init(DefaultOsgiServiceDependency.java:52)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.MandatoryImporterDependencyFactory.getServiceDependencies(MandatoryImporterDependencyFactory.java:69)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.DependencyServiceManager.findServiceDependencies(DependencyServiceManager.java:233)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.stageOne(DependencyWaiterApplicationContextExecutor.java:248)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.refresh(DependencyWaiterApplicationContextExecutor.java:172)
  [java] at 
 org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.refresh(AbstractDelegatedExecutionApplicationContext.java:136)
  [java] at 
 org.springframework.osgi.extender.internal.activator.ContextLoaderListener$2.run(ContextLoaderListener.java:746)
  [java] at java.lang.Thread.run(Thread.java:613)
 My first guess would be we are constructing a filter improperly in our Spring 
 config, but the fact that it only happens some of the time is strange.  If 
 nothing else, it would be nice if this bit of code was a bit more defensive.

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



[jira] Commented: (FELIX-721) NPE in FilterImpl.toString()

2008-09-12 Thread Karl Pauls (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12630514#action_12630514
 ] 

Karl Pauls commented on FELIX-721:
--

o.k., I can do this today. 

 NPE in FilterImpl.toString()
 

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

 We see this NPE occasionally, probably 10% of the time on application startup:
  [java] java.lang.NullPointerException
  [java] at 
 org.apache.felix.framework.util.ldap.Parser$AndOperator.toStringInfix(Parser.java:601)
  [java] at 
 org.apache.felix.framework.util.ldap.Evaluator.toStringInfix(Evaluator.java:184)
  [java] at 
 org.apache.felix.framework.FilterImpl.toString(FilterImpl.java:242)
  [java] at java.lang.String.valueOf(String.java:2615)
  [java] at java.lang.StringBuffer.append(StringBuffer.java:220)
  [java] at 
 org.springframework.osgi.service.importer.DefaultOsgiServiceDependency.init(DefaultOsgiServiceDependency.java:52)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.MandatoryImporterDependencyFactory.getServiceDependencies(MandatoryImporterDependencyFactory.java:69)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.DependencyServiceManager.findServiceDependencies(DependencyServiceManager.java:233)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.stageOne(DependencyWaiterApplicationContextExecutor.java:248)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.refresh(DependencyWaiterApplicationContextExecutor.java:172)
  [java] at 
 org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.refresh(AbstractDelegatedExecutionApplicationContext.java:136)
  [java] at 
 org.springframework.osgi.extender.internal.activator.ContextLoaderListener$2.run(ContextLoaderListener.java:746)
  [java] at java.lang.Thread.run(Thread.java:613)
 My first guess would be we are constructing a filter improperly in our Spring 
 config, but the fact that it only happens some of the time is strange.  If 
 nothing else, it would be nice if this bit of code was a bit more defensive.

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



[jira] Updated: (FELIX-721) NPE in FilterImpl.toString()

2008-09-12 Thread Karl Pauls (JIRA)

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

Karl Pauls updated FELIX-721:
-

Attachment: ldap.patch

This patch should fix the issue by making the children member volatile and 
assign it optimistic. 

Let me know what you think. 



 NPE in FilterImpl.toString()
 

 Key: FELIX-721
 URL: https://issues.apache.org/jira/browse/FELIX-721
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: felix-1.0.4
Reporter: Don Brown
 Attachments: ldap.patch


 We see this NPE occasionally, probably 10% of the time on application startup:
  [java] java.lang.NullPointerException
  [java] at 
 org.apache.felix.framework.util.ldap.Parser$AndOperator.toStringInfix(Parser.java:601)
  [java] at 
 org.apache.felix.framework.util.ldap.Evaluator.toStringInfix(Evaluator.java:184)
  [java] at 
 org.apache.felix.framework.FilterImpl.toString(FilterImpl.java:242)
  [java] at java.lang.String.valueOf(String.java:2615)
  [java] at java.lang.StringBuffer.append(StringBuffer.java:220)
  [java] at 
 org.springframework.osgi.service.importer.DefaultOsgiServiceDependency.init(DefaultOsgiServiceDependency.java:52)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.MandatoryImporterDependencyFactory.getServiceDependencies(MandatoryImporterDependencyFactory.java:69)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.DependencyServiceManager.findServiceDependencies(DependencyServiceManager.java:233)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.stageOne(DependencyWaiterApplicationContextExecutor.java:248)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.refresh(DependencyWaiterApplicationContextExecutor.java:172)
  [java] at 
 org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.refresh(AbstractDelegatedExecutionApplicationContext.java:136)
  [java] at 
 org.springframework.osgi.extender.internal.activator.ContextLoaderListener$2.run(ContextLoaderListener.java:746)
  [java] at java.lang.Thread.run(Thread.java:613)
 My first guess would be we are constructing a filter improperly in our Spring 
 config, but the fact that it only happens some of the time is strange.  If 
 nothing else, it would be nice if this bit of code was a bit more defensive.

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



[jira] Created: (FELIX-723) ArrayIndexOutOfBoundsException in aQute.lib.osgi.Clazz.parseClassFile

2008-09-12 Thread Brad Cox (JIRA)
ArrayIndexOutOfBoundsException in aQute.lib.osgi.Clazz.parseClassFile
-

 Key: FELIX-723
 URL: https://issues.apache.org/jira/browse/FELIX-723
 Project: Felix
  Issue Type: Bug
  Components: Maven Bundle Plugin
 Environment: MacOSX
Reporter: Brad Cox


 I integrated the recommended changes (pom enclosed below) but that
 com.ibm.icu error turned up again. Bad chinese locale class out there
 somewhere? com/ibm/icu/impl/data/LocaleElements_zh__PINYIN.class.

Seems to be triggered by  
Embed-Dependency*;scope=compile|runtime;inline=true/Embed-Dependency. 
At least removing that eliminates the symptom.

I'll work towards a small test case once I understand this a bit better. 
This bug is ephemeral so I want to capture what I have first.

I tried erasing it in .m2 but that didn't help. POM and stacktrace below

?xml version=1.0 encoding=UTF-8?
 project
xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
 http://maven.apache.org/maven-v4_0_0.xsd;
  
  modelVersion4.0.0/modelVersion
  groupIdsoakit/groupId
  artifactIdsoakit.core/artifactId
  version1.0-SNAPSHOT/version
  namesoakit.core/name
  descriptionSoaKit Core Abstraction Layer. Defines interfaces and
 abstract classes for the components defined in sub-modules. Provides a
 service (factory class) for defining soakit composites with an XML
 configuration file./description

  packagingbundle/packaging

  parent
groupIdsoakit/groupId
artifactIdsoakit/artifactId
version1.0-SNAPSHOT/version
  /parent

  dependencies
dependency
  groupIdcommons-collections/groupId
  artifactIdcommons-collections/artifactId
  version3.2/version
/dependency
dependency
groupIdjdom/groupId
artifactIdjdom/artifactId
version1.0/version
/dependency
!--
dependency
groupIdjavax.xml.parsers/groupId
artifactIdjaxp-api/artifactId
version1.4/version
/dependency
dependency
groupIdjavax.xml.ws/groupId
artifactIdjaxws-api/artifactId
version2.1-1/version
/dependency
dependency
groupIdxerces/groupId
artifactIdxercesImpl/artifactId
version2.8.1/version
/dependency
 dependency
groupIdorg.eclipse/groupId
artifactIdosgi/artifactId
version3.4.0.v20080605-1900/version
/dependency
dependency
groupIdjaxen/groupId
artifactIdjaxen/artifactId
  version1.1-beta-9/version
/dependency
--
  /dependencies

  build
resources
  resource
directorysrc/main/resources/directory
  /resource
  resource
directory./directory
includes
  includeplugin.xml/include
/includes
  /resource
/resources

plugins
plugin
artifactIdmaven-eclipse-plugin/artifactId
configuration
  pdetrue/pde
/configuration
  /plugin
  plugin
groupIdorg.apache.felix/groupId
artifactIdmaven-bundle-plugin/artifactId
version1.4.3/version
extensionstrue/extensions
configuration
unpackBundletrue/unpackBundle
  manifestLocationMETA-INF/manifestLocation
  instructions
Bundle-Version${pom.version}/Bundle-Version
Bundle-Name${artifactId}/Bundle-Name
Bundle-SymbolicName${artifactId}/Bundle-SymbolicName
Bundle-DescriptionSoakit
 Core Bundle/Bundle-Description

 Bundle-Activatorcom.gestalt.soakit.core.CoreActivator/Bundle-Activator

 Embed-Dependency*;scope=compile|runtime;inline=true/Embed-Dependency

  Embed-Transitivetrue/Embed-Transitive
Embed-Directorytarget/dependency/Embed-Directory

 Bundle-RequiredExecutionEnvironmentJ2SE-1.5/Bundle-RequiredExecutionEnvironment
Import-Package
*,
!--

  org.apache.commons.collections.*;version=3.2

  org.apache.commons.collections.iterators.*;version=3.2,

  org.jdom;version=1.0,

  org.jdom.*;version=1.0,

  org.jdom.input.*;version=1.0,

  org.jdom.output.*;version=1.0,

  org.apache.xerces.parsers,
javax.*,
   

[jira] Commented: (FELIX-721) NPE in FilterImpl.toString()

2008-09-12 Thread Stuart McCulloch (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12630574#action_12630574
 ] 

Stuart McCulloch commented on FELIX-721:


+1, patch looks good to me.

 NPE in FilterImpl.toString()
 

 Key: FELIX-721
 URL: https://issues.apache.org/jira/browse/FELIX-721
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: felix-1.0.4
Reporter: Don Brown
 Attachments: ldap.patch


 We see this NPE occasionally, probably 10% of the time on application startup:
  [java] java.lang.NullPointerException
  [java] at 
 org.apache.felix.framework.util.ldap.Parser$AndOperator.toStringInfix(Parser.java:601)
  [java] at 
 org.apache.felix.framework.util.ldap.Evaluator.toStringInfix(Evaluator.java:184)
  [java] at 
 org.apache.felix.framework.FilterImpl.toString(FilterImpl.java:242)
  [java] at java.lang.String.valueOf(String.java:2615)
  [java] at java.lang.StringBuffer.append(StringBuffer.java:220)
  [java] at 
 org.springframework.osgi.service.importer.DefaultOsgiServiceDependency.init(DefaultOsgiServiceDependency.java:52)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.MandatoryImporterDependencyFactory.getServiceDependencies(MandatoryImporterDependencyFactory.java:69)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.DependencyServiceManager.findServiceDependencies(DependencyServiceManager.java:233)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.stageOne(DependencyWaiterApplicationContextExecutor.java:248)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.refresh(DependencyWaiterApplicationContextExecutor.java:172)
  [java] at 
 org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.refresh(AbstractDelegatedExecutionApplicationContext.java:136)
  [java] at 
 org.springframework.osgi.extender.internal.activator.ContextLoaderListener$2.run(ContextLoaderListener.java:746)
  [java] at java.lang.Thread.run(Thread.java:613)
 My first guess would be we are constructing a filter improperly in our Spring 
 config, but the fact that it only happens some of the time is strange.  If 
 nothing else, it would be nice if this bit of code was a bit more defensive.

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



[jira] Commented: (FELIX-723) ArrayIndexOutOfBoundsException in aQute.lib.osgi.Clazz.parseClassFile

2008-09-12 Thread Stuart McCulloch (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12630579#action_12630579
 ] 

Stuart McCulloch commented on FELIX-723:


FYI, removing the embed instruction just means you won't be adding
any of the classfiles from the dependencies - so I'd fully expect that to
eliminate the symptom, as BND will never see that particular class.

So it's now just a matter of finding which dependency contains that
class and then we can confirm whether or not this is a broken class,
or a bug in BND.

 ArrayIndexOutOfBoundsException in aQute.lib.osgi.Clazz.parseClassFile
 -

 Key: FELIX-723
 URL: https://issues.apache.org/jira/browse/FELIX-723
 Project: Felix
  Issue Type: Bug
  Components: Maven Bundle Plugin
 Environment: MacOSX
Reporter: Brad Cox

  I integrated the recommended changes (pom enclosed below) but that
  com.ibm.icu error turned up again. Bad chinese locale class out there
  somewhere? com/ibm/icu/impl/data/LocaleElements_zh__PINYIN.class.
 Seems to be triggered by  
 Embed-Dependency*;scope=compile|runtime;inline=true/Embed-Dependency. 
 At least removing that eliminates the symptom.
 I'll work towards a small test case once I understand this a bit better. 
 This bug is ephemeral so I want to capture what I have first.
 I tried erasing it in .m2 but that didn't help. POM and stacktrace below
 ?xml version=1.0 encoding=UTF-8?
  project
 xmlns=http://maven.apache.org/POM/4.0.0;
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
  http://maven.apache.org/maven-v4_0_0.xsd;
   
   modelVersion4.0.0/modelVersion
   groupIdsoakit/groupId
   artifactIdsoakit.core/artifactId
   version1.0-SNAPSHOT/version
   namesoakit.core/name
   descriptionSoaKit Core Abstraction Layer. Defines interfaces and
  abstract classes for the components defined in sub-modules. Provides a
  service (factory class) for defining soakit composites with an XML
  configuration file./description
 
   packagingbundle/packaging
 
   parent
 groupIdsoakit/groupId
 artifactIdsoakit/artifactId
 version1.0-SNAPSHOT/version
   /parent
 
   dependencies
 dependency
   groupIdcommons-collections/groupId
   artifactIdcommons-collections/artifactId
   version3.2/version
 /dependency
 dependency
 groupIdjdom/groupId
 artifactIdjdom/artifactId
 version1.0/version
 /dependency
 !--
 dependency
 groupIdjavax.xml.parsers/groupId
 artifactIdjaxp-api/artifactId
 version1.4/version
 /dependency
 dependency
 groupIdjavax.xml.ws/groupId
 artifactIdjaxws-api/artifactId
 version2.1-1/version
 /dependency
 dependency
 groupIdxerces/groupId
 artifactIdxercesImpl/artifactId
 version2.8.1/version
 /dependency
  dependency
 groupIdorg.eclipse/groupId
 artifactIdosgi/artifactId
 version3.4.0.v20080605-1900/version
 /dependency
 dependency
 groupIdjaxen/groupId
 artifactIdjaxen/artifactId
   version1.1-beta-9/version
 /dependency
 --
   /dependencies
 
   build
 resources
   resource
 directorysrc/main/resources/directory
   /resource
   resource
 directory./directory
 includes
   includeplugin.xml/include
 /includes
   /resource
 /resources
 
 plugins
 plugin
 artifactIdmaven-eclipse-plugin/artifactId
 configuration
   pdetrue/pde
 /configuration
   /plugin
   plugin
 groupIdorg.apache.felix/groupId
 artifactIdmaven-bundle-plugin/artifactId
 version1.4.3/version
 extensionstrue/extensions
 configuration
 unpackBundletrue/unpackBundle
   manifestLocationMETA-INF/manifestLocation
   instructions
 Bundle-Version${pom.version}/Bundle-Version
 Bundle-Name${artifactId}/Bundle-Name
 Bundle-SymbolicName${artifactId}/Bundle-SymbolicName
 Bundle-DescriptionSoakit
  Core Bundle/Bundle-Description
 
  Bundle-Activatorcom.gestalt.soakit.core.CoreActivator/Bundle-Activator
 
  

[REPORT] Apache Felix

2008-09-12 Thread Richard S. Hall

Apache Felix Board Report

Community

   * Presented iPOJO at the OSGi Community Event in Berlin in June.
   * Added committers Edward Yakop and Makas Lau for Log Service
 contribution.
   * Received a contribution from Dieter Wimberger for a bundle that
 provides simple remote telnet access to the Felix shell.
   * Receiving web site documentation contributions from Richard
 Jackson; Richard has been granted karma to modify the wiki for his
 contributions.

Software

   * Still working on incorporating the new Log Service contribution
 from PAX; largely delayed due to a naming issue and lack of time.
   * Release version 1.2.0 of Felix (includes Framework 1.2.0, Main
 1.2.0, Shell 1.0.2, Shell TUI 1.0.2, Bundle Repository 1.2.0).
 This release marks the first steps toward bundle fragment support
 in Felix, which is one of the last major hurdles to full OSGi R4
 specification compliance; however, there is still plenty of work
 to be done to complete this feature.
   * Released various other subprojects (e.g., iPOJO, UPnP, SCR, Maven
 SCR Plugin, Maven Bundle Plugin, File Install).
   * Working on creating an official bundle repository to make it
 easier for the community to use subprojects.

Licensing and other issues

   * None.



[jira] Commented: (FELIX-723) ArrayIndexOutOfBoundsException in aQute.lib.osgi.Clazz.parseClassFile

2008-09-12 Thread Stuart McCulloch (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12630583#action_12630583
 ] 

Stuart McCulloch commented on FELIX-723:


OK, here's a much simpler testcase pom that shows the same bug:

?xml version=1.0 encoding=UTF-8?
project xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; 
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/maven-v4_0_0.xsd; 
xmlns=http://maven.apache.org/POM/4.0.0;

  modelVersion4.0.0/modelVersion

  groupIdexamples/groupId
  artifactIdcom.ibm.icu.icu4j/artifactId
  version2.6.1/version

  packagingbundle/packaging

  build
plugins
  plugin
groupIdorg.apache.felix/groupId
artifactIdmaven-bundle-plugin/artifactId
version1.4.3/version
extensionstrue/extensions
configuration
  instructions
Private-Package*/Private-Package
  /instructions
/configuration
  /plugin
/plugins
  /build

  dependencies
dependency
  groupIdcom.ibm.icu/groupId
  artifactIdicu4j/artifactId
  version2.6.1/version
/dependency
  /dependencies

/project


 ArrayIndexOutOfBoundsException in aQute.lib.osgi.Clazz.parseClassFile
 -

 Key: FELIX-723
 URL: https://issues.apache.org/jira/browse/FELIX-723
 Project: Felix
  Issue Type: Bug
  Components: Maven Bundle Plugin
 Environment: MacOSX
Reporter: Brad Cox

  I integrated the recommended changes (pom enclosed below) but that
  com.ibm.icu error turned up again. Bad chinese locale class out there
  somewhere? com/ibm/icu/impl/data/LocaleElements_zh__PINYIN.class.
 Seems to be triggered by  
 Embed-Dependency*;scope=compile|runtime;inline=true/Embed-Dependency. 
 At least removing that eliminates the symptom.
 I'll work towards a small test case once I understand this a bit better. 
 This bug is ephemeral so I want to capture what I have first.
 I tried erasing it in .m2 but that didn't help. POM and stacktrace below
 ?xml version=1.0 encoding=UTF-8?
  project
 xmlns=http://maven.apache.org/POM/4.0.0;
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
  http://maven.apache.org/maven-v4_0_0.xsd;
   
   modelVersion4.0.0/modelVersion
   groupIdsoakit/groupId
   artifactIdsoakit.core/artifactId
   version1.0-SNAPSHOT/version
   namesoakit.core/name
   descriptionSoaKit Core Abstraction Layer. Defines interfaces and
  abstract classes for the components defined in sub-modules. Provides a
  service (factory class) for defining soakit composites with an XML
  configuration file./description
 
   packagingbundle/packaging
 
   parent
 groupIdsoakit/groupId
 artifactIdsoakit/artifactId
 version1.0-SNAPSHOT/version
   /parent
 
   dependencies
 dependency
   groupIdcommons-collections/groupId
   artifactIdcommons-collections/artifactId
   version3.2/version
 /dependency
 dependency
 groupIdjdom/groupId
 artifactIdjdom/artifactId
 version1.0/version
 /dependency
 !--
 dependency
 groupIdjavax.xml.parsers/groupId
 artifactIdjaxp-api/artifactId
 version1.4/version
 /dependency
 dependency
 groupIdjavax.xml.ws/groupId
 artifactIdjaxws-api/artifactId
 version2.1-1/version
 /dependency
 dependency
 groupIdxerces/groupId
 artifactIdxercesImpl/artifactId
 version2.8.1/version
 /dependency
  dependency
 groupIdorg.eclipse/groupId
 artifactIdosgi/artifactId
 version3.4.0.v20080605-1900/version
 /dependency
 dependency
 groupIdjaxen/groupId
 artifactIdjaxen/artifactId
   version1.1-beta-9/version
 /dependency
 --
   /dependencies
 
   build
 resources
   resource
 directorysrc/main/resources/directory
   /resource
   resource
 directory./directory
 includes
   includeplugin.xml/include
 /includes
   /resource
 /resources
 
 plugins
 plugin
 artifactIdmaven-eclipse-plugin/artifactId
 configuration
   pdetrue/pde
 /configuration
   /plugin
   plugin
 groupIdorg.apache.felix/groupId
 artifactIdmaven-bundle-plugin/artifactId
 

[jira] Assigned: (FELIX-722) Can't manage split packages with Require-Bundle header

2008-09-12 Thread Richard S. Hall (JIRA)

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

Richard S. Hall reassigned FELIX-722:
-

Assignee: Richard S. Hall

 Can't manage split packages with Require-Bundle header
 --

 Key: FELIX-722
 URL: https://issues.apache.org/jira/browse/FELIX-722
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: felix-1.2.1

 Environment: Linux
Reporter: Pierre De Rop
Assignee: Richard S. Hall
Priority: Minor
 Fix For: felix-1.2.1


 Attachments: test-splitpackage.tgz


 Attached to this post a sample code which tries to manage split packages with 
 the
 Require-Bundle header. 
 It does not work with felix 1.2.1 (but sounds like working with knoperfish).
 Please have a look at the following felix forum post:
 http://www.mail-archive.com/[EMAIL PROTECTED]/msg02044.html

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



[jira] Assigned: (FELIX-723) ArrayIndexOutOfBoundsException in aQute.lib.osgi.Clazz.parseClassFile

2008-09-12 Thread Stuart McCulloch (JIRA)

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

Stuart McCulloch reassigned FELIX-723:
--

Assignee: Peter Kriens

Hi Peter - do you have any time to look into this?  it's either a bad classfile 
or a bug in the BND classfile parser...

 ArrayIndexOutOfBoundsException in aQute.lib.osgi.Clazz.parseClassFile
 -

 Key: FELIX-723
 URL: https://issues.apache.org/jira/browse/FELIX-723
 Project: Felix
  Issue Type: Bug
  Components: Maven Bundle Plugin
 Environment: MacOSX
Reporter: Brad Cox
Assignee: Peter Kriens

  I integrated the recommended changes (pom enclosed below) but that
  com.ibm.icu error turned up again. Bad chinese locale class out there
  somewhere? com/ibm/icu/impl/data/LocaleElements_zh__PINYIN.class.
 Seems to be triggered by  
 Embed-Dependency*;scope=compile|runtime;inline=true/Embed-Dependency. 
 At least removing that eliminates the symptom.
 I'll work towards a small test case once I understand this a bit better. 
 This bug is ephemeral so I want to capture what I have first.
 I tried erasing it in .m2 but that didn't help. POM and stacktrace below
 ?xml version=1.0 encoding=UTF-8?
  project
 xmlns=http://maven.apache.org/POM/4.0.0;
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
  http://maven.apache.org/maven-v4_0_0.xsd;
   
   modelVersion4.0.0/modelVersion
   groupIdsoakit/groupId
   artifactIdsoakit.core/artifactId
   version1.0-SNAPSHOT/version
   namesoakit.core/name
   descriptionSoaKit Core Abstraction Layer. Defines interfaces and
  abstract classes for the components defined in sub-modules. Provides a
  service (factory class) for defining soakit composites with an XML
  configuration file./description
 
   packagingbundle/packaging
 
   parent
 groupIdsoakit/groupId
 artifactIdsoakit/artifactId
 version1.0-SNAPSHOT/version
   /parent
 
   dependencies
 dependency
   groupIdcommons-collections/groupId
   artifactIdcommons-collections/artifactId
   version3.2/version
 /dependency
 dependency
 groupIdjdom/groupId
 artifactIdjdom/artifactId
 version1.0/version
 /dependency
 !--
 dependency
 groupIdjavax.xml.parsers/groupId
 artifactIdjaxp-api/artifactId
 version1.4/version
 /dependency
 dependency
 groupIdjavax.xml.ws/groupId
 artifactIdjaxws-api/artifactId
 version2.1-1/version
 /dependency
 dependency
 groupIdxerces/groupId
 artifactIdxercesImpl/artifactId
 version2.8.1/version
 /dependency
  dependency
 groupIdorg.eclipse/groupId
 artifactIdosgi/artifactId
 version3.4.0.v20080605-1900/version
 /dependency
 dependency
 groupIdjaxen/groupId
 artifactIdjaxen/artifactId
   version1.1-beta-9/version
 /dependency
 --
   /dependencies
 
   build
 resources
   resource
 directorysrc/main/resources/directory
   /resource
   resource
 directory./directory
 includes
   includeplugin.xml/include
 /includes
   /resource
 /resources
 
 plugins
 plugin
 artifactIdmaven-eclipse-plugin/artifactId
 configuration
   pdetrue/pde
 /configuration
   /plugin
   plugin
 groupIdorg.apache.felix/groupId
 artifactIdmaven-bundle-plugin/artifactId
 version1.4.3/version
 extensionstrue/extensions
 configuration
 unpackBundletrue/unpackBundle
   manifestLocationMETA-INF/manifestLocation
   instructions
 Bundle-Version${pom.version}/Bundle-Version
 Bundle-Name${artifactId}/Bundle-Name
 Bundle-SymbolicName${artifactId}/Bundle-SymbolicName
 Bundle-DescriptionSoakit
  Core Bundle/Bundle-Description
 
  Bundle-Activatorcom.gestalt.soakit.core.CoreActivator/Bundle-Activator
 
  Embed-Dependency*;scope=compile|runtime;inline=true/Embed-Dependency
 
   Embed-Transitivetrue/Embed-Transitive
 Embed-Directorytarget/dependency/Embed-Directory
 
  Bundle-RequiredExecutionEnvironmentJ2SE-1.5/Bundle-RequiredExecutionEnvironment
 

[jira] Resolved: (FELIX-721) NPE in FilterImpl.toString()

2008-09-12 Thread Karl Pauls (JIRA)

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

Karl Pauls resolved FELIX-721.
--

Resolution: Fixed

Fixed in trunk as of revision 694713. Please close this issue if it works for 
you.

 NPE in FilterImpl.toString()
 

 Key: FELIX-721
 URL: https://issues.apache.org/jira/browse/FELIX-721
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: felix-1.0.4
Reporter: Don Brown
 Attachments: ldap.patch


 We see this NPE occasionally, probably 10% of the time on application startup:
  [java] java.lang.NullPointerException
  [java] at 
 org.apache.felix.framework.util.ldap.Parser$AndOperator.toStringInfix(Parser.java:601)
  [java] at 
 org.apache.felix.framework.util.ldap.Evaluator.toStringInfix(Evaluator.java:184)
  [java] at 
 org.apache.felix.framework.FilterImpl.toString(FilterImpl.java:242)
  [java] at java.lang.String.valueOf(String.java:2615)
  [java] at java.lang.StringBuffer.append(StringBuffer.java:220)
  [java] at 
 org.springframework.osgi.service.importer.DefaultOsgiServiceDependency.init(DefaultOsgiServiceDependency.java:52)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.MandatoryImporterDependencyFactory.getServiceDependencies(MandatoryImporterDependencyFactory.java:69)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.DependencyServiceManager.findServiceDependencies(DependencyServiceManager.java:233)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.stageOne(DependencyWaiterApplicationContextExecutor.java:248)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.refresh(DependencyWaiterApplicationContextExecutor.java:172)
  [java] at 
 org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.refresh(AbstractDelegatedExecutionApplicationContext.java:136)
  [java] at 
 org.springframework.osgi.extender.internal.activator.ContextLoaderListener$2.run(ContextLoaderListener.java:746)
  [java] at java.lang.Thread.run(Thread.java:613)
 My first guess would be we are constructing a filter improperly in our Spring 
 config, but the fact that it only happens some of the time is strange.  If 
 nothing else, it would be nice if this bit of code was a bit more defensive.

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



[jira] Updated: (FELIX-721) NPE in FilterImpl.toString()

2008-09-12 Thread Karl Pauls (JIRA)

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

Karl Pauls updated FELIX-721:
-

Assignee: Karl Pauls

 NPE in FilterImpl.toString()
 

 Key: FELIX-721
 URL: https://issues.apache.org/jira/browse/FELIX-721
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: felix-1.0.4
Reporter: Don Brown
Assignee: Karl Pauls
 Attachments: ldap.patch


 We see this NPE occasionally, probably 10% of the time on application startup:
  [java] java.lang.NullPointerException
  [java] at 
 org.apache.felix.framework.util.ldap.Parser$AndOperator.toStringInfix(Parser.java:601)
  [java] at 
 org.apache.felix.framework.util.ldap.Evaluator.toStringInfix(Evaluator.java:184)
  [java] at 
 org.apache.felix.framework.FilterImpl.toString(FilterImpl.java:242)
  [java] at java.lang.String.valueOf(String.java:2615)
  [java] at java.lang.StringBuffer.append(StringBuffer.java:220)
  [java] at 
 org.springframework.osgi.service.importer.DefaultOsgiServiceDependency.init(DefaultOsgiServiceDependency.java:52)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.MandatoryImporterDependencyFactory.getServiceDependencies(MandatoryImporterDependencyFactory.java:69)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.DependencyServiceManager.findServiceDependencies(DependencyServiceManager.java:233)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.stageOne(DependencyWaiterApplicationContextExecutor.java:248)
  [java] at 
 org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.refresh(DependencyWaiterApplicationContextExecutor.java:172)
  [java] at 
 org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.refresh(AbstractDelegatedExecutionApplicationContext.java:136)
  [java] at 
 org.springframework.osgi.extender.internal.activator.ContextLoaderListener$2.run(ContextLoaderListener.java:746)
  [java] at java.lang.Thread.run(Thread.java:613)
 My first guess would be we are constructing a filter improperly in our Spring 
 config, but the fact that it only happens some of the time is strange.  If 
 nothing else, it would be nice if this bit of code was a bit more defensive.

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



Re: web console multi file upload and install

2008-09-12 Thread Roger Martin
Hi Felix,

It is solely in the client side javascript and using flash.  The FancyUpload
builds a hidden queue in the DOM and then sends them one by one back to the
server as if the user did it.

I was hoping to hear more from Rob.

Planning on creating a patch.  There were a couple of JavaScript variable
collisions I need to work out and also test on more than Firefox...

On Wed, Sep 10, 2008 at 2:50 PM, Felix Meschberger [EMAIL PROTECTED]wrote:

 Hi Roger,

 Roger Martin schrieb:
  Hi Felix developers,
 
  In my local Felix development  I've been testing different ways to
  change the web console to allow multiple files to be dragged from an
  OS folder and upload them via the Apache Felix Web Management
  Console.  After searching, testing and running into many obsolete
  documentations in this murky territory I found the FancyUpload by
  http://digitarald.de/project/fancyupload/1-0/ works using a flash
  method.  My first case, Firefox is working and I got all the other
  noted browsers queued up for testing. FancyUpload has an MIT license
  (http://www.opensource.org/licenses/mit-license.php).
 
  If this feature is of interest, is the license ok?

 I would be interested in seeing a patch, yes, of course ;-)

 I assume beside the client side, you also had to modify the server side
 to accept multiple files, right ?

 
  Is there another preferred technology I should test?

 I have no preference of course.

 Regards
 Felix

 
  Also I know that Glassfish is possibly remodeling to fit the Felix
  console in with the Glassfish Admin Console; perhaps this may fit
  there?  Although I know that there are many profiles I as a Felix user
  like to set up independent of glassfish for testing.  Each of these
  profiles are very much like a unit test for scenarios involving a
  subset of the composite apps I'm working on.  So a way to quickly set
  them up via multi file upload and install works for me.  Perhaps for
  others as well.
 



ipojo event admin handler

2008-09-12 Thread anne.gerodolle
Hi everybody,

is there any plan to release the ipojo event admin handler bunlde, or at
least to make it available on an OBR ? I've notices it was not released
with ipojo 0.8.0 .

regarding namespaces, some handlers use the
org.apache.felix.ipojo.handlers prefix, other
org.apache.felix.ipojo.handler (without s). Maybe this could be
harmonized.

Regards,

Anne


[jira] Updated: (FELIX-713) Add support for Bundle.start(int)

2008-09-12 Thread Sahoo (JIRA)

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

Sahoo updated FELIX-713:


Attachment: Felix-713.zip

This patch adds supports for Bundle.start(START_TRANSIENT) and 
Bundle.stop(STOP_TRANSIENT).

Attached zip file contains the following files:

patch/new - contains changed .java files
patch/diff  - contains svn diff output
testcases   - contains a couple of test cases to test start/stop method 
behavior.

I have not tested the update code path after making this change. 

 Add support for Bundle.start(int)
 -

 Key: FELIX-713
 URL: https://issues.apache.org/jira/browse/FELIX-713
 Project: Felix
  Issue Type: New Feature
  Components: Framework
Affects Versions: felix-1.2.1

 Environment: NA
Reporter: Sahoo
 Attachments: Felix-713.zip


 I would like Felix to support for Bundle.start(int), which is introduced in 
 OSGi R4, version 4.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-722) Can't manage split packages with Require-Bundle header

2008-09-12 Thread Richard S. Hall (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12630642#action_12630642
 ] 

Richard S. Hall commented on FELIX-722:
---

I think I have gotten to the bottom of this, but I uncovered another issue that 
I now need to address first. Expect a fix before long.

 Can't manage split packages with Require-Bundle header
 --

 Key: FELIX-722
 URL: https://issues.apache.org/jira/browse/FELIX-722
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: felix-1.2.1

 Environment: Linux
Reporter: Pierre De Rop
Assignee: Richard S. Hall
Priority: Minor
 Fix For: felix-1.2.1


 Attachments: test-splitpackage.tgz


 Attached to this post a sample code which tries to manage split packages with 
 the
 Require-Bundle header. 
 It does not work with felix 1.2.1 (but sounds like working with knoperfish).
 Please have a look at the following felix forum post:
 http://www.mail-archive.com/[EMAIL PROTECTED]/msg02044.html

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



[jira] Created: (FELIX-724) Dynamic imports should not be searched if the bundle already has required or exported the package

2008-09-12 Thread Richard S. Hall (JIRA)
Dynamic imports should not be searched if the bundle already has required or 
exported the package
-

 Key: FELIX-724
 URL: https://issues.apache.org/jira/browse/FELIX-724
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: felix-1.2.1

Reporter: Richard S. Hall
Assignee: Richard S. Hall


When search for a class, we search a bundle's imports, then required bundles, 
then content, and finally its dynamic imports. Currently, dynamic imports are 
not search only if we have an import for the specific package; however, we 
should also not search dynamic imports if the package is visible in a 
require-bundle or export either, otherwise we allow splitting across to an 
import, which is not correct.

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



[jira] Updated: (FELIX-722) Can't manage split packages with Require-Bundle header

2008-09-12 Thread Richard S. Hall (JIRA)

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

Richard S. Hall updated FELIX-722:
--

Fix Version/s: (was: felix-1.2.1
)

 Can't manage split packages with Require-Bundle header
 --

 Key: FELIX-722
 URL: https://issues.apache.org/jira/browse/FELIX-722
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: felix-1.2.1

 Environment: Linux
Reporter: Pierre De Rop
Assignee: Richard S. Hall
Priority: Minor
 Attachments: test-splitpackage.tgz


 Attached to this post a sample code which tries to manage split packages with 
 the
 Require-Bundle header. 
 It does not work with felix 1.2.1 (but sounds like working with knoperfish).
 Please have a look at the following felix forum post:
 http://www.mail-archive.com/[EMAIL PROTECTED]/msg02044.html

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



[jira] Updated: (FELIX-713) Add support for Bundle.start(int)

2008-09-12 Thread Richard S. Hall (JIRA)

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

Richard S. Hall updated FELIX-713:
--

Fix Version/s: felix-1.2.2

 Add support for Bundle.start(int)
 -

 Key: FELIX-713
 URL: https://issues.apache.org/jira/browse/FELIX-713
 Project: Felix
  Issue Type: New Feature
  Components: Framework
Affects Versions: felix-1.2.1

 Environment: NA
Reporter: Sahoo
 Fix For: felix-1.2.2

 Attachments: Felix-713.zip


 I would like Felix to support for Bundle.start(int), which is introduced in 
 OSGi R4, version 4.1.

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



[jira] Updated: (FELIX-722) Can't manage split packages with Require-Bundle header

2008-09-12 Thread Richard S. Hall (JIRA)

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

Richard S. Hall updated FELIX-722:
--

Fix Version/s: felix-1.2.2

 Can't manage split packages with Require-Bundle header
 --

 Key: FELIX-722
 URL: https://issues.apache.org/jira/browse/FELIX-722
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: felix-1.2.1

 Environment: Linux
Reporter: Pierre De Rop
Assignee: Richard S. Hall
Priority: Minor
 Fix For: felix-1.2.2

 Attachments: test-splitpackage.tgz


 Attached to this post a sample code which tries to manage split packages with 
 the
 Require-Bundle header. 
 It does not work with felix 1.2.1 (but sounds like working with knoperfish).
 Please have a look at the following felix forum post:
 http://www.mail-archive.com/[EMAIL PROTECTED]/msg02044.html

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



[jira] Updated: (FELIX-724) Dynamic imports should not be searched if the bundle already has required or exported the package

2008-09-12 Thread Richard S. Hall (JIRA)

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

Richard S. Hall updated FELIX-724:
--

Description: When searching for a class, we search a bundle's imports, then 
required bundles, then content, and finally its dynamic imports. Currently, 
dynamic imports are not searched if we have an import for the specific package; 
however, we should also not search dynamic imports if the package is visible in 
a require-bundle or export as well, otherwise we allow splitting across to an 
import, which is not correct.  (was: When search for a class, we search a 
bundle's imports, then required bundles, then content, and finally its dynamic 
imports. Currently, dynamic imports are not search only if we have an import 
for the specific package; however, we should also not search dynamic imports if 
the package is visible in a require-bundle or export either, otherwise we allow 
splitting across to an import, which is not correct.)

 Dynamic imports should not be searched if the bundle already has required or 
 exported the package
 -

 Key: FELIX-724
 URL: https://issues.apache.org/jira/browse/FELIX-724
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: felix-1.2.1

Reporter: Richard S. Hall
Assignee: Richard S. Hall
 Fix For: felix-1.2.2


 When searching for a class, we search a bundle's imports, then required 
 bundles, then content, and finally its dynamic imports. Currently, dynamic 
 imports are not searched if we have an import for the specific package; 
 however, we should also not search dynamic imports if the package is visible 
 in a require-bundle or export as well, otherwise we allow splitting across to 
 an import, which is not correct.

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



[jira] Created: (FELIX-725) Make fragment install exception configurable

2008-09-12 Thread Richard S. Hall (JIRA)
Make fragment install exception configurable


 Key: FELIX-725
 URL: https://issues.apache.org/jira/browse/FELIX-725
 Project: Felix
  Issue Type: Improvement
  Components: Framework
Affects Versions: felix-1.2.1

Reporter: Richard S. Hall
Assignee: Richard S. Hall
 Fix For: felix-1.2.2


When we install a fragment that uses features we do not support, currently we 
throw an exception where previously we just ignored it. We should make the 
exception configurable.

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



[jira] Closed: (FELIX-725) Make fragment install exception configurable

2008-09-12 Thread Richard S. Hall (JIRA)

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

Richard S. Hall closed FELIX-725.
-

Resolution: Fixed

Introduced a new configuration property called 'felix.fragment.validation' 
which can have the value 'exception' or 'warning' with the default of 
'exception'. This can be used to control whether installing a fragment that 
uses unimplemented features throws an exception or logs a warning.

 Make fragment install exception configurable
 

 Key: FELIX-725
 URL: https://issues.apache.org/jira/browse/FELIX-725
 Project: Felix
  Issue Type: Improvement
  Components: Framework
Affects Versions: felix-1.2.1

Reporter: Richard S. Hall
Assignee: Richard S. Hall
 Fix For: felix-1.2.2


 When we install a fragment that uses features we do not support, currently we 
 throw an exception where previously we just ignored it. We should make the 
 exception configurable.

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



Re: Fragment support 1.0.4 to 1.2 doesn't Import classes

2008-09-12 Thread Richard S. Hall

Daniel,

I just applied a patch to trunk that makes the fragment install 
exception configurable. For details:


   https://issues.apache.org/jira/browse/FELIX-725

I have deployed a new maven snapshot or you can build from trunk if you 
want to use it.


- richard

Daniel Rubio wrote:


I hadn't actually tried to upgrade until now, and since some of the 
bundles I was using were libraries (apache tomcat, jasper 
compiler,etc) I didn't realize they were fragments until I got this 
message testing on 1.2!


I believe ignoring fragments in 1.0.4 - or the Fragment-Host directive 
- simply processed the Import-Package statement and made the fragments 
classes available as if they were a normal bundle, so that's why it 
worked
 Inclusively I removed the Fragment-Host from the bundle and the app 
works in 1.2, so I'm also realizing what is packaged as a fragment 
didn't actually require being a full-fledged fragment, go figure, but 
that's for the one's OSGi'fying bundles...


  I guess we will leave 1.0.4 in place. If a new release comes out 
before the last draft revision, that warns about fragments but still 
loads classes 'as if it were a normal bundle' then I will use that ;) 
otherwise I will just put a note.


  Don't know what the consequence/side effects may be, in my app there 
didn't seem to be trouble converting a fragment to a bundle just to 
Import its classes an run the app successfully in 1.2...though there 
might be trouble in some 'well-designed fragments' that do require not 
just importing classes but the whole functionality required by the 
fragment spec (but I guess that's where the warning comes in :-)  ).




Richard S. Hall wrote:

Argh!

Yes, we probably should have made that configurable. Where were you 
when I was asking about throwing an exception on fragment install? ;-)


I guess the short answer is no, there is no way to change it. You 
have two options at this point:


  1. Roll your own release that disables the exception (pretty easy to
 do, I guess I might actually be able to make this configurable in
 trunk and create a new snapshot that will eventually become 1.2.2
 and you could use that for the time being).
  2. Keep using 1.0.4 until we do another release that makes this
 configurable.

I don't see any reason why we couldn't make this configurable, 
perhaps someone sees something that I don't. The fact that your apps 
worked at all before I guess was just luck, since we ignored 
fragments altogether in 1.0.4.


- richard

Daniel Rubio (OSGI Mailing List) wrote:
I just upgraded to Felix 1.2+ from 1.0.4, only to realize some of my 
(library) bundles are fragments.


I'm getting a warning that in 1.2 there is partial support for 
fragments, which I of course appreciate. However, the application 
now ceases to work since it apparently doesn't import any classes in 
the fragment
Is there some way to get things to work as in 1.0.4 and get the 
warning ?
I realize full support for fragments may be well down the road, but 
is there any plan for a release like 1.0.4 (import class from the 
fragment ) and getting a warning ?


Thanks for any information on the subject.
Daniel Rubio
P.S- I realize the simple answer is keep using 1.0.4, but the reason 
for my question is because I'm in the process of writing a book (for 
Apress on Spring-OSGi) which is using Apache Felix, and some things 
are already based on the v.1.0.4 and the upgrade to the newer v.1.2 
breaks a few of the apps.