Ticket #272 (closed Defect: fixed)

Opened 12 years ago

Last modified 12 years ago

Hot deploying a module unnecessarily restarts all other modules

Reported by: jri Owned by: jri
Priority: Major Milestone: Release 4.1
Component: DeepaMehta Standard Distribution Version: 4.0.11
Keywords: Cc: dgf
Complexity: 5 Area: Runtime Environment
Module: deepamehta-core

Description

This happens only if the deployed module provides REST resources.

Thanks dgf for pointing this out!

Change History

comment:1 Changed 12 years ago by jri

  • Status changed from new to accepted

comment:2 Changed 12 years ago by Jörg Richter

Core: use a Jersey servlet singleton (#272).

We hope this will solve the oddities with module hot deployment.

The singleton is encapsulated in a new OSGi "WebPublishingService?" as provided by the DM core.
The plugins register their resources through this service.

Not fully functional.

See ticket 272.

comment:3 Changed 12 years ago by Jörg Richter

Core: adapt plugin REST services (#272).

A plugin's provider classes are picked up automatically.
A plugin must no longer provide an Application class.

The Webclient's start URL has changed:

http://localhost:8080/de.deepamehta.webclient/

The root namespace is already occupied by the Jersey root application.

IMPORTANT: To adapt to the new Webclient base URL you must reset your database.

Not fully functional.

See ticket 272.

comment:4 Changed 12 years ago by Jörg Richter

Core: WebPublishing? service basically works (#272)

Plugins add their REST resources via the WebPublishing? service.
Removing resources is pending.

Plugin's "Application" classes are dropped.

See ticket 272.

comment:5 Changed 12 years ago by Jörg Richter

Core: removing REST resources dynamically (#272).

Reloading a module (via hot deployment) that provides REST resources works properly now. Other modules are not affected.
So, the main problem seems to be solved now.

Secondary issues remain (e.g. reloading the core, or shutdown) and will be addressed shortly.

Hi dgf! Your intuition with the multiple Jersey servlet instances as the culprit seems to prove correct.
Thank you!

See ticket 272.

comment:6 Changed 12 years ago by Jörg Richter

Core: dynamic un/register Jersey servlet (#272).

Once all REST resources are removed the Jersey servlet is unregistered.
As soon as resources are added the Jersey servlet is registered again.
So, actions like reloading the DM core or shutdown the platform perform properly.

Note: there is still an issue with reloading the Webclient module but this is not REST related and needs to be addressed in another ticket.

See ticket 272.

comment:7 Changed 12 years ago by Jörg Richter

Core: abolish resource config properties (#272).

2 properties are no longer required to be set in plugin.properties:

"restResourcesNamespace" -- now set in the plugin class's @Path anotation
"webResourcesNamespace" -- not configurable anymore

See ticket 272.

comment:8 Changed 12 years ago by Jörg Richter

Core: plugins doesn't consume HttpService? (#272).

Instead they are register their web resources through the WebPublishingService?.

WebPublishingService? provides 2 new methods:

WebResources addWebResources(Bundle bundle, String uriNamespace)
void removeWebResources(WebResources webResources)

All web publishing features are encapsulated in the WebPublishingService?.

See ticket 272.

comment:9 Changed 12 years ago by Jörg Richter

Core: use a Jersey servlet singleton (#272).

We hope this will solve the oddities with module hot deployment.

The singleton is encapsulated in a new OSGi "WebPublishingService?" as provided by the DM core.
The plugins register their resources through this service.

Not fully functional.

See ticket 272.

comment:10 Changed 12 years ago by Jörg Richter

Core: adapt plugin REST services (#272).

A plugin's provider classes are picked up automatically.
A plugin must no longer provide an Application class.

The Webclient's start URL has changed:

http://localhost:8080/de.deepamehta.webclient/

The root namespace is already occupied by the Jersey root application.

IMPORTANT: To adapt to the new Webclient base URL you must reset your database.

Not fully functional.

See ticket 272.

comment:11 Changed 12 years ago by Jörg Richter

Core: WebPublishing? service basically works (#272)

Plugins add their REST resources via the WebPublishing? service.
Removing resources is pending.

Plugin's "Application" classes are dropped.

See ticket 272.

comment:12 Changed 12 years ago by Jörg Richter

Core: removing REST resources dynamically (#272).

Reloading a module (via hot deployment) that provides REST resources works properly now. Other modules are not affected.
So, the main problem seems to be solved now.

Secondary issues remain (e.g. reloading the core, or shutdown) and will be addressed shortly.

Hi dgf! Your intuition with the multiple Jersey servlet instances as the culprit seems to prove correct.
Thank you!

See ticket 272.

comment:13 Changed 12 years ago by Jörg Richter

Core: dynamic un/register Jersey servlet (#272).

Once all REST resources are removed the Jersey servlet is unregistered.
As soon as resources are added the Jersey servlet is registered again.
So, actions like reloading the DM core or shutdown the platform perform properly.

Note: there is still an issue with reloading the Webclient module but this is not REST related and needs to be addressed in another ticket.

See ticket 272.

comment:14 Changed 12 years ago by Jörg Richter

Core: abolish resource config properties (#272).

2 properties are no longer required to be set in plugin.properties:

"restResourcesNamespace" -- now set in the plugin class's @Path anotation
"webResourcesNamespace" -- not configurable anymore

See ticket 272.

comment:15 Changed 12 years ago by Jörg Richter

Core: plugins doesn't consume HttpService? (#272).

Instead they are register their web resources through the WebPublishingService?.

WebPublishingService? provides 2 new methods:

WebResources addWebResources(Bundle bundle, String uriNamespace)
void removeWebResources(WebResources webResources)

All web publishing features are encapsulated in the WebPublishingService?.

See ticket 272.

comment:16 Changed 12 years ago by jri

  • Status changed from accepted to closed
  • Resolution set to fixed

comment:17 Changed 12 years ago by dgf

what a run - great! a hotdeploy now works as expected and the implementation looks more compatible to the OSGi especially Service design. it feels always rigth to me if some configurations can be eleminated in favour of convention like the provider package.

comment:18 Changed 12 years ago by jri

Thanks for the kind comment :-)
In fact it was you who gave the trigger for dealing with that nasty problem now and who delivered the basic idea for solution.

Meanwhile I have a clue what might be the original problem cause: The Plugin base class's dependeny on the ServletContainer? class. Once the latter is unloaded by Felix all bundles depending on it are stopped. That is *all* bundles (because all depend on Plugin). Now, with the new design, Plugin has no Jersey dependency at all, only the Core module has.
You can see the same bundle stopping behavior when redeploying the Core module: Felix stops all bundles because all depend on Core classes (at least on Plugin as the OSGi Activator). But in this case this is exactly the intended behavior.

I feel happy with the new implementation too.
Thanks for good cooperation!

comment:19 Changed 12 years ago by Jörg Richter

Core: use a Jersey servlet singleton (#272).

We hope this will solve the oddities with module hot deployment.

The singleton is encapsulated in a new OSGi "WebPublishingService?" as provided by the DM core.
The plugins register their resources through this service.

Not fully functional.

See ticket 272.

comment:20 Changed 12 years ago by Jörg Richter

Core: adapt plugin REST services (#272).

A plugin's provider classes are picked up automatically.
A plugin must no longer provide an Application class.

The Webclient's start URL has changed:

http://localhost:8080/de.deepamehta.webclient/

The root namespace is already occupied by the Jersey root application.

IMPORTANT: To adapt to the new Webclient base URL you must reset your database.

Not fully functional.

See ticket 272.

comment:21 Changed 12 years ago by Jörg Richter

Core: WebPublishing? service basically works (#272)

Plugins add their REST resources via the WebPublishing? service.
Removing resources is pending.

Plugin's "Application" classes are dropped.

See ticket 272.

comment:22 Changed 12 years ago by Jörg Richter

Core: removing REST resources dynamically (#272).

Reloading a module (via hot deployment) that provides REST resources works properly now. Other modules are not affected.
So, the main problem seems to be solved now.

Secondary issues remain (e.g. reloading the core, or shutdown) and will be addressed shortly.

Hi dgf! Your intuition with the multiple Jersey servlet instances as the culprit seems to prove correct.
Thank you!

See ticket 272.

comment:23 Changed 12 years ago by Jörg Richter

Core: dynamic un/register Jersey servlet (#272).

Once all REST resources are removed the Jersey servlet is unregistered.
As soon as resources are added the Jersey servlet is registered again.
So, actions like reloading the DM core or shutdown the platform perform properly.

Note: there is still an issue with reloading the Webclient module but this is not REST related and needs to be addressed in another ticket.

See ticket 272.

comment:24 Changed 12 years ago by Jörg Richter

Core: abolish resource config properties (#272).

2 properties are no longer required to be set in plugin.properties:

"restResourcesNamespace" -- now set in the plugin class's @Path anotation
"webResourcesNamespace" -- not configurable anymore

See ticket 272.

comment:25 Changed 12 years ago by Jörg Richter

Core: plugins doesn't consume HttpService? (#272).

Instead they are register their web resources through the WebPublishingService?.

WebPublishingService? provides 2 new methods:

WebResources addWebResources(Bundle bundle, String uriNamespace)
void removeWebResources(WebResources webResources)

All web publishing features are encapsulated in the WebPublishingService?.

See ticket 272.

Note: See TracTickets for help on using tickets.