Am 07.08.2008 um 18:09 schrieb "Stuart McCulloch" <[EMAIL PROTECTED]
>:
2008/8/7 Jackson, Bruce <[EMAIL PROTECTED]>
Its not exactly a legacy situation. The problem I have is one
that's shared
with many object persistence frameworks that would naturally
provide that
capability as a serv
2008/8/7 Jackson, Bruce <[EMAIL PROTECTED]>
> Its not exactly a legacy situation. The problem I have is one that's shared
> with many object persistence frameworks that would naturally provide that
> capability as a service in an OSGi environment.
>
> In my case, the persistence model is based on
Its not exactly a legacy situation. The problem I have is one that's shared
with many object persistence frameworks that would naturally provide that
capability as a service in an OSGi environment.
In my case, the persistence model is based on the ability of any bundle to
declare an interface w
Jackson, Bruce wrote:
Does Felix support anything that carries out a similar function to buddy class
loading in Equinox?
I'm aware of the DynamicImport-Package, but that rather supposes that the bundle who
declares this knows the bundles that it needs as "helpers" to load classes.
Sorry, n
Does Felix support anything that carries out a similar function to buddy class
loading in Equinox?
I'm aware of the DynamicImport-Package, but that rather supposes that the
bundle who declares this knows the bundles that it needs as "helpers" to load
classes.
er play the "service injection" game
myself, frankly...
Well, glad to see some closure on this one... Have a good day, happy
trails, Craig Phillips, Praxis
-Original Message-
From: Jackson, Bruce [mailto:[EMAIL PROTECTED]
Sent: Monday, August 04, 2008 10:08 AM
To: dev@felix.apa
Thanks for that, I've got to the bottom of the problem.
Its quite obscure: obviously, my handler does many other things and contains a
helper which in the constructor stores a copy of the class name.
In the invoke, the stored class name is used in a Class.forName() call, and
that is what causes t
2008/8/4 Jackson, Bruce <[EMAIL PROTECTED]>
> Hi Stuart
>
> Well, that's interesting. To use your description of my problem (which is
> correct) the interface ObjectManagement declared in bundle A is indeed
> public, and it is also imported by B. B provides its own interface (in the
> code fragmen
Hi Stuart
Well, that's interesting. To use your description of my problem (which is
correct) the interface ObjectManagement declared in bundle A is indeed public,
and it is also imported by B. B provides its own interface (in the code
fragment, its passed as the argument clazz) which it passes
2008/8/1 Jackson, Bruce <[EMAIL PROTECTED]>
> Yes, the code in ObjectFactory is basically:
>
> public static Object getObject(Class clazz) {
>
>...
>obj= Proxy.newProxyInstance(clazz.getClassLoader(), new Class[]{clazz,
> ObjectManagement.class}, new Invoker(clazz, id, tableName));
>..
Interesting point...
I've done a bit more investigation around this, and actually, both clazz and
ObjectManagement do appear to be accessible at the point that:
obj= Proxy.newProxyInstance(clazz.getClassLoader(), new Class[] {clazz,
ObjectManagement.class}, new Invoker(clazz, id, tableName));
Yes, I was on the point to say that. This is from JavaDoc of Proxy:
"All of the interface types must be visible by name through the
specified class loader."
You may try to define your own class loader that will delegate to the
class loader of clazz and use as parent the class loader of the bundle
my guess would be it's the objectmanagment class that can not be found
by the classloader of the Foo class :-)
regards,
Karl
Am 01.08.2008 um 17:31 schrieb "Jackson, Bruce" <[EMAIL PROTECTED]>:
Yes, the code in ObjectFactory is basically:
public static Object getObject(Class clazz) {
.
Yes, the code in ObjectFactory is basically:
public static Object getObject(Class clazz) {
...
obj= Proxy.newProxyInstance(clazz.getClassLoader(), new Class[]{clazz,
ObjectManagement.class}, new Invoker(clazz, id, tableName));
...
return obj;
}
That's throws a ClassNotFoundExcep
Do you use Proxy.newProxyInstance?
The first param of this method is a class loader. So, what is the
value you use for that param? In my view you should use the
clazz.getClassLoader that is equal with the class loader that loaded
Foo.
And it should not matter that you export or not the the package
I'm not passing any classloader with my class, just the object Foo.class.
The issue is that bundle B (which is the caller to ObjectFactory declared in A)
does not export Foo.class, and thus the class loader in A can't see it.
Now that's well, and good for most cases since I can always export the
What class loader are you pasing to Proxy.newProxyInstance? You should
pass the one of the class you send as parameter so in your case
clazz.getClassLoader.
On Fri, Aug 1, 2008 at 4:57 PM, Jackson, Bruce <[EMAIL PROTECTED]> wrote:
> Sorry, I don't think I made myself particularly clear:
>
> I have
Jackson, Bruce wrote:
Sorry, I don't think I made myself particularly clear:
I have a bundle "A" which exports a package containing a class
(ObjectFactory.class) with the method:
public static Object getObject(Class clazz);
This method creates a dynamic proxy object to be returned to the call
Sorry, I don't think I made myself particularly clear:
I have a bundle "A" which exports a package containing a class
(ObjectFactory.class) with the method:
public static Object getObject(Class clazz);
This method creates a dynamic proxy object to be returned to the caller.
I have bundles B, C,
Jackson, Bruce wrote:
Here's a question:
I have a utility class in a bundle which will generate a dynamic proxy as a
service to other bundles running inside Felix. Lets call this bundle "A".
Is this possible in Felix/OSGi without having having to explicitly declare
the import of the interface o
Here's a question:
I have a utility class in a bundle which will generate a dynamic proxy as a
service to other bundles running inside Felix. Lets call this bundle "A".
Is this possible in Felix/OSGi without having having to explicitly declare
the import of the interface over which A will operate
21 matches
Mail list logo