« Return to Thread: Communication with an ApplicationServer
Re: AW: Communication with an ApplicationServer
by Richard S. Hall
::
Rate this Message:
On 6/23/09 1:34 AM, Lohmann Kevin wrote:
> Hi Richard,
>
> thanks for replying!
>
>
>>> (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.
>>>
> [..]
>
>> 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.
>>
> In this point I was not very clear or I don't understand fragments
> right.
> My opinion is, that the use-bundle, which has an import-directive for
> the interfaces, retrieve them from the ejb-bundle. Because the
> interface-bundle is an fragment to the ejb-bundle.
> So both bundles (ejb + use) must have the same copy of the interface.
> Isn't that, what fragments are designed to?
>
Ok, it wasn't clear to me that the interface bundle was a fragment of
the ejb-bundle.
So, if I understand correctly, you are using fragments in this case
because ejb-bundle does not know which interfaces it will need, so it
cannot import them statically in advance, correct?
This sounds fairly reasonable.
>> Dynamic fragment attachment is not mandated by the spec. I
>> don't think
>> dynamic fragment detachment is possible.
>>
> Ah, ok, thats bad for us, but a statement.
>
> So question to the list:
> How do you use the initial context for looking up ejb-remote interfaces?
>
That, I don't know.
-> richard
> Cheers,
> Kevin
>
>
>
>> 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@...
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
> Hi Richard,
>
> thanks for replying!
>
>
>>> (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.
>>>
> [..]
>
>> 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.
>>
> In this point I was not very clear or I don't understand fragments
> right.
> My opinion is, that the use-bundle, which has an import-directive for
> the interfaces, retrieve them from the ejb-bundle. Because the
> interface-bundle is an fragment to the ejb-bundle.
> So both bundles (ejb + use) must have the same copy of the interface.
> Isn't that, what fragments are designed to?
>
Ok, it wasn't clear to me that the interface bundle was a fragment of
the ejb-bundle.
So, if I understand correctly, you are using fragments in this case
because ejb-bundle does not know which interfaces it will need, so it
cannot import them statically in advance, correct?
This sounds fairly reasonable.
>> Dynamic fragment attachment is not mandated by the spec. I
>> don't think
>> dynamic fragment detachment is possible.
>>
> Ah, ok, thats bad for us, but a statement.
>
> So question to the list:
> How do you use the initial context for looking up ejb-remote interfaces?
>
That, I don't know.
-> richard
> Cheers,
> Kevin
>
>
>
>> 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@...
>>
>>
>>
>
> ---------------------------------------------------------------------
> 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 |
