Skip to main content

hybrid OSGI+Web+EJB+JPA application

5 replies [Last post]
mvolkov
Offline
Joined: 2009-02-10

First of all, I would like to appreciate Sahoo for his efforts in EJB, WEB and OSGI hybridization. I have a strong intention to use the benefits of the new approach, but some questions arose:

1. Currently (GF v3 b65), the WEB based administrative console has no information about deployed hybrid applications. Are you planning to extend the current abilities of the console to allow the user to see the installed hybrid applications?

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?

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?

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.

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;

6. Are you planning to implement the possibility of EJB container and services launching in “pure” OSGI environment?

With best regards, Maxim Volkov.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
mvolkov
Offline
Joined: 2009-02-10

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.

Sahoo

glassfish@javadesktop.org wrote:
> 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).
>
>
I am not surprised that it is not extensible enough to allow the
extension we are talking about here. That's why I asked you to file an
RFE and let deployment team take a look at it. If you can even propose a
patch or suggest an approach to address the RFE, that's more than welcome.
>>> 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?
>
>
Interesting requirement. I think Spring Slices project [1] is one
approach. I think with programmatic servlet registration feature of
Servlet 3.0 spec, we should be able to extend web apps in GlassFish as
well. I will experiment around this. Can you file an RFE with your
requirements and thoughts?

[1]
http://blog.springsource.com/2009/06/22/modular-web-applications-with-sp...
>>> 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.
>
File an RFE. It needs further investigation.
>
>>> 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.
>
Yes, I do realize the benefits of extensible web apps. Thanks for asking
for them. If you want to help me in implementation of any of any of
these features, you are most welcome.

Thanks,
Sahoo
> With best regards,
> Maxim Volkov.
> [Message sent by forum member 'mvolkov' (reson@mail.ru)]
>
> http://forums.java.net/jive/thread.jspa?messageID=368611
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Sahoo

Hi Maxim,

Sorry for the late reply. Pl. see reply in line...

glassfish@javadesktop.org wrote:
> First of all, I would like to appreciate Sahoo for his efforts in EJB, WEB and OSGI hybridization. I have a strong intention to use the benefits of the new approach, but some questions arose:
>
> 1. Currently (GF v3 b65), the WEB based administrative console has no information about deployed hybrid applications. Are you planning to extend the current abilities of the console to allow the user to see the installed hybrid applications?
>
This is largely because our admin console does not have any features for
administration of OSGi runtime. We wanted to do this in v3 release
(scheduled to release very soon), but because of lack of resource, we
could not achieve this. However, given that admin console in v3 is
extensible, this feature can be added even after the release.
> 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.
> 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.
> 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.
> 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?
> 6. Are you planning to implement the possibility of EJB container and services launching in “pure” OSGI environment?
>
What exactly you mean by pure OSGi environment? GlassFish does not use
any custom OSGi runtime. It is possible to launch GF bundles in an
existing OSGi runtime. What is currently lacking is launching of
individual containers like ejb-container or web-container. I guess
that's a question for individual container owners. I don't know what
their plans are.

Once again, thanks for your comments. Keep them coming.

Thanks,
Sahoo

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

mvolkov
Offline
Joined: 2009-02-10

Dear Sahoo,

I really appreciate your quick response. Unfortunately, I didn't make questions 3-6 as clear as they should be and I'll try to make them so as soon as possible.
With best regards, Maxim Volkov.

Sahoo

Hi Maxim,

Thanks for your feedback. Please give me some more time to go through
the issues you have raised in your email and I shall respond. I will
appreciate if you can offer any help in improving the support for hybrid
applications.

Thanks,
Sahoo

glassfish@javadesktop.org wrote:
> First of all, I would like to appreciate Sahoo for his efforts in EJB, WEB and OSGI hybridization. I have a strong intention to use the benefits of the new approach, but some questions arose:
>
> 1. Currently (GF v3 b65), the WEB based administrative console has no information about deployed hybrid applications. Are you planning to extend the current abilities of the console to allow the user to see the installed hybrid applications?
>
> 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?
>
> 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?
>
> 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.
>
> 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;
>
> 6. Are you planning to implement the possibility of EJB container and services launching in “pure” OSGI environment?
>
> With best regards, Maxim Volkov.
> [Message sent by forum member 'mvolkov' (reson@mail.ru)]
>
> http://forums.java.net/jive/thread.jspa?messageID=367098
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net