You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Lohmann Kevin <ke...@d-velop.de> on 2009/06/22 15:00:13 UTC
Communication with an ApplicationServer
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?
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.
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@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
AW: AW: Communication with an ApplicationServer
Posted by Lohmann Kevin <ke...@d-velop.de>.
Richard S. Hall [mailto:heavy@ungoverned.org], 23. Juni 2009 15:39:
> >>> (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?
Thats correct!
It seems, that the InitialContext has to have the interfaces on its
classpath when it is created. But not only the interfaces, the
application server-specific classes too.
But that is something, we just suppose and I hope, someone can clarify
that.
Cheers,
Kevin
> >> 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@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: AW: Communication with an ApplicationServer
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
AW: Communication with an ApplicationServer
Posted by Lohmann Kevin <ke...@d-velop.de>.
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?
> 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?
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@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Communication with an ApplicationServer
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org