geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shenghao Fang <michael1224.f...@gmail.com>
Subject Re: [Disscussion] Reference binded in JNDI is not dereferenced properly when lookup
Date Fri, 15 Apr 2011 06:17:40 GMT
> So far I can't think of any cases where we intentionally let code into geronimo that isn't
in a bundle after we get it deployed.  I'd prefer to see a real example of the problem before
spending time on it.

I'm just thinking about such scenarios but cannot give a real example so far...

> I'm not sure how we avoided bundleizing tranql previously or missed this problem.

Tranql did be bundled currently but we also need to register
TranqlDataSource$SelfObjectFactory as a service according to the
implementation of OSGiObjectFactoryBuilder in Aries.

So other stuffs also need to be register as services besides being
bundled, I'm not sure whether Geronimo does this automatically in
current implementation or there are other mechanisms to handle this.

Anyway, I agree that we can hold on this before there is a real scenario.

Thanks.


2011/4/15 David Jencks <david_jencks@yahoo.com>:
>
> On Apr 14, 2011, at 7:31 PM, Shenghao Fang wrote:
>
>> Hi Devid,
>>
>> Thanks for your reply.
>>
>> I'll take a look at the changes in tranql to see whether it will be
>> working properly with geronimo.
>>
>> But at geronimo side, I'm still thinking of providing some mechanisms
>> for making those none-OSGi stuffs, not only datasources but also any
>> other Referencable objects be dereferenced properly. Since I thought
>> from the user side it's not required to make such stuff be a bundle.
>>
>> Is it necessary? I'm looking forward to your opinions.
>
> So far I can't think of any cases where we intentionally let code into geronimo that
isn't in a bundle after we get it deployed.  I'd prefer to see a real example of the problem
before spending time on it.
>
> I'm not sure how we avoided bundleizing tranql previously or missed this problem.
>
> I expect that if you add a jdbc driver you will need to bundleize it or include it in
an ee application.  One way to bundleize it should be to use the pax wrap url handler....
although I'm not sure it's included in trunk geronimo right now (it is in karaf).
>
> I could be missing something important.... so please let me know if I am.
>
> thanks
> david jencks
>
>
>>
>> Thanks.
>>
>>
>> 2011/4/15 David Jencks <david_jencks@yahoo.com>:
>>> In tranql trunk I've made all the jars into bundles and put in some code that
does some of the work for the DataSourceBuilder.  This is all used in my sandbox txmanager
code and it seems to work by itself but I haven't tried to integrate it into geronimo itself
yet.
>>>
>>> I don't remember if there are still gbeans for the deployer in my sandbox.  if
there aren't, it might be possible to integrate this stuff by wrapping services with gbeans.
 It there are, it's possible that integration might work directly.
>>>
>>> On a separate issue I wonder if it is time to upgrade tranql to java 6 with updated
jdbc interfaces.  Any thoughts?
>>>
>>> thanks
>>> david jencks
>>>
>>> On Apr 14, 2011, at 2:45 AM, Shenghao Fang wrote:
>>>
>>>> https://issues.apache.org/jira/browse/GERONIMO-5904
>>>>
>>>> A JIRA created regarding this issue.
>>>>
>>>> 2011/4/14 Ivan <xhhsld@gmail.com>:
>>>>> I investigated it a bit, the problem should be we need to register the
>>>>> TranqlDataSource.SelfObjectFactory as a service somewhere, maybe it should
>>>>> be done by tranql itself, or be done while Geronimo binds the datasource
>>>>> into the jndi tree.
>>>>>
>>>>> 2011/4/14 Shenghao Fang <michael1224.fang@gmail.com>
>>>>>>
>>>>>> Actually I thought the problem is caused by that we use
>>>>>> OSGiObjectFactoryBuilder to initialize the object, and
>>>>>> OSGiObjectFactoryBuilder tries to initialize the object by OSGi
>>>>>> services, but the jdbc driver (tranql) is not a bundle (it is not
>>>>>> required to be a bundle), so the initialization fails and the
>>>>>> Reference itself returned.
>>>>>>
>>>>>> I debugged into the following method, it uses OSGi services to
>>>>>> initialize the object, but since the jdbc driver is not a bundle,
>>>>>> ServiceReference[] refs is null, and the initialization fails.
>>>>>>
>>>>>> org.apache.aries.jndi.ObjectFactoryHelper: 196
>>>>>>
>>>>>>    private Object getObjectInstanceUsingClassName(Object reference,
>>>>>>                                            
      String className,
>>>>>>                                            
      Object obj,
>>>>>>                                            
      Name name,
>>>>>>                                            
      Context nameCtx,
>>>>>>                                            
      Hashtable<?, ?>
>>>>>> environment)
>>>>>>        throws Exception {
>>>>>>        ServiceReference serviceReference = null;
>>>>>>
>>>>>>        try {
>>>>>>            ServiceReference[] refs =
>>>>>> defaultContext.getServiceReferences(className, null);
>>>>>>            if (refs != null && refs.length > 0)
{
>>>>>>                serviceReference = refs[0];
>>>>>>            }
>>>>>>        } catch (InvalidSyntaxException e) {
>>>>>>            // should not happen
>>>>>>            throw new RuntimeException("Invalid filter", e);
>>>>>>        }
>>>>>>
>>>>>>        Object result = null;
>>>>>>
>>>>>>        if (serviceReference != null) {
>>>>>>            ObjectFactory factory = (ObjectFactory)
>>>>>> defaultContext.getService(serviceReference);
>>>>>>            try {
>>>>>>                result = factory.getObjectInstance(reference,
name,
>>>>>> nameCtx, environment);
>>>>>>            } finally {
>>>>>>                defaultContext.ungetService(serviceReference);
>>>>>>            }
>>>>>>        }
>>>>>>
>>>>>>        return (result == null) ? obj : result;
>>>>>>    }
>>>>>>
>>>>>> And in doGetObjectInstance method, the methods
>>>>>> 'getObjectInstanceUsingRefAddress',
>>>>>> 'getObjectInstanceUsingObjectFactoryBuilders',
>>>>>> 'getObjectInstanceUsingObjectFactories' also use the OSGi way as
what
>>>>>> getObjectInstanceUsingClassName does.
>>>>>>
>>>>>> org.apache.aries.jndi.ObjectFactoryHelper: 62
>>>>>>
>>>>>>    private Object doGetObjectInstance(Object obj,
>>>>>>                                       Name name,
>>>>>>                                       Context
nameCtx,
>>>>>>                                       Hashtable<?,
?> environment)
>>>>>> throws Exception {
>>>>>>
>>>>>>        // Step 1
>>>>>>        if (obj instanceof Referenceable) {
>>>>>>            obj = ((Referenceable) obj).getReference();
>>>>>>        }
>>>>>>
>>>>>>        Object result = obj;
>>>>>>
>>>>>>        // Step 2
>>>>>>        if (obj instanceof Reference) {
>>>>>>            Reference ref = (Reference) obj;
>>>>>>            String className = ref.getFactoryClassName();
>>>>>>
>>>>>>            if (className != null) {
>>>>>>                // Step 3
>>>>>>                result = getObjectInstanceUsingClassName(obj,
>>>>>> className, obj, name, nameCtx, environment);
>>>>>>            } else {
>>>>>>                // Step 4
>>>>>>                result =
>>>>>> getObjectInstanceUsingRefAddress(ref.getAll(), obj, name, nameCtx,
>>>>>> environment);
>>>>>>            }
>>>>>>        }
>>>>>>
>>>>>>        // Step 5
>>>>>>        if (result == null || result == obj) {
>>>>>>            result = getObjectInstanceUsingObjectFactoryBuilders(obj,
>>>>>> name, nameCtx, environment);
>>>>>>        }
>>>>>>
>>>>>>        // Step 6
>>>>>>        if (result == null || result == obj) {
>>>>>>            if ((obj instanceof Reference && ((Reference)
>>>>>> obj).getFactoryClassName() == null) ||
>>>>>>                !(obj instanceof Reference)) {
>>>>>>                result = getObjectInstanceUsingObjectFactories(obj,
>>>>>> name, nameCtx, environment);
>>>>>>            }
>>>>>>        }
>>>>>>
>>>>>>        return (result == null) ? obj : result;
>>>>>>    }
>>>>>>
>>>>>> The solution in mind currently is setting a different
>>>>>> ObjectFactoryBuilder instead of OSGiObjectFactoryBuilder on
>>>>>> NamingManager for those plain jars. But where shall I do this? Any
>>>>>> idea?
>>>>>>
>>>>>> 2011/4/14 Shenghao Fang <michael1224.fang@gmail.com>:
>>>>>>> Hi Ivan,
>>>>>>>
>>>>>>> Thanks for your hits.
>>>>>>>
>>>>>>> 2011/4/14 Ivan <xhhsld@gmail.com>:
>>>>>>>> From the codes in DataSourceBuilder, the jndi reference is
with prefix
>>>>>>>> aries:service, so there should be something like an ObjectFactory
would
>>>>>>>> take
>>>>>>>> care of it. I could see a service
>>>>>>>> org\apache\aries\jndi\url\Activator.class
>>>>>>>> support this schema is registered in the activator, I simply
compared
>>>>>>>> that
>>>>>>>> Java file between 0.2 and 0.3 seems that some logic is changed,
think
>>>>>>>> this
>>>>>>>> should be a place to begin the debugging.
>>>>>>>> Hope it helps.
>>>>>>>>
>>>>>>>> 2011/4/14 Shenghao Fang <michael1224.fang@gmail.com>
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> When I did the enablement for the monitoring portlet,
I lookup the
>>>>>>>>> datasource from JNDI and got an object of type javax.naming.Reference
>>>>>>>>> instead of javax.sql.DataSource.
>>>>>>>>>
>>>>>>>>> I debugged into JNDI related modules and found the following
clues:
>>>>>>>>>
>>>>>>>>> 1. If the object to be bound is of type javax.naming.Referenceable,
>>>>>>>>> then the object of type javax.naming.Reference retrieved
by
>>>>>>>>> Referenceable.getReference() will be bound. And the object
should be
>>>>>>>>> dereferenced automatically when lookup.
>>>>>>>>>
>>>>>>>>> 2. When lookup from JNDI, javax.naming.spi.NamingManager
tries to use
>>>>>>>>> the ObjectFactoryBuilder set to dereference. In current
>>>>>>>>> implementation, we set org.apache.aries.jndi.OSGiObjectFactoryBuilder
>>>>>>>>> to ObjectFactoryBuilder.
>>>>>>>>>
>>>>>>>>> 3. Since the datasource is not packaged as an OSGi bundle,
>>>>>>>>> OSGiObjectFactoryBuilder returns the Reference directly.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I have no idea on how to fix this, any idea? Thanks.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Michael
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Ivan
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Michael
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Michael
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Ivan
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Michael
>>>
>>>
>>
>>
>>
>> --
>> Michael
>
>



-- 
Michael

Mime
View raw message