Hi Sahoo.
1. Many thanks for your reply, it much more clear to me now.
> > 2. Currently, the “asadmin” utility doesn’t
> allow to use a valid URL (only file system objects
> are allowed) to specify a module for deploy. Are you
> planning to extend the current abilities of the
> utility to allow this feature?
> >
> This will be a good feature to have in asadmin. Can
> you file an RFE? It
> should be possible to easily extend asadmin to accept
> a URL which is
> then interpreted only at the server side where
> appropriate URL handlers
> can be installed for custom URL protocols.
We have made an attempt to implement the own ReadableArchive extension which dynamically builds the content of a module. To our deep regrets we couldn’t deploy it because according to the current deployment procedure the instance of ReadableArchive must be associated with file only (DeployCommand.java).
> > 3. Once hybrid OSGI bundle deployed, an
> ApplicationInfo instance created for it. That means
> there is no possibility to add an additional module
> to the existing application. Are you planning to
> extend the functionality of WEB-OSGI and deployment
> utility to allow changing the set of modules the
> running application consists of?
> >
> If you look at the code for OSGi Web Container, you
> shall see that upon
> update of an OSGi bundle, we redeploy the underlying
> Java EE artifact,
> so everything that a redeploy allows is theoritically
> possible via a
> bundle update. Given that it requires stopping of
> currently deployed
> app, I guess this is not what you are looking for.
The basic point of that question was that it would be nice to have a possibility to develop applications (including the Web based ones) extendable with the external modules. A good sample of that approach is GF Web Console that could be easily extended with HK2 services. At the same time, the same approach has significant disadvantage I’ll try to demonstrate:
Let’s say we have a couple of OSGI-web bundles (Ext1 and Ext2) with some J2EE artifacts. We also have a couple of OSGI-Web applications: App1 and App2. Currently, we can’t extend App1 with artifacts of Ext1 as well as App2 with Ext2 because:
1. Once deployed, Ext1 and Ext2 will cause the new applications creation;
2. Once deployed as Web bundle, they will be added into domain as regular OSGI bundles. That will expose their content to all domains’ applications.
What I expect instead of what we currently have is that the application would have the own J2EE artifacts as well as the artifacts from the extensions deployed and associated with that application.
It seems that this issue could be resolved by establishing the relation between the applications and extensions at deploy time. For instance, it could be done by adding “application-name” argument to the “-t osgi deploy” command.
Are you planning to provide something similar to the functionality described above to support modularized applications?
> > 4. The problem is that currently, the hybrid
> OSGI+WEB+EJB bundle must be packet into one single
> bundle, an analog of EAR. Are you planning to extend
> the functionality of the deployment module to allow
> the installation of OSGI modules from Maven
> repositories with resolving (and installing) of
> referenced\dependent modules? There is an external
> OSGI module called PAX
> URL(http://wiki.ops4j.org/display/paxurl/Pax+URL)
> that allows installing OSGI bundles from Maven
> repository with using of osgi console but it doesn’t
> process the referenced modules.
> >
> I am not sure why you raised the issue of WAR/EAR
> packaging in the above
> paragraph. I don't see the connection between them
> and your subsequent
> question of installing a bundle and its dependencies
> from maven. We
> currently only support WAR packaging as that's
> getting standardised in
> the OSGi enterprise spec. We are thinking of EAR
> case as well.
> Installing bundles and its dependencies from maven
> can probably be
> addressed via OBR.
You are absolutely right that OBR is quite suitable for uploading of dependent modules. At the same time, since the MAVEN is used for development purposes, it would be nice to eliminate the additional phase of OBR repository building.
> > 5. Are you planning to implement JPA support as
> a part of GF v3 for hybrid modules by the following
> way: the newly installed (redeployed) bundle would
> extend the existing Persistent Unit(s) with the new
> classes, or it would cause the new PU creation.
> “Dynamic JPA” project
> (http://www.dynamicjava.org/projects/dynamic-jpa) is
> a good sample of this approach implementation;
> >
> >
> Currently I am investigating use of JPA in hybrid
> applications. Since
> class file transformation is still an open issue in
> OSGi environment, I
> have not made a lot of progress here.
>
> DynamicJPA project sounds very interesting, but I
> don't understand what
> a container has to do here. You should be able to use
> it even now in
> GFv3, right?
One of the most important features that the application may use is the possibility to operate with DB via JPA. Potentially, an extension module could extend the PU model by installing the new and/or modifying the existing ones. In other words, by installing of the extension modules, the new PU’s could become available for application(s) as well as the existing ones could be modified (new entities, relations etc.)
I really appreciate you patience and hope to continue this discussion.
With best regards,
Maxim Volkov.
[Message sent by forum member 'mvolkov' (reson_at_mail.ru)]
http://forums.java.net/jive/thread.jspa?messageID=368611