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

Matthieu Morel commented on S4-4:
---------------------------------

I pushed some improvements to the current multiclassloader approach to leo's 
master branch for s4-piper.

We are now able to load applications from a given application directory, and 
the code of an application runs in isolation from other applications, including 
dynamically generated classes.

I included some regression tests and I also checked that the mechanism works 
correctly for packaging and deploying an existing app from s4-examples.


In addition, we also have a basis for s4r application archives: jar file with a 
manifest identifying app entry point (application class).

This corresponds to M1 above, but there are more improvements to be included:

Next steps:
1. provide a mechanism for users to generate s4r packages by encapsulating both 
application code and related dependencies
2. define an API for fetching s4r packages from remote repositories (with 
implementation using different underlying technologies: file system etc... and 
provide some security features, though maybe not in a first version)
3. synchronize deployment (and startup of applications) through zookeeper

                
> Dynamic App Loading
> -------------------
>
>                 Key: S4-4
>                 URL: https://issues.apache.org/jira/browse/S4-4
>             Project: Apache S4
>          Issue Type: New Feature
>            Reporter: Leo Neumeyer
>            Assignee: Matthieu Morel
>             Fix For: 0.5
>
>
> We want to be able to load and unload applications dynamically. Here is some 
> background information:
> Once a server is started, we expect it to run indefinitely until there is a 
> failure or we need to upgrade the framework software or we change the cluster 
> configuration. In S4, the cluster is symmetric, that is, all the nodes are 
> identical, with the same code base and the same configuration.
> Applications are loaded dynamically after the cluster is started. If app1 
> depends on app2, then app2 needs to use an EventSource to publish events. 
> Apps must be able to find EventSource and subscribe to it during 
> initialization.
> When an app is unloaded, it will close its EventSource(s). This in turn, will 
> close all the streams that are subscribed. The apps that own the streams are 
> responsible for taking action once their dependencies are gone.
> Possible roadmap:
> M1:
> - Server starts with no apps.
> - Apps are loaded during initialization, for example by searching an
> app directory.
> - Apps are initialized (no dependencies among apps).
> - Apps are started.
> M2:
> - Add dependencies among apps using EventSource.
> M3:
> - Add runtime loading/unloading functionality
> Leo implemented a solution using JBOSS Modules which seems simpler than using 
> OSGI. Modules seems to work but is not well documented which makes it hard to 
> use without understanding the low level details. See the commented out code 
> here: 
> https://github.com/leoneu/s4-piper/blob/master/subprojects/s4-core/src/main/java/io/s4/core/Server.java
> From Adam:
> Yes I have a few ideas but I need couple days to implement them.
> First, is to build S4 and examples as proper OSGi bundles using gradle osgi 
> plugin http://gradle.org/osgi_plugin.
> Its using bnd tool http://www.aqute.biz/Bnd/Bnd.
> Then embed osgi container (using standard osgi api)  in Controller instead of 
> JBoss modules see 
> http://felix.apache.org/site/apache-felix-framework-launching-and-embedding.html.
> and configure directory from which felix should auto deploy our examples 
> http://felix.apache.org/site/apache-felix-framework-usage-documentation.html#ApacheFelixFrameworkUsageDocumentation-autodeploy.
>  For dynamic deployment we can use file install bundle 
> http://felix.apache.org/site/apache-felix-file-install.html, it will watch 
> directory from which it loads new bundles.
> To configure properly examples we can use ipojo 
> http://felix.apache.org/site/apache-felix-ipojo.html or declarative services 
> http://felix.apache.org/site/apache-felix-service-component-runtime.html, 
> they both using service component model and are not intrusive in the code.
> That will be enough to load properly the apps.
> Later we have to think how we want to use osgi in s4, just to load apps or 
> properly use service management. Bundles are hiding the internals from other 
> bundles and should communicate through well defined services. And also I 
> don't have clear picture how s4 is going to be distributed (have to look more 
> at https://github.com/s4/s4). Maybe you can write me some small description 
> of s4 concept.
> ...
> I've implemented ideas which I sent you before. Now I can load the apps using 
> embedded osgi container but there is still class loading issue 
> (com.esotericsoftware.kryo.SerializationException: Unable to find class: 
> io.s4.example.counter.UserEvent). To be able to run s4 I had to put plenty 
> system packages in configuration file for felix. 
> Around 15 jars defined in libraries are not osgi bundles (don't have proper 
> manifest file). The biggest issue are dependencies and classloading (for 
> example Kryo is trying to load UserEvent class but that class is not visible 
> for him so Class.forName is not going to work).I will try to fix these 
> problems, in the meantime you can have a look at my repo 
> https://github.com/adamwojtuniak/s4-piper. I added task createRepo, it will 
> create bundles directory with all dependencies and project jars. When you 
> launch Main class from s4-core, it launches embedded felix which will auto 
> deploy all bundles located in bundles directory. In the console you will see 
> felix gogo shell ( http://www.packtpub.com/article/apache-felix-gogo ).
> From Henry:
> Ugh, I was actually trying to avoid OSGI if I can =)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to