Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [gyrex-dev] dealing with modularization...

On 28/11/12 17:33, Gunnar Wagenknecht wrote:
Hi,

Am 28.11.2012 15:20, schrieb Cristiano Gavião:
I could note that gyrex product has more than one application, being one
visible, ok.

Do you mean OSGi applications or HTTP applications?
yep. I'm referring to an OSGi app, the ones that has org.eclipse.core.runtime.applications extension point(org.eclipse.gyrex.cloud, org.eclipse.gyrex.http.jetty. 

but what is the rule for my own apps creation? I mean, when should I
create an application or just add features/bundles ?

I assume you are speaking about OSGi applications. So there is some history. First we associated roles only with bundles. This meant that everything was tight to the bundle activator start/stop. At some point we came up with the idea of using OSGi applications instead of the bundles. The motivation was that they would give us more flexibility long term. Thus, we migrated to OSGi applications. We are now no longer tight to bundles and can refactor applications into different bundles (if necessary).

I have no sure yet, but seems that an application (the one defined in OSGi Application Admin specification) has no lifecycle relation with the bundles that it depends on, right? I mean, if I start/stop one app it not necessarily will do the same with it child bundles, right?

I could see that the application defined in Subsystem Service Specification do that... but only Apache Aries have implementation for that(http://aries.apache.org/modules/applications.html)...
how could I setup bundles that needs to auto-start, for example
gemini-jpa and eclipse-link ?

I created:
http://wiki.eclipse.org/Gyrex/Developer_Guide/Roles

Let me know if I need to add more explanations to that page.

It would be interesting to explain the existent trigger types. they are fixed ?

when these roles are processed ? who is responsible for that?

is there an api for the roles maintenance  ?


and how to setup a default p2 url ?
should I create my own product for that?

That's something we haven't had yet. p2 URLs are stored in ZooKeeper. The p2.inf won't work here. I think one possibility would be to write a small initialization role that checks on cloud connect if the data has been initialized already and inserts the necessary data into ZooKeeper if not (using P2Activator.getInstance.getRepositoryManager).

what is the expected behavior actually defined for provisioning ? installing a feature in the master node will trigger the same in the other nodes?


-Gunnar



Back to the top