Re: DS property replacement?
On Mon, Mar 9, 2015 at 6:18 AM, Carsten Ziegeler cziege...@apache.org
wrote:
Am 08.03.15 um 16:24 schrieb Raymond Auge:
Would people be opposed to felix scr supporting property replacement
something like (à la spring PropertyPlaceholderConfigurer):
// implied from bundle runtime details
@Reference(target = (service.bundleid=${bundle.id}))
// implied from bundle headers
@Reference(target = (context.path=${Web-ContextPath}))
etc.
One might overload the KXml2SAXParser.getAttributeValue(i) method which
scans for replaceable tokens where KXml2SAXParser is passed the bundle in
it's constructor.
I think this one will be troublesome. Apart from having a proprietary
extension where do those values come from?
Bundle headers, and bundle details.
Then you have the properties element which you could use to point to
a properties file in your bundle overriding the values - I guess that's
not working for your case.
This can't work. You can only get information which exists before coming
into the runtime which is not the goal.
And finally you can change the values through a configuration, so
instead of coming up with a new way to get a value for the placeholders
you create a configuration that set the [reference].target property to
the appropriate value.
This also isn't the goal. The goal is to automate/simplify parts which you
don't want to handle via configuration. For instance you would never use
the bundle.id because that would be foolish since uninstall and reinstall
would make the configuration invalid.
However, there are many details for which it might be useful to be able to
apply filters on, but due to their dynamic nature its impractical to use
them because you must hard code the values currently. This is true for
almost all details of a bundle at runtime.
It's also true that some information you don't want to duplicate. For
instance, anything that is in the manifest you probably want to keep
centralized there, and not require a developer to duplicate it since this
causes a change management problem.
So, my thought about where the information for replacement is that it would
come from only
- bundle runtime info
- manifest
Sincerely,
- Ray
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
--
*Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
(@rotty3000)
Senior Software Architect *Liferay, Inc.* http://www.liferay.com
(@Liferay)
Board Member EEG Co-Chair, OSGi Alliance http://osgi.org (@OSGiAlliance)
Re: DS property replacement?
Am 09.03.15 um 15:08 schrieb Raymond Auge: This also isn't the goal. The goal is to automate/simplify parts which you don't want to handle via configuration. For instance you would never use the bundle.id because that would be foolish since uninstall and reinstall would make the configuration invalid. However, there are many details for which it might be useful to be able to apply filters on, but due to their dynamic nature its impractical to use them because you must hard code the values currently. This is true for almost all details of a bundle at runtime. It's also true that some information you don't want to duplicate. For instance, anything that is in the manifest you probably want to keep centralized there, and not require a developer to duplicate it since this causes a change management problem. So, my thought about where the information for replacement is that it would come from only - bundle runtime info What exactly do you mean with that? - manifest How is this different from a properties file in the bundle? Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: DS property replacement?
On Mon, Mar 9, 2015 at 10:48 AM, Felix Meschberger fmesc...@adobe.com
wrote:
Hi
What prevents you from doing this with your build tooling ? This should,
apart from the bundle.id part, be rather easy.
You can't see runtime info from the build!
This is the main point!
E.g. leveraging the resource filtering feature of Maven
Regards
Felix
Am 09.03.2015 um 15:08 schrieb Raymond Auge raymond.a...@liferay.com:
On Mon, Mar 9, 2015 at 6:18 AM, Carsten Ziegeler cziege...@apache.org
wrote:
Am 08.03.15 um 16:24 schrieb Raymond Auge:
Would people be opposed to felix scr supporting property replacement
something like (à la spring PropertyPlaceholderConfigurer):
// implied from bundle runtime details
@Reference(target = (service.bundleid=${bundle.id}))
// implied from bundle headers
@Reference(target = (context.path=${Web-ContextPath}))
etc.
One might overload the KXml2SAXParser.getAttributeValue(i) method which
scans for replaceable tokens where KXml2SAXParser is passed the bundle
in
it's constructor.
I think this one will be troublesome. Apart from having a proprietary
extension where do those values come from?
Bundle headers, and bundle details.
Then you have the properties element which you could use to point to
a properties file in your bundle overriding the values - I guess that's
not working for your case.
This can't work. You can only get information which exists before coming
into the runtime which is not the goal.
And finally you can change the values through a configuration, so
instead of coming up with a new way to get a value for the placeholders
you create a configuration that set the [reference].target property to
the appropriate value.
This also isn't the goal. The goal is to automate/simplify parts which
you
don't want to handle via configuration. For instance you would never use
the bundle.id because that would be foolish since uninstall and
reinstall
would make the configuration invalid.
However, there are many details for which it might be useful to be able
to
apply filters on, but due to their dynamic nature its impractical to use
them because you must hard code the values currently. This is true for
almost all details of a bundle at runtime.
It's also true that some information you don't want to duplicate. For
instance, anything that is in the manifest you probably want to keep
centralized there, and not require a developer to duplicate it since this
causes a change management problem.
So, my thought about where the information for replacement is that it
would
come from only
- bundle runtime info
- manifest
Sincerely,
- Ray
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
--
*Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
(@rotty3000)
Senior Software Architect *Liferay, Inc.* http://www.liferay.com
(@Liferay)
Board Member EEG Co-Chair, OSGi Alliance http://osgi.org
(@OSGiAlliance)
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
--
*Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
(@rotty3000)
Senior Software Architect *Liferay, Inc.* http://www.liferay.com
(@Liferay)
Board Member EEG Co-Chair, OSGi Alliance http://osgi.org (@OSGiAlliance)
Re: DS property replacement?
I think you have prematurely decided on a solution and have not analyzed your
requirements from a sufficiently abstract level.
There are a ton of ways to specify wiring that don't augment the ds spec.
From a more conceptual level, what is determining which Fum a particular Foo is
wired to?
thanks
david jencks
On Mar 9, 2015, at 11:10 AM, Raymond Auge raymond.a...@liferay.com wrote:
In fact, I would be satisfied it there were placeholders ONLY for the
service properties which can only be known at runtime.
On Mon, Mar 9, 2015 at 11:07 AM, Raymond Auge raymond.a...@liferay.com
wrote:
Allow me to demonstrate using a real world scenario we have right now.
There is an API comprised of at least two parts - Foo Fum
There are many implementations of Foo and Fum coming from many bundles
However, the typical case is also that a Foo impl uses it's own Fum impl.
So, your first attempt looks like this:
@Component(service = Fum.class)
public class MyFum implements Fum { }
@Component(service = Foo.class)
public class MyFoo implements Foo {
@Reference
public void setFum(Fum fum) {..}
}
Now this can break, because there are many Fums, right?
So I need to be more specific. At the moment I have to do an ugly hack
which is export the Fum by also it's FumImpl type:
@Component(service = {Fum.class, MuFum.class})
public class MyFum implements Fum { }
and now in the Foo impl, I need to change to either:
@Component(service = Foo.class)
public class MyFoo implements Foo {
@Reference(service = MyFum.class)
public void setFum(Fum fum) {..}
}
OR
@Component(service = Foo.class)
public class MyFoo implements Foo {
@Reference(target = (objectClass=MyFum))
public void setFum(Fum fum) {..}
}
all of that is really crappy!
Why do I need to expose the internal details just so I can connect two
Components together with such crud information.
Why can't I simply do this:
@Component(service = Fum.class)
public class MyFum implements Fum { }
@Component(service = Foo.class)
public class MyFoo implements Foo {
@Reference(target = (service.bundleid=${bundle.id}))
public void setFum(Fum fum) {..}
}
There! problem solved!
R6 added a few very nice service properties like service.bundleid but they
are completely useless because I CAN'T use them realistically because that
information is runtime only and you can't know about it ahead of time.
On Mon, Mar 9, 2015 at 10:51 AM, Raymond Auge raymond.a...@liferay.com
wrote:
On Mon, Mar 9, 2015 at 10:29 AM, Carsten Ziegeler cziege...@apache.org
wrote:
Am 09.03.15 um 15:08 schrieb Raymond Auge:
This also isn't the goal. The goal is to automate/simplify parts which
you
don't want to handle via configuration. For instance you would never
use
the bundle.id because that would be foolish since uninstall and
reinstall
would make the configuration invalid.
However, there are many details for which it might be useful to be
able to
apply filters on, but due to their dynamic nature its impractical to
use
them because you must hard code the values currently. This is true for
almost all details of a bundle at runtime.
It's also true that some information you don't want to duplicate. For
instance, anything that is in the manifest you probably want to keep
centralized there, and not require a developer to duplicate it since
this
causes a change management problem.
So, my thought about where the information for replacement is that it
would
come from only
- bundle runtime info
What exactly do you mean with that?
- manifest
How is this different from a properties file in the bundle?
It's most often calculated during the build and you can't really see the
result until the bundle is running.
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
--
*Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
(@rotty3000)
Senior Software Architect *Liferay, Inc.* http://www.liferay.com
(@Liferay)
Board Member EEG Co-Chair, OSGi Alliance http://osgi.org
(@OSGiAlliance)
--
*Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
(@rotty3000)
Senior Software Architect *Liferay, Inc.* http://www.liferay.com
(@Liferay)
Board Member EEG Co-Chair, OSGi Alliance http://osgi.org
(@OSGiAlliance)
--
*Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
(@rotty3000)
Senior Software Architect *Liferay, Inc.* http://www.liferay.com
(@Liferay)
Board Member EEG Co-Chair, OSGi Alliance http://osgi.org (@OSGiAlliance)
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands,
Re: DS property replacement?
Am 09.03.15 um 16:10 schrieb Raymond Auge: In fact, I would be satisfied it there were placeholders ONLY for the service properties which can only be known at runtime. Thanks Ray, I understand your use case now. You have to somehow - at runtime - provide your mapping, so for all your Foo implementations you need to set the correct target property for the reference to the Fum service. Regardless of what mechanism is used (your replacement idea or something else). Now, my argument is that this code can - at runtime - simply generated OSGi configurations with that target property being correct. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: DS property replacement?
Hi
What prevents you from doing this with your build tooling ? This should, apart
from the bundle.id part, be rather easy.
E.g. leveraging the resource filtering feature of Maven
Regards
Felix
Am 09.03.2015 um 15:08 schrieb Raymond Auge raymond.a...@liferay.com:
On Mon, Mar 9, 2015 at 6:18 AM, Carsten Ziegeler cziege...@apache.org
wrote:
Am 08.03.15 um 16:24 schrieb Raymond Auge:
Would people be opposed to felix scr supporting property replacement
something like (à la spring PropertyPlaceholderConfigurer):
// implied from bundle runtime details
@Reference(target = (service.bundleid=${bundle.id}))
// implied from bundle headers
@Reference(target = (context.path=${Web-ContextPath}))
etc.
One might overload the KXml2SAXParser.getAttributeValue(i) method which
scans for replaceable tokens where KXml2SAXParser is passed the bundle in
it's constructor.
I think this one will be troublesome. Apart from having a proprietary
extension where do those values come from?
Bundle headers, and bundle details.
Then you have the properties element which you could use to point to
a properties file in your bundle overriding the values - I guess that's
not working for your case.
This can't work. You can only get information which exists before coming
into the runtime which is not the goal.
And finally you can change the values through a configuration, so
instead of coming up with a new way to get a value for the placeholders
you create a configuration that set the [reference].target property to
the appropriate value.
This also isn't the goal. The goal is to automate/simplify parts which you
don't want to handle via configuration. For instance you would never use
the bundle.id because that would be foolish since uninstall and reinstall
would make the configuration invalid.
However, there are many details for which it might be useful to be able to
apply filters on, but due to their dynamic nature its impractical to use
them because you must hard code the values currently. This is true for
almost all details of a bundle at runtime.
It's also true that some information you don't want to duplicate. For
instance, anything that is in the manifest you probably want to keep
centralized there, and not require a developer to duplicate it since this
causes a change management problem.
So, my thought about where the information for replacement is that it would
come from only
- bundle runtime info
- manifest
Sincerely,
- Ray
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
--
*Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
(@rotty3000)
Senior Software Architect *Liferay, Inc.* http://www.liferay.com
(@Liferay)
Board Member EEG Co-Chair, OSGi Alliance http://osgi.org (@OSGiAlliance)
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: DS property replacement?
In fact, I would be satisfied it there were placeholders ONLY for the
service properties which can only be known at runtime.
On Mon, Mar 9, 2015 at 11:07 AM, Raymond Auge raymond.a...@liferay.com
wrote:
Allow me to demonstrate using a real world scenario we have right now.
There is an API comprised of at least two parts - Foo Fum
There are many implementations of Foo and Fum coming from many bundles
However, the typical case is also that a Foo impl uses it's own Fum impl.
So, your first attempt looks like this:
@Component(service = Fum.class)
public class MyFum implements Fum { }
@Component(service = Foo.class)
public class MyFoo implements Foo {
@Reference
public void setFum(Fum fum) {..}
}
Now this can break, because there are many Fums, right?
So I need to be more specific. At the moment I have to do an ugly hack
which is export the Fum by also it's FumImpl type:
@Component(service = {Fum.class, MuFum.class})
public class MyFum implements Fum { }
and now in the Foo impl, I need to change to either:
@Component(service = Foo.class)
public class MyFoo implements Foo {
@Reference(service = MyFum.class)
public void setFum(Fum fum) {..}
}
OR
@Component(service = Foo.class)
public class MyFoo implements Foo {
@Reference(target = (objectClass=MyFum))
public void setFum(Fum fum) {..}
}
all of that is really crappy!
Why do I need to expose the internal details just so I can connect two
Components together with such crud information.
Why can't I simply do this:
@Component(service = Fum.class)
public class MyFum implements Fum { }
@Component(service = Foo.class)
public class MyFoo implements Foo {
@Reference(target = (service.bundleid=${bundle.id}))
public void setFum(Fum fum) {..}
}
There! problem solved!
R6 added a few very nice service properties like service.bundleid but they
are completely useless because I CAN'T use them realistically because that
information is runtime only and you can't know about it ahead of time.
On Mon, Mar 9, 2015 at 10:51 AM, Raymond Auge raymond.a...@liferay.com
wrote:
On Mon, Mar 9, 2015 at 10:29 AM, Carsten Ziegeler cziege...@apache.org
wrote:
Am 09.03.15 um 15:08 schrieb Raymond Auge:
This also isn't the goal. The goal is to automate/simplify parts which
you
don't want to handle via configuration. For instance you would never
use
the bundle.id because that would be foolish since uninstall and
reinstall
would make the configuration invalid.
However, there are many details for which it might be useful to be
able to
apply filters on, but due to their dynamic nature its impractical to
use
them because you must hard code the values currently. This is true for
almost all details of a bundle at runtime.
It's also true that some information you don't want to duplicate. For
instance, anything that is in the manifest you probably want to keep
centralized there, and not require a developer to duplicate it since
this
causes a change management problem.
So, my thought about where the information for replacement is that it
would
come from only
- bundle runtime info
What exactly do you mean with that?
- manifest
How is this different from a properties file in the bundle?
It's most often calculated during the build and you can't really see the
result until the bundle is running.
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
--
*Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
(@rotty3000)
Senior Software Architect *Liferay, Inc.* http://www.liferay.com
(@Liferay)
Board Member EEG Co-Chair, OSGi Alliance http://osgi.org
(@OSGiAlliance)
--
*Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
(@rotty3000)
Senior Software Architect *Liferay, Inc.* http://www.liferay.com
(@Liferay)
Board Member EEG Co-Chair, OSGi Alliance http://osgi.org
(@OSGiAlliance)
--
*Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
(@rotty3000)
Senior Software Architect *Liferay, Inc.* http://www.liferay.com
(@Liferay)
Board Member EEG Co-Chair, OSGi Alliance http://osgi.org (@OSGiAlliance)
Re: DS property replacement?
On Mon, Mar 9, 2015 at 10:29 AM, Carsten Ziegeler cziege...@apache.org wrote: Am 09.03.15 um 15:08 schrieb Raymond Auge: This also isn't the goal. The goal is to automate/simplify parts which you don't want to handle via configuration. For instance you would never use the bundle.id because that would be foolish since uninstall and reinstall would make the configuration invalid. However, there are many details for which it might be useful to be able to apply filters on, but due to their dynamic nature its impractical to use them because you must hard code the values currently. This is true for almost all details of a bundle at runtime. It's also true that some information you don't want to duplicate. For instance, anything that is in the manifest you probably want to keep centralized there, and not require a developer to duplicate it since this causes a change management problem. So, my thought about where the information for replacement is that it would come from only - bundle runtime info What exactly do you mean with that? - manifest How is this different from a properties file in the bundle? It's most often calculated during the build and you can't really see the result until the bundle is running. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org -- *Raymond Augé* http://www.liferay.com/web/raymond.auge/profile (@rotty3000) Senior Software Architect *Liferay, Inc.* http://www.liferay.com (@Liferay) Board Member EEG Co-Chair, OSGi Alliance http://osgi.org (@OSGiAlliance)
Re: DS property replacement?
Allow me to demonstrate using a real world scenario we have right now.
There is an API comprised of at least two parts - Foo Fum
There are many implementations of Foo and Fum coming from many bundles
However, the typical case is also that a Foo impl uses it's own Fum impl.
So, your first attempt looks like this:
@Component(service = Fum.class)
public class MyFum implements Fum { }
@Component(service = Foo.class)
public class MyFoo implements Foo {
@Reference
public void setFum(Fum fum) {..}
}
Now this can break, because there are many Fums, right?
So I need to be more specific. At the moment I have to do an ugly hack
which is export the Fum by also it's FumImpl type:
@Component(service = {Fum.class, MuFum.class})
public class MyFum implements Fum { }
and now in the Foo impl, I need to change to either:
@Component(service = Foo.class)
public class MyFoo implements Foo {
@Reference(service = MyFum.class)
public void setFum(Fum fum) {..}
}
OR
@Component(service = Foo.class)
public class MyFoo implements Foo {
@Reference(target = (objectClass=MyFum))
public void setFum(Fum fum) {..}
}
all of that is really crappy!
Why do I need to expose the internal details just so I can connect two
Components together with such crud information.
Why can't I simply do this:
@Component(service = Fum.class)
public class MyFum implements Fum { }
@Component(service = Foo.class)
public class MyFoo implements Foo {
@Reference(target = (service.bundleid=${bundle.id}))
public void setFum(Fum fum) {..}
}
There! problem solved!
R6 added a few very nice service properties like service.bundleid but they
are completely useless because I CAN'T use them realistically because that
information is runtime only and you can't know about it ahead of time.
On Mon, Mar 9, 2015 at 10:51 AM, Raymond Auge raymond.a...@liferay.com
wrote:
On Mon, Mar 9, 2015 at 10:29 AM, Carsten Ziegeler cziege...@apache.org
wrote:
Am 09.03.15 um 15:08 schrieb Raymond Auge:
This also isn't the goal. The goal is to automate/simplify parts which
you
don't want to handle via configuration. For instance you would never use
the bundle.id because that would be foolish since uninstall and
reinstall
would make the configuration invalid.
However, there are many details for which it might be useful to be able
to
apply filters on, but due to their dynamic nature its impractical to use
them because you must hard code the values currently. This is true for
almost all details of a bundle at runtime.
It's also true that some information you don't want to duplicate. For
instance, anything that is in the manifest you probably want to keep
centralized there, and not require a developer to duplicate it since
this
causes a change management problem.
So, my thought about where the information for replacement is that it
would
come from only
- bundle runtime info
What exactly do you mean with that?
- manifest
How is this different from a properties file in the bundle?
It's most often calculated during the build and you can't really see the
result until the bundle is running.
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
--
*Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
(@rotty3000)
Senior Software Architect *Liferay, Inc.* http://www.liferay.com
(@Liferay)
Board Member EEG Co-Chair, OSGi Alliance http://osgi.org
(@OSGiAlliance)
--
*Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
(@rotty3000)
Senior Software Architect *Liferay, Inc.* http://www.liferay.com
(@Liferay)
Board Member EEG Co-Chair, OSGi Alliance http://osgi.org (@OSGiAlliance)
Re: DS property replacement?
Am 08.03.15 um 16:24 schrieb Raymond Auge:
Would people be opposed to felix scr supporting property replacement
something like (à la spring PropertyPlaceholderConfigurer):
// implied from bundle runtime details
@Reference(target = (service.bundleid=${bundle.id}))
// implied from bundle headers
@Reference(target = (context.path=${Web-ContextPath}))
etc.
One might overload the KXml2SAXParser.getAttributeValue(i) method which
scans for replaceable tokens where KXml2SAXParser is passed the bundle in
it's constructor.
I think this one will be troublesome. Apart from having a proprietary
extension where do those values come from?
Then you have the properties element which you could use to point to
a properties file in your bundle overriding the values - I guess that's
not working for your case.
And finally you can change the values through a configuration, so
instead of coming up with a new way to get a value for the placeholders
you create a configuration that set the [reference].target property to
the appropriate value.
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
DS property replacement?
Would people be opposed to felix scr supporting property replacement
something like (à la spring PropertyPlaceholderConfigurer):
// implied from bundle runtime details
@Reference(target = (service.bundleid=${bundle.id}))
// implied from bundle headers
@Reference(target = (context.path=${Web-ContextPath}))
etc.
One might overload the KXml2SAXParser.getAttributeValue(i) method which
scans for replaceable tokens where KXml2SAXParser is passed the bundle in
it's constructor.
--
*Raymond Augé* http://www.liferay.com/web/raymond.auge/profile
(@rotty3000)
Senior Software Architect *Liferay, Inc.* http://www.liferay.com
(@Liferay)
Board Member EEG Co-Chair, OSGi Alliance http://osgi.org (@OSGiAlliance)
