<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<tt>> using the OSGi programming model I won't be able to employ
JBoss AS 7's configuration model for my needs. Or am I mistaken in
this?</tt><tt><br>
<br>
Right from the beginning I copied the semantics from <a
href="http://www.osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html">ConfigurationAdmin</a>
and made it available as a native AS7 service - its the <a
href="https://github.com/tdiesler/jboss-as/tree/master/osgi/configadmin">configadmin</a>
subsystem that does this. In fact when you use the <a
href="http://felix.apache.org/site/apache-felix-config-admin.html">Felix
ConfigurationAdmin</a> it delegates to this services and your
configurations are maintained as part of the AS7 domain model.
Hence they are exposed through the management API and therefore
visible in the web console and cli.<br>
<br>
> On the other hand I do understand why one might be reluctant
to introduce yet another programming model to a wider audience.<br>
<br>
I recommend to stick with the EE programming model when you can.
If your requirements are such that you need to have modular
applications that can be developed by disconnected teams, need to
have lifecycle with your components (i.e. start/stop/update) or
loose coupling of dynamic services I'd go with the OSGi standard.<br>
<br>
In AS7 you can mix both worlds i.e. access OSGi services from EE
components and vice versa. You can for example architect a complex
web application as a collection of bundles, each dedicated to a
specific functionality. These plugin bundles can be
added/updated/removed on the fly with your webapp reacting
accordingly. Additionally, you can start/stop the web context
without having to undeploy the archive. Have a look at <a
href="https://issues.jboss.org/browse/AS7-5051">[AS7-5051] Allow
EE deployments as OSGi bundles</a> for more like this. <br>
<br>
--thomas<br>
</tt><br>
<div class="moz-cite-prefix">On 09/06/2012 08:24 PM, Olaf Bergner
wrote:<br>
</div>
<blockquote cite="mid:5048EA4D.7040104@gmx.de" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">That sounds reasonable. Time
permitting, I might try to lend a hand. The only downside I see
that as a developer building an application on this platform
using the OSGi programming model I won't be able to employ JBoss
AS 7's configuration model for my needs. Or am I mistaken in
this? Maybe a custom configuration admin implementation that
delegates to JBoss AS 7's built-in mechanism ...<br>
<br>
On the other hand I do understand why one might be reluctant to
introduce yet another programming model to a wider audience.<br>
<br>
Am 05.09.12 10:36, schrieb Thomas Diesler:<br>
</div>
<blockquote cite="mid:50470F27.7020704@jboss.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<tt>I agree, that there is value in a modular build. Its tracked
by <a moz-do-not-send="true"
href="https://issues.jboss.org/browse/AS7-5494">[AS7-5494]
Add support for a modular AS7 build</a><br>
<br>
It would also allow other projects to decouple from the AS7
release cycle and provide a minimalistic runtime to support
their stuff. Specifically, I'm interested to go back to a more
predictable release cycle for the jbosgi and again include a
standalone runtime with our distribution. The runtime would be
AS7 based, include the osgi subsystem and possibly other
subsystems we integrate with (e.g. naming, transaction, jmx,
web, ...)<br>
<br>
</tt>
<div class="moz-cite-prefix">On 09/04/2012 12:58 PM, Thomas
Diesler wrote:<br>
</div>
<blockquote cite="mid:5045DEC2.1060502@jboss.com" type="cite">This
probably needs to be a community driven effort. A "product in
its own right" actually triggers an armada of jboss/redhat
folks to do additional work on top of what we put out as a
community project. This would only be done if justified by
sufficient interest. <br>
<br>
A good starting point would be to modify the build such that
is supports configurable subsystems. From a modular service
container perspective it's probably worth to stick with the
standards and use the osgi only profile. <br>
<br>
On 09/03/2012 09:48 PM, Olaf Bergner wrote: <br>
<blockquote type="cite">While I think that JBoss AS 7's
architecture and implementation are <br>
outstanding neither I nor the company I'm working for have a
need for a <br>
JEE container. What we *do* have a need for, though, is a
robust, <br>
performant, flexibel and manageable runtime for deploying
our networked <br>
services in. Having taken a look at JBoss AS 7's Modular
Service <br>
Container, its extension mechanism, its flexibel
configuration model and <br>
the fact that it's based on JBoss Modules I started to think
that a <br>
JBoss AS 7 distribution stripped down to its core just might
fit the bill. <br>
<br>
Beyond creating that minimal distribution itself I think all
it would <br>
take is to add some documentation, especially on how to use
the Modular <br>
Service Container, something I couldn't find *any*
documentation for. <br>
Plus maybe a sample application or two. Provided someone in
the know <br>
volunteered to assist me I would be more than willing to
provide those. <br>
<br>
What do you think? <br>
<br>
Regards, <br>
Olaf <br>
_______________________________________________ <br>
jboss-as7-dev mailing list <br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:jboss-as7-dev@lists.jboss.org">jboss-as7-dev@lists.jboss.org</a>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://lists.jboss.org/mailman/listinfo/jboss-as7-dev">https://lists.jboss.org/mailman/listinfo/jboss-as7-dev</a>
<br>
</blockquote>
<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
</pre>
</blockquote>
<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
</pre>
</body>
</html>