Sahoo,
Thank you very much for the tip, I did not notice the imports of the javax,
makes sense. It is working now :)!
Sorry to bug with other stuff but, I am looking for a "best practice" or
sample articles on how to do unit testing for the glassfish environment from
Maven. Wonder if you have come across something like that?
Thanks again!
On Mon, May 2, 2011 at 12:08 PM, Sahoo <sanjeeb.sahoo_at_oracle.com> wrote:
> Eduardo,
>
> Even though javax.naming is part of Java SE, your bundle does not get
> automatic access to it. Except java.* packages, a bundle has to declare
> explicit dependencies on all other packages except a few scenarios. So, add
> Import-Package for javax.naming and any other such packages and you will be
> fine I think.
>
> Sahoo
>
> On Monday 02 May 2011 08:50 PM, Eduardo Solis wrote:
>
> Here is the stack trace
>
> [#|2011-05-02T10:20:12.678-0500|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=54;_ThreadName=Thread-1;|org.osgi.framework.BundleException:
> Activator start error in bundle com.acs.connetor [272].
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:1882)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1752)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:922)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:1175)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:1153)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.processAllBundles(DirectoryWatcher.java:1146)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:456)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:263)
> Caused by: java.lang.NoClassDefFoundError: javax/naming/InitialContext
> at com.acs.connector.Activator.start(Activator.java:27)
> at
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:629)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:1835)
>
>
>
> On Mon, May 2, 2011 at 10:17 AM, Eduardo Solis <eleduardo.solis_at_gmail.com>wrote:
>
>> Hi Sahoo!
>>
>> Thank you very much for the prompt response. I am actually kind of
>> excited that you looked at it as I am a big admirer of your and Arun's work
>> :)
>>
>> I removed the declarative service and moved the lookup into the
>> activator. Seems that what is happening is that I am getting a classdef not
>> found for InitialContext (WEIRD) I don't understand how that can be if that
>> interface is defined in the JVM. At this point I am suspecting that
>> something is wrong with my server too... Just ran an update on it and I'll
>> try to recreate.
>>
>> Thanks again!
>>
>>
>> On Sat, Apr 30, 2011 at 2:30 AM, Sahoo <sanjeeb.sahoo_at_oracle.com> wrote:
>>
>>> Hi Eduardo,
>>>
>>> I can't reproduce this. We have tests where we do JNDI lookup from pure
>>> OSGi bundles and they work. I even tried doing the same from an SCR
>>> component and it works both in GF 3.1 and 3.2-SNAPSHOT. From the stack trace
>>> it appears that one of our internal service tracker got a notification about
>>> the service, but the service object was found to be null. I can't explain
>>> how that's happening. Can you supply us the test case? For your reference,
>>> the test case I just developed to test this scenario is available at
>>>
>>>
>>> https://svn.java.net/svn/glassfish~svn/trunk/fighterfish/test/testapp/test.app15
>>>
>>> You can just checkout that url, build and try out yourself.
>>>
>>> We have one bug about looking up JNDI from a BundleActivator, but that's
>>> only applicable when a bundle is deployed using "asadmin deploy --type=osgi"
>>> command as discussed in http://java.net/jira/browse/GLASSFISH-16412.
>>> That bug has been fixed in glassfish trunk. I am sure you are not affected
>>> by that bug as you said you are deploying via autodeploy/bundles/.
>>>
>>> Thanks,
>>> Sahoo
>>>
>>>
>>> On Friday 29 April 2011 11:51 PM, Eduardo Solis wrote:
>>>
>>> Hi there!
>>>
>>> Got a question. I am trying to create an osgi service (using
>>> declarative services). what I want this service to do is to provide the JNDI
>>> lookup for the datasource and hand-out connections to other bundles and to
>>> other J2EE clients (servlet). I created the skeleton of the service and its
>>> service declaration and things work fine.
>>>
>>> public interface IConnectionGetter {
>>>
>>> public Connection getConnection();
>>> }
>>>
>>>
>>> public class ConnectionGetterImpl implements IConnectionGetter {
>>> private static final String MYCLASS =
>>> ConnectionGetterImpl.class.getName();
>>> private static Logger logger = Logger.getLogger(MYCLASS);
>>>
>>> /*
>>> * (non-Javadoc)
>>> *
>>> * @see com.acs.connector.IConnectionGetter#getConnection()
>>> */
>>> @Override
>>> public Connection getConnection() {
>>> String method = "getConnection";
>>> logger.entering(MYCLASS, method);
>>> Connection conn = null;
>>> logger.exiting(MYCLASS, method);
>>> return conn;
>>> }
>>> }
>>>
>>> This works fine, I can see the service in the registry and the servlet
>>> can get to it (using @Resource to get it). Now, when I actually code the
>>> JNDI lookup
>>>
>>> public class ConnectionGetterImpl implements IConnectionGetter {
>>> private static final String MYCLASS =
>>> ConnectionGetterImpl.class.getName();
>>> private static Logger logger = Logger.getLogger(MYCLASS);
>>>
>>> /*
>>> * (non-Javadoc)
>>> *
>>> * @see com.acs.connector.IConnectionGetter#getConnection()
>>> */
>>> @Override
>>> public Connection getConnection() {
>>> String method = "getConnection";
>>> logger.entering(MYCLASS, method);
>>> Connection conn = null;
>>> try {
>>> InitialContext context = new InitialContext();
>>> DataSource src = (DataSource) context.lookup("jdbc/testConnection");
>>> conn = src.getConnection();
>>> } catch (NamingException e) {
>>> // TODO Auto-generated catch block
>>> e.printStackTrace();
>>> } catch (SQLException e) {
>>> // TODO Auto-generated catch block
>>> e.printStackTrace();
>>> }
>>> logger.exiting(MYCLASS, method);
>>> return conn;
>>> }
>>> }
>>>
>>>
>>> As soon as I add the InitialContext I get this when I deploy the bundle
>>> (autodeploy/bundles)
>>>
>>>
>>> [#|2011-04-29T12:02:40.509-0500|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=96;_ThreadName=Thread-1;|java.lang.NullPointerException
>>> at
>>> com.sun.hk2.component.ExistingSingletonInhabitant.<init>(ExistingSingletonInhabitant.java:57)
>>> at
>>> org.jvnet.hk2.osgiadapter.HK2Main$HK2ServiceTrackerCustomizer.addingService(HK2Main.java:273)
>>> at
>>> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:896)
>>> at
>>> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261)
>>> at
>>> org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:233)
>>> at
>>> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:840)
>>> at
>>> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:871)
>>> at
>>> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:733)
>>> at
>>> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662)
>>> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3769)
>>> at org.apache.felix.framework.Felix.access$000(Felix.java:80)
>>> at org.apache.felix.framework.Felix$2.serviceChanged(Felix.java:722)
>>> at
>>> org.apache.felix.framework.ServiceRegistry.registerService(ServiceRegistry.java:107)
>>> at org.apache.felix.framework.Felix.registerService(Felix.java:2854)
>>> at
>>> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:251)
>>> at
>>> org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:408)
>>> at
>>> org.apache.felix.scr.impl.manager.AbstractComponentManager.registerComponentService(AbstractComponentManager.java:419)
>>> at
>>> org.apache.felix.scr.impl.manager.AbstractComponentManager$Unsatisfied.activate(AbstractComponentManager.java:1003)
>>> at
>>> org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:298)
>>> at
>>> org.apache.felix.scr.impl.manager.AbstractComponentManager$1.doRun(AbstractComponentManager.java:138)
>>> at
>>> org.apache.felix.scr.impl.ComponentActivatorTask.run(ComponentActivatorTask.java:67)
>>> at
>>> org.apache.felix.scr.impl.ComponentActorThread.run(ComponentActorThread.java:96)
>>> at java.lang.Thread.run(Thread.java:662)
>>> |#]
>>>
>>>
>>> I found an example from Sahoo where he was doing the same lookup from
>>> an activator only his was a wab rather than just a simple bundle.
>>>
>>> Has anyone done this or is there an article somewhere on how to do
>>> this?
>>>
>>> Thanks!
>>>
>>> Eduardo Solis.
>>>
>>>
>>>
>>
>
>