You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pivot.apache.org by Greg Brown <gk...@mac.com> on 2009/07/14 15:18:40 UTC
Make Pivot JARs OSGi-compliant
Hi all,
There was a thread a couple weeks ago about making the Pivot JARs OSGi-
compliant:
http://mail-archives.apache.org/mod_mbox/incubator-pivot-dev/200907.mbox/%3ccaf30e2a0907020028y49c1347bscca42f2543a1cd5a@mail.gmail.com%3e
This seems like a good idea, but it sounds like there may be some
challenges. Chris, you seem to have the most experience with OSGi - is
this something you would be willing to look into? Obviously, the first
step would simply be assessing the effort required. Then, depending on
the level of effort/timeframe, we could decide whether or not we want
to proceed.
What do you think?
Thanks,
Greg
Re: Make Pivot JARs OSGi-compliant
Posted by Sandro Martini <sa...@gmail.com>.
Hi to all,
I've a very very little experience on OSGI, but I've tried an useful
utility called bnd that takes any normal jar and repackage in a
osgi-compliant jar (inspect it and creates manifests, etc).
But then there may be classloader issues, etc, depending on how the
library works ... and then some tests should be done from an OSGI
environment.
You can find it here: http://www.aqute.biz/Code/Bnd
Good tests ...
Bye
Re: Make Pivot JARs OSGi-compliant
Posted by Noel Grandin <no...@gmail.com>.
Hi
I've no actual OSGi experience, but from watching various OSGi
discussions, and playing with Eclipse,
the minimum Pivot should provide is an OSGi-manifest that specifies the
"actual public" classes,
as opposed to the "public because it has to be, but actually internal"
classes.
Also, there would be
(1) the matter of maintaining the Pivot version number in the OSGi-manifest.
(2) any inter-jar dependencies should also be in the manifest, with the
requisite care about specifying optional vs. required dependencies.
(3) perhaps adding the eclipse-specific metadata that specifies the
minimum required Java environment.
That would not necessarily be a complete implementation of OSGi-fication,
but it would make the life of someone who wanted to drop Pivot into an
OSGi container much easier.
Regards, Noel.
Greg Brown wrote:
> Hi all,
>
> There was a thread a couple weeks ago about making the Pivot JARs
> OSGi-compliant:
>
> http://mail-archives.apache.org/mod_mbox/incubator-pivot-dev/200907.mbox/%3ccaf30e2a0907020028y49c1347bscca42f2543a1cd5a@mail.gmail.com%3e
>
>
> This seems like a good idea, but it sounds like there may be some
> challenges. Chris, you seem to have the most experience with OSGi - is
> this something you would be willing to look into? Obviously, the first
> step would simply be assessing the effort required. Then, depending on
> the level of effort/timeframe, we could decide whether or not we want
> to proceed.
>
> What do you think?
>
> Thanks,
> Greg
>
Re: Make Pivot JARs OSGi-compliant
Posted by Greg Brown <gk...@mac.com>.
Sounds good - thanks!
On Jul 14, 2009, at 9:52 AM, Christopher Brind wrote:
> I'm actually at an OSGi event today/this evening, so I will also
> talk to a
> couple of OSGi experts about it as well and see if I can get them to
> have a
> look at Pivot and give their opinion.
>
> Neil Bartlett is particularly experienced with OSGi and very
> approachable,
> so I'll have a word with him later. I seem to remember he is a fan
> of Felix
> as well. You can read his blog here:
> http://neilbartlett.name/blog/
>
> Making the JARs OSGi friend is actually quite easy - but working out
> how
> people would find them useful is a different matter.
>
> I'll give it some serious thought over the next few days and report
> back.
>
> Cheers,
> Chris
>
>
> 2009/7/14 Greg Brown <gk...@mac.com>
>
>> Hi all,
>>
>> There was a thread a couple weeks ago about making the Pivot JARs
>> OSGi-compliant:
>>
>>
>> http://mail-archives.apache.org/mod_mbox/incubator-pivot-dev/200907.mbox/%3ccaf30e2a0907020028y49c1347bscca42f2543a1cd5a@mail.gmail.com%3e
>>
>> This seems like a good idea, but it sounds like there may be some
>> challenges. Chris, you seem to have the most experience with OSGi -
>> is this
>> something you would be willing to look into? Obviously, the first
>> step would
>> simply be assessing the effort required. Then, depending on the
>> level of
>> effort/timeframe, we could decide whether or not we want to proceed.
>>
>> What do you think?
>>
>> Thanks,
>> Greg
>>
>>
Re: Make Pivot JARs OSGi-compliant
Posted by Christopher Brind <br...@brindy.org.uk>.
I'm actually at an OSGi event today/this evening, so I will also talk to a
couple of OSGi experts about it as well and see if I can get them to have a
look at Pivot and give their opinion.
Neil Bartlett is particularly experienced with OSGi and very approachable,
so I'll have a word with him later. I seem to remember he is a fan of Felix
as well. You can read his blog here:
http://neilbartlett.name/blog/
Making the JARs OSGi friend is actually quite easy - but working out how
people would find them useful is a different matter.
I'll give it some serious thought over the next few days and report back.
Cheers,
Chris
2009/7/14 Greg Brown <gk...@mac.com>
> Hi all,
>
> There was a thread a couple weeks ago about making the Pivot JARs
> OSGi-compliant:
>
>
> http://mail-archives.apache.org/mod_mbox/incubator-pivot-dev/200907.mbox/%3ccaf30e2a0907020028y49c1347bscca42f2543a1cd5a@mail.gmail.com%3e
>
> This seems like a good idea, but it sounds like there may be some
> challenges. Chris, you seem to have the most experience with OSGi - is this
> something you would be willing to look into? Obviously, the first step would
> simply be assessing the effort required. Then, depending on the level of
> effort/timeframe, we could decide whether or not we want to proceed.
>
> What do you think?
>
> Thanks,
> Greg
>
>
Re: Make Pivot JARs OSGi-compliant
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wed, Jul 15, 2009 at 7:14 PM, Christopher Brind<br...@brindy.org.uk> wrote:
> For those who are interested the constraints that Niclas mentioned is in
> section 3.6.4 but that whole section is a really interesting read.
> http://www.osgi.org/download/r4v41/r4.core.pdf
An interesting read, but can be extremely overwhelming to grasp. I
think I took 3 or 4 passes of the whole class spaces section before I
got it.
> I never realised how much the Eclipse editor has dumbed down what can be
> (should be?) put in the manifest! I will definitely be getting to grips
> with this stuff for future bundle work.
:-) Yes, Eclipse isn't the 'best citizens' of OSGi world.
Go look at the Pax tools at http://wiki.ops4j.org to do decent
IDE-independent OSGi development.
For instance, Pax Runner even includes an Eclipse plugin (formerly
called Pax Cursor in separate project) that can run Eclipse RCP's
better than Eclipse itself, i.e. you can select and launch the RCP
under any of the supported frameworks (Felix, Knopflerfish, Equinox
and Concierge) in any version available of the selected framework.
Anyway, if you guys want to make Pivot OSGi-friendly, then I can help
you out quite a bit. But I will not have an opinion whether you should
or should not do it at all.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
Re: Make Pivot JARs OSGi-compliant
Posted by Christopher Brind <br...@brindy.org.uk>.
For those who are interested the constraints that Niclas mentioned is in
section 3.6.4 but that whole section is a really interesting read.
http://www.osgi.org/download/r4v41/r4.core.pdf
I never realised how much the Eclipse editor has dumbed down what can be
(should be?) put in the manifest! I will definitely be getting to grips
with this stuff for future bundle work.
Thanks!
Cheers,
Chris
2009/7/15 Niclas Hedhman <ni...@hedhman.org>
> On Wed, Jul 15, 2009 at 6:06 PM, Christopher Brind<br...@brindy.org.uk>
> wrote:
> > Hi Niclas,
> >
> > Just to be clear - I wasn't advocating using the PDE toolchain, I was
> > talking about using the manifest editor only but concur with your
> comments
> > about Bnd... and everything else. :)
> >
> > I've not used Bnd because I work in Eclipse and don't like to replicate
> the
> > meta information in multiple places. Eclipse's approach to bundle
> > development is to store the meta information in a manifest file - which
> kind
> > of makes sense to me! So I can't see the pointing in maintaining that
> meta
> > information in a format for Bnd as well.
>
> One point; AFAIK, PDE doesn't generate the content that is needed for
> the Manifest file. You have to manually enter things. Versions have a
> tendency to be forgotten, and "uses" are so hard to figure out, that I
> have not seen any PDE user put it in. And without the "uses"
> directives, an accurate class space can not be created. Examples are
> listed in chapter 3 of the OSGi spec under 'constraints' somewhere.
>
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://www.qi4j.org - New Energy for Java
>
> I live here; http://tinyurl.com/2qq9er
> I work here; http://tinyurl.com/2ymelc
> I relax here; http://tinyurl.com/2cgsug
>
Re: Make Pivot JARs OSGi-compliant
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wed, Jul 15, 2009 at 6:06 PM, Christopher Brind<br...@brindy.org.uk> wrote:
> Hi Niclas,
>
> Just to be clear - I wasn't advocating using the PDE toolchain, I was
> talking about using the manifest editor only but concur with your comments
> about Bnd... and everything else. :)
>
> I've not used Bnd because I work in Eclipse and don't like to replicate the
> meta information in multiple places. Eclipse's approach to bundle
> development is to store the meta information in a manifest file - which kind
> of makes sense to me! So I can't see the pointing in maintaining that meta
> information in a format for Bnd as well.
One point; AFAIK, PDE doesn't generate the content that is needed for
the Manifest file. You have to manually enter things. Versions have a
tendency to be forgotten, and "uses" are so hard to figure out, that I
have not seen any PDE user put it in. And without the "uses"
directives, an accurate class space can not be created. Examples are
listed in chapter 3 of the OSGi spec under 'constraints' somewhere.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
Re: Make Pivot JARs OSGi-compliant
Posted by Christopher Brind <br...@brindy.org.uk>.
Hi Niclas,
Just to be clear - I wasn't advocating using the PDE toolchain, I was
talking about using the manifest editor only but concur with your comments
about Bnd... and everything else. :)
I've not used Bnd because I work in Eclipse and don't like to replicate the
meta information in multiple places. Eclipse's approach to bundle
development is to store the meta information in a manifest file - which kind
of makes sense to me! So I can't see the pointing in maintaining that meta
information in a format for Bnd as well.
But I suppose if we're wanting to remain IDE agnostic then storing that meta
information in a format that can be used by Bnd is acceptable too.
Cheers,
Chris
2009/7/15 Niclas Hedhman <ni...@hedhman.org>
> On Wed, Jul 15, 2009 at 3:52 PM, Christopher Brind<br...@brindy.org.uk>
> wrote:
> > Before jumping in and solving our class loading problem I would say it is
> > more important to establish what we're trying to achieve by this
> exercise.
>
> Fair enough...
>
> > Is the goal essentially to be able to start a pivot application from
> within
> > an osgi container and then allow the application and ui to be extended
> using
> > the osgi mechanism?
> >
> > Or did you have something else in mind?
>
> I don't have a 'use-case' in mind, but I have been around the block a
> dozen times of adapting something for OSGi (in various forms) to know
> where the problems will be, and common approaches to solve them.
>
> For Pivot, I would recommend the same approach as we have in Qi4j,
> i.e. "OSGi-friendly but not OSGi-dependent". That basically means that
> the Jar files are OSGi bundles that will work both in OSGi and in a
> OSGi-free environment. It means that OSGi requirements are met in
> terms of classloading, and in Qi4j it means that OSGi services can be
> 'imported' if the extension is installed (not done yet).
>
> Exactly how far down the 'friendliness'-path you want to walk is not
> something needed to be decided upfront. It can be a slow progress,
> driven by actual use-cases.
>
> > How would this work in the applet environment, if at all?
>
> Perhaps poorly. The applet would start an OSGi framework, which in
> turn would load the bundles needed, possibly lazily.
>
> > That is, I am trying to understand the use case you are thinking of,
> though
> > I am starting to guess that you are talking from the desktop application
> > point of view?
>
> As I said, I don't have the strong use-case yet. My messing around
> with Pivot so far is rudimentary at best, and although I have a
> long-term plan for using it, that plan may or may not include OSGi. It
> is something not decided yet. In fact, I have not even decided whether
> it will be applet, jws or desktop app, although jws is a personal
> favorite of mine.
>
> > How do you see the deployment of an osgi based pivot application working
> > and what are the deployment scenarios?
>
> I love plugin concepts, and since I first wrote my own plugin system
> back in 1999 or so, I am equally concerned that a good plugin system
> can unload/reload plugins on the fly. OSGi R4 can make this a reality,
> much easier than fooling around with Java 2 classloader model. But it
> comes at a price of how you should deal with classloading. And since
> most systems that has some form of classloading mechanism (Pivot incl)
> assumes that the world == Java 2 classloader model, you are set for
> problems. Eclipse for instance, is since 3.0 based on OSGi, but has
> been unable to make the reloadable plugins a reality, since too much
> code are not following the classloader constraints set in OSGi. I
> doubt that they will ever try to solve it properly.
>
> For Pivot users, who want to build RCP-like applications, it would be
> nice if Pivot was "OSGi-friendly" and the frameworks built on top
> could be fully reloadable. I think the overall effort from Pivot is
> quite minimal, and will largely be a) a single classloading pattern
> and b) testing effort to ensure that it works in each release.
>
> > With regards to bnd, yes it is a good tool, but i think it could be
> overkill
> > here. Once we establish our goals someone with osgi experience can
> simply
> > write the headers in to manifest file to be referenced at build time by
> the
> > jar ant task rather than introducing a new and potentially complex step
> in
> > to the build.
>
> I disagree. To create and maintain the manifest is actually much, much
> harder than you may initially think. And in comparison, the BND
> descriptor is fairly easy to maintain and for Ant I think it is one
> antlib and one target that you will need to add.
>
> > Since most of us are using Eclipse that is actually quite
> > easy using pde tools and will probably only need doing once, or very
> rarely,
> > so shouldn't affect those using some other ide.
>
> The PDE toolchain is of poor quality. In fact, most leading OSGi
> developers who are also Eclipse users, never use the PDE due to its
> limitations, bugs and different approach than what is expected. In
> fact, it is so bad that I use Idea even when developing Eclipse
> plugins... And it will be a manual process, and with not enough usage
> in the dev team, likely to be error-prone during releases. by
> comparison, the BND tool is automated, relatively fast and requires
> that all classes are marked explicitly, just to ensure that one didn't
> just "forgot". So, releases is just a matter of looking out for BND
> warnings.
>
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://www.qi4j.org - New Energy for Java
>
> I live here; http://tinyurl.com/2qq9er
> I work here; http://tinyurl.com/2ymelc
> I relax here; http://tinyurl.com/2cgsug
>
Re: Make Pivot JARs OSGi-compliant
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wed, Jul 15, 2009 at 3:52 PM, Christopher Brind<br...@brindy.org.uk> wrote:
> Before jumping in and solving our class loading problem I would say it is
> more important to establish what we're trying to achieve by this exercise.
Fair enough...
> Is the goal essentially to be able to start a pivot application from within
> an osgi container and then allow the application and ui to be extended using
> the osgi mechanism?
>
> Or did you have something else in mind?
I don't have a 'use-case' in mind, but I have been around the block a
dozen times of adapting something for OSGi (in various forms) to know
where the problems will be, and common approaches to solve them.
For Pivot, I would recommend the same approach as we have in Qi4j,
i.e. "OSGi-friendly but not OSGi-dependent". That basically means that
the Jar files are OSGi bundles that will work both in OSGi and in a
OSGi-free environment. It means that OSGi requirements are met in
terms of classloading, and in Qi4j it means that OSGi services can be
'imported' if the extension is installed (not done yet).
Exactly how far down the 'friendliness'-path you want to walk is not
something needed to be decided upfront. It can be a slow progress,
driven by actual use-cases.
> How would this work in the applet environment, if at all?
Perhaps poorly. The applet would start an OSGi framework, which in
turn would load the bundles needed, possibly lazily.
> That is, I am trying to understand the use case you are thinking of, though
> I am starting to guess that you are talking from the desktop application
> point of view?
As I said, I don't have the strong use-case yet. My messing around
with Pivot so far is rudimentary at best, and although I have a
long-term plan for using it, that plan may or may not include OSGi. It
is something not decided yet. In fact, I have not even decided whether
it will be applet, jws or desktop app, although jws is a personal
favorite of mine.
> How do you see the deployment of an osgi based pivot application working
> and what are the deployment scenarios?
I love plugin concepts, and since I first wrote my own plugin system
back in 1999 or so, I am equally concerned that a good plugin system
can unload/reload plugins on the fly. OSGi R4 can make this a reality,
much easier than fooling around with Java 2 classloader model. But it
comes at a price of how you should deal with classloading. And since
most systems that has some form of classloading mechanism (Pivot incl)
assumes that the world == Java 2 classloader model, you are set for
problems. Eclipse for instance, is since 3.0 based on OSGi, but has
been unable to make the reloadable plugins a reality, since too much
code are not following the classloader constraints set in OSGi. I
doubt that they will ever try to solve it properly.
For Pivot users, who want to build RCP-like applications, it would be
nice if Pivot was "OSGi-friendly" and the frameworks built on top
could be fully reloadable. I think the overall effort from Pivot is
quite minimal, and will largely be a) a single classloading pattern
and b) testing effort to ensure that it works in each release.
> With regards to bnd, yes it is a good tool, but i think it could be overkill
> here. Once we establish our goals someone with osgi experience can simply
> write the headers in to manifest file to be referenced at build time by the
> jar ant task rather than introducing a new and potentially complex step in
> to the build.
I disagree. To create and maintain the manifest is actually much, much
harder than you may initially think. And in comparison, the BND
descriptor is fairly easy to maintain and for Ant I think it is one
antlib and one target that you will need to add.
> Since most of us are using Eclipse that is actually quite
> easy using pde tools and will probably only need doing once, or very rarely,
> so shouldn't affect those using some other ide.
The PDE toolchain is of poor quality. In fact, most leading OSGi
developers who are also Eclipse users, never use the PDE due to its
limitations, bugs and different approach than what is expected. In
fact, it is so bad that I use Idea even when developing Eclipse
plugins... And it will be a manual process, and with not enough usage
in the dev team, likely to be error-prone during releases. by
comparison, the BND tool is automated, relatively fast and requires
that all classes are marked explicitly, just to ensure that one didn't
just "forgot". So, releases is just a matter of looking out for BND
warnings.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
Re: Make Pivot JARs OSGi-compliant
Posted by Christopher Brind <br...@brindy.org.uk>.
Niclas
Before jumping in and solving our class loading problem I would say it is
more important to establish what we're trying to achieve by this exercise.
Is the goal essentially to be able to start a pivot application from within
an osgi container and then allow the application and ui to be extended using
the osgi mechanism?
Or did you have something else in mind?
How would this work in the applet environment, if at all?
That is, I am trying to understand the use case you are thinking of, though
I am starting to guess that you are talking from the desktop application
point of view?
How do you see the deployment of an osgi based pivot application working
and what are the deployment scenarios?
With regards to bnd, yes it is a good tool, but i think it could be overkill
here. Once we establish our goals someone with osgi experience can simply
write the headers in to manifest file to be referenced at build time by the
jar ant task rather than introducing a new and potentially complex step in
to the build. Since most of us are using Eclipse that is actually quite
easy using pde tools and will probably only need doing once, or very rarely,
so shouldn't affect those using some other ide.
Cheers
Chris
On Jul 15, 2009 4:10 AM, "Niclas Hedhman" <ni...@hedhman.org> wrote:
On Tue, Jul 14, 2009 at 9:18 PM, Greg Brown<gk...@mac.com> wrote: > Hi
all, > > There was a thread...
I probably have the most experience of OSGi in this group.
* have been Member of the Alliance,
* expert group member on JSR-291,
* started one RFP (database access) in the Alliance,
* started the Pax project which has plenty of OSGi related tools in them,
* Felix committer (former PMC member).
As Noel pointed out, the most important tool of them all is BND, from
Peter Kriens (a founder of OSGi). It is fairly flexible and can be
used in most build environments, although my own experience is only
for Maven, where it is embedded into the Maven Bundle Plugin, mostly
developed by one of my former staff (Stuart McCulloch, resident here
in Kuala Lumpur).
I think I have mentioned it before, the most critical part of an
explicit OSGi strategy from Pivot would be the classloading. OSGi
doesn't like 'unknown classes'. The workaround (DynamicImport) is not
good to use, as it disables some of the class space checks and
'clean-up' is a bit less predictable. For instance ORM has the same
problems, and what we did in-house here was to require the application
to "register" classes that was going to be available, and not relying
on ClassLoader.loadClass() to find them. We are effectively doing the
same in Qi4j (http://www.qi4j.org), but for other reasons.
If such approach is chosen, the important bit is that one also listens
for bundle events regarding the bundle being unloaded or refreshed, in
case the bundle forgets to unregister the classes.
I think I can assist with the expertise, but I don't really have the
time to set up the tests. If someone can get to the point where
bundles are built with BND (use external package file), I think I can
"make it work" and "troubleshoot"...
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
Re: Make Pivot JARs OSGi-compliant
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tue, Jul 14, 2009 at 9:18 PM, Greg Brown<gk...@mac.com> wrote:
> Hi all,
>
> There was a thread a couple weeks ago about making the Pivot JARs
> OSGi-compliant:
>
> http://mail-archives.apache.org/mod_mbox/incubator-pivot-dev/200907.mbox/%3ccaf30e2a0907020028y49c1347bscca42f2543a1cd5a@mail.gmail.com%3e
>
> This seems like a good idea, but it sounds like there may be some
> challenges. Chris, you seem to have the most experience with OSGi - is this
> something you would be willing to look into? Obviously, the first step would
> simply be assessing the effort required. Then, depending on the level of
> effort/timeframe, we could decide whether or not we want to proceed.
I probably have the most experience of OSGi in this group.
* have been Member of the Alliance,
* expert group member on JSR-291,
* started one RFP (database access) in the Alliance,
* started the Pax project which has plenty of OSGi related tools in them,
* Felix committer (former PMC member).
As Noel pointed out, the most important tool of them all is BND, from
Peter Kriens (a founder of OSGi). It is fairly flexible and can be
used in most build environments, although my own experience is only
for Maven, where it is embedded into the Maven Bundle Plugin, mostly
developed by one of my former staff (Stuart McCulloch, resident here
in Kuala Lumpur).
I think I have mentioned it before, the most critical part of an
explicit OSGi strategy from Pivot would be the classloading. OSGi
doesn't like 'unknown classes'. The workaround (DynamicImport) is not
good to use, as it disables some of the class space checks and
'clean-up' is a bit less predictable. For instance ORM has the same
problems, and what we did in-house here was to require the application
to "register" classes that was going to be available, and not relying
on ClassLoader.loadClass() to find them. We are effectively doing the
same in Qi4j (http://www.qi4j.org), but for other reasons.
If such approach is chosen, the important bit is that one also listens
for bundle events regarding the bundle being unloaded or refreshed, in
case the bundle forgets to unregister the classes.
I think I can assist with the expertise, but I don't really have the
time to set up the tests. If someone can get to the point where
bundles are built with BND (use external package file), I think I can
"make it work" and "troubleshoot"...
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug