Embedding vertx in OSGi

[Glyn]

I've prototyped ([1]) how vertx core can be embedded in an OSGi
runtime. It's working now, but I'd like to know if there is a better
way of adjusting the paths of static resources.

Currently I have the following logic inside the handle method of my
application's HttpServerRequest Handler:

private void setPathAdjuster() {
Context vertxContext = Context.getContext();
if (vertxContext.getPathAdjustment() == null) {
vertxContext.setPathAdjustment(new ResolvingPath());
}
}

where ResolvingPath is a Path implementation with a carefully crafted
resolve(Path) method:

public Path resolve(Path other) {
URL resource =
this.getClass().getClassLoader().getResource(other.toString());
try {
URI uri = resource.toURI();
return Paths.get(uri);
} catch (URISyntaxException e) {
}
return null;
}

I'd prefer to put this logic (or something similar or better) in the
non-application specific code which creates the HttpServer, registers
the handler, and starts listening. Unfortunately, this code can't get
at the thread-local Context that will be used to drive the
application's handler, so I'm currently stuck with the non-application
specific path resolution code inside the application. Yes, I know I
could move it out and call it from the application, but that's
logically not much better as it still complicates the application
logic unnecessarily.

[1] https://github.com/glyn/vert.x.osgi

[Glyn]

Another reason for removing that code from the application is that I
want the application code to look like vanilla vertx code without any
OSGi-specific novelties.

[Pid]

Remind me about this after the refactoring is done, because I had to
make changes to Context (ie, remove the static & add a ContextImpl.).


p



--

[key:62590808]

[Glyn]

Will do. Is there an issue for "the refactoring" that I can track to
know when it's done?

Meanwhile, please could someone say what the purpose of Context is? It
feels like a slightly odd beast since it is shared across verticles
and yet is thread-local

>
> p
>
> --
>
> [key:62590808]
>
>  signature.asc
> < 1KViewDownload

[Pid]

I should probably create one.

> Meanwhile, please could someone say what the purpose of Context is? It
> feels like a slightly odd beast since it is shared across verticles
> and yet is thread-local

Over to Tim for the history...


p

>>
>> p
>>
>> --
>>
>> [key:62590808]
>>
>> signature.asc
>> < 1KViewDownload

--

[key:62590808]

[Tim Fox]

>>> make changes to Context (ie, remove the static& add a ContextImpl.).

>> Will do. Is there an issue for "the refactoring" that I can track to
>> know when it's done?
> I should probably create one.
>
>
>> Meanwhile, please could someone say what the purpose of Context is? It
>> feels like a slightly odd beast since it is shared across verticles
>> and yet is thread-local
> Over to Tim for the history...
>

Off the top of my head... Context basic represents the execution context
for a piece of code.

E.g. each verticle has its own Context, and a context (non worker) is
associated with an event loop (an event loop can have many contexts
associated with it).

When you call execute on a context it executes the runnable on the same
context, e.g. on the same event loop.

This is used all over the place, e.g. when you set a timer, vertx needs
to ensure that when it fires the firing occurs on the same context as
the caller. The system maintains many timer handlers all from
potentially different contexts so it needs to know this information in
order to execute it correctly.

Contexts can also represent non event loop contexts e.g. worker
verticles, where actions are run on a thread from a pool instead.

BTW, Context is an internal class, not part of the public API, so not
sure why it needs to be split out into interface + impl...

> p
>
>
>>> p
>>>
>>> --
>>>
>>> [key:62590808]
>>>
>>> signature.asc
>>> < 1KViewDownload
>


--

Tim Fox

Vert.x - effortless polyglot asynchronous application development
http://vertx.io
twitter:@timfox

[Glyn]

I see. So each verticle has its own Context and so before a verticle
is dispatched on its thread, vertx presumably needs to set the
corresponding Context into thread local (unless the same verticle was
the last one dispatched, I guess).

Therefore, I'd like some way to set the path adjustment of the Context
when the verticle is created rather than in the request path.

[Tim Fox]

Not sure what you mean by "request path", but the path adjustment is set
by the container when the verticle is deployed.

>> When you call execute on a context it executes the runnable on the same
>> context, e.g. on the same event loop.
>>
>> This is used all over the place, e.g. when you set a timer, vertx needs
>> to ensure that when it fires the firing occurs on the same context as
>> the caller. The system maintains many timer handlers all from
>> potentially different contexts so it needs to know this information in
>> order to execute it correctly.
>>
>> Contexts can also represent non event loop contexts e.g. worker
>> verticles, where actions are run on a thread from a pool instead.
>>
>> BTW, Context is an internal class, not part of the public API, so not
>> sure why it needs to be split out into interface + impl...
>>
>>> p
>>>>> p
>>>>> --
>>>>> [key:62590808]
>>>>> signature.asc
>>>>> < 1KViewDownload
>> --
>> Tim Fox
>>
>> Vert.x - effortless polyglot asynchronous application developmenthttp://vertx.io
>> twitter:@timfox


--
Tim Fox

[Glyn]

I mean the code path which runs under a particular HTTP request.

> but the path adjustment is set
> by the container when the verticle is deployed.

Ok, so I think I'd like to control the path adjustment that the
container sets when the verticle is deployed. I have a non-application
specific path adjustment policy for OSGi and I don't want to pollute
the application with this code.

[Tim Fox]

I'm not sure what you're trying to achieve here, are you writing a
replacement for our current container? ;)

Perhaps if you explain a bit more about what you're aiming for, I can
point you in the right direction.

The path adjustment only really means something in the context of the
container. It basically allows modules to run from their module install
directory as if their working directory was there.

[Glyn]

Not really. I'm embedding vertx core in an OSGi server runtime like
we've done for other types of server including Tomcat, Jetty, and the
OSGi HttpService. This might seem an odd thing to do from your
perspective, but it makes a lot of sense from mine. ;-) I think the
requirements this drives in vertx should be fairly general and be
useful when vertx is embedded in other environments.

I work on the Virgo project which provides a fully-fledged server
runtime constructed from OSGi bundles. To embed a server in this
runtime, we typically wrap the relevant JARs in OSGi bundles (which
usually amounts to little more than augmenting META-INF/MANIFEST.MF
using one of the tools available for that purpose). Then we have to
worry about class and resource loading to make sure this works ok in
the OSGi environment with its graph of class loaders.

So I took the vertx core JAR, converted it into an OSGi bundle, and
got it running in Virgo along with its dependencies (netty, jackson-
core/mapper) each running as a separate OSGi bundle.

The aim is then to be able to deploy vertx applications, packaged in
OSGi bundles, into Virgo and have the applications use vertx in a
fairly normal way. I say fairly normal, as the modular structure lets
you factor out some of the boilerplate code from the application and
leave the application as essentially an HTTP request handler.

(Another possibility, which I won't go into now is to allow "vanilla"
vertx applications to be deployed into this system, but that's another
kettle of fish.)

>
> Perhaps if you explain a bit more about what you're aiming for, I can
> point you in the right direction.

I hope the above explanation is sufficient? Maybe a demo would help?

>
> The path adjustment only really means something in the context of the
> container. It basically allows modules to run from their module install
> directory as if their working directory was there.

Since the application in Virgo is an OSGi bundle with its own class
loader I need to intercept the file lookup to make it use the
application bundle's class loader. The only way I found to do this was
to provide a path adjustment, but I'm open to better alternatives.

[Pid *]

Some of the public API classes refer to it. I will look at how to
internalise it.


p

[Tim Fox]

This is where I get confused.

Vert.x already has a concept of "application", which is basically a set
of verticles executed by vertx run or vertx deploy.

So it seems what you're referring to is some other alternative
definition of vert.x application. (?)

My worry is this is going to confuse users.

Who is the target user group you are envisioning for this?

[Glyn]

I have no desire to hijack vertx terminology. Maybe I should simple
talk about HTTP request handlers packaged ad OSGi bundles instead of
"applications".

>
> My worry is this is going to confuse users.

Agreed.

>
> Who is the target user group you are envisioning for this?

Actually, we have an interesting usecase for Virgo (in the context of
CloudFoundry as it happens) where we need to provide REST endpoints.
Since I have a pet dislike of current web containers, I was even
jokingly speculating about running node.js in Virgo using Rhino a few
days before I became aware of the existence of vertx. So you can
imagine my interest...

The target user group is therefore really only Virgo committers or
possibly CloudFoundry folks who eventually want to see what we come up
with. People who read my blog might take an interest, and they are
usually Virgo and/or OSGi afficionados.

As you'll have noticed, I'm trying to keep this thread separate from
my general comments on the verx module system as I don't want to foist
technology onto the vertx project if it's not appropriate or too
complex. (But I would like the vertx module system design decisions to
be informed by the existence of mature module systems like OSGi since
it's a shame to re-invent the wheel. Some of the major app servers
base their module systems on OSGi as does the Eclipse IDE, so it seems
OSGi is quite generally applicable when there is a requirement for a
Java module system.)

[Tim Fox]

Sounds cool. Hope it goes well.

 

As you'll have noticed, I'm trying to keep this thread separate from
my general comments on the verx module system as I don't want to foist
technology onto the vertx project if it's not appropriate or too
complex. (But I would like the vertx module system design decisions to
be informed by the existence of mature module systems like OSGi since
it's a shame to re-invent the wheel. Some of the major app servers
base their module systems on OSGi as does the Eclipse IDE, so it seems
OSGi is quite generally applicable when there is a requirement for a
Java module system.)

I think we may be able to learn something from OSGI.

OSGI is something that I've been aware of for quite some time, but never really looked into in detail.

I will add it to my TODO list :)

[Glyn]

On May 15, 4:51 pm, Pid <p...@pidster.com> wrote:

I raised https://github.com/purplefox/vert.x/issues/161 to track this
requirement.

Pid: did you raise an issue for the refactoring which I could cite in
issue 161?

[Pid]

https://github.com/purplefox/vert.x/issues/145

p


>> --
>>
>> [key:62590808]
>>
>> signature.asc
>> < 1KViewDownload
>

--

[key:62590808]

[Michiel Vermandel]

Link to the issue seems to be broken...

[Michiel Vermandel]

Hi,

You should definitely look at OSGI. It has quite some similarities, but then again it is not the same.
I think running vertx from within OSGI would be awesome.