Re: [equinox-dev] Bug 566085 - javax.annotation package-uses problems with Java 8

[Neil Bartlett]

Thanks Jürgen. Here is the same article, with the diagrams included:
http://njbartlett.github.io/2011/09/02/uses-constraints.html

Hope it helps.

On Fri, 28 Aug 2020 at 13:14, Jürgen Albert 
wrote:

> Hi,
>
> it seems as if Neil already described the problem and what might cause the
> problem pretty spot on in this blog post:
>
> https://blogs.paremus.com/2011/09/solving-osgi-uses-constraint-violations/
>
> Jürgen.
> Am 28/08/2020 um 13:35 schrieb Mark Hoffmann:
>
> Hi Neil,
>
> somehow I have the feeling, this problem can be solved in a different way.
>
> If the osgi.framework.system.packages / extra is provided including a
> version qualifier for JavaSE-1.8. Mostly, I see, if provided at all, that
> these definitions are provided without version attribute.
>
> If I understand it correctly in
> https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module.resolvingprocess.
>
>
> The resolver preference priorities are resolved exporter before unresolved
> exporters and then versioned exports before un-versioned.
>
> That would mean that the system-bundle with system.packages is always
> resolved, and would preferred before other bundles. If then also a correct
> version is provided in the system.packages, it should be the preferred wire
> before all others.
>
> Adding an Import-Package, where an Export-Package exist, could also lead
> to the situation, where the Import-Package is ignored by the framework:
>
>
> https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-import.export.same.package
>
> Or am I missing something here?
>
> Regards,
>
> Mark
> Am 26.08.20 um 16:44 schrieb Neil Bartlett:
>
> I'm not sure that class loading order is even relevant here. The stack
> trace linked by Brian was an OSGi resolution error... resolution happens
> before a Bundle ClassLoader is constructed and therefore before the bundle
> attempts to load any class name.
>
> Neil
>
> On Sat, 22 Aug 2020 at 09:50, Mark Hoffmann  wrote:
>
>> Hi,
>>
>> I dont think that this is final solution for that problem.
>>
>> The class finding search order is defined in OSGi:
>>
>>
>> https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module.overallsearchorder
>>
>> That mean finding a class to be loaded will be initially done using the
>> boot delegation (Step 2 in this case). If defined correctly the following
>> will happen:
>>
>> Java 1.8 - delegate to parent class loader an load javax.annotation from
>> there (no matter, if you have an bundle provided for that package)
>>
>> Java 11 - cannot find javax.annotation over boot-delegation, go on with
>> Import-Package or Require-Bundle
>>
>> Either provide a org.osgi.framework.bootdelegation=javax.* as property to
>> activate boot-delegation or you can use the existing profiles instead.
>>
>> The Profiles are defined in Equinox:
>>
>>
>> https://github.com/eclipse/rt.equinox.framework/blob/master/bundles/org.eclipse.osgi/JavaSE-1.8.profile
>>
>> You can find the property: org.osgi.framework.bootdelegation there with a
>> definition for javax.*
>>
>> To make Equinox use this profile (I dont know, if this happens by
>> default) via launcher, you should provide the osgi.java.profile=file:/
>> /JavaSE-1.8.profile
>>
>> If you take the profile, then you have to additionally provide the
>> property: osgi.java.profile.bootdelegation=override, so that Equinox takes
>> the profile boot delegation entries. instead of already defined ones
>>
>> With the correct boot-delegation configuration, always that same class
>> loader will be taken for this constellation, no matter, if in Java 1.8 or
>> 11. The same applies to JAXB problems.
>>
>> https://wiki.eclipse.org/Equinox_Boot_Delegation
>>
>>
>> Regards,
>>
>> Mark
>>
>>
>> Am 21.08.20 um 22:43 schrieb Brian de Alwis:
>>
>> Unfortunately javax.annotation *package-uses* issues have returned
>>  :(
>>
>> The effort to replace the no-longer maintained Spotify Docker
>> Client
>>  (bug 558284)
>>  introduced a new
>> version of the javax.annotation bundle into Orbit
>>  based on Jakarta
>> EE’s somewhat recently released javax.annotation bundle with version 1.3.5
>> .
>> This bundle doesn’t use the same approach used for the javax.annotation
>> 1.2.0 bundle  to
>> use import-what-you-export *and* requiring system.bundle.
>>
>> The issue only occurs on Java 8 and has been seen in the wild
>> .
>> I suspect it has not been more widespread due to increased adoption of Java
>> 

Re: [equinox-dev] Bug 566085 - javax.annotation package-uses problems with Java 8

[Jürgen Albert]

Hi,

it seems as if Neil already described the problem and what might cause 
the problem pretty spot on in this blog post:


https://blogs.paremus.com/2011/09/solving-osgi-uses-constraint-violations/

Jürgen.

Am 28/08/2020 um 13:35 schrieb Mark Hoffmann:


Hi Neil,

somehow I have the feeling, this problem can be solved in a different 
way.


If the osgi.framework.system.packages / extra is provided including a 
version qualifier for JavaSE-1.8. Mostly, I see, if provided at all, 
that these definitions are provided without version attribute.


If I understand it correctly in 
https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module.resolvingprocess. 



The resolver preference priorities are resolved exporter before 
unresolved exporters and then versioned exports before un-versioned.


That would mean that the system-bundle with system.packages is always 
resolved, and would preferred before other bundles. If then also a 
correct version is provided in the system.packages, it should be the 
preferred wire before all others.


Adding an Import-Package, where an Export-Package exist, could also 
lead to the situation, where the Import-Package is ignored by the 
framework:


https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-import.export.same.package

Or am I missing something here?

Regards,

Mark

Am 26.08.20 um 16:44 schrieb Neil Bartlett:
I'm not sure that class loading order is even relevant here. The 
stack trace linked by Brian was an OSGi resolution error... 
resolution happens before a Bundle ClassLoader is constructed and 
therefore before the bundle attempts to load any class name.


Neil

On Sat, 22 Aug 2020 at 09:50, Mark Hoffmann > wrote:


Hi,

I dont think that this is final solution for that problem.

The class finding search order is defined in OSGi:


https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module.overallsearchorder

That mean finding a class to be loaded will be initially done
using the boot delegation (Step 2 in this case). If defined
correctly the following will happen:

Java 1.8 - delegate to parent class loader an load
javax.annotation from there (no matter, if you have an bundle
provided for that package)

Java 11 - cannot find javax.annotation over boot-delegation, go
on with Import-Package or Require-Bundle

Either provide a org.osgi.framework.bootdelegation=javax.* as
property to activate boot-delegation or you can use the existing
profiles instead.

The Profiles are defined in Equinox:


https://github.com/eclipse/rt.equinox.framework/blob/master/bundles/org.eclipse.osgi/JavaSE-1.8.profile

You can find the property: org.osgi.framework.bootdelegation
there with a definition for javax.*

To make Equinox use this profile (I dont know, if this happens by
default) via launcher, you should provide the
osgi.java.profile=file://JavaSE-1.8.profile

If you take the profile, then you have to additionally provide
the property: osgi.java.profile.bootdelegation=override, so that
Equinox takes the profile boot delegation entries. instead of
already defined ones

With the correct boot-delegation configuration, always that same
class loader will be taken for this constellation, no matter, if
in Java 1.8 or 11. The same applies to JAXB problems.

https://wiki.eclipse.org/Equinox_Boot_Delegation


Regards,

Mark


Am 21.08.20 um 22:43 schrieb Brian de Alwis:

Unfortunately javax.annotation /package-uses/ issues have
returned  :(

The effort to replace the no-longer maintained Spotify Docker
Client
 (bug
558284)
 introduced
a new version of the javax.annotation bundle into Orbit
 based
on Jakarta EE’s somewhat recently released javax.annotation
bundle with version 1.3.5

.
 
This bundle doesn’t use the same approach used for the
javax.annotation 1.2.0 bundle
 to
use import-what-you-export /and/ requiring system.bundle.

The issue only occurs on Java 8 and has been seen in the wild
. 
I suspect it has not been more widespread due to increased
adoption of Java 11.

I’ve pushed up a fix to the javax.annotation 1.3.5 bundle
.  I
think the risk is small, but given that we’re in RC season, it

Re: [equinox-dev] Bug 566085 - javax.annotation package-uses problems with Java 8

[Mark Hoffmann]

Hi Neil,

somehow I have the feeling, this problem can be solved in a different way.

If the osgi.framework.system.packages / extra is provided including a
version qualifier for JavaSE-1.8. Mostly, I see, if provided at all,
that these definitions are provided without version attribute.

If I understand it correctly in
https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module.resolvingprocess.


The resolver preference priorities are resolved exporter before
unresolved exporters and then versioned exports before un-versioned.

That would mean that the system-bundle with system.packages is always
resolved, and would preferred before other bundles. If then also a
correct version is provided in the system.packages, it should be the
preferred wire before all others.

Adding an Import-Package, where an Export-Package exist, could also lead
to the situation, where the Import-Package is ignored by the framework:

https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-import.export.same.package

Or am I missing something here?

Regards,

Mark

Am 26.08.20 um 16:44 schrieb Neil Bartlett:

I'm not sure that class loading order is even relevant here. The stack
trace linked by Brian was an OSGi resolution error... resolution
happens before a Bundle ClassLoader is constructed and therefore
before the bundle attempts to load any class name.

Neil

On Sat, 22 Aug 2020 at 09:50, Mark Hoffmann mailto:mark.hoffm...@web.de>> wrote:

Hi,

I dont think that this is final solution for that problem.

The class finding search order is defined in OSGi:


https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module.overallsearchorder

That mean finding a class to be loaded will be initially done
using the boot delegation (Step 2 in this case). If defined
correctly the following will happen:

Java 1.8 - delegate to parent class loader an load
javax.annotation from there (no matter, if you have an bundle
provided for that package)

Java 11 - cannot find javax.annotation over boot-delegation, go on
with Import-Package or Require-Bundle

Either provide a org.osgi.framework.bootdelegation=javax.* as
property to activate boot-delegation or you can use the existing
profiles instead.

The Profiles are defined in Equinox:


https://github.com/eclipse/rt.equinox.framework/blob/master/bundles/org.eclipse.osgi/JavaSE-1.8.profile

You can find the property: org.osgi.framework.bootdelegation there
with a definition for javax.*

To make Equinox use this profile (I dont know, if this happens by
default) via launcher, you should provide the
osgi.java.profile=file://JavaSE-1.8.profile

If you take the profile, then you have to additionally provide the
property: osgi.java.profile.bootdelegation=override, so that
Equinox takes the profile boot delegation entries. instead of
already defined ones

With the correct boot-delegation configuration, always that same
class loader will be taken for this constellation, no matter, if
in Java 1.8 or 11. The same applies to JAXB problems.

https://wiki.eclipse.org/Equinox_Boot_Delegation


Regards,

Mark


Am 21.08.20 um 22:43 schrieb Brian de Alwis:

Unfortunately javax.annotation /package-uses/ issues have
returned  :(

The effort to replace the no-longer maintained Spotify Docker
Client
 (bug
558284)
 introduced
a new version of the javax.annotation bundle into Orbit
 based
on Jakarta EE’s somewhat recently released javax.annotation
bundle with version 1.3.5

.
 
This bundle doesn’t use the same approach used for the
javax.annotation 1.2.0 bundle
 to use
import-what-you-export /and/ requiring system.bundle.

The issue only occurs on Java 8 and has been seen in the wild
. 
I suspect it has not been more widespread due to increased
adoption of Java 11.

I’ve pushed up a fix to the javax.annotation 1.3.5 bundle
.  I
think the risk is small, but given that we’re in RC season, it
would be good to get some more eyes on this.

If you have concerns, please comment on Bug 566085
.

Brian.

___
equinox-dev mailing list

Re: [equinox-dev] Bug 566085 - javax.annotation package-uses problems with Java 8

[Neil Bartlett]

I'm not sure that class loading order is even relevant here. The stack
trace linked by Brian was an OSGi resolution error... resolution happens
before a Bundle ClassLoader is constructed and therefore before the bundle
attempts to load any class name.

Neil

On Sat, 22 Aug 2020 at 09:50, Mark Hoffmann  wrote:

> Hi,
>
> I dont think that this is final solution for that problem.
>
> The class finding search order is defined in OSGi:
>
>
> https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module.overallsearchorder
>
> That mean finding a class to be loaded will be initially done using the
> boot delegation (Step 2 in this case). If defined correctly the following
> will happen:
>
> Java 1.8 - delegate to parent class loader an load javax.annotation from
> there (no matter, if you have an bundle provided for that package)
>
> Java 11 - cannot find javax.annotation over boot-delegation, go on with
> Import-Package or Require-Bundle
>
> Either provide a org.osgi.framework.bootdelegation=javax.* as property to
> activate boot-delegation or you can use the existing profiles instead.
>
> The Profiles are defined in Equinox:
>
>
> https://github.com/eclipse/rt.equinox.framework/blob/master/bundles/org.eclipse.osgi/JavaSE-1.8.profile
>
> You can find the property: org.osgi.framework.bootdelegation there with a
> definition for javax.*
>
> To make Equinox use this profile (I dont know, if this happens by default)
> via launcher, you should provide the osgi.java.profile=file:/
> /JavaSE-1.8.profile
>
> If you take the profile, then you have to additionally provide the
> property: osgi.java.profile.bootdelegation=override, so that Equinox takes
> the profile boot delegation entries. instead of already defined ones
>
> With the correct boot-delegation configuration, always that same class
> loader will be taken for this constellation, no matter, if in Java 1.8 or
> 11. The same applies to JAXB problems.
>
> https://wiki.eclipse.org/Equinox_Boot_Delegation
>
>
> Regards,
>
> Mark
>
>
> Am 21.08.20 um 22:43 schrieb Brian de Alwis:
>
> Unfortunately javax.annotation *package-uses* issues have returned
>  :(
>
> The effort to replace the no-longer maintained Spotify Docker
> Client
>  (bug 558284)
>  introduced a new
> version of the javax.annotation bundle into Orbit
>  based on Jakarta
> EE’s somewhat recently released javax.annotation bundle with version 1.3.5
> .
> This bundle doesn’t use the same approach used for the javax.annotation
> 1.2.0 bundle  to
> use import-what-you-export *and* requiring system.bundle.
>
> The issue only occurs on Java 8 and has been seen in the wild
> .
> I suspect it has not been more widespread due to increased adoption of Java
> 11.
>
> I’ve pushed up a fix to the javax.annotation 1.3.5 bundle
> .  I think the
> risk is small, but given that we’re in RC season, it would be good to get
> some more eyes on this.
>
> If you have concerns, please comment on Bug 566085
> .
>
> Brian.
>
> ___
> equinox-dev mailing listequinox-...@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/equinox-dev
>
> --
> Mark Hoffmann
>
> E-Mail: mark.hoffm...@web.de
>
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/equinox-dev
>
___
equinox-dev mailing list
equinox-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Bug 566085 - javax.annotation package-uses problems with Java 8

[Brian de Alwis]

Hi Mark.

I’ve added your comment to Bug 566085 
.

Brian.


> On Aug 22, 2020, at 4:50 AM, Mark Hoffmann  wrote:
> 
> 
> Hi,
> 
> I dont think that this is final solution for that problem.
> 
> The class finding search order is defined in OSGi:
> 
> https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module.overallsearchorder
>  
> 
> That mean finding a class to be loaded will be initially done using the boot 
> delegation (Step 2 in this case). If defined correctly the following will 
> happen:
> 
> Java 1.8 - delegate to parent class loader an load javax.annotation from 
> there (no matter, if you have an bundle provided for that package)
> 
> Java 11 - cannot find javax.annotation over boot-delegation, go on with 
> Import-Package or Require-Bundle
> 
> Either provide a org.osgi.framework.bootdelegation=javax.* as property to 
> activate boot-delegation or you can use the existing profiles instead.
> 
> The Profiles are defined in Equinox:
> 
> https://github.com/eclipse/rt.equinox.framework/blob/master/bundles/org.eclipse.osgi/JavaSE-1.8.profile
>  
> 
> You can find the property: org.osgi.framework.bootdelegation there with a 
> definition for javax.*
> 
> To make Equinox use this profile (I dont know, if this happens by default) 
> via launcher, you should provide the osgi.java.profile=file:/ 
> /JavaSE-1.8.profile
> 
> If you take the profile, then you have to additionally provide the property: 
> osgi.java.profile.bootdelegation=override, so that Equinox takes the profile 
> boot delegation entries. instead of already defined ones
> 
> With the correct boot-delegation configuration, always that same class loader 
> will be taken for this constellation, no matter, if in Java 1.8 or 11. The 
> same applies to JAXB problems.
> 
> https://wiki.eclipse.org/Equinox_Boot_Delegation 
> 
> 
> Regards,
> 
> Mark
> 
> 
> 
> Am 21.08.20 um 22:43 schrieb Brian de Alwis:
>> Unfortunately javax.annotation package-uses issues have returned 
>>  :(  
>> 
>> The effort to replace the no-longer maintained Spotify Docker  
>> Client 
>>  (bug 558284) 
>>  introduced a new 
>> version of the javax.annotation bundle into Orbit 
>>  based on Jakarta 
>> EE’s somewhat recently released javax.annotation bundle with version 1.3.5 
>> .
>>   This bundle doesn’t use the same approach used for the javax.annotation 
>> 1.2.0 bundle  to 
>> use import-what-you-export and requiring system.bundle.
>> 
>> The issue only occurs on Java 8 and has been seen in the wild 
>> .  
>> I suspect it has not been more widespread due to increased adoption of Java 
>> 11.
>> 
>> I’ve pushed up a fix to the javax.annotation 1.3.5 bundle 
>> .  I think the 
>> risk is small, but given that we’re in RC season, it would be good to get 
>> some more eyes on this.
>> 
>> If you have concerns, please comment on Bug 566085 
>> .
>> 
>> Brian.
>> 
>> 
>> ___
>> equinox-dev mailing list
>> equinox-dev@eclipse.org 
>> To unsubscribe from this list, visit 
>> https://www.eclipse.org/mailman/listinfo/equinox-dev 
>> 
> --
> Mark Hoffmann
> 
> E-Mail: mark.hoffm...@web.de 
> 
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Bug 566085 - javax.annotation package-uses problems with Java 8

[Mark Hoffmann]

Hi,

I dont think that this is final solution for that problem.

The class finding search order is defined in OSGi:

https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module.overallsearchorder

That mean finding a class to be loaded will be initially done using the
boot delegation (Step 2 in this case). If defined correctly the
following will happen:

Java 1.8 - delegate to parent class loader an load javax.annotation from
there (no matter, if you have an bundle provided for that package)

Java 11 - cannot find javax.annotation over boot-delegation, go on with
Import-Package or Require-Bundle

Either provide a org.osgi.framework.bootdelegation=javax.* as property
to activate boot-delegation or you can use the existing profiles instead.

The Profiles are defined in Equinox:

https://github.com/eclipse/rt.equinox.framework/blob/master/bundles/org.eclipse.osgi/JavaSE-1.8.profile

You can find the property: org.osgi.framework.bootdelegation there with
a definition for javax.*

To make Equinox use this profile (I dont know, if this happens by
default) via launcher, you should provide the
osgi.java.profile=file://JavaSE-1.8.profile

If you take the profile, then you have to additionally provide the
property: osgi.java.profile.bootdelegation=override, so that Equinox
takes the profile boot delegation entries. instead of already defined ones

With the correct boot-delegation configuration, always that same class
loader will be taken for this constellation, no matter, if in Java 1.8
or 11. The same applies to JAXB problems.

https://wiki.eclipse.org/Equinox_Boot_Delegation


Regards,

Mark


Am 21.08.20 um 22:43 schrieb Brian de Alwis:

Unfortunately javax.annotation /package-uses/ issues have returned
 :(

The effort to replace the no-longer maintained Spotify Docker
Client
 (bug 558284)
 introduced a
new version of the javax.annotation bundle into Orbit
 based on
Jakarta EE’s somewhat recently released javax.annotation bundle with
version 1.3.5
.
 This bundle doesn’t use the same approach used for the
javax.annotation 1.2.0 bundle
 to use
import-what-you-export /and/ requiring system.bundle.

The issue only occurs on Java 8 and has been seen in the wild
.
 I suspect it has not been more widespread due to increased adoption
of Java 11.

I’ve pushed up a fix to the javax.annotation 1.3.5 bundle
.  I think
the risk is small, but given that we’re in RC season, it would be good
to get some more eyes on this.

If you have concerns, please comment on Bug 566085
.

Brian.

___
equinox-dev mailing list
equinox-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/equinox-dev


--
Mark Hoffmann

E-Mail: mark.hoffm...@web.de

___
equinox-dev mailing list
equinox-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] Bug 566085 - javax.annotation package-uses problems with Java 8

[Brian de Alwis]

Unfortunately javax.annotation package-uses issues have returned 
 :(  

The effort to replace the no-longer maintained Spotify Docker  
 
Client 
 (bug 558284) 
 introduced a new version 
of the javax.annotation bundle into Orbit 
 based on Jakarta 
EE’s somewhat recently released javax.annotation bundle with version 1.3.5 
.
  This bundle doesn’t use the same approach used for the javax.annotation 1.2.0 
bundle  to use 
import-what-you-export and requiring system.bundle.

The issue only occurs on Java 8 and has been seen in the wild 
.  I 
suspect it has not been more widespread due to increased adoption of Java 11.

I’ve pushed up a fix to the javax.annotation 1.3.5 bundle 
.  I think the risk 
is small, but given that we’re in RC season, it would be good to get some more 
eyes on this.

If you have concerns, please comment on Bug 566085 
.

Brian.___
equinox-dev mailing list
equinox-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] Bug 475656 - RegistryStrategyOSGI is using the non-thread-safe ReferenceMap without synchronization

[Hermann Czedik-Eysenberg]

Hi Equinox developers,

I made a little patch to fix the bug described by 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=475656 . The patch is attached to 
the bug report.

We get hit by this bug at customers running our software. The bad thing is that 
the unsynchronized put access to this map can lead to a map corruption which 
then results in an endless loop the next time the map is being accessed. Stack 
track then looks like this (stuck in an endless loop):
"TaskProcessor 1-10" Id=123 RUNNABLE
at 
org.eclipse.core.internal.registry.ReferenceMap.get(ReferenceMap.java:280)
at 
org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.getBundle(RegistryStrategyOSGI.java:133)
at 
org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:152)
at 
org.eclipse.core.internal.registry.ExtensionRegistry.createExecutableExtension(ExtensionRegistry.java:874)
at 
org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:243)
at 
org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:51)
at 
com.agfa.pacs.core.EclipseExtensionRecord.createExtension(EclipseExtensionRecord.java:72)

I was hoping that one of you Equinox developers can pick this fix up an commit 
it for a future version of Equinox.

Thank you!

Liebe Grüße,

Hermann Czedik-Eysenberg | Agfa HealthCare
Software Architect Image Area | HE/Architecture/Requirements - Enterprise 
Imaging
T  +43 1 89966 320 | F  +43 1 89966 110

Agfa HealthCare GmbH, Diefenbachgasse 35, 1150 Wien, Austria
http://www.agfahealthcare.com
http://blog.agfahealthcare.com
Geschäftsführer: Dkfm. Winfried Post | Sitz der Gesellschaft: Wien, 
Handelsgericht Wien, FN 56704p | UID ATU15133905
Click on link to read important disclaimer: 
http://www.agfahealthcare.com/maildisclaimer

___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] [Bug 531680] [code mining] Avoid cancellation by exception

[Gunnar Wagenknecht]

> On Jul 30, 2018, at 09:04, Daniel Megert  wrote:
> 
> > (Moved discussion from bug to Equinox mailing list)
> 
> Why? I prefer to keep discussions in bug reports.

Hmm... I thought there are people on the bug not interested in the details. 
Thus, I didn't want to clutter the bug with this. :) 

> And, it would not be an Equinox specific question/issue.

How so? Isn't the interface defined in Equinox? All the downstream consumers 
would just consume the new major version, wouldn't they? Maybe I'm missing 
something here.

-Gunnar
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] [Bug 531680] [code mining] Avoid cancellation by exception

[Daniel Megert]

> (Moved discussion from bug to Equinox mailing list)

Why? I prefer to keep discussions in bug reports.

And, it would not be an Equinox specific question/issue.

Dani



From:   Gunnar Wagenknecht 
To: equinox-dev@eclipse.org
Date:   30.07.2018 18:00
Subject:Re: [equinox-dev] [Bug 531680] [code mining] Avoid 
cancellation by exception
Sent by:equinox-dev-boun...@eclipse.org



(Moved discussion from bug to Equinox mailing list)

>> As for the other comments, is introducing this as a new default method 
on
>> IProgressMonitor and coordinating a release with fixes upstream 
possible? Or
>> will that never allowed?
> 
> Following the rules as they are now that would require a major version
> increase.  Not something I think is justified to fix this issue.

What are the general plans here? I'd like to see the specific issue fixed 
in a good way. Having the new default method on IProgressMonitor seems 
like a clean approach. However, I tend to agree that this is a big change 
(in terms of impact).

Are there any plans to have another major version? What are the main 
concerns in that area?

-Gunnar
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev






___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] [Bug 531680] [code mining] Avoid cancellation by exception

[Gunnar Wagenknecht]

(Moved discussion from bug to Equinox mailing list)

>> As for the other comments, is introducing this as a new default method on
>> IProgressMonitor and coordinating a release with fixes upstream possible? Or
>> will that never allowed?
> 
> Following the rules as they are now that would require a major version
> increase.  Not something I think is justified to fix this issue.

What are the general plans here? I'd like to see the specific issue fixed in a 
good way. Having the new default method on IProgressMonitor seems like a clean 
approach. However, I tend to agree that this is a big change (in terms of 
impact).

Are there any plans to have another major version? What are the main concerns 
in that area?

-Gunnar
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] Bug Reminder - Re: [platform-releng-dev] 4.7.3 RC1 Schedule

[Daniel Megert]

NOTE: There are still 35 bugs open against RC1. Please either fix or 
retarget them.

Thanks,
Dani



From:   "Sravan K Lakkimsetti" 
To: "Eclipse platform release engineering list." 
, eclipse-...@eclipse.org, 
equinox-dev@eclipse.org, platform-...@eclipse.org
Date:   05.02.2018 07:28
Subject:[platform-releng-dev] 4.7.3 RC1 Schedule
Sent by:platform-releng-dev-boun...@eclipse.org



Hi,
 
We have 4.7.3 RC1 scheduled this week (Feb 9, 2018). 
Please go through the endgame plan provided here 
https://www.eclipse.org/eclipse/development/plans/freeze_plan_4_7_3.php 
 
Please Note: All fixes submitted to update stream builds must have a 
component lead or PMC vote on the bug report, and the fix must be reviewed 
by an additional committer (any committer other than the one who made the 
fix).  No new features or APIs are allowed after RC1.
 
Schedule
Here is the schedule for the same. All times in Eastern standard time.
 
Feb 6  Feature and API freeze
Feb 7 4:00 AM   Checkpoint build
Feb 7 5:00 PM   Candidate build
Feb 8 Signoff
Feb 9 Promotion to downloads and contribution to 
simrel
 
 
New and Noteworthy 
The "New and Noteworthy" entries for all the new features are due by 
Wednesday evening:
Git repo: ssh://git.eclipse.org/gitroot/www.eclipse.org/eclipse/news.git
Gerrit: ssh://git.eclipse.org:29418/www.eclipse.org/eclipse/news.git
Live website: https://www.eclipse.org/eclipse/news/4.7.3/ 
 
Thanks and Regards,
Sravan 
 
Sravan Kumar Lakkimsetti
IBM India Pvt Ltd,
Embassy Golf Links Business Park, D Block,
Off Indiranagar-Kormangla Inner Ring Road,
Bangalore - 560071, India
Phone: 91-80-41776858
 
 

___
platform-releng-dev mailing list
platform-releng-...@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_platform-2Dreleng-2Ddev=DwICAg=jf_iaSHvJObTbx-siA1ZOg=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y=Qz-lI-61OPxuIINAoSGgxtJmR-VZs7CRmrow-vLd2R8=4PT2C2Rt4W0G-8EpNKwvrqxAFuBHzMNjVpnf9Rg6EtM=



___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] Bug 493193 - MirrorApplication should explicitly use MD5 artifact comparator

[Mykola Nikishov]

Hi there,

When adding support for SHA256 checksums [1], I've found out that the
only place that documents the usage of MD5 comparator in
MirrorApplication is Equinox p2 Repository Mirroring wiki page [2]:

Adding the argument -comparator  specifies the
mirroring application should use an Artifact Comparator with an ID
of "comparator ID" to compare artifact descriptors. The mirroring
application uses the "MD5 Comparator" to compare the MD5 hash
property of the artifact descriptors if no comparator is defined.

If no comparator is defined, ArtifactComparatorFactory's
getArtifactComparator(String) will be finally called with null as a
comparator ID. It's an ArtifactComparatorFactory's implementation detail
that it will return the first configured one. MD5 comparator is the only
one available now, but this may (and my I hope it will) change and break
MirrorApplication's expectation.

To avoid such breakage, MirrorApplication declares [3] an explicit
dependency on MD5 comparator. So, when '-compare' CLI parameter is true
but '-comparator' CLI parameter is missing, it will request MD5 artifact
comparator to be used.

Please provide your feedback or just merge [3].

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=493193
[2] https://wiki.eclipse.org/Equinox_p2_Repository_Mirroring
[3] https://git.eclipse.org/r/72234

-- 
Mykola
https://manandbytes.github.io/

___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] bug or not

[Raymond Auge]

Hey all,

I have to write code as follows in a ServiceFactory impl in order for my
factory to always return the same instance per bundle running on
equinox 3.8.0.v20120529-1548

===
public HttpService getService(
Bundle bundle, ServiceRegistrationHttpService registration) {

HttpServiceImpl httpServiceImpl = serviceMap.get(bundle);

if (httpServiceImpl != null) {
return httpServiceImpl;
}

httpServiceImpl = new HttpServiceImpl(
bundle, contextController, legacyServiceIdGenerator);

serviceMap.putIfAbsent(bundle, httpServiceImpl);

return httpServiceImpl;
}
===

This seems clearly wrong as per the spec.

It's certainly calling the getService method of the ServiceFactory which
I'm guessing means it's not incorrectly registered.

What could I be doing wrong? Was this ever a bug in equinox that was later
resolved?

-- 
*Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
 (@rotty3000)
Senior Software Architect
*Liferay, Inc.* http://www.liferay.com (@Liferay)
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] bug or not

[BJ Hargrave]

You don't have to manage the instance. The framework, per spec, must cache 
the instance the return it for future BundleContext.getService calls.

I am quite sure Equinox is fine here. Never heard of a problem in this 
area. You don't mention what version you use.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:   Raymond Auge raymond.a...@liferay.com
To: Equinox development mailing list equinox-dev@eclipse.org
Date:   2014/04/28 16:24
Subject:[equinox-dev] bug or not
Sent by:equinox-dev-boun...@eclipse.org



Hey all,

I have to write code as follows in a ServiceFactory impl in order for my 
factory to always return the same instance per bundle running on 
equinox 3.8.0.v20120529-1548

===
public HttpService getService(
Bundle bundle, ServiceRegistrationHttpService registration) {

HttpServiceImpl httpServiceImpl = serviceMap.get(bundle);

if (httpServiceImpl != null) {
return httpServiceImpl;
}

httpServiceImpl = new HttpServiceImpl(
bundle, contextController, legacyServiceIdGenerator);

serviceMap.putIfAbsent(bundle, httpServiceImpl);

return httpServiceImpl;
}
===

This seems clearly wrong as per the spec. 

It's certainly calling the getService method of the ServiceFactory which 
I'm guessing means it's not incorrectly registered.

What could I be doing wrong? Was this ever a bug in equinox that was later 
resolved?

-- 
Raymond Augé (@rotty3000)
Senior Software Architect
Liferay, Inc. (@Liferay)
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] bug or not

[Raymond Auge]

 equinox 3.8.0.v20120529-1548

- Ray

On Mon, Apr 28, 2014 at 4:30 PM, BJ Hargrave hargr...@us.ibm.com wrote:

 You don't have to manage the instance. The framework, per spec, must cache
 the instance the return it for future BundleContext.getService calls.

 I am quite sure Equinox is fine here. Never heard of a problem in this
 area. You don't mention what version you use.
 --

  *BJ Hargrave*
 Senior Technical Staff Member, IBM
 OSGi Fellow and CTO of the *OSGi Alliance* http://www.osgi.org/
 *hargr...@us.ibm.com* hargr...@us.ibm.com

 office: +1 386 848 1781
 mobile: +1 386 848 3788





 From:Raymond Auge raymond.a...@liferay.com
 To:Equinox development mailing list equinox-dev@eclipse.org
 Date:2014/04/28 16:24
 Subject:[equinox-dev] bug or not
 Sent by:equinox-dev-boun...@eclipse.org
 --



 Hey all,

 I have to write code as follows in a ServiceFactory impl in order for my
 factory to always return the same instance per bundle running on
 equinox 3.8.0.v20120529-1548

 ===
 public HttpService getService(
 Bundle bundle, ServiceRegistrationHttpService registration) {

 HttpServiceImpl httpServiceImpl = serviceMap.get(bundle);

 if (httpServiceImpl != null) {
 return httpServiceImpl;
 }

 httpServiceImpl = new HttpServiceImpl(
 bundle, contextController, legacyServiceIdGenerator);

 serviceMap.putIfAbsent(bundle, httpServiceImpl);

 return httpServiceImpl;
 }
 ===

 This seems clearly wrong as per the spec.

 It's certainly calling the getService method of the ServiceFactory which
 I'm guessing means it's not incorrectly registered.

 What could I be doing wrong? Was this ever a bug in equinox that was later
 resolved?

 --
 *Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
  (@rotty3000)
 Senior Software Architect
 *Liferay, Inc.* http://www.liferay.com/ (@Liferay)
 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev


 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev




-- 
*Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
 (@rotty3000)
Senior Software Architect
*Liferay, Inc.* http://www.liferay.com (@Liferay)
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] bug or not

[Thomas Watson]

You seem to be implementing the work that the framework already does for
ServiceFactory registrations.  The framework will only call your factory
once as long as the use count of the service is greater than zero for a
particular bundle.  The framework will then cache that service instance and
keep returning it directly to the bundle without calling the ServiceFactory
again.

Am I understanding your observation correctly?  You are stating that your
factory is not called multiple times for the same consuming bundle?

Tom





From:   Raymond Auge raymond.a...@liferay.com
To: Equinox development mailing list equinox-dev@eclipse.org
Date:   04/28/2014 03:24 PM
Subject:[equinox-dev] bug or not
Sent by:equinox-dev-boun...@eclipse.org



Hey all,

I have to write code as follows in a ServiceFactory impl in order for my
factory to always return the same instance per bundle running on
equinox 3.8.0.v20120529-1548

===
public HttpService getService(
Bundle bundle, ServiceRegistrationHttpService registration) {

HttpServiceImpl httpServiceImpl = serviceMap.get(bundle);

if (httpServiceImpl != null) {
return httpServiceImpl;
}

httpServiceImpl = new HttpServiceImpl(
bundle, contextController, legacyServiceIdGenerator);

serviceMap.putIfAbsent(bundle, httpServiceImpl);

return httpServiceImpl;
}
===

This seems clearly wrong as per the spec.

It's certainly calling the getService method of the ServiceFactory which
I'm guessing means it's not incorrectly registered.

What could I be doing wrong? Was this ever a bug in equinox that was later
resolved?

--
Raymond Augé (@rotty3000)
Senior Software Architect
Liferay, Inc. (@Liferay)
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] bug or not

[Raymond Auge]

On Mon, Apr 28, 2014 at 5:17 PM, Thomas Watson tjwat...@us.ibm.com wrote:

 You seem to be implementing the work that the framework already does for
 ServiceFactory registrations.  The framework will only call your factory
 once as long as the use count of the service is greater than zero for a
 particular bundle.  The framework will then cache that service instance and
 keep returning it directly to the bundle without calling the ServiceFactory
 again.

 Am I understanding your observation correctly?  You are stating that your
 factory is not called multiple times for the same consuming bundle?


I'm stating that when a single bundle is deployed which requests the same
service multiple times the factory method is called multiple times and the
bundle gets a different instance of the service each time.

I'm not sure if there is some sort of race condition but the client bundle
(in this case the felix webconsole) is requesting the HttpService mutliple
times (in the same thread) and each time the equinox framework is invoking
the HttpServiceFactory method returning different HttpServiceImpl instance.

- Ray




 Tom



 [image: Inactive hide details for Raymond Auge ---04/28/2014 03:24:26
 PM---Hey all, I have to write code as follows in a ServiceFactory]Raymond
 Auge ---04/28/2014 03:24:26 PM---Hey all, I have to write code as follows
 in a ServiceFactory impl in order for my


 From: Raymond Auge raymond.a...@liferay.com
 To: Equinox development mailing list equinox-dev@eclipse.org
 Date: 04/28/2014 03:24 PM

 Subject: [equinox-dev] bug or not
 Sent by: equinox-dev-boun...@eclipse.org
 --



 Hey all,

 I have to write code as follows in a ServiceFactory impl in order for my
 factory to always return the same instance per bundle running on
 equinox 3.8.0.v20120529-1548

 ===
 public HttpService getService(
 Bundle bundle, ServiceRegistrationHttpService registration) {

 HttpServiceImpl httpServiceImpl = serviceMap.get(bundle);

 if (httpServiceImpl != null) {
 return httpServiceImpl;
 }

 httpServiceImpl = new HttpServiceImpl(
 bundle, contextController, legacyServiceIdGenerator);

 serviceMap.putIfAbsent(bundle, httpServiceImpl);

 return httpServiceImpl;
 }
 ===

 This seems clearly wrong as per the spec.

 It's certainly calling the getService method of the ServiceFactory which
 I'm guessing means it's not incorrectly registered.

 What could I be doing wrong? Was this ever a bug in equinox that was later
 resolved?

 --
 *Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
  (@rotty3000)
 Senior Software Architect
 *Liferay, Inc.* http://www.liferay.com/ (@Liferay)
 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev


 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev




-- 
*Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
 (@rotty3000)
Senior Software Architect
*Liferay, Inc.* http://www.liferay.com (@Liferay)
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] bug or not

[Raymond Auge]

I agree that I should NOT have to implement this code. However, I'm having
to do so in order to work around this apparent issue.

- Ray


On Mon, Apr 28, 2014 at 5:23 PM, Raymond Auge raymond.a...@liferay.comwrote:




 On Mon, Apr 28, 2014 at 5:17 PM, Thomas Watson tjwat...@us.ibm.comwrote:

 You seem to be implementing the work that the framework already does for
 ServiceFactory registrations.  The framework will only call your factory
 once as long as the use count of the service is greater than zero for a
 particular bundle.  The framework will then cache that service instance and
 keep returning it directly to the bundle without calling the ServiceFactory
 again.

 Am I understanding your observation correctly?  You are stating that your
 factory is not called multiple times for the same consuming bundle?


 I'm stating that when a single bundle is deployed which requests the same
 service multiple times the factory method is called multiple times and the
 bundle gets a different instance of the service each time.

 I'm not sure if there is some sort of race condition but the client bundle
 (in this case the felix webconsole) is requesting the HttpService mutliple
 times (in the same thread) and each time the equinox framework is invoking
 the HttpServiceFactory method returning different HttpServiceImpl instance.

 - Ray




 Tom



 [image: Inactive hide details for Raymond Auge ---04/28/2014 03:24:26
 PM---Hey all, I have to write code as follows in a ServiceFactory]Raymond
 Auge ---04/28/2014 03:24:26 PM---Hey all, I have to write code as follows
 in a ServiceFactory impl in order for my


 From: Raymond Auge raymond.a...@liferay.com
 To: Equinox development mailing list equinox-dev@eclipse.org
 Date: 04/28/2014 03:24 PM

 Subject: [equinox-dev] bug or not
 Sent by: equinox-dev-boun...@eclipse.org
 --



 Hey all,

 I have to write code as follows in a ServiceFactory impl in order for my
 factory to always return the same instance per bundle running on
 equinox 3.8.0.v20120529-1548

 ===
 public HttpService getService(
 Bundle bundle, ServiceRegistrationHttpService registration) {

 HttpServiceImpl httpServiceImpl = serviceMap.get(bundle);

 if (httpServiceImpl != null) {
 return httpServiceImpl;
 }

 httpServiceImpl = new HttpServiceImpl(
 bundle, contextController, legacyServiceIdGenerator);

 serviceMap.putIfAbsent(bundle, httpServiceImpl);

 return httpServiceImpl;
 }
 ===

 This seems clearly wrong as per the spec.

 It's certainly calling the getService method of the ServiceFactory which
 I'm guessing means it's not incorrectly registered.

 What could I be doing wrong? Was this ever a bug in equinox that was
 later resolved?

 --
 *Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
  (@rotty3000)
 Senior Software Architect
 *Liferay, Inc.* http://www.liferay.com/ (@Liferay)
 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev


 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/equinox-dev




 --
 *Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
  (@rotty3000)
 Senior Software Architect
 *Liferay, Inc.* http://www.liferay.com (@Liferay)




-- 
*Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
 (@rotty3000)
Senior Software Architect
*Liferay, Inc.* http://www.liferay.com (@Liferay)
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] bug or not

[Thomas Watson]

Is your ServiceFactory.ungetService getting called each time?  If so then
it is likely the felix webconsole is using an anti pattern like this:

HttpService service = bc.getService(httpServiceRef);
/// do some work with http service
bc.ungetService(httpServiceRef);

If they are getting/ungetting the service each time they are interacting
with the service then the usecount for the service goes to zero for each
usage which then causes the framework to free the service instance object.
The should be using something like a ServiceTracker to avoid this kind of
anti-pattern.

Tom





From:   Raymond Auge raymond.a...@liferay.com
To: Equinox development mailing list equinox-dev@eclipse.org
Date:   04/28/2014 04:26 PM
Subject:Re: [equinox-dev] bug or not
Sent by:equinox-dev-boun...@eclipse.org



I agree that I should NOT have to implement this code. However, I'm having
to do so in order to work around this apparent issue.

- Ray


On Mon, Apr 28, 2014 at 5:23 PM, Raymond Auge raymond.a...@liferay.com
wrote:



  On Mon, Apr 28, 2014 at 5:17 PM, Thomas Watson tjwat...@us.ibm.com
  wrote:
   You seem to be implementing the work that the framework already does for
   ServiceFactory registrations.  The framework will only call your factory
   once as long as the use count of the service is greater than zero for a
   particular bundle.  The framework will then cache that service instance
   and keep returning it directly to the bundle without calling the
   ServiceFactory again.

   Am I understanding your observation correctly?  You are stating that
   your factory is not called multiple times for the same consuming bundle?



  I'm stating that when a single bundle is deployed which requests the same
  service multiple times the factory method is called multiple times and
  the bundle gets a different instance of the service each time.

  I'm not sure if there is some sort of race condition but the client
  bundle (in this case the felix webconsole) is requesting the HttpService
  mutliple times (in the same thread) and each time the equinox framework
  is invoking the HttpServiceFactory method returning different
  HttpServiceImpl instance.

  - Ray



   Tom



   Inactive hide details for Raymond Auge ---04/28/2014 03:24:26 PM---Hey
   all, I have to write code as follows in a ServiceFactoryRaymond Auge
   ---04/28/2014 03:24:26 PM---Hey all, I have to write code as follows in
   a ServiceFactory impl in order for my




   From: Raymond Auge raymond.a...@liferay.com
   To: Equinox development mailing list equinox-dev@eclipse.org
   Date: 04/28/2014 03:24 PM

   Subject: [equinox-dev] bug or not
   Sent by: equinox-dev-boun...@eclipse.org



   Hey all,

   I have to write code as follows in a ServiceFactory impl in order for my
   factory to always return the same instance per bundle running on
   equinox 3.8.0.v20120529-1548

   ===
   public HttpService getService(
   Bundle bundle, ServiceRegistrationHttpService registration) {

   HttpServiceImpl httpServiceImpl = serviceMap.get(bundle);

   if (httpServiceImpl != null) {
   return httpServiceImpl;
   }

   httpServiceImpl = new HttpServiceImpl(
   bundle, contextController, legacyServiceIdGenerator);

   serviceMap.putIfAbsent(bundle, httpServiceImpl);

   return httpServiceImpl;
   }
   ===

   This seems clearly wrong as per the spec.

   It's certainly calling the getService method of the ServiceFactory which
   I'm guessing means it's not incorrectly registered.

   What could I be doing wrong? Was this ever a bug in equinox that was
   later resolved?

   --
   Raymond Augé (@rotty3000)
   Senior Software Architect
   Liferay, Inc. (@Liferay)
   ___
   equinox-dev mailing list
   equinox-dev@eclipse.org
   https://dev.eclipse.org/mailman/listinfo/equinox-dev


   ___
   equinox-dev mailing list
   equinox-dev@eclipse.org
   https://dev.eclipse.org/mailman/listinfo/equinox-dev




  --
  Raymond Augé (@rotty3000)
  Senior Software Architect
  Liferay, Inc. (@Liferay)






--
Raymond Augé (@rotty3000)
Senior Software Architect
Liferay, Inc. (@Liferay)
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] bug or not

[Raymond Auge]

will check!

Thx,
- Ray


On Mon, Apr 28, 2014 at 5:37 PM, Thomas Watson tjwat...@us.ibm.com wrote:

 Is your ServiceFactory.ungetService getting called each time?  If so then
 it is likely the felix webconsole is using an anti pattern like this:

 HttpService service = bc.getService(httpServiceRef);
 /// do some work with http service
 bc.ungetService(httpServiceRef);

 If they are getting/ungetting the service each time they are interacting
 with the service then the usecount for the service goes to zero for each
 usage which then causes the framework to free the service instance object.
  The should be using something like a ServiceTracker to avoid this kind of
 anti-pattern.

 Tom



 [image: Inactive hide details for Raymond Auge ---04/28/2014 04:26:50
 PM---I agree that I should NOT have to implement this code. Howev]Raymond
 Auge ---04/28/2014 04:26:50 PM---I agree that I should NOT have to
 implement this code. However, I'm having to do so in order to work


 From: Raymond Auge raymond.a...@liferay.com
 To: Equinox development mailing list equinox-dev@eclipse.org
 Date: 04/28/2014 04:26 PM
 Subject: Re: [equinox-dev] bug or not

 Sent by: equinox-dev-boun...@eclipse.org
 --



 I agree that I should NOT have to implement this code. However, I'm having
 to do so in order to work around this apparent issue.

 - Ray


 On Mon, Apr 28, 2014 at 5:23 PM, Raymond Auge 
 *raymond.a...@liferay.com*raymond.a...@liferay.com
 wrote:




On Mon, Apr 28, 2014 at 5:17 PM, Thomas Watson 
 *tjwat...@us.ibm.com*tjwat...@us.ibm.com
wrote:
   You seem to be implementing the work that the framework already
   does for ServiceFactory registrations.  The framework will only call 
 your
   factory once as long as the use count of the service is greater than 
 zero
   for a particular bundle.  The framework will then cache that service
   instance and keep returning it directly to the bundle without calling 
 the
   ServiceFactory again.

   Am I understanding your observation correctly?  You are stating
   that your factory is not called multiple times for the same consuming
   bundle?


I'm stating that when a single bundle is deployed which requests the
same service multiple times the factory method is called multiple times and
the bundle gets a different instance of the service each time.

I'm not sure if there is some sort of race condition but the client
bundle (in this case the felix webconsole) is requesting the HttpService
mutliple times (in the same thread) and each time the equinox framework is
invoking the HttpServiceFactory method returning different HttpServiceImpl
instance.

- Ray



   Tom



   [image: Inactive hide details for Raymond Auge ---04/28/2014
   03:24:26 PM---Hey all, I have to write code as follows in a 
 ServiceFactory]Raymond
   Auge ---04/28/2014 03:24:26 PM---Hey all, I have to write code as 
 follows
   in a ServiceFactory impl in order for my



   From: Raymond Auge *raymond.a...@liferay.com*raymond.a...@liferay.com
   
   To: Equinox development mailing list 
 *equinox-dev@eclipse.org*equinox-dev@eclipse.org
   
   Date: 04/28/2014 03:24 PM

   Subject: [equinox-dev] bug or not
   Sent by: 
 *equinox-dev-boun...@eclipse.org*equinox-dev-boun...@eclipse.org
   --



   Hey all,

   I have to write code as follows in a ServiceFactory impl in order
   for my factory to always return the same instance per bundle running on
   equinox 3.8.0.v20120529-1548

   ===
   public HttpService getService(
   Bundle bundle, ServiceRegistrationHttpService registration) {

   HttpServiceImpl httpServiceImpl = serviceMap.get(bundle);

   if (httpServiceImpl != null) {
   return httpServiceImpl;
   }

   httpServiceImpl = new HttpServiceImpl(
   bundle, contextController, legacyServiceIdGenerator);

   serviceMap.putIfAbsent(bundle, httpServiceImpl);

   return httpServiceImpl;
   }
   ===

   This seems clearly wrong as per the spec.

   It's certainly calling the getService method of the ServiceFactory
   which I'm guessing means it's not incorrectly registered.

   What could I be doing wrong? Was this ever a bug in equinox that
   was later resolved?

   --
 *Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
(@rotty3000)
   Senior Software Architect
 *Liferay, Inc.* http://www.liferay.com/ (@Liferay)
   ___
   equinox-dev mailing list
 *equinox-dev@eclipse.org* equinox-dev@eclipse.org
 *https://dev.eclipse.org/mailman/listinfo/equinox-dev*https://dev.eclipse.org/mailman/listinfo/equinox-dev


   ___
   equinox-dev

Re: [equinox-dev] bug or not

[Richard S. Hall]

On 4/28/14, 17:37 , Thomas Watson wrote:


Is your ServiceFactory.ungetService getting called each time?  If so 
then it is likely the felix webconsole is using an anti pattern like this:


HttpService service = bc.getService(httpServiceRef);
/// do some work with http service
bc.ungetService(httpServiceRef);



Is this really an anti-pattern? It doesn't seem so to me. If so, why 
don't we just deprecate ungetService() and tell all bundle implementers 
to not worry about ungetting, since they framework will do it for you 
when the bundle stops?


The fact that ungetting and recreating may be costly is an issue for the 
service implementer, it would seem, not the service consumer. If it 
costs a lot to create instances, the service factory could consider 
doing caching of instances and reusing them on subsequent requests.


Having client bundles call ungetService when they are done with a 
service that they may not use again for a while seems reasonable to me.


- richard



If they are getting/ungetting the service each time they are 
interacting with the service then the usecount for the service goes to 
zero for each usage which then causes the framework to free the 
service instance object.  The should be using something like a 
ServiceTracker to avoid this kind of anti-pattern.


Tom



Inactive hide details for Raymond Auge ---04/28/2014 04:26:50 PM---I 
agree that I should NOT have to implement this code. HowevRaymond Auge 
---04/28/2014 04:26:50 PM---I agree that I should NOT have to 
implement this code. However, I'm having to do so in order to work


From: Raymond Auge raymond.a...@liferay.com
To: Equinox development mailing list equinox-dev@eclipse.org
Date: 04/28/2014 04:26 PM
Subject: Re: [equinox-dev] bug or not
Sent by: equinox-dev-boun...@eclipse.org





I agree that I should NOT have to implement this code. However, I'm 
having to do so in order to work around this apparent issue.


- Ray


On Mon, Apr 28, 2014 at 5:23 PM, Raymond Auge 
_raymond.auge@liferay.com_ mailto:raymond.a...@liferay.com wrote:





On Mon, Apr 28, 2014 at 5:17 PM, Thomas Watson
_tjwat...@us.ibm.com_ mailto:tjwat...@us.ibm.com wrote:
You seem to be implementing the work that the framework
already does for ServiceFactory registrations.  The framework
will only call your factory once as long as the use count of
the service is greater than zero for a particular bundle.  The
framework will then cache that service instance and keep
returning it directly to the bundle without calling the
ServiceFactory again.

Am I understanding your observation correctly?  You are
stating that your factory is not called multiple times for the
same consuming bundle? 


I'm stating that when a single bundle is deployed which requests
the same service multiple times the factory method is called
multiple times and the bundle gets a different instance of the
service each time.

I'm not sure if there is some sort of race condition but the
client bundle (in this case the felix webconsole) is requesting
the HttpService mutliple times (in the same thread) and each time
the equinox framework is invoking the HttpServiceFactory method
returning different HttpServiceImpl instance.

- Ray


Tom



Inactive hide details for Raymond Auge ---04/28/2014 03:24:26
PM---Hey all, I have to write code as follows in a
ServiceFactoryRaymond Auge ---04/28/2014 03:24:26 PM---Hey
all, I have to write code as follows in a ServiceFactory impl
in order for my



From: Raymond Auge _raymond.auge@liferay.com_
mailto:raymond.a...@liferay.com
To: Equinox development mailing list
_equinox-dev@eclipse.org_ mailto:equinox-dev@eclipse.org
Date: 04/28/2014 03:24 PM

Subject: [equinox-dev] bug or not
Sent by: _equinox-dev-bounces@eclipse.org_
mailto:equinox-dev-boun...@eclipse.org





Hey all,

I have to write code as follows in a ServiceFactory impl in
order for my factory to always return the same instance per
bundle running on equinox 3.8.0.v20120529-1548

===
public HttpService getService(
Bundle bundle, ServiceRegistrationHttpService registration) {

HttpServiceImpl httpServiceImpl = serviceMap.get(bundle);

if (httpServiceImpl != null) {
return httpServiceImpl;
}

httpServiceImpl = new HttpServiceImpl(
bundle, contextController, legacyServiceIdGenerator);

serviceMap.putIfAbsent(bundle, httpServiceImpl);

return httpServiceImpl;
}
===

This seems clearly

Re: [equinox-dev] bug or not

[Thomas Watson]

But for the HttpService I consider this an anti-pattern.  When a bundle's
usecount reaches zero the HttpService implementation must unregister all
resources registered by that bundle.  If that is really what the webconsole
bundle wants then that is fine and I agree with you.  But if the webconsole
has resources (servlets) it does not want unregisered then it better keep
its usecount of the service (it is still using to serve resources) greater
than zero.

Tom





From:   Richard S. Hall he...@ungoverned.org
To: Equinox development mailing list equinox-dev@eclipse.org
Date:   04/28/2014 05:34 PM
Subject:Re: [equinox-dev] bug or not
Sent by:equinox-dev-boun...@eclipse.org



On 4/28/14, 17:37 , Thomas Watson wrote:


  Is your ServiceFactory.ungetService getting called each time?  If so
  then it is likely the felix webconsole is using an anti pattern like
  this:

  HttpService service = bc.getService(httpServiceRef);
  /// do some work with http service
  bc.ungetService(httpServiceRef);



Is this really an anti-pattern? It doesn't seem so to me. If so, why don't
we just deprecate ungetService() and tell all bundle implementers to not
worry about ungetting, since they framework will do it for you when the
bundle stops?

The fact that ungetting and recreating may be costly is an issue for the
service implementer, it would seem, not the service consumer. If it costs a
lot to create instances, the service factory could consider doing caching
of instances and reusing them on subsequent requests.

Having client bundles call ungetService when they are done with a service
that they may not use again for a while seems reasonable to me.

- richard




  If they are getting/ungetting the service each time they are
  interacting with the service then the usecount for the service goes
  to zero for each usage which then causes the framework to free the
  service instance object.  The should be using something like a
  ServiceTracker to avoid this kind of anti-pattern.

  Tom



  Inactive hide details for Raymond Auge ---04/28/2014
  04:26:50 PM---I agree that I should NOT have to implement this
  code. HowevRaymond Auge ---04/28/2014 04:26:50 PM---I agree that I
  should NOT have to implement this code. However, I'm having to do so
  in order to work

  From: Raymond Auge raymond.a...@liferay.com
  To: Equinox development mailing list equinox-dev@eclipse.org
  Date: 04/28/2014 04:26 PM
  Subject: Re: [equinox-dev] bug or not
  Sent by: equinox-dev-boun...@eclipse.org





  I agree that I should NOT have to implement this code. However, I'm
  having to do so in order to work around this apparent issue.

  - Ray


  On Mon, Apr 28, 2014 at 5:23 PM, Raymond Auge 
  raymond.a...@liferay.com wrote:



On Mon, Apr 28, 2014 at 5:17 PM, Thomas Watson 
tjwat...@us.ibm.com wrote:
  You seem to be implementing the work that the framework
  already does for ServiceFactory registrations.  The
  framework will only call your factory once as long as the
  use count of the service is greater than zero for a
  particular bundle.  The framework will then cache that
  service instance and keep returning it directly to the
  bundle without calling the ServiceFactory again.

  Am I understanding your observation correctly?  You are
  stating that your factory is not called multiple times
  for the same consuming bundle?


I'm stating that when a single bundle is deployed which
requests the same service multiple times the factory method is
called multiple times and the bundle gets a different instance
of the service each time.

I'm not sure if there is some sort of race condition but the
client bundle (in this case the felix webconsole) is requesting
the HttpService mutliple times (in the same thread) and each
time the equinox framework is invoking the HttpServiceFactory
method returning different HttpServiceImpl instance.

- Ray



  Tom



  Inactive hide details for Raymond Auge ---04/28/2014
  03:24:26 PM---Hey all, I have to write code as follows in
  a
ServiceFactoryRaymond Auge ---04/28/2014
  03:24:26 PM---Hey all, I have to write code as follows in
  a ServiceFactory impl in order for my




  From: Raymond Auge raymond.a...@liferay.com
  To: Equinox development mailing list 
  equinox-dev@eclipse.org
  Date: 04/28/2014 03:24 PM

  Subject: [equinox-dev] bug or not
  Sent by: equinox-dev-boun

Re: [equinox-dev] bug or not

[Richard Hall]

If you only meant for registering resources with the HttpService, then i
can agree with that. :-)

- richard
 On Apr 28, 2014 8:59 PM, Thomas Watson tjwat...@us.ibm.com wrote:

 But for the HttpService I consider this an anti-pattern.  When a bundle's
 usecount reaches zero the HttpService implementation must unregister all
 resources registered by that bundle.  If that is really what the webconsole
 bundle wants then that is fine and I agree with you.  But if the webconsole
 has resources (servlets) it does not want unregisered then it better keep
 its usecount of the service (it is still using to serve resources) greater
 than zero.

 Tom



 [image: Inactive hide details for Richard S. Hall ---04/28/2014 05:34:25
 PM---On 4/28/14, 17:37 , Thomas Watson wrote: ]Richard S. Hall
 ---04/28/2014 05:34:25 PM---On 4/28/14, 17:37 , Thomas Watson wrote: 

 From: Richard S. Hall he...@ungoverned.org
 To: Equinox development mailing list equinox-dev@eclipse.org
 Date: 04/28/2014 05:34 PM
 Subject: Re: [equinox-dev] bug or not
 Sent by: equinox-dev-boun...@eclipse.org
 --



 On 4/28/14, 17:37 , Thomas Watson wrote:


Is your ServiceFactory.ungetService getting called each time?  If so
then it is likely the felix webconsole is using an anti pattern like this:

HttpService service = bc.getService(httpServiceRef);
/// do some work with http service
bc.ungetService(httpServiceRef);



 Is this really an anti-pattern? It doesn't seem so to me. If so, why don't
 we just deprecate ungetService() and tell all bundle implementers to not
 worry about ungetting, since they framework will do it for you when the
 bundle stops?

 The fact that ungetting and recreating may be costly is an issue for the
 service implementer, it would seem, not the service consumer. If it costs a
 lot to create instances, the service factory could consider doing caching
 of instances and reusing them on subsequent requests.

 Having client bundles call ungetService when they are done with a service
 that they may not use again for a while seems reasonable to me.

 - richard



If they are getting/ungetting the service each time they are
interacting with the service then the usecount for the service goes to zero
for each usage which then causes the framework to free the service instance
object.  The should be using something like a ServiceTracker to avoid this
kind of anti-pattern.

Tom



[image: Inactive hide details for Raymond Auge ---04/28/2014 04:26:50
PM---I agree that I should NOT have to implement this code. Howev]Raymond
Auge ---04/28/2014 04:26:50 PM---I agree that I should NOT have to
implement this code. However, I'm having to do so in order to work

From: Raymond Auge *raymond.a...@liferay.com*raymond.a...@liferay.com
To: Equinox development mailing list 
 *equinox-dev@eclipse.org*equinox-dev@eclipse.org
Date: 04/28/2014 04:26 PM
Subject: Re: [equinox-dev] bug or not
Sent by: *equinox-dev-boun...@eclipse.org*equinox-dev-boun...@eclipse.org

--



I agree that I should NOT have to implement this code. However, I'm
having to do so in order to work around this apparent issue.

- Ray


On Mon, Apr 28, 2014 at 5:23 PM, Raymond Auge 
*raymond.a...@liferay.com* raymond.a...@liferay.com wrote:



   On Mon, Apr 28, 2014 at 5:17 PM, Thomas Watson 
   *tjwat...@us.ibm.com* tjwat...@us.ibm.com wrote:
  You seem to be implementing the work that the framework already
  does for ServiceFactory registrations.  The framework will only call 
 your
  factory once as long as the use count of the service is greater than 
 zero
  for a particular bundle.  The framework will then cache that service
  instance and keep returning it directly to the bundle without 
 calling the
  ServiceFactory again.

  Am I understanding your observation correctly?  You are stating
  that your factory is not called multiple times for the same consuming
  bundle?


   I'm stating that when a single bundle is deployed which requests
   the same service multiple times the factory method is called multiple 
 times
   and the bundle gets a different instance of the service each time.

   I'm not sure if there is some sort of race condition but the client
   bundle (in this case the felix webconsole) is requesting the HttpService
   mutliple times (in the same thread) and each time the equinox framework 
 is
   invoking the HttpServiceFactory method returning different 
 HttpServiceImpl
   instance.

   - Ray



  Tom



  [image: Inactive hide details for Raymond Auge ---04/28/2014
  03:24:26 PM---Hey all, I have to write code as follows in a 
 ServiceFactory]Raymond
  Auge ---04/28/2014 03:24:26 PM---Hey all, I have to write code as 
 follows
  in a ServiceFactory

Re: [equinox-dev] bug or not

[Raymond Auge]

Hey all,

I think I may have gotten a false positive on some tests because this week
I can't reproduce it.

Seems you should test code again after a week off. Glad I didn't file a
ticket.

Excuse the noise,
Ray
On Apr 28, 2014 9:07 PM, Richard Hall he...@ungoverned.org wrote:

 If you only meant for registering resources with the HttpService, then i
 can agree with that. :-)

 - richard
  On Apr 28, 2014 8:59 PM, Thomas Watson tjwat...@us.ibm.com wrote:

  But for the HttpService I consider this an anti-pattern.  When a
 bundle's usecount reaches zero the HttpService implementation must
 unregister all resources registered by that bundle.  If that is really what
 the webconsole bundle wants then that is fine and I agree with you.  But if
 the webconsole has resources (servlets) it does not want unregisered then
 it better keep its usecount of the service (it is still using to serve
 resources) greater than zero.

 Tom



 [image: Inactive hide details for Richard S. Hall ---04/28/2014
 05:34:25 PM---On 4/28/14, 17:37 , Thomas Watson wrote: ]Richard S.
 Hall ---04/28/2014 05:34:25 PM---On 4/28/14, 17:37 , Thomas Watson wrote: 

 From: Richard S. Hall he...@ungoverned.org
 To: Equinox development mailing list equinox-dev@eclipse.org
 Date: 04/28/2014 05:34 PM
 Subject: Re: [equinox-dev] bug or not
 Sent by: equinox-dev-boun...@eclipse.org
 --



 On 4/28/14, 17:37 , Thomas Watson wrote:


Is your ServiceFactory.ungetService getting called each time?  If so
then it is likely the felix webconsole is using an anti pattern like this:

HttpService service = bc.getService(httpServiceRef);
/// do some work with http service
bc.ungetService(httpServiceRef);



 Is this really an anti-pattern? It doesn't seem so to me. If so, why
 don't we just deprecate ungetService() and tell all bundle implementers to
 not worry about ungetting, since they framework will do it for you when the
 bundle stops?

 The fact that ungetting and recreating may be costly is an issue for the
 service implementer, it would seem, not the service consumer. If it costs a
 lot to create instances, the service factory could consider doing caching
 of instances and reusing them on subsequent requests.

 Having client bundles call ungetService when they are done with a service
 that they may not use again for a while seems reasonable to me.

 - richard



If they are getting/ungetting the service each time they are
interacting with the service then the usecount for the service goes to 
 zero
for each usage which then causes the framework to free the service 
 instance
object.  The should be using something like a ServiceTracker to avoid this
kind of anti-pattern.

Tom



[image: Inactive hide details for Raymond Auge ---04/28/2014 04:26:50
PM---I agree that I should NOT have to implement this code. Howev]Raymond
Auge ---04/28/2014 04:26:50 PM---I agree that I should NOT have to
implement this code. However, I'm having to do so in order to work

From: Raymond Auge *raymond.a...@liferay.com*raymond.a...@liferay.com
To: Equinox development mailing list 
 *equinox-dev@eclipse.org*equinox-dev@eclipse.org
Date: 04/28/2014 04:26 PM
Subject: Re: [equinox-dev] bug or not
Sent by: 
 *equinox-dev-boun...@eclipse.org*equinox-dev-boun...@eclipse.org

--



I agree that I should NOT have to implement this code. However, I'm
having to do so in order to work around this apparent issue.

- Ray


On Mon, Apr 28, 2014 at 5:23 PM, Raymond Auge 
*raymond.a...@liferay.com* raymond.a...@liferay.com wrote:



   On Mon, Apr 28, 2014 at 5:17 PM, Thomas Watson 
   *tjwat...@us.ibm.com* tjwat...@us.ibm.com wrote:
  You seem to be implementing the work that the framework already
  does for ServiceFactory registrations.  The framework will only 
 call your
  factory once as long as the use count of the service is greater 
 than zero
  for a particular bundle.  The framework will then cache that service
  instance and keep returning it directly to the bundle without 
 calling the
  ServiceFactory again.

  Am I understanding your observation correctly?  You are stating
  that your factory is not called multiple times for the same 
 consuming
  bundle?


   I'm stating that when a single bundle is deployed which requests
   the same service multiple times the factory method is called multiple 
 times
   and the bundle gets a different instance of the service each time.

   I'm not sure if there is some sort of race condition but the
   client bundle (in this case the felix webconsole) is requesting the
   HttpService mutliple times (in the same thread) and each time the 
 equinox
   framework is invoking the HttpServiceFactory method returning different
   HttpServiceImpl instance.

   - Ray

Re: [equinox-dev] bug or not

[Thomas Watson]

I meant for any service that maintains state for the duration of usage for
each using bundle.  Luckily that is not common for the services that the
OSGi specification defines.  HttpService is probably the most commonly used
one that has to maintain state for using bundles.  Regardless of that,
using a pattern that will constantly get/unget the same service over and
over cannot perform as well as using some higher level API like
SerivceTracker or declarative models like DS, or if you must use raw
BundleContext APIs then caching it yourself.  If it is a rarely used
service and you don't need it that often then I guess using the get/unget
each time is not that costly, but it still does not seem like something we
would want to recommend for services that are often used.  Regardless of
how cheap it is to construct there is still more code you have to run to
construct and get it each time.

Tom





From:   Richard Hall he...@ungoverned.org
To: Equinox development mailing list equinox-dev@eclipse.org
Date:   04/28/2014 08:08 PM
Subject:Re: [equinox-dev] bug or not
Sent by:equinox-dev-boun...@eclipse.org



If you only meant for registering resources with the HttpService, then i
can agree with that. :-)


- richard


On Apr 28, 2014 8:59 PM, Thomas Watson tjwat...@us.ibm.com wrote:
  But for the HttpService I consider this an anti-pattern.  When a bundle's
  usecount reaches zero the HttpService implementation must unregister all
  resources registered by that bundle.  If that is really what the
  webconsole bundle wants then that is fine and I agree with you.  But if
  the webconsole has resources (servlets) it does not want unregisered then
  it better keep its usecount of the service (it is still using to serve
  resources) greater than zero.

  Tom



  Inactive hide details for Richard S. Hall ---04/28/2014 05:34:25
  PM---On 4/28/14, 17:37 , Thomas Watson wrote: Richard S. Hall
  ---04/28/2014 05:34:25 PM---On 4/28/14, 17:37 , Thomas Watson wrote: 

  From: Richard S. Hall he...@ungoverned.org
  To: Equinox development mailing list equinox-dev@eclipse.org
  Date: 04/28/2014 05:34 PM
  Subject: Re: [equinox-dev] bug or not
  Sent by: equinox-dev-boun...@eclipse.org



  On 4/28/14, 17:37 , Thomas Watson wrote:

Is your ServiceFactory.ungetService getting called each time?  If
so then it is likely the felix webconsole is using an anti pattern
like this:

HttpService service = bc.getService(httpServiceRef);
/// do some work with http service
bc.ungetService(httpServiceRef);


  Is this really an anti-pattern? It doesn't seem so to me. If so, why
  don't we just deprecate ungetService() and tell all bundle implementers
  to not worry about ungetting, since they framework will do it for you
  when the bundle stops?

  The fact that ungetting and recreating may be costly is an issue for the
  service implementer, it would seem, not the service consumer. If it costs
  a lot to create instances, the service factory could consider doing
  caching of instances and reusing them on subsequent requests.

  Having client bundles call ungetService when they are done with a service
  that they may not use again for a while seems reasonable to me.

  - richard


If they are getting/ungetting the service each time they are
interacting with the service then the usecount for the service goes
to zero for each usage which then causes the framework to free the
service instance object.  The should be using something like a
ServiceTracker to avoid this kind of anti-pattern.

Tom



Inactive hide details for Raymond Auge ---04/28/2014
04:26:50 PM---I agree that I should NOT have to implement this
code. HowevRaymond Auge ---04/28/2014 04:26:50 PM---I agree that I
should NOT have to implement this code. However, I'm having to do
so in order to work

From: Raymond Auge raymond.a...@liferay.com
To: Equinox development mailing list equinox-dev@eclipse.org
Date: 04/28/2014 04:26 PM
Subject: Re: [equinox-dev] bug or not
Sent by: equinox-dev-boun...@eclipse.org





I agree that I should NOT have to implement this code. However, I'm
having to do so in order to work around this apparent issue.

- Ray


On Mon, Apr 28, 2014 at 5:23 PM, Raymond Auge 
raymond.a...@liferay.com wrote:



  On Mon, Apr 28, 2014 at 5:17 PM, Thomas Watson 
  tjwat...@us.ibm.com wrote:
You seem to be implementing the work that the framework
already does for ServiceFactory registrations.  The
framework will only call your factory once as long as
the use count of the service is greater than zero for a
particular bundle.  The framework will then cache that
service instance and keep returning

Re: [equinox-dev] bug or not

[Richard Hall]

I'd agree if you are using a service constantly, it doesn't makes sense to
release it after each use. It is less clear when it is not a constant need.

Of course, HttpService perhaps causes acute pain since it is from a time
before the whiteboard pattern...

- richard
 On Apr 28, 2014 9:54 PM, Thomas Watson tjwat...@us.ibm.com wrote:

 I meant for any service that maintains state for the duration of usage for
 each using bundle.  Luckily that is not common for the services that the
 OSGi specification defines.  HttpService is probably the most commonly used
 one that has to maintain state for using bundles.  Regardless of that,
 using a pattern that will constantly get/unget the same service over and
 over cannot perform as well as using some higher level API like
 SerivceTracker or declarative models like DS, or if you must use raw
 BundleContext APIs then caching it yourself.  If it is a rarely used
 service and you don't need it that often then I guess using the get/unget
 each time is not that costly, but it still does not seem like something we
 would want to recommend for services that are often used.  Regardless of
 how cheap it is to construct there is still more code you have to run to
 construct and get it each time.

 Tom



 [image: Inactive hide details for Richard Hall ---04/28/2014 08:08:47
 PM---If you only meant for registering resources with the HttpSer]Richard
 Hall ---04/28/2014 08:08:47 PM---If you only meant for registering
 resources with the HttpService, then i can agree with that. :-)

 From: Richard Hall he...@ungoverned.org
 To: Equinox development mailing list equinox-dev@eclipse.org
 Date: 04/28/2014 08:08 PM
 Subject: Re: [equinox-dev] bug or not
 Sent by: equinox-dev-boun...@eclipse.org
 --



 If you only meant for registering resources with the HttpService, then i
 can agree with that. :-)

 - richard

 On Apr 28, 2014 8:59 PM, Thomas Watson 
 *tjwat...@us.ibm.com*tjwat...@us.ibm.com
 wrote:

But for the HttpService I consider this an anti-pattern.  When a
bundle's usecount reaches zero the HttpService implementation must
unregister all resources registered by that bundle.  If that is really what
the webconsole bundle wants then that is fine and I agree with you.  But if
the webconsole has resources (servlets) it does not want unregisered then
it better keep its usecount of the service (it is still using to serve
resources) greater than zero.

Tom



[image: Inactive hide details for Richard S. Hall ---04/28/2014
05:34:25 PM---On 4/28/14, 17:37 , Thomas Watson wrote: ]Richard S.
Hall ---04/28/2014 05:34:25 PM---On 4/28/14, 17:37 , Thomas Watson wrote: 
 

From: Richard S. Hall *he...@ungoverned.org* he...@ungoverned.org
To: Equinox development mailing list 
 *equinox-dev@eclipse.org*equinox-dev@eclipse.org

Date: 04/28/2014 05:34 PM
Subject: Re: [equinox-dev] bug or not
Sent by: *equinox-dev-boun...@eclipse.org*equinox-dev-boun...@eclipse.org
--



On 4/28/14, 17:37 , Thomas Watson wrote:

   Is your ServiceFactory.ungetService getting called each time?  If
   so then it is likely the felix webconsole is using an anti pattern like
   this:

   HttpService service = bc.getService(httpServiceRef);
   /// do some work with http service
   bc.ungetService(httpServiceRef);


Is this really an anti-pattern? It doesn't seem so to me. If so, why
don't we just deprecate ungetService() and tell all bundle implementers to
not worry about ungetting, since they framework will do it for you when the
bundle stops?

The fact that ungetting and recreating may be costly is an issue for
the service implementer, it would seem, not the service consumer. If it
costs a lot to create instances, the service factory could consider doing
caching of instances and reusing them on subsequent requests.

Having client bundles call ungetService when they are done with a
service that they may not use again for a while seems reasonable to me.

- richard


   If they are getting/ungetting the service each time they are
   interacting with the service then the usecount for the service goes to 
 zero
   for each usage which then causes the framework to free the service 
 instance
   object.  The should be using something like a ServiceTracker to avoid 
 this
   kind of anti-pattern.

   Tom



   [image: Inactive hide details for Raymond Auge ---04/28/2014
   04:26:50 PM---I agree that I should NOT have to implement this code. 
 Howev]Raymond
   Auge ---04/28/2014 04:26:50 PM---I agree that I should NOT have to
   implement this code. However, I'm having to do so in order to work

   From: Raymond Auge 
 *raymond.a...@liferay.com*raymond.a...@liferay.com
   To: Equinox development mailing list 
 *equinox-dev@eclipse.org*equinox-dev@eclipse.org
   Date: 04/28/2014

[equinox-dev] Bug in event admin

[Alan D. Cabrera]

I found a bug in event admin but am not sure where I should report it.  Can 
someone point me to where bugs are reported?


Regards,
Alan

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Bug in event admin

[BJ Hargrave]

https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Equinox then select 
component Compendium and start the summary with [eventadmin].
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788





From:   Alan D. Cabrera l...@toolazydogs.com
To: equinox-dev@eclipse.org
Date:   2010/09/12 20:58
Subject:[equinox-dev] Bug in event admin
Sent by:equinox-dev-boun...@eclipse.org



I found a bug in event admin but am not sure where I should report it. Can 
someone point me to where bugs are reported?


Regards,
Alan

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] bug triage process

[Susan Franklin McCourt]

In the p2 call this week
(http://wiki.eclipse.org/Equinox/p2/Meetings/20081014#Minutes)
we talked about bug triage and trying to assign real owners to bugs.  We
also mentioned assigning them directly within the team when we open a bug,
to avoid a bunch of bug noise.

Just now I opened a bug, assigned it directly to Pascal.  But then I
remembered...it's important that when you first open a bug, you should
leave the owner as the inbox.  Otherwise people watching the inbox to keep
up with what's going on won't see the bug go by.

Just wanted to bring up this point.

susan___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] Bug in BundleLoader's findClass(String, boolean)?

[David Shepherdson]

Hello,

I've come across what appears to be a bug in the findClass(String,  
boolean) method in  
org.eclipse.osgi.framework.internal.core.BundleLoader. It doesn't seem  
to cope with arrays of basic Java types. For example, if I call


findClass(String[].class.getName())

...it throws a ClassNotFoundException.

From my reading of the OSGi spec, it sounds like it should be  
delegating to the parent classloader in such a case. However, looking  
at the code, the actual test it does is


name.startsWith(JAVA_PACKAGE)

...which in the case of an array will fail (the name of String[].class  
is '[Ljava.lang.String;', for example).


Should this code be changed so that, rather than just checking whether  
the class's name starts with 'java.', it checks whether the underlying  
type is a 'java.*' type?


Thank you,

David Shepherdson
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev