« Return to Thread: Communication with an ApplicationServer
Re: Communication with an ApplicationServer
by Richard S. Hall
::
Rate this Message:
On 6/22/09 9:00 AM, Lohmann Kevin wrote:
> Hi *,
>
> our application does communication with an ApplicationServer with
> JNDI-lookups. Therefore we have 3 types of bundles:
>
> (1) "ejb-bundle": It is an special bundle, which encapsulates the true
> AppServer, so with a change of this bundle, we can change the AppServer
> too. This bundle has an explizit symbolic-bundle-name ("ejb-bundle").
> This bundle exists just one time in the OSGi-runtime and includes all
> vendor-specific jar as private-packages (i.e. the jboss-all-client.jar).
> It services an OSGi-service to lookup a remote-interface on the
> AppServer. For this service, it initialized an InitialContext, so the
> "lookup"-service just call lookup on the InitialContext.
>
> (2) "interface-bundle": These bundles includes interfaces, which are the
> remote-interfaces, that are implemented by EJBs on the AppServer. The
> bundles export its interfaces.
>
> (3) "use-bundle": It is a bundle, which use the remote-interface. Is has
> imports on the interface-packages. The use-bundle gets the
> remote-Interface over the OSGi-Service, described above.
>
> So, we call in an use-bundle the lookup-service and hope to retrieve a
> remote-interface. But this only works, when we make the
> interface-bundles as fragments and attach them to the "ejb-bundle".
> Otherwise we retrieve not a proxy-object, but an object, which we can
> not cast to our remote-interface -> class-loading-issue.
>
> So far, so good? Is there a solution without fragment/host?
>
It is not clear to me why the ejb-bundle must have the remote interfaces
attached as fragments as opposed to just importing the remote
interfaces. If use-bundle gets its interfaces from interface-bundle, but
ejb-bundle gets them as fragments, then they are seeing different copies
of the same interfaces, which is typically not good.
> We could live with that, but we allow to install bundles during runtime.
> That means, we must dynamicly attach fragments to the ejb-bundle. But we
> run in errors, when we uninstall these bundles. Then we have to
> dynamicly detach the fragments from the host. Surprisingly when we type
> "refresh n" in the console from equinox (n is the bundle_id from the
> ejb-bundle), the whole OSGi-framework is refreshed.
>
Dynamic fragment attachment is not mandated by the spec. I don't think
dynamic fragment detachment is possible.
-> richard
> How do you do this?
> Instead of returning an remote-interface, the lookup-service could
> return the initialcontext-object. But then we run into
> class-loading-issues too. Creating the initialcontext in the
> "use-bundle" works not too, I assume this is because of not importing
> the vendor-specific classes from the ejb-bundle. But the use-bundles
> does not know about the AppServer-vendor.
>
> I hope, my concerns got clear. Any ideas to this?
>
> Cheers,
> Kevin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...
> Hi *,
>
> our application does communication with an ApplicationServer with
> JNDI-lookups. Therefore we have 3 types of bundles:
>
> (1) "ejb-bundle": It is an special bundle, which encapsulates the true
> AppServer, so with a change of this bundle, we can change the AppServer
> too. This bundle has an explizit symbolic-bundle-name ("ejb-bundle").
> This bundle exists just one time in the OSGi-runtime and includes all
> vendor-specific jar as private-packages (i.e. the jboss-all-client.jar).
> It services an OSGi-service to lookup a remote-interface on the
> AppServer. For this service, it initialized an InitialContext, so the
> "lookup"-service just call lookup on the InitialContext.
>
> (2) "interface-bundle": These bundles includes interfaces, which are the
> remote-interfaces, that are implemented by EJBs on the AppServer. The
> bundles export its interfaces.
>
> (3) "use-bundle": It is a bundle, which use the remote-interface. Is has
> imports on the interface-packages. The use-bundle gets the
> remote-Interface over the OSGi-Service, described above.
>
> So, we call in an use-bundle the lookup-service and hope to retrieve a
> remote-interface. But this only works, when we make the
> interface-bundles as fragments and attach them to the "ejb-bundle".
> Otherwise we retrieve not a proxy-object, but an object, which we can
> not cast to our remote-interface -> class-loading-issue.
>
> So far, so good? Is there a solution without fragment/host?
>
It is not clear to me why the ejb-bundle must have the remote interfaces
attached as fragments as opposed to just importing the remote
interfaces. If use-bundle gets its interfaces from interface-bundle, but
ejb-bundle gets them as fragments, then they are seeing different copies
of the same interfaces, which is typically not good.
> We could live with that, but we allow to install bundles during runtime.
> That means, we must dynamicly attach fragments to the ejb-bundle. But we
> run in errors, when we uninstall these bundles. Then we have to
> dynamicly detach the fragments from the host. Surprisingly when we type
> "refresh n" in the console from equinox (n is the bundle_id from the
> ejb-bundle), the whole OSGi-framework is refreshed.
>
Dynamic fragment attachment is not mandated by the spec. I don't think
dynamic fragment detachment is possible.
-> richard
> How do you do this?
> Instead of returning an remote-interface, the lookup-service could
> return the initialcontext-object. But then we run into
> class-loading-issues too. Creating the initialcontext in the
> "use-bundle" works not too, I assume this is because of not importing
> the vendor-specific classes from the ejb-bundle. But the use-bundles
> does not know about the AppServer-vendor.
>
> I hope, my concerns got clear. Any ideas to this?
>
> Cheers,
> Kevin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...
« Return to Thread: Communication with an ApplicationServer
| Free embeddable forum powered by Nabble | Forum Help |
