[jira] [Resolved] (FELIX-6034) Gogo JLine requirement doesn't allow to embed gogo.jline

[JIRA]

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

Jean-Baptiste Onofré resolved FELIX-6034.
-
Resolution: Not A Problem

> Gogo JLine requirement doesn't allow to embed gogo.jline
> 
>
> Key: FELIX-6034
> URL: https://issues.apache.org/jira/browse/FELIX-6034
> Project: Felix
>  Issue Type: Bug
>  Components: Gogo JLine
>Affects Versions: gogo.jline-1.1.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
>
> Felix Gogo Jline 1.1.2 introduced a Requirement:
> {code}
> @Requirement(
> effective = "active",
> namespace = "org.apache.felix.gogo",
> name = "command.implementation",
> version = "1.0.0"
> )
> {code}
> This requirement is a contract to find concrete command. However, in the case 
> of Gogo JLine embedded as a standalone bundle, waiting for commands 
> implementation (later on), this requirement doesn't allow to start. That's 
> the case in Apache Karaf shell.
> [~rotty3000] do you mind if I remove this requirement (as I did other fixes 
> like in {{Posix}} commands) ? We could add this Requirement in gogo.jline 2.x 
> and then, I will have to find a bypass or at least a fake command providing a 
> capability.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] felix pull request #169: [FELIX-6034] Remove Requirement from Gogo JLine

[jbonofre]

Github user jbonofre closed the pull request at:

https://github.com/apache/felix/pull/169


---

[jira] [Commented] (FELIX-6034) Gogo JLine requirement doesn't allow to embed gogo.jline

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-6034:
---

Github user jbonofre closed the pull request at:

https://github.com/apache/felix/pull/169


> Gogo JLine requirement doesn't allow to embed gogo.jline
> 
>
> Key: FELIX-6034
> URL: https://issues.apache.org/jira/browse/FELIX-6034
> Project: Felix
>  Issue Type: Bug
>  Components: Gogo JLine
>Affects Versions: gogo.jline-1.1.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
>
> Felix Gogo Jline 1.1.2 introduced a Requirement:
> {code}
> @Requirement(
> effective = "active",
> namespace = "org.apache.felix.gogo",
> name = "command.implementation",
> version = "1.0.0"
> )
> {code}
> This requirement is a contract to find concrete command. However, in the case 
> of Gogo JLine embedded as a standalone bundle, waiting for commands 
> implementation (later on), this requirement doesn't allow to start. That's 
> the case in Apache Karaf shell.
> [~rotty3000] do you mind if I remove this requirement (as I did other fixes 
> like in {{Posix}} commands) ? We could add this Requirement in gogo.jline 2.x 
> and then, I will have to find a bypass or at least a fake command providing a 
> capability.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FELIX-6034) Gogo JLine requirement doesn't allow to embed gogo.jline

[JIRA]

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

Jean-Baptiste Onofré updated FELIX-6034:

Fix Version/s: (was: gogo.jline-1.1.3)

> Gogo JLine requirement doesn't allow to embed gogo.jline
> 
>
> Key: FELIX-6034
> URL: https://issues.apache.org/jira/browse/FELIX-6034
> Project: Felix
>  Issue Type: Bug
>  Components: Gogo JLine
>Affects Versions: gogo.jline-1.1.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
>
> Felix Gogo Jline 1.1.2 introduced a Requirement:
> {code}
> @Requirement(
> effective = "active",
> namespace = "org.apache.felix.gogo",
> name = "command.implementation",
> version = "1.0.0"
> )
> {code}
> This requirement is a contract to find concrete command. However, in the case 
> of Gogo JLine embedded as a standalone bundle, waiting for commands 
> implementation (later on), this requirement doesn't allow to start. That's 
> the case in Apache Karaf shell.
> [~rotty3000] do you mind if I remove this requirement (as I did other fixes 
> like in {{Posix}} commands) ? We could add this Requirement in gogo.jline 2.x 
> and then, I will have to find a bypass or at least a fake command providing a 
> capability.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[VOTE] Release Apache Felix Gogo JLine 1.1.4

[Jean-Baptiste Onofré]

Hi all,

We solved 3 issues in this release (release notes):
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12344851

Staging repository:
https://repository.apache.org/content/repositories/orgapachefelix-1278/

Please vote to approve this release:

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

This vote will be open for 72 hours.

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

Re: [VOTE] Release Apache Felix Gogo JLine 1.1.4

[Christian Schneider]

+1

Christian

Am Fr., 25. Jan. 2019 um 13:55 Uhr schrieb Jean-Baptiste Onofré <
j...@nanthrax.net>:

> Hi all,
>
> We solved 3 issues in this release (release notes):
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12344851
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1278/
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
>
> This vote will be open for 72 hours.
>
> Thanks,
> Regards
> JB
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>


-- 
-- 
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com

Re: [VOTE] Release Apache Felix Gogo JLine 1.1.4

[David Bosschaert]

+1

David

On Fri, 25 Jan 2019 at 12:55, Jean-Baptiste Onofré  wrote:

> Hi all,
>
> We solved 3 issues in this release (release notes):
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12344851
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1278/
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
>
> This vote will be open for 72 hours.
>
> Thanks,
> Regards
> JB
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Showing commits on JIRA issues

[Richard S. Hall]

Hey everyone,

Back in the old days we used to be able to see associated commits on a 
JIRA issue if we included the JIRA issue number in the commit message. I 
recently wanted to check on the diff of a commit for one of Karl's 
commits on FELIX-6035 where he did reference the issue number in the 
commit message, but I can't find it on the JIRA issue.


Is this broken, did we stop doing this, or am I missing it?

-> richard

[jira] [Commented] (FELIX-6036) Race condition prevents optional/greedy ref setter method from being called

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-6036:
---

Github user tjwatson closed the pull request at:

https://github.com/apache/felix/pull/170


> Race condition prevents optional/greedy ref setter method from being called
> ---
>
> Key: FELIX-6036
> URL: https://issues.apache.org/jira/browse/FELIX-6036
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.1.14
>Reporter: Brent Daniel
>Assignee: Thomas Watson
>Priority: Major
>
> I have a component with an optional/dynamic/greedy reference. The target is 
> registered directly with OSGi using BundleContext.registerService(). 
> Normally, either SingleDynamicCustomizer.addedService() or 
> SingleComponentManager.createImplementationObject() will succeed in binding 
> the reference, but there is a race condition that can prevent the setter 
> method from ever being called. 
>  
> The failure path is as follows:
> 1) SingleComponentManager.createImplementationObject calls open() on each of 
> its DependencyManagers. This generates an OpenStatus where the RefPair list 
> is empty because our target has not been registered yet. 
> 2) Before createImplementationObject() can set the component context, the 
> customizer's addedService() method is called in response to the target 
> service registration. It attempts to bind the target service, but that will 
> not happen because the component context has not been set yet. 
> 3) createImplementationObject then creates the implementation, sets the 
> component context, and goes through the list of OpenStatus objects to bind 
> target services. The RefPair list for the OpenStatus object will still be 
> empty, so we will not call the setter method for the reference we're 
> concerned about. 
>  
> I'm not sure of a good way to fix this. I couldn't come up with a good 
> approach using synchronization or earlier creation of the implementation 
> object. At the moment I am working around this by refreshing the list of 
> RefPairs in the OpenStatus object at the top of 
> DependencyManager.bindDependency():
>  
> {code:java}
> // Refresh ref list before binding
> synchronized(m_tracker.tracked()) {
>status.refs=m_customizer.getRefs(status.trackingCount);
> }
> {code}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] felix pull request #170: FELIX-6036 - avoid stashing stale RefPair objects i...

[tjwatson]

Github user tjwatson closed the pull request at:

https://github.com/apache/felix/pull/170


---

[jira] [Resolved] (FELIX-6036) Race condition prevents optional/greedy ref setter method from being called

[Thomas Watson (JIRA)]

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

Thomas Watson resolved FELIX-6036.
--
   Resolution: Fixed
Fix Version/s: scr-2.1.16

Will be fixed in next release of SCR

> Race condition prevents optional/greedy ref setter method from being called
> ---
>
> Key: FELIX-6036
> URL: https://issues.apache.org/jira/browse/FELIX-6036
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.1.14
>Reporter: Brent Daniel
>Assignee: Thomas Watson
>Priority: Major
> Fix For: scr-2.1.16
>
>
> I have a component with an optional/dynamic/greedy reference. The target is 
> registered directly with OSGi using BundleContext.registerService(). 
> Normally, either SingleDynamicCustomizer.addedService() or 
> SingleComponentManager.createImplementationObject() will succeed in binding 
> the reference, but there is a race condition that can prevent the setter 
> method from ever being called. 
>  
> The failure path is as follows:
> 1) SingleComponentManager.createImplementationObject calls open() on each of 
> its DependencyManagers. This generates an OpenStatus where the RefPair list 
> is empty because our target has not been registered yet. 
> 2) Before createImplementationObject() can set the component context, the 
> customizer's addedService() method is called in response to the target 
> service registration. It attempts to bind the target service, but that will 
> not happen because the component context has not been set yet. 
> 3) createImplementationObject then creates the implementation, sets the 
> component context, and goes through the list of OpenStatus objects to bind 
> target services. The RefPair list for the OpenStatus object will still be 
> empty, so we will not call the setter method for the reference we're 
> concerned about. 
>  
> I'm not sure of a good way to fix this. I couldn't come up with a good 
> approach using synchronization or earlier creation of the implementation 
> object. At the moment I am working around this by refreshing the list of 
> RefPairs in the OpenStatus object at the top of 
> DependencyManager.bindDependency():
>  
> {code:java}
> // Refresh ref list before binding
> synchronized(m_tracker.tracked()) {
>status.refs=m_customizer.getRefs(status.trackingCount);
> }
> {code}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Showing commits on JIRA issues

[Jean-Baptiste Onofré]

Hi Richard,

good question, it's possible to be related to a change made by INFRA.
It's worth to create a Jira at INFRA IMHO.

Regards
JB

On 25/01/2019 15:35, Richard S. Hall wrote:
> Hey everyone,
> 
> Back in the old days we used to be able to see associated commits on a
> JIRA issue if we included the JIRA issue number in the commit message. I
> recently wanted to check on the diff of a commit for one of Karl's
> commits on FELIX-6035 where he did reference the issue number in the
> commit message, but I can't find it on the JIRA issue.
> 
> Is this broken, did we stop doing this, or am I missing it?
> 
> -> richard

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

[jira] [Commented] (FELIX-6037) Commons FileUpload 1.4 + Apache Felix Bundle WebConsole

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on FELIX-6037:
-

This sounds like a bug in commons fileupload; they seem to move the file but 
the tmp file already exists.And it worked in previous versions. 

We could change all our code to use an input stream but that's a lot of work, 
especially as the web console first reads the bundle to get the symbolic name 
and then it needs to pass an input stream to the framework for an update.
We could also simply create the tmp file and then use the input stream from the 
item and save it into the file manually, but tht will create two copies of the 
tmp file (one created by fileupload and one by the web console)
There are options, but still I think the fix should be done in commons 
fileupload

> Commons FileUpload 1.4 + Apache Felix Bundle WebConsole
> ---
>
> Key: FELIX-6037
> URL: https://issues.apache.org/jira/browse/FELIX-6037
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Affects Versions: webconsole-4.3.8
>Reporter: Dan Klco
>Priority: Major
>
> When using Commons Fileupload with the Apache Felix Bundle webconsole, I've 
> found an error when uploading SNAPSHOT bundles to the webconsole. The process 
> fails with the following exception:
> 23.01.2019 06:56:29.098 *ERROR* [qtp24255790-48] org.apache.felix.http.jetty 
> Problem accessing uploaded bundle file: 
> org.apache.sling.cms.ui-0.11.3-SNAPSHOT.jar 
> (org.apache.commons.io.FileExistsException: Destination 
> '/var/folders/lk/m1djs7v96_b9xfy_7_xhn33hgq/T/install8148467763631161526.tmp'
>  already exists)
> org.apache.commons.io.FileExistsException: Destination 
> '/var/folders/lk/m1djs7v96_b9xfy_7_xhn33hgq/T/install8148467763631161526.tmp'
>  already exists
> at org.apache.commons.io.FileUtils.moveFile(FileUtils.java:3001) 
> [org.apache.commons.io:2.6.0]
> at 
> org.apache.commons.fileupload.disk.DiskFileItem.write(DiskFileItem.java:405) 
> [org.apache.commons.commons-fileupload:1.4.0]
> at 
> org.apache.felix.webconsole.internal.core.BundlesServlet.installBundles(BundlesServlet.java:1553)
>  [org.apache.felix.webconsole:4.3.8]
> at 
> org.apache.felix.webconsole.internal.core.BundlesServlet.doPost(BundlesServlet.java:330)
>  [org.apache.felix.webconsole:4.3.8]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:644) 
> [org.apache.felix.http.servlet-api:1.1.2]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:725) 
> [org.apache.felix.http.servlet-api:1.1.2]
> at 
> org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:563)
>  [org.apache.felix.webconsole:4.3.8]
> at 
> org.apache.felix.webconsole.internal.servlet.OsgiManager$3.run(OsgiManager.java:465)
>  [org.apache.felix.webconsole:4.3.8]
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:461)
>  [org.apache.felix.webconsole:4.3.8]
> at 
> org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:120)
>  [org.apache.felix.http.jetty:4.0.6]
> at 
> org.apache.felix.http.base.internal.dispatch.InvocationChain.doFilter(InvocationChain.java:86)
>  [org.apache.felix.http.jetty:4.0.6]
> at org.apache.sling.i18n.impl.I18NFilter.doFilter(I18NFilter.java:131) 
> [org.apache.sling.i18n:2.5.14]
> at 
> org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:135)
>  [org.apache.felix.http.jetty:4.0.6]
> at 
> org.apache.felix.http.base.internal.dispatch.InvocationChain.doFilter(InvocationChain.java:81)
>  [org.apache.felix.http.jetty:4.0.6]
> at 
> org.apache.felix.http.base.internal.dispatch.Dispatcher$1.doFilter(Dispatcher.java:146)
>  [org.apache.felix.http.jetty:4.0.6]
> at 
> org.apache.felix.http.base.internal.whiteboard.WhiteboardManager$2.doFilter(WhiteboardManager.java:1014)
>  [org.apache.felix.http.jetty:4.0.6]
> at 
> org.apache.felix.http.sslfilter.internal.SslFilter.doFilter(SslFilter.java:97)
>  [org.apache.felix.http.sslfilter:1.2.6]
> at 
> org.apache.felix.http.base.internal.handler.PreprocessorHandler.handle(PreprocessorHandler.java:133)
>  [org.apache.felix.http.jetty:4.0.6]
> at 
> org.apache.felix.http.base.internal.whiteboard.WhiteboardManager$2.doFilter(WhiteboardManager.java:1020)
>  [org.apache.felix.http.jetty:4.0.6]
> at 
> org.apache.felix.http.base.internal.whiteboard.WhiteboardManager.invokePreprocessors(WhiteboardManager.java:1024)
>  [org.apache.felix.http.jetty:4.0.6]
> at 
> org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:91)
>  [org.apache.felix.http.jetty:4.0.6]
> at 
> org.apache.felix.http.base.internal.dispatch.Dispatch

[jira] [Commented] (FELIX-6025) Create ScriptedHealthCheck

[Georg Henzler (JIRA)]

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

Georg Henzler commented on FELIX-6025:
--

Slightly refactored for reusability from Sling in 
[r1852182|http://svn.apache.org/r1852182]

> Create ScriptedHealthCheck
> --
>
> Key: FELIX-6025
> URL: https://issues.apache.org/jira/browse/FELIX-6025
> Project: Felix
>  Issue Type: New Feature
>  Components: Health Checks
>Reporter: Georg Henzler
>Assignee: Georg Henzler
>Priority: Major
>
> Allow to create health via script where the script source is either
> * the OSGi configuration itself
> * via url reference (would usually be a file url)
> It should support the same languages as the felix script console [1] does.
> [1]
> http://felix.apache.org/documentation/subprojects/apache-felix-script-console-plugin.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] felix pull request #171: pull back in Java 7 support for gogo runtime,shell ...

[sebratton]

GitHub user sebratton opened a pull request:

https://github.com/apache/felix/pull/171

pull back in Java 7 support for gogo runtime,shell and console

This is for jira FELIX-6038

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/sebratton/felix supportJava7

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/171.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #171


commit 52326f130881027a0117ca253274261ed8045b7f
Author: Samuel E Bratton 
Date:   2019-01-23T16:06:52Z

pull back in Java 7 support for gogo runtime,shell and console




---

[jira] [Commented] (FELIX-6038) Need gogo command, runtime, and shell to support java 7

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-6038:
---

GitHub user sebratton opened a pull request:

https://github.com/apache/felix/pull/171

pull back in Java 7 support for gogo runtime,shell and console

This is for jira FELIX-6038

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/sebratton/felix supportJava7

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/171.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #171


commit 52326f130881027a0117ca253274261ed8045b7f
Author: Samuel E Bratton 
Date:   2019-01-23T16:06:52Z

pull back in Java 7 support for gogo runtime,shell and console




> Need gogo command, runtime, and shell to support java 7 
> 
>
> Key: FELIX-6038
> URL: https://issues.apache.org/jira/browse/FELIX-6038
> Project: Felix
>  Issue Type: Improvement
>  Components: Gogo Command, Gogo Runtime, Gogo Shell
>Affects Versions: gogo.runtime-1.1.2, gogo.shell-1.1.2, gogo.command-1.1.0
>Reporter: Samuel Bratton
>Assignee: Thomas Watson
>Priority: Minor
>
> Command, runtime, and shell currently produce bundles that require JavaSE 
> version=1.8. We need to continue support for java 7 a bit longer. This will 
> need updates to some poms and minor syntax changes to convert code that uses 
> new Java 8 syntax back to Java 7.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [DISCUSS] First release of health check modules annotation, api, core, generalchecks and webconsoleplugin

[Georg Henzler]

Having thought a bit more about this, for most bundles implementing a 
health check it is more of an optional extension. This means bundle-XYZ 
primarily will provide the functionality XYZ with an optional health 
check testing state around functionality XYZ in action. Usually you 
would even make the package dependency to org.apache.felix.hc.api 
optional with the result that


- if bundle org.apache.sling.hc.api is *not* available,
  functionality XYZ is still fully working
- if bundle org.apache.sling.hc.api *is* available,
  functionality XYZ is working and can be checked via provided HC(s)

So I think it's fine to start without an explicitly declared capability, 
we can add this easily later if desired.


-Georg


On 2019-01-21 15:06, Raymond Auge wrote:
On Mon, Jan 21, 2019 at 2:19 AM Georg Henzler  
wrote:



Hi Ray,

so your suggestion is more about referring to a capability like
"org.apache.felix.healthcheck" by using requirements in other bundles
than writing a health check that ensures the framework provides a
certain non-healthcheck-related capability.



Precisely,

- Ray




> I can probably try it out and submit the proper cap&req.

that would be great!

-Georg

Re: Showing commits on JIRA issues

[Richard S. Hall]

I do see that a commit did appear on the sidebar of issue FELIX-6035 
under "Development". Unforunately, I am unable to view it because it 
wants me to authenticate FishEye and that appears to be impossible for 
me to do.


Ah, the good ol' days, when I could just click on the commit in the 
issue's activity log...


On 1/25/19 09:43 , Jean-Baptiste Onofré wrote:

Hi Richard,

good question, it's possible to be related to a change made by INFRA.
It's worth to create a Jira at INFRA IMHO.

Regards
JB

On 25/01/2019 15:35, Richard S. Hall wrote:

Hey everyone,

Back in the old days we used to be able to see associated commits on a
JIRA issue if we included the JIRA issue number in the commit message. I
recently wanted to check on the diff of a commit for one of Karl's
commits on FELIX-6035 where he did reference the issue number in the
commit message, but I can't find it on the JIRA issue.

Is this broken, did we stop doing this, or am I missing it?

-> richard

Add my key to https://dist.apache.org/repos/dist/release/felix/KEYS

[Georg Henzler]

Hi PMC-members,

could someone please add my key to list [1] as described in the release 
docu [2]? See attached file toadd.key.


Thanks!
Georg

[1] https://dist.apache.org/repos/dist/release/felix/KEYS
[2] 
http://felix.apache.org/documentation/development/release-management-nexus.html#appendix-a-create-and-add-your-key-to-httpwwwapacheorgdistfelixkeys

Re: Add my key to https://dist.apache.org/repos/dist/release/felix/KEYS

[Georg Henzler]

Looks like the attachment didn't come through, so see [3] for the 
contents of toadd.key


On 2019-01-25 23:06, Georg Henzler wrote:

Hi PMC-members,

could someone please add my key to list [1] as described in the
release docu [2]? See attached file toadd.key.

Thanks!
Georg

[1] https://dist.apache.org/repos/dist/release/felix/KEYS
[2]
http://felix.apache.org/documentation/development/release-management-nexus.html#appendix-a-create-and-add-your-key-to-httpwwwapacheorgdistfelixkeys



[3]


pub   rsa2048 2018-10-09 [SC] [expires: 2020-10-08]
  34456ED30980EAD976FA50E33C7DEF7D6A42B333
uid   [ultimate] Georg Henzler 
sig 33C7DEF7D6A42B333 2018-10-09  Georg Henzler 


sub   rsa2048 2018-10-09 [E] [expires: 2020-10-08]
sig  3C7DEF7D6A42B333 2018-10-09  Georg Henzler 



-BEGIN PGP PUBLIC KEY BLOCK-

mQENBFu9J7wBCAC9WGaJwY3chAvX0nU+NnUNq8JxGuOUexUpm2ubKJ8KNzEp6O7Z
pOGt4Tfuzgy7t9OMS+fCuAKLBCsns8376BxEAA3AQriGPyFUM8XncNo+TeBsd2Hy
SlLjyT5uAqks+/lAoVqeXmfgMbHS/aMx4INC5evyAarFegpqK91WR4X/6NqZ1eza
cQsN6zC6FUg8WJ84ZfYmxX5DUXE8zT1spQ8kwWnJarxG3cKLCH2p7NtWe2dZr+3O
d5gQv/hVZWDi5prbiRJPrUgOBXZrswYSzO+NKFneETxsBWDFObCLNPYSWukyLsRx
URpkg4I7KE3UKXss2nl8nv3h8ab50wISjGpHABEBAAG0I0dlb3JnIEhlbnpsZXIg
PGdoZW56bGVyQGFwYWNoZS5vcmc+iQFUBBMBCAA+FiEENEVu0wmA6tl2+lDjPH3v
fWpCszMFAlu9J7wCGwMFCQPCZwAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ
PH3vfWpCszOVvwgAlf09YG6Rv1uls/H5Cbov9oryJqbIFH1LfMhfuhdgxLS/hUHD
YNOhjX10IoZq5cR3GAEZYomwLX8Ov8qEEnIt+55dYwvFh1m77Ca9aQrItwvr23jX
dWExk+tglhanWAfM9jC40p6qM0QRU2xvmiZmjpKwNEqEakI26mFSnYiZWRpCXZKi
0MyPHd2gzRkMdTNpYj5ZbRhurPEjX8VNnUfAX++ABSI8+xFwghm9mZcDbbJqJ8GB
r+oPhEbVXXTPYBHp5ymqahda90v6Y5I/XXN9NZW+lXpbFbzLuQ2NHhYV1BO//Zas
yDDrtOD/Vam1bHs8Gq1NNWLZXI4pmNQ49hlcILkBDQRbvSe8AQgAsQ/4/UixAE7A
8AX2TaG/rMJ+qPM9DRXgRKCJs6zgRUFtwdvpOXkv+nX5Hhboevjn0TurwOaWalSg
i1iiIzEhIn/X9biYq9li0aIvIXxnw4hapSLRAObv/a5OQrywmgkX/H8nYdQyr64X
A8SLZih0VPYVX8udR+ock2hRf8kA/kflv+9QiG3l86Rt5Ayl7tqKqTpTozObnsi3
mHtmyLVEx1ng01ArNRYqVtYeEin6+tjT4wakRPOZIY403m1IPJHXBOk0fdcW0Zs+
SkPGesyPa4BveCKxv14LWP/DUcc2Yk6z1NKYMpZlXOgBcjlqZuRS2FzJfL1QukP1
FuWWjO2h6wARAQABiQE8BBgBCAAmFiEENEVu0wmA6tl2+lDjPH3vfWpCszMFAlu9
J7wCGwwFCQPCZwAACgkQPH3vfWpCszMw9ggApDmLWYV+ZgRY5WKEZkyWrdB9k/eF
pFn8lT0JXjB/UwRH00uAi0sYyKbH3ERD2rcOD8JhKlQf2A+NLBEwzptRbDKW78mP
kiFMuUe5R55GPGDn13uO9eUyqI7VLXD2SQex2+mDGKvPvhVxnJC9o/wjx2h9vVyZ
igT9hMoc1vrCYMJOa6kYxL1r5XunqMRMpOflTBKzaBX1nkbULTnEaPVbQS8wpoah
2WNB5v32i+fyZMFYGyqR4MeIfrvptxSMBN99SsAAncudfUIGM+X7Z/c/6P1CNztn
JkDeE4i0ePtsjUmcmtbxXJOuAteaj4SFPKfKkEZzbnzIkBB8GNEknrhxXA==
=NLRB
-END PGP PUBLIC KEY BLOCK-

[jira] [Commented] (FELIX-6026) SCR command problems

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-6026:
---

GitHub user tjwatson opened a pull request:

https://github.com/apache/felix/pull/172

FELIX-6026 - Fix ScrInfo service issues



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/tjwatson/felix FELIX-6026

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/172.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #172


commit 07c1ebab265fc88fb95f34efad8a51e73220b009
Author: Tom Watson 
Date:   2019-01-25T14:27:14Z

FELIX-6026 - Fix ScrInfo service issues




> SCR command problems
> 
>
> Key: FELIX-6026
> URL: https://issues.apache.org/jira/browse/FELIX-6026
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.1.14
>Reporter: Brent Daniel
>Priority: Major
>
> There are a couple of problems resulting from the changes to SCR commands in 
> [https://github.com/apache/felix/pull/130] .
> First, ScrInfo is not registered as a service when ds.info.service=true is 
> specified in config admin. The core issue is that the setScrCommand method of 
> ScrConfigurationImpl is never called, so it will not be available in this 
> block around line 208:
> {code:java}
> if ( scrCommand != null )
> {
> scrCommand.updateProvideScrInfoService( infoAsService() );
> }
> {code}
> That can be fixed by adding the following to the Activator.doStart() method 
> (though I haven't spent much time thinking about better solutions):
> {code:java}
> m_configuration.setScrCommand(m_componentCommands);
> {code}
> Second, the ScrInfo list() and info() implementation no longer accept a null 
> component ID. The javadoc for ScrInfo still indicates that a null ID will 
> give information for all components. We have found this function invaluable 
> for dumping the state of every component, so it would be nice to get this 
> back.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] felix pull request #172: FELIX-6026 - Fix ScrInfo service issues

[tjwatson]

GitHub user tjwatson opened a pull request:

https://github.com/apache/felix/pull/172

FELIX-6026 - Fix ScrInfo service issues



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/tjwatson/felix FELIX-6026

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/172.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #172


commit 07c1ebab265fc88fb95f34efad8a51e73220b009
Author: Tom Watson 
Date:   2019-01-25T14:27:14Z

FELIX-6026 - Fix ScrInfo service issues




---

[GitHub] felix pull request #172: FELIX-6026 - Fix ScrInfo service issues

[tjwatson]

Github user tjwatson closed the pull request at:

https://github.com/apache/felix/pull/172


---

[jira] [Commented] (FELIX-6026) SCR command problems

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-6026:
---

Github user tjwatson closed the pull request at:

https://github.com/apache/felix/pull/172


> SCR command problems
> 
>
> Key: FELIX-6026
> URL: https://issues.apache.org/jira/browse/FELIX-6026
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.1.14
>Reporter: Brent Daniel
>Priority: Major
>
> There are a couple of problems resulting from the changes to SCR commands in 
> [https://github.com/apache/felix/pull/130] .
> First, ScrInfo is not registered as a service when ds.info.service=true is 
> specified in config admin. The core issue is that the setScrCommand method of 
> ScrConfigurationImpl is never called, so it will not be available in this 
> block around line 208:
> {code:java}
> if ( scrCommand != null )
> {
> scrCommand.updateProvideScrInfoService( infoAsService() );
> }
> {code}
> That can be fixed by adding the following to the Activator.doStart() method 
> (though I haven't spent much time thinking about better solutions):
> {code:java}
> m_configuration.setScrCommand(m_componentCommands);
> {code}
> Second, the ScrInfo list() and info() implementation no longer accept a null 
> component ID. The javadoc for ScrInfo still indicates that a null ID will 
> give information for all components. We have found this function invaluable 
> for dumping the state of every component, so it would be nice to get this 
> back.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (FELIX-6026) SCR command problems

[Thomas Watson (JIRA)]

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

Thomas Watson resolved FELIX-6026.
--
   Resolution: Fixed
Fix Version/s: scr-2.1.16

Will be fixed in 2.1.16 release.

> SCR command problems
> 
>
> Key: FELIX-6026
> URL: https://issues.apache.org/jira/browse/FELIX-6026
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.1.14
>Reporter: Brent Daniel
>Priority: Major
> Fix For: scr-2.1.16
>
>
> There are a couple of problems resulting from the changes to SCR commands in 
> [https://github.com/apache/felix/pull/130] .
> First, ScrInfo is not registered as a service when ds.info.service=true is 
> specified in config admin. The core issue is that the setScrCommand method of 
> ScrConfigurationImpl is never called, so it will not be available in this 
> block around line 208:
> {code:java}
> if ( scrCommand != null )
> {
> scrCommand.updateProvideScrInfoService( infoAsService() );
> }
> {code}
> That can be fixed by adding the following to the Activator.doStart() method 
> (though I haven't spent much time thinking about better solutions):
> {code:java}
> m_configuration.setScrCommand(m_componentCommands);
> {code}
> Second, the ScrInfo list() and info() implementation no longer accept a null 
> component ID. The javadoc for ScrInfo still indicates that a null ID will 
> give information for all components. We have found this function invaluable 
> for dumping the state of every component, so it would be nice to get this 
> back.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Add my key to https://dist.apache.org/repos/dist/release/felix/KEYS

[Karl Pauls]

Done.

regards,

Karl

On Fri, Jan 25, 2019 at 11:16 PM Georg Henzler  wrote:
>
> Looks like the attachment didn't come through, so see [3] for the
> contents of toadd.key
>
> On 2019-01-25 23:06, Georg Henzler wrote:
> > Hi PMC-members,
> >
> > could someone please add my key to list [1] as described in the
> > release docu [2]? See attached file toadd.key.
> >
> > Thanks!
> > Georg
> >
> > [1] https://dist.apache.org/repos/dist/release/felix/KEYS
> > [2]
> > http://felix.apache.org/documentation/development/release-management-nexus.html#appendix-a-create-and-add-your-key-to-httpwwwapacheorgdistfelixkeys
>
>
> [3]
>
>
> pub   rsa2048 2018-10-09 [SC] [expires: 2020-10-08]
>34456ED30980EAD976FA50E33C7DEF7D6A42B333
> uid   [ultimate] Georg Henzler 
> sig 33C7DEF7D6A42B333 2018-10-09  Georg Henzler
> 
> sub   rsa2048 2018-10-09 [E] [expires: 2020-10-08]
> sig  3C7DEF7D6A42B333 2018-10-09  Georg Henzler
> 
>
> -BEGIN PGP PUBLIC KEY BLOCK-
>
> mQENBFu9J7wBCAC9WGaJwY3chAvX0nU+NnUNq8JxGuOUexUpm2ubKJ8KNzEp6O7Z
> pOGt4Tfuzgy7t9OMS+fCuAKLBCsns8376BxEAA3AQriGPyFUM8XncNo+TeBsd2Hy
> SlLjyT5uAqks+/lAoVqeXmfgMbHS/aMx4INC5evyAarFegpqK91WR4X/6NqZ1eza
> cQsN6zC6FUg8WJ84ZfYmxX5DUXE8zT1spQ8kwWnJarxG3cKLCH2p7NtWe2dZr+3O
> d5gQv/hVZWDi5prbiRJPrUgOBXZrswYSzO+NKFneETxsBWDFObCLNPYSWukyLsRx
> URpkg4I7KE3UKXss2nl8nv3h8ab50wISjGpHABEBAAG0I0dlb3JnIEhlbnpsZXIg
> PGdoZW56bGVyQGFwYWNoZS5vcmc+iQFUBBMBCAA+FiEENEVu0wmA6tl2+lDjPH3v
> fWpCszMFAlu9J7wCGwMFCQPCZwAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ
> PH3vfWpCszOVvwgAlf09YG6Rv1uls/H5Cbov9oryJqbIFH1LfMhfuhdgxLS/hUHD
> YNOhjX10IoZq5cR3GAEZYomwLX8Ov8qEEnIt+55dYwvFh1m77Ca9aQrItwvr23jX
> dWExk+tglhanWAfM9jC40p6qM0QRU2xvmiZmjpKwNEqEakI26mFSnYiZWRpCXZKi
> 0MyPHd2gzRkMdTNpYj5ZbRhurPEjX8VNnUfAX++ABSI8+xFwghm9mZcDbbJqJ8GB
> r+oPhEbVXXTPYBHp5ymqahda90v6Y5I/XXN9NZW+lXpbFbzLuQ2NHhYV1BO//Zas
> yDDrtOD/Vam1bHs8Gq1NNWLZXI4pmNQ49hlcILkBDQRbvSe8AQgAsQ/4/UixAE7A
> 8AX2TaG/rMJ+qPM9DRXgRKCJs6zgRUFtwdvpOXkv+nX5Hhboevjn0TurwOaWalSg
> i1iiIzEhIn/X9biYq9li0aIvIXxnw4hapSLRAObv/a5OQrywmgkX/H8nYdQyr64X
> A8SLZih0VPYVX8udR+ock2hRf8kA/kflv+9QiG3l86Rt5Ayl7tqKqTpTozObnsi3
> mHtmyLVEx1ng01ArNRYqVtYeEin6+tjT4wakRPOZIY403m1IPJHXBOk0fdcW0Zs+
> SkPGesyPa4BveCKxv14LWP/DUcc2Yk6z1NKYMpZlXOgBcjlqZuRS2FzJfL1QukP1
> FuWWjO2h6wARAQABiQE8BBgBCAAmFiEENEVu0wmA6tl2+lDjPH3vfWpCszMFAlu9
> J7wCGwwFCQPCZwAACgkQPH3vfWpCszMw9ggApDmLWYV+ZgRY5WKEZkyWrdB9k/eF
> pFn8lT0JXjB/UwRH00uAi0sYyKbH3ERD2rcOD8JhKlQf2A+NLBEwzptRbDKW78mP
> kiFMuUe5R55GPGDn13uO9eUyqI7VLXD2SQex2+mDGKvPvhVxnJC9o/wjx2h9vVyZ
> igT9hMoc1vrCYMJOa6kYxL1r5XunqMRMpOflTBKzaBX1nkbULTnEaPVbQS8wpoah
> 2WNB5v32i+fyZMFYGyqR4MeIfrvptxSMBN99SsAAncudfUIGM+X7Z/c/6P1CNztn
> JkDeE4i0ePtsjUmcmtbxXJOuAteaj4SFPKfKkEZzbnzIkBB8GNEknrhxXA==
> =NLRB
> -END PGP PUBLIC KEY BLOCK-



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

Re: [DISCUSS] First release of health check modules annotation, api, core, generalchecks and webconsoleplugin

[Raymond Auge]

So, I wasn't suggesting to make an explicit requirement needed for this,
but rather a convenience annotation similar to

@RequireJaxrsWhiteboard [1]

which is an annotation that I can use if I want to assert that the
deployment will calculate that I want a JAXRS whiteboard dpeloyed.

:)

This is a way to build a deployment descriptor into what you might refer to
as an "Application bundle" which might be a package-info.java containing:

@RequireJaxrsWhiteboard
@RequireCDIExtender
@RequireGogo
@RequireFelixHealthCheck
package com.acme.application;

This is in place of having to write out some deployment descriptor
somewhere in like a bndrun or feature file. The resolver can simple resolve
those from some set of repositories with no other input other than your
application bundle.

Sincerely,
- Ray

[1]
https://osgi.org/specification/osgi.cmpn/7.0.0/service.jaxrs.html#org.osgi.service.jaxrs.whiteboard.annotations.RequireJaxrsWhiteboard

On Fri, Jan 25, 2019 at 4:50 PM Georg Henzler  wrote:

> Having thought a bit more about this, for most bundles implementing a
> health check it is more of an optional extension. This means bundle-XYZ
> primarily will provide the functionality XYZ with an optional health
> check testing state around functionality XYZ in action. Usually you
> would even make the package dependency to org.apache.felix.hc.api
> optional with the result that
>
> - if bundle org.apache.sling.hc.api is *not* available,
>functionality XYZ is still fully working
> - if bundle org.apache.sling.hc.api *is* available,
>functionality XYZ is working and can be checked via provided HC(s)
>
> So I think it's fine to start without an explicitly declared capability,
> we can add this easily later if desired.
>
> -Georg
>
>
> On 2019-01-21 15:06, Raymond Auge wrote:
> > On Mon, Jan 21, 2019 at 2:19 AM Georg Henzler 
> > wrote:
> >
> >> Hi Ray,
> >>
> >> so your suggestion is more about referring to a capability like
> >> "org.apache.felix.healthcheck" by using requirements in other bundles
> >> than writing a health check that ensures the framework provides a
> >> certain non-healthcheck-related capability.
> >>
> >
> > Precisely,
> >
> > - Ray
> >
> >
> >>
> >> > I can probably try it out and submit the proper cap&req.
> >>
> >> that would be great!
> >>
> >> -Georg
> >>
> >>
>


-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)

Re: [VOTE] Release Apache Felix Gogo JLine 1.1.4

[Francois Papon]

+1 (non-binding)

Thanks!

Regards,

François Papon
fpa...@apache.org

Le 25/01/2019 à 16:55, Jean-Baptiste Onofré a écrit :
> Hi all,
>
> We solved 3 issues in this release (release notes):
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12344851
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1278/
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
>
> This vote will be open for 72 hours.
>
> Thanks,
> Regards
> JB

Re: [DISCUSS] First release of health check modules annotation, api, core, generalchecks and webconsoleplugin

[Christian Schneider]

+1 for a @RequireFelixHealthCheck annotation.
I think we then also need an annotation for requiring the health check web
console plugin, or do you see a way to automate this when web console is
present.

I just also checked where we could put the annotations. We have the bundles
API and annotation.
This makes me wonder if we could put the annotations into the API bundle.
WDYT?

Christian

Am Sa., 26. Jan. 2019 um 00:04 Uhr schrieb Raymond Auge <
raymond.a...@liferay.com>:

> So, I wasn't suggesting to make an explicit requirement needed for this,
> but rather a convenience annotation similar to
>
> @RequireJaxrsWhiteboard [1]
>
> which is an annotation that I can use if I want to assert that the
> deployment will calculate that I want a JAXRS whiteboard dpeloyed.
>
> :)
>
> This is a way to build a deployment descriptor into what you might refer to
> as an "Application bundle" which might be a package-info.java containing:
>
> @RequireJaxrsWhiteboard
> @RequireCDIExtender
> @RequireGogo
> @RequireFelixHealthCheck
> package com.acme.application;
>
> This is in place of having to write out some deployment descriptor
> somewhere in like a bndrun or feature file. The resolver can simple resolve
> those from some set of repositories with no other input other than your
> application bundle.
>
> Sincerely,
> - Ray
>
> [1]
>
> https://osgi.org/specification/osgi.cmpn/7.0.0/service.jaxrs.html#org.osgi.service.jaxrs.whiteboard.annotations.RequireJaxrsWhiteboard
>
> On Fri, Jan 25, 2019 at 4:50 PM Georg Henzler  wrote:
>
> > Having thought a bit more about this, for most bundles implementing a
> > health check it is more of an optional extension. This means bundle-XYZ
> > primarily will provide the functionality XYZ with an optional health
> > check testing state around functionality XYZ in action. Usually you
> > would even make the package dependency to org.apache.felix.hc.api
> > optional with the result that
> >
> > - if bundle org.apache.sling.hc.api is *not* available,
> >functionality XYZ is still fully working
> > - if bundle org.apache.sling.hc.api *is* available,
> >functionality XYZ is working and can be checked via provided HC(s)
> >
> > So I think it's fine to start without an explicitly declared capability,
> > we can add this easily later if desired.
> >
> > -Georg
> >
> >
> > On 2019-01-21 15:06, Raymond Auge wrote:
> > > On Mon, Jan 21, 2019 at 2:19 AM Georg Henzler 
> > > wrote:
> > >
> > >> Hi Ray,
> > >>
> > >> so your suggestion is more about referring to a capability like
> > >> "org.apache.felix.healthcheck" by using requirements in other bundles
> > >> than writing a health check that ensures the framework provides a
> > >> certain non-healthcheck-related capability.
> > >>
> > >
> > > Precisely,
> > >
> > > - Ray
> > >
> > >
> > >>
> > >> > I can probably try it out and submit the proper cap&req.
> > >>
> > >> that would be great!
> > >>
> > >> -Georg
> > >>
> > >>
> >
>
>
> --
> *Raymond Augé* 
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance 
> (@OSGiAlliance)
>


-- 
-- 
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com