Re: java 7 osgi core & compendium

2012-11-01 Thread Andrei Pozolotin 
JB: great, thank you!

also:

since migration to R5 will probably be as painful as this one, I suggest
to have more properties, such as

org.osgi
4.3.1
4.3.1
org.osgi.core
   
org.osgi.compendium

and to make switch between osgi releases controlled via maven profile(s)

 Original Message 
Subject: Re: java 7 osgi core & compendium
From: Jean-Baptiste Onofré 
To: Andrei Pozolotin 
Cc: Felix Dev , Karaf Dev 
Date: Thu 01 Nov 2012 11:51:51 AM CDT
> Hi,
>
> I will work on it tonight.
> I keep you posted.
>
> Regards
> JB
>
> On 11/01/2012 05:50 PM, Andrei Pozolotin wrote:
>> JB:
>>
>> https://www.osgi.org/bugzilla/show_bug.cgi?id=153
>>
>> I tried to migrate karaf trunk to new osgi 4.3.1
>> https://github.com/carrot-garden/carrot-apache-karaf/tree/osgi-4.3.1
>>
>> so far compile fails. I hope JB has better luck.
>>
>>
>>  Original Message 
>> Subject: Re: java 7 osgi core & compendium
>> From: Jean-Baptiste Onofré 
>> To: dev@felix.apache.org
>> Date: Tue 30 Oct 2012 05:26:53 AM CDT
>>> Thanks David,
>>>
>>> I gonna make a try in Karaf.
>>>
>>> I keep you posted.
>>>
>>> Regards
>>> JB
>>>
>>> On 10/30/2012 11:24 AM, David Bosschaert wrote:
 I've uploaded the 4.3.1 jars to the Maven Central staging area. It
 would be great if someone could check that they are indeed working
 fine and properly signed.

 See: https://www.osgi.org/bugzilla/show_bug.cgi?id=153#c13

 Thanks,

 David

 On 8 October 2012 20:45, Andrei Pozolotin
  wrote:
> David:
>
> great! thank you.
>
> I answered back on https://www.osgi.org/bugzilla/show_bug.cgi?id=153
>
> Andrei.
>
>
>  Original Message 
> Subject: Re: java 7 osgi core & compendium
> From: David Bosschaert 
> To: dev@felix.apache.org
> Date: Mon 08 Oct 2012 03:05:18 AM CDT
>
> Hi Andrei,
>
> I left a comment on that bug and reassigned it to me, as I have been
> the one who uploaded OSGi Artifacts to Maven in the recent past.
> I would be happy to help getting OSGi 4.3 artifacts in maven that
> work
> with Java 7.
>
> Best regards,
>
> David
>
> On 5 October 2012 20:03, Andrei Pozolotin
> 
> wrote:
>
>  *Felix and Jean-Baptiste*:
>
>  since osgi alliance does not want to take responsibility for
> this
> https://www.osgi.org/bugzilla/show_bug.cgi?id=153
>
>  1) do you think it would be appropriate for felix or karaf to
> step in,
>  and to produce and maintain shared java 7 osgi core & compendium
>  jars for all of us?
>
>  2) or else should everyone continue to bake their own?
>
>  3) if shared, can you agree who should lead?
>
>  Thank you,
>
>  Andrei
>
>
>>>
>>
>

Re: java 7 osgi core & compendium

2012-11-01 Thread Jean-Baptiste Onofré 

Hi,

I will work on it tonight.
I keep you posted.

Regards
JB

On 11/01/2012 05:50 PM, Andrei Pozolotin wrote:

JB:

https://www.osgi.org/bugzilla/show_bug.cgi?id=153

I tried to migrate karaf trunk to new osgi 4.3.1
https://github.com/carrot-garden/carrot-apache-karaf/tree/osgi-4.3.1

so far compile fails. I hope JB has better luck.


 Original Message 
Subject: Re: java 7 osgi core & compendium
From: Jean-Baptiste Onofré 
To: dev@felix.apache.org
Date: Tue 30 Oct 2012 05:26:53 AM CDT

Thanks David,

I gonna make a try in Karaf.

I keep you posted.

Regards
JB

On 10/30/2012 11:24 AM, David Bosschaert wrote:

I've uploaded the 4.3.1 jars to the Maven Central staging area. It
would be great if someone could check that they are indeed working
fine and properly signed.

See: https://www.osgi.org/bugzilla/show_bug.cgi?id=153#c13

Thanks,

David

On 8 October 2012 20:45, Andrei Pozolotin
 wrote:

David:

great! thank you.

I answered back on https://www.osgi.org/bugzilla/show_bug.cgi?id=153

Andrei.


 Original Message 
Subject: Re: java 7 osgi core & compendium
From: David Bosschaert 
To: dev@felix.apache.org
Date: Mon 08 Oct 2012 03:05:18 AM CDT

Hi Andrei,

I left a comment on that bug and reassigned it to me, as I have been
the one who uploaded OSGi Artifacts to Maven in the recent past.
I would be happy to help getting OSGi 4.3 artifacts in maven that work
with Java 7.

Best regards,

David

On 5 October 2012 20:03, Andrei Pozolotin 
wrote:

 *Felix and Jean-Baptiste*:

 since osgi alliance does not want to take responsibility for this
https://www.osgi.org/bugzilla/show_bug.cgi?id=153

 1) do you think it would be appropriate for felix or karaf to
step in,
 and to produce and maintain shared java 7 osgi core & compendium
 jars for all of us?

 2) or else should everyone continue to bake their own?

 3) if shared, can you agree who should lead?

 Thank you,

 Andrei








--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: java 7 osgi core & compendium

2012-11-01 Thread Andrei Pozolotin 
JB:

https://www.osgi.org/bugzilla/show_bug.cgi?id=153

I tried to migrate karaf trunk to new osgi 4.3.1
https://github.com/carrot-garden/carrot-apache-karaf/tree/osgi-4.3.1

so far compile fails. I hope JB has better luck.


 Original Message 
Subject: Re: java 7 osgi core & compendium
From: Jean-Baptiste Onofré 
To: dev@felix.apache.org
Date: Tue 30 Oct 2012 05:26:53 AM CDT
> Thanks David,
>
> I gonna make a try in Karaf.
>
> I keep you posted.
>
> Regards
> JB
>
> On 10/30/2012 11:24 AM, David Bosschaert wrote:
>> I've uploaded the 4.3.1 jars to the Maven Central staging area. It
>> would be great if someone could check that they are indeed working
>> fine and properly signed.
>>
>> See: https://www.osgi.org/bugzilla/show_bug.cgi?id=153#c13
>>
>> Thanks,
>>
>> David
>>
>> On 8 October 2012 20:45, Andrei Pozolotin
>>  wrote:
>>> David:
>>>
>>> great! thank you.
>>>
>>> I answered back on https://www.osgi.org/bugzilla/show_bug.cgi?id=153
>>>
>>> Andrei.
>>>
>>>
>>>  Original Message 
>>> Subject: Re: java 7 osgi core & compendium
>>> From: David Bosschaert 
>>> To: dev@felix.apache.org
>>> Date: Mon 08 Oct 2012 03:05:18 AM CDT
>>>
>>> Hi Andrei,
>>>
>>> I left a comment on that bug and reassigned it to me, as I have been
>>> the one who uploaded OSGi Artifacts to Maven in the recent past.
>>> I would be happy to help getting OSGi 4.3 artifacts in maven that work
>>> with Java 7.
>>>
>>> Best regards,
>>>
>>> David
>>>
>>> On 5 October 2012 20:03, Andrei Pozolotin 
>>> wrote:
>>>
>>>  *Felix and Jean-Baptiste*:
>>>
>>>  since osgi alliance does not want to take responsibility for this
>>>  https://www.osgi.org/bugzilla/show_bug.cgi?id=153
>>>
>>>  1) do you think it would be appropriate for felix or karaf to
>>> step in,
>>>  and to produce and maintain shared java 7 osgi core & compendium
>>>  jars for all of us?
>>>
>>>  2) or else should everyone continue to bake their own?
>>>
>>>  3) if shared, can you agree who should lead?
>>>
>>>  Thank you,
>>>
>>>  Andrei
>>>
>>>
>

[jira] [Commented] (FELIX-3739) scr-plugin: "Annotated method {0} not found"

2012-11-01 Thread Johannes Schneider (JIRA) 

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

Johannes Schneider commented on FELIX-3739:
---

Can u give me a hint where the SNAPSHOTS are deployed to?

https://repository.apache.org/content/groups/snapshots/org/apache/felix/maven-scr-plugin/
 seems to be the wrong place

> scr-plugin: "Annotated method {0} not found"
> 
>
> Key: FELIX-3739
> URL: https://issues.apache.org/jira/browse/FELIX-3739
> Project: Felix
>  Issue Type: Bug
>  Components: Maven SCR Plugin
>Affects Versions: maven-scr-plugin-1.8.0, scr ant task 1.2.0, scr 
> generator 1.2.0
> Environment: Linux, Maven 3, Java 7
>Reporter: Johannes Schneider
>Assignee: Carsten Ziegeler
> Fix For: maven-scr-plugin-1.8.2, scr ant task 1.2.2, scr 
> generator 1.2.2
>
>
> I run in to that[1] problem.
> The method that is not found looks like that:
> > @Nonnull public static  Entry create( @Nonnull T
> > object,
> @Nonnull >byte[] expected ) {
> > }
> I have debugged this and it comes to that:
> in ClassScanner#237 parameters are compared. The second parameter of
> my method (byte[]) has a strange difference here:
> parameterTypeName: [B
> signature[index].getClassName(): byte[]
> So I think this might be related to the asm usage
> I *think* instead of "signature[index].getClassName()" there should be
> called
> signature[index].getDescriptor()
> Any idea how I could work around that problem (without changing my
> method's signature)?
> Thanks,
> Johannes
> [1]
> [ERROR] Failed to execute goal
> org.apache.felix:maven-scr-plugin:1.8.0:scr
> (generate-scr-scrdescriptor) on project test-utils:
> com.cedarsoft.serialization.test.utils.AbstractSerializerTest2 :
> Annotated method create not found. -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal org.apache.felix:maven-scr-plugin:1.8.0:scr
> (generate-scr-scrdescriptor) on project test-utils:
> com.cedarsoft.serialization.test.utils.AbstractSerializerTest2 :
> Annotated method create not found.
>   at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
>   at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>   at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>   at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
>   at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
>   at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
>   at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:601)
>   at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
>   at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
>   at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
>   at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException:
> com.cedarsoft.serialization.test.utils.AbstractSerializerTest2 :
> Annotated method create not found.
>   at
> org.apache.felix.scrplugin.mojo.SCRDescriptorMojo.execute(SCRDescriptorMojo.java:222)
>   at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
>   at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
>   ... 19 more
> Caused by: org.apache.felix.scrplugin.SCRDescriptorException:
> Annotated method create not found.
>   at
> org.apache.felix.scrplugin.helper.ClassScanner.extractAnnotation(ClassScanner.java:249)
>   at
> org.apache.felix.scrplugin.helper.ClassScanner.processClass(ClassScanner.java:180)
>   at
> org.apache.felix.scrplugin.helper.ClassScanner.scanSources(ClassScanner.java:143)
>   at
> org.apache.felix.scrplugin.S

[RESULT] [VOTE] Release Apache Felix Metatype Service 1.0.6

2012-11-01 Thread Felix Meschberger 
Hi

Time to tally the vote:

  +1 Felix Meschberger*, Jean-Baptiste Onofré, Jeremias Maerki,
 Clement Escoffier*, Carsten Ziegeler*, Pierre De Rop
   0 -
  -1 -

This vote thus passes with  6 +1 (3 of which binding) votes. No other votes 
have been cast.

I will proceed with the publication process.

Regards
Felix

Am 29.10.2012 um 16:54 schrieb Felix Meschberger:

> Hi,
> 
> Here is the Apache Felix Metatype Service 1.0.6 release implementing the most 
> recent MetaType Service Specification Version 1.2.
> 
> The issues completed in this release are listed in the release notes at (also 
> attached at the end of this message):
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12314144
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachefelix-177/
> 
> 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 177 /tmp/felix-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Release
> [ ] -1 Don't release, because ...
> 
> This vote will be open for at least 72 hours.
> 
> Regards
> Felix
> 
> ** Bug
> * [FELIX-2094] - AttributeDefinition with an empty default value
> must attribute must result in a single (empty
> string) entry string array
> * [FELIX-2097] - DefaultMetaTypeProvider.getLocales() must not
> reuturn an empty string entry
> * [FELIX-2860] - getLocales() in DefaultMetaTypeProvider needs
> to check return of findEntries
> * [FELIX-2867] - getIcon() in LocalizedObjectClassDefinition keyset
> iteration incorrect
> * [FELIX-2868] - Icon only works if absolute path specified, but
> specification allows for relative urls
> * [FELIX-3183] - Attribute requirement is not validated
> * [FELIX-3364] - MetaDataReader exposes a private exception class on
> the public API
> * [FELIX-3720] - Designate's pid attribute is optional and not mandatory
> * [FELIX-3730] - AD.validate of string attributes must validate the
> string length
> * [FELIX-3732] - service.pid properties of ManagedServiceFactory services
> must be used as factory PIDs
> * [FELIX-3734] - MetaType: NPE in ServiceTracker for fragment bundle
> ** Improvement
> * [FELIX-3167] - Add support for new PASSWORD attribute type
> * [FELIX-3338] - Add support for optional attributes in the
> MetaDataReader as defined in the XML schema for metatype
> * [FELIX-3736] - Add support for MetaTypeProvider service modifications
> * [FELIX-3740] - Maintain the MetaTypeProvider service tracker on the
> MetaTypeService
> ** New Feature
> * [FELIX-2719] - Add name space support to the meta type implementation
> ** Task
> * [FELIX-2096] - Check MetaTypeProvider.getObjectClassDefinition(String,
> String) specification compliance
> * [FELIX-3182] - Update to use parent POM 2.1
> * [FELIX-3184] - Add support for metatype extension by MetatypeProvider 
> services
> * [FELIX-3731] - Multi-Value service.pid service properties must be supported
> * [FELIX-3733] - Clarify icon location
>

Re: Fwd: [osgi-blog] [OSGi Alliance Blog] 4.3 Companion Code for Java 7

2012-11-01 Thread David Bosschaert 
Hi,

I have prepared these artifacts for upload to Maven Central earlier
this week, but am looking for someone to validate them before I
release them.
See here: http://www.mail-archive.com/dev@felix.apache.org/msg27287.html
and here: http://www.osgi.org/bugzilla/show_bug.cgi?id=153

If someone has a moment to sanity check, please do so and let me know.

Best regards,

David

On 29 October 2012 08:03, Jean-Baptiste Onofré  wrote:
> FYI,
>
> the 4.3.1 artifacts have not yet been deployed on Central.
>
> Regards
> JB
>
>
> On 10/29/2012 09:00 AM, Felix Meschberger wrote:
>>
>> FYI in case you missed it.
>>
>> In short: The OSGi R 4.3 libraries have been recompiled with Java 5 target
>> and republished as version 4.3.1 to maven. So to use OSGi R 4.3 libraries in
>> a Java 5 (and up) environment you should use the 4.3.1 version dependency.
>>
>> Nothing to be done when using older (4.2.0 and before) dependencies
>> because they are compiled for Java 1.4.
>>
>> Regards
>> Felix
>>
>> Anfang der weitergeleiteten E-Mail:
>>
>> Von: BJ Hargrave mailto:b...@bjhargrave.com>>
>> Betreff: [osgi-blog] [OSGi Alliance Blog] 4.3 Companion Code for Java 7
>> Datum: 26. Oktober 2012 21:06:11 MESZ
>> An: "osgi-b...@mail.osgi.org"
>> mailto:osgi-b...@mail.osgi.org>>
>> Antwort an: Private list for OSGi blog discussion
>> mailto:osgi-b...@mail.osgi.org>>
>>
>> Starting in version 4.3, OSGi started to use generics in some of the API
>> including the Core specification. Generics were
>> introduced to the Java
>> language in Java 5. However, OSGi needed to continue to support embedded use
>> cases which use the CDC/Foundation 1.1 runtime which is still based upon the
>> Java 1.4 language level and JVM. To address this issue, OSGi compiled the
>> APIs with -target
>> jsr14;
>> an undocumented javac flag introduced before Java 5 was final. So we had the
>> best of both worlds: we can use generics and still compile to run on Java
>> 1.4 based runtimes.
>>
>> This worked for Java 5 and Java 6. But when Java 7 shipped, two things
>> changed: javac no longer understood the jsr14 option to -target and javac
>> refused to recognize the attributes containing the generics information in
>> class files already compiled with -target jsr14. The change to no longer
>> support creating -target jsr14 class files was ok; we could continue to
>> compile with Java 6 javac. But the change to the javac to cease to recognize
>> the class file attributes with the generics information in existing class
>> files was a bigger problem. It meant that the 4.3 API jars published by OSGi
>> were not useable by people who need to compile with Java 7 javac. By not
>> useable, I mean javac treated the classes as if they did not contain any
>> generics information: they were raw. A
>> bug was filed
>> against Java to see if this was some mistake or oversight. The reply was
>> that the change was intentional.
>>
>> At the time this was first
>> noticed,
>> Java 7 was new and not too widely used. OSGi also included the source code
>> in the jars so you could recompile the code yourself if you needed. Later,
>> when it came time to ship Core R5, we changed to compile the API classes
>> with -target 1.5 and so they work fine on Java 7. So problem solved; the new
>> release's jars don't use -target jsr14! Except some of the current OSGi
>> implementations (I'm looking at you Felix and
>> Karaf) are still based upon Core 4.3 and thus
>> people using those implementations still need to use the Core 4.3 API. And
>> if they also want to use Java 7, they need to recompile the OSGi API source.
>> So after some prodding by a few folks, OSGi rebuilt the Core and Compendium
>> API jars as Core
>> 4.3.1
>> and Compendium 4.3.1
> ile?url=/download/r4v43/osgi.cmpn-4.3.1.jar>. The new jars have the same
> packages at the same package versions having the same API signatures. They
> are just not compiled with -target jsr14 so they work fine with Java 7.
>>
>>
>> So if you need to use the 4.3 API with Java 7, pick up these new 4.3.1
>> jars. They should also be available on
>> maven shortly.
>>
>> --
>> Posted By BJ Hargrave to OSGi Alliance
>> Blog at
>> 10/26/2012 07:06:00 PM ___
>> osgi-blog mailing list
>> osgi-b...@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-blog
>>
>>
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talen

[jira] [Resolved] (FELIX-3743) Potential endless loop setting the active framework startlevel

2012-11-01 Thread Felix Meschberger (JIRA) 

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

Felix Meschberger resolved FELIX-3743.
--

Resolution: Fixed
  Assignee: Felix Meschberger

Committed the patch in Rev. 1404499

This removes uninstalled bundles from the set of bundles to handle.

Another cause for an IllegalStateException thrown from acquiring the bundle 
lock is failure to get the lock. In this case the bundle remains in the set and 
is retried later.

> Potential endless loop setting the active framework startlevel
> --
>
> Key: FELIX-3743
> URL: https://issues.apache.org/jira/browse/FELIX-3743
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: framework-4.0.2
>Reporter: Felix Meschberger
>Assignee: Felix Meschberger
> Fix For: framework-4.2.0
>
>
> We experience an issue with setting the framework startlevel in the 
> Felix.setActiveStartLevel(int, FrameworkListener[]) method.
> On line 1216 the bundle lock is acquired. If this fails with an 
> IllegalStateException the loop just continues. But the bundle remains in the 
> m_startLevelBundles set and is retried later. In the case of an uninstalled 
> bundle, this situation will not change and the method is probabl going into 
> an endless loop.
> Would it make sense to remove the bundle from the m_startLevelBundles set in 
> the catch block starting line 1223 if the bundle has been uninstalled ?
> Proposed patch:
> Index: Felix.java
> ===
> --- Felix.java(revision 1404016)
> +++ Felix.java(working copy)
> @@ -1227,6 +1227,14 @@
> Logger.LOG_ERROR,
> "Error locking " + 
> tuple.m_bundle._getLocation(), ex);
> }
> +else
> +{
> +synchronized (m_startLevelBundles)
> +{
> +m_startLevelBundles.remove(tuple);
> +bundlesRemaining = 
> !m_startLevelBundles.isEmpty();
> +}
> +}
> continue;
> }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (FELIX-3743) Potential endless loop setting the active framework startlevel

2012-11-01 Thread Felix Meschberger (JIRA) 
Felix Meschberger created FELIX-3743:


 Summary: Potential endless loop setting the active framework 
startlevel
 Key: FELIX-3743
 URL: https://issues.apache.org/jira/browse/FELIX-3743
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: framework-4.0.2
Reporter: Felix Meschberger
 Fix For: framework-4.2.0


We experience an issue with setting the framework startlevel in the 
Felix.setActiveStartLevel(int, FrameworkListener[]) method.

On line 1216 the bundle lock is acquired. If this fails with an 
IllegalStateException the loop just continues. But the bundle remains in the 
m_startLevelBundles set and is retried later. In the case of an uninstalled 
bundle, this situation will not change and the method is probabl going into an 
endless loop.

Would it make sense to remove the bundle from the m_startLevelBundles set in 
the catch block starting line 1223 if the bundle has been uninstalled ?

Proposed patch:

Index: Felix.java
===
--- Felix.java  (revision 1404016)
+++ Felix.java  (working copy)
@@ -1227,6 +1227,14 @@
Logger.LOG_ERROR,
"Error locking " + 
tuple.m_bundle._getLocation(), ex);
}
+else
+{
+synchronized (m_startLevelBundles)
+{
+m_startLevelBundles.remove(tuple);
+bundlesRemaining = 
!m_startLevelBundles.isEmpty();
+}
+}
continue;
}


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Problem setting framework start level

2012-11-01 Thread Felix Meschberger 
Ok. Will do. Thanks.

Regards
Felix

Am 01.11.2012 um 09:19 schrieb Karl Pauls:

> I agree, this looks like a bug. We need to remove that tuple one way
> or the other - nothing else makes sense.
> 
> Richard is traveling atm so I'd say, create a JIRA issue to track this
> and go ahead and commit your fix to trunk referencing the issue. The
> patch looks good to me.
> 
> regards,
> 
> Karl
> 
> On Wed, Oct 31, 2012 at 9:13 AM, Felix Meschberger  wrote:
>> Hi,
>> 
>> We experience an issue with setting the framework startlevel in the 
>> Felix.setActiveStartLevel(int, FrameworkListener[]) method.
>> 
>> On line 1216 the bundle lock is acquired. If this fails with an 
>> IllegalStateException the loop just continues. But the bundle remains in the 
>> m_startLevelBundles set and is retried later. In the case of an uninstalled 
>> bundle, this situation will not change and the method is probabl going into 
>> an endless loop.
>> 
>> Would it make sense to remove the bundle from the m_startLevelBundles set in 
>> the catch block starting line 1223 if the bundle has been uninstalled ?
>> 
>> Something like:
>> 
>>> Index: Felix.java
>>> ===
>>> --- Felix.java(revision 1404016)
>>> +++ Felix.java(working copy)
>>> @@ -1227,6 +1227,14 @@
>>> Logger.LOG_ERROR,
>>> "Error locking " + 
>>> tuple.m_bundle._getLocation(), ex);
>>> }
>>> +else
>>> +{
>>> +synchronized (m_startLevelBundles)
>>> +{
>>> +m_startLevelBundles.remove(tuple);
>>> +bundlesRemaining = 
>>> !m_startLevelBundles.isEmpty();
>>> +}
>>> +}
>>> continue;
>>> }
>>> 
>>> 
>> 
>> 
>> Regards
>> Felix
> 
> 
> 
> -- 
> Karl Pauls
> karlpa...@gmail.com
> http://twitter.com/karlpauls
> http://www.linkedin.com/in/karlpauls
> https://profiles.google.com/karlpauls

Re: Problem setting framework start level

2012-11-01 Thread Karl Pauls 
I agree, this looks like a bug. We need to remove that tuple one way
or the other - nothing else makes sense.

Richard is traveling atm so I'd say, create a JIRA issue to track this
and go ahead and commit your fix to trunk referencing the issue. The
patch looks good to me.

regards,

Karl

On Wed, Oct 31, 2012 at 9:13 AM, Felix Meschberger  wrote:
> Hi,
>
> We experience an issue with setting the framework startlevel in the 
> Felix.setActiveStartLevel(int, FrameworkListener[]) method.
>
> On line 1216 the bundle lock is acquired. If this fails with an 
> IllegalStateException the loop just continues. But the bundle remains in the 
> m_startLevelBundles set and is retried later. In the case of an uninstalled 
> bundle, this situation will not change and the method is probabl going into 
> an endless loop.
>
> Would it make sense to remove the bundle from the m_startLevelBundles set in 
> the catch block starting line 1223 if the bundle has been uninstalled ?
>
> Something like:
>
>> Index: Felix.java
>> ===
>> --- Felix.java(revision 1404016)
>> +++ Felix.java(working copy)
>> @@ -1227,6 +1227,14 @@
>>  Logger.LOG_ERROR,
>>  "Error locking " + 
>> tuple.m_bundle._getLocation(), ex);
>>  }
>> +else
>> +{
>> +synchronized (m_startLevelBundles)
>> +{
>> +m_startLevelBundles.remove(tuple);
>> +bundlesRemaining = 
>> !m_startLevelBundles.isEmpty();
>> +}
>> +}
>>  continue;
>>  }
>>
>>
>
>
> Regards
> Felix



-- 
Karl Pauls
karlpa...@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls

Re: [DS] How about an SCR 1.6.2 release ?

2012-11-01 Thread Felix Meschberger 
Hi

Am 31.10.2012 um 21:31 schrieb David Jencks:

> DS 1.2:  AFAIK we've completely implemented the DS 1.2 spec.

Excellent.

>  I don't really understand the location binding and targeted PID bits.

It comes from the Configuration Admin spec and must be replicate in SCR since 
we basically act like a Configuration Admin service (the configuration 
provisioning part) towards the components.

I think we can live without this for the 1.6.2 relase.

> 
> Java 5: I'm certainly happy with not temporarily removing the java 5-isms, 
> but I could still do it if anyone else asks.   I havent' done any basic 
> housekeeping like removing the pre-java-5 concurrency compatibility code.  I 
> have no strong feeling about releasing with or without this stuff.

Ok, lets release with this cruft in and cleanup after the release.

I just started a thread on the users list asking for opinions regarding our 
itended use to just use Java 5 features and API going forward.

Regards
Felix

> 
> thanks!
> david jencks
> 
> On Oct 31, 2012, at 12:32 PM, Felix Meschberger wrote:
> 
>> Hi
>> 
>> Am 31.10.2012 um 19:54 schrieb David Jencks:
>> 
>>> I updated the changelog from the svn log hopefully I didn't miss 
>>> anything.
>> 
>> Just updated the changelog from the JIRA release notes.
>> 
>> Another question crossing my mind: Since the current state passes the most 
>> recent CT and checking the changes section in the 4.3 compendium spec I 
>> would assume this version also implements Version 1.2 of the DS spec. 
>> Correct ?
>> 
>> The only thing not fully implemented for the most recent specs is support 
>> for the most recent Configuration Admin features like relaxed location 
>> binding and targetted PIDs. I can live with that.
>> 
>> Regards
>> Felix
>> 
>>> 
>>> waiting for advice on the other two questions
>>> 
>>> thanks
>>> david jencks
>>> 
>>> On Oct 31, 2012, at 8:44 AM, David Jencks wrote:
>>> 
 At the moment the code uses some java 5.  How important is it that this 
 release not require java 5?  It would not be very difficult to remove the 
 java 5-isms and put them back after the release.
 
 I've been marking defects as applying to and fixed in scr-1.8.0.  I guess 
 we should go back and change them to 1.6.2?
 
 I have not been maintaining the changelog that will be a bit of work.
 
 If I don't discover any giant problems before we get the above done I'm 
 fine with a release.
 
 thanks
 david jencks
 
 On Oct 31, 2012, at 3:05 AM, Felix Meschberger wrote:
 
> Hi all,
> 
> I see the current trunk build passes our own as well as the OSGi CT tests 
> and there are no open issues marked with 1.6.2.
> 
> Shall I go ahead and cut a release ?
> 
> This would IMHO also enable David to continue his refactorings.
> 
> Regards
> Felix
 
>>> 
>> 
>