ejb@glassfish.java.net

Re: Eclipse RCP client for Glassfish v2.1 using EJB3 -- Security Problems/Questions

From: Andreas Kozma <andreas.kozma_at_ansis.com>
Date: Mon, 18 May 2009 18:26:09 +0200

Thank you for the pointer, Cheng.

In the meantime we've done a lot more research and from bits and
pieces found in forums/blogs I think I know what the situation is,
even though we weren't able to get a running sample app. Some better
documentation in this field would really be useful.


Our conclusions/questions at this point:


1 - is it true that Glassfish doesn't support the passing of username/
password via the InitialContext and you have to use ProgrammaticLogin,
which does much of the same: it passes the username/password with each
lookup call when requesting EJBs?

2 - in addition you need to configure JAAS on the client. Is there
anything else required on top of the configuration of the realm?

3 - when everything is working properly, are you supposed to call
callerPrincipal.getName() and you see the user name you passed with
ProgrammaticLogin.login? We are always getting ANONYMOUS!! What are we
doing wrong?


Please help as there is really not too much information out there on
the web! Even a seemingly complete blog like http://blogbysud.blogspot.com/2007/10/programmatic-login-to-authenticate.html
  has a comment in the end having the same problem we have.

I have to say, GF makes a great impression, so we would like to start
using it, but so far we've had much more difficulty than when we
started using JBoss a few years ago. There must be a simpler way of
using GF!

As usual your help is appreciated (as you can tell, we're getting a
bit frustrated)... :- )


Kind regards,

- Andreas Kozma
www.ansis.com



On May 8, 2009, at 6:32 , Cheng Fang wrote:

> Have you tried programmatic login? Search for various sun docs on
> GlassFish for more details (for ex: http://docs.sun.com/app/docs/doc/820-4496/beacp?a=view
>
> -cheng
>
> On 5/8/09 12:13 PM, Andreas Kozma wrote:
>>
>> Hi Kenneth,
>>
>> I'm sure you must be very busy, but please help, as these problems
>> are show-stoppers in our migration efforts to GF. You're help is
>> highly appreciated.
>>
>> Here is our next question - we can't get security (authentication)
>> to run even with the simplest text file based realm:
>>
>> 1 - how do we pass user name/password to the server? In JBoss we
>> simply added Context.SECURITY_PRINCIPAL and
>> Context.SECURITY_CREDENTIALS to the InitialContext. Does it work
>> the same way with GF?
>>
>> 2 - How and where do we need to configure the Security Realm? We
>> found some documentation, but we hit the brick wall without
>> receiving any error messages. Can you point us towards any
>> documentation/tutorials, etc. that we may not have found yet?
>>
>>
>> Thank you indeed and kind regards,
>>
>> - Andreas Kozma
>> www.ansis.com
>>
>> <mime-attachment.gif>
>>
>> On May 7, 2009, at 10:45 , Andreas Kozma wrote:
>>
>>> Kenneth, here is the stacktrace when trying to run with a separate
>>> plugin containing GF jars and EJB jar, as well as the consuming jar:
>>>
>>> May 7, 2009 10:42:59 AM com.sun.enterprise.util.ORBManager initORB
>>> SEVERE: UTIL6009:Unexcpected Exception in createORB.
>>> org.omg.CORBA.INITIALIZE: can't instantiate default ORB
>>> implementation com.sun.corba.ee.impl.orb.ORBImpl vmcid: 0x0
>>> minor code: 0 completed: No
>>> at org.omg.CORBA.ORB.create_impl(ORB.java:326)
>>> at org.omg.CORBA.ORB.init(ORB.java:365)
>>> at com.sun.enterprise.util.ORBManager.initORB(ORBManager.java:546)
>>> at com.sun.enterprise.util.ORBManager.getORB(ORBManager.java:278)
>>> at
>>> com
>>> .sun
>>> .enterprise
>>> .naming
>>> .SerialInitContextFactory
>>> .getInitialContext(SerialInitContextFactory.java:178)
>>> at
>>> javax
>>> .naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
>>> at
>>> javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:
>>> 247)
>>> at javax.naming.InitialContext.init(InitialContext.java:223)
>>> at javax.naming.InitialContext.<init>(InitialContext.java:197)
>>> at
>>> com.ansis.aef.ui.session.LookupTest3.testConnect(LookupTest3.java:
>>> 49)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>> sun
>>> .reflect
>>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>> at
>>> sun
>>> .reflect
>>> .DelegatingMethodAccessorImpl
>>> .invoke(DelegatingMethodAccessorImpl.java:25)
>>> at java.lang.reflect.Method.invoke(Method.java:585)
>>> at junit.framework.TestCase.runTest(TestCase.java:164)
>>> at junit.framework.TestCase.runBare(TestCase.java:130)
>>> at junit.framework.TestResult$1.protect(TestResult.java:106)
>>> at junit.framework.TestResult.runProtected(TestResult.java:124)
>>> at junit.framework.TestResult.run(TestResult.java:109)
>>> at junit.framework.TestCase.run(TestCase.java:120)
>>> at junit.framework.TestSuite.runTest(TestSuite.java:230)
>>> at junit.framework.TestSuite.run(TestSuite.java:225)
>>> at
>>> org
>>> .eclipse
>>> .jdt
>>> .internal
>>> .junit
>>> .runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>>> at
>>> org
>>> .eclipse
>>> .jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>> at
>>> org
>>> .eclipse
>>> .jdt
>>> .internal
>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>>> at
>>> org
>>> .eclipse
>>> .jdt
>>> .internal
>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>>> at
>>> org
>>> .eclipse
>>> .jdt
>>> .internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:
>>> 386)
>>> at
>>> org
>>> .eclipse
>>> .pde
>>> .internal
>>> .junit
>>> .runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:62)
>>> at org.eclipse.pde.internal.junit.runtime.UITestApplication
>>> $1.run(UITestApplication.java:114)
>>> at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
>>> at
>>> org
>>> .eclipse
>>> .swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:133)
>>> at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:
>>> 3342)
>>> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:
>>> 3071)
>>> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:
>>> 2384)
>>> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2348)
>>> at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2200)
>>> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:495)
>>> at
>>> org
>>> .eclipse
>>> .core.databinding.observable.Realm.runWithDefault(Realm.java:288)
>>> at
>>> org
>>> .eclipse
>>> .ui.internal.Workbench.createAndRunWorkbench(Workbench.java:490)
>>> at
>>> org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
>>> at
>>> org
>>> .eclipse
>>> .ui
>>> .internal.ide.application.IDEApplication.start(IDEApplication.java:
>>> 113)
>>> at
>>> org
>>> .eclipse
>>> .pde
>>> .internal
>>> .junit.runtime.UITestApplication.start(UITestApplication.java:46)
>>> at
>>> org
>>> .eclipse
>>> .equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:
>>> 193)
>>> at
>>> org
>>> .eclipse
>>> .core
>>> .runtime
>>> .internal
>>> .adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:
>>> 110)
>>> at
>>> org
>>> .eclipse
>>> .core
>>> .runtime
>>> .internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:
>>> 79)
>>> at
>>> org
>>> .eclipse
>>> .core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:386)
>>> at
>>> org
>>> .eclipse
>>> .core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>> sun
>>> .reflect
>>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>> at
>>> sun
>>> .reflect
>>> .DelegatingMethodAccessorImpl
>>> .invoke(DelegatingMethodAccessorImpl.java:25)
>>> at java.lang.reflect.Method.invoke(Method.java:585)
>>> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549)
>>> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
>>> at org.eclipse.equinox.launcher.Main.run(Main.java:1236)
>>> at org.eclipse.equinox.launcher.Main.main(Main.java:1212)
>>> Caused by: java.lang.ClassCastException:
>>> com.sun.corba.ee.impl.orb.ORBImpl
>>> at org.omg.CORBA.ORB.create_impl(ORB.java:324)
>>> ... 54 more
>>>
>>> When all Jars and consuming classes are in one plugin, it all works.
>>>
>>>
>>> Thanks.
>>>
>>>
>>> Kind regards,
>>>
>>> - Andreas Kozma
>>> www.ansis.com
>>>
>>> <ansis_logo.gif>
>>>
>>> On May 7, 2009, at 10:31 , Andreas Kozma wrote:
>>>
>>>> Thanks a lot for your quick answer, Kenneth. We managed to
>>>> connect to GF as described in the #nonJavaEEwebcontainerRemoteEJB
>>>> section of the EJB FAQ;
>>>>
>>>>
>>>> 1.)
>>>> - running a simple unit test (with a normal java classpath)
>>>> worked like a charm
>>>>
>>>> - running an Eclipse RCP test app with one plugin worked as well.
>>>> as each plugin has its own class loader, all classes in all four
>>>> required GF jars (appserv-deployment-client.jar, appserv-ext.jar,
>>>> appserv-rt.jar, javaee.jar) are visible in the plugin itself.
>>>>
>>>>
>>>> - running with two plugins (where one plugin contains the four GF
>>>> jars and the jar with the required EJB3 remote interfaces and
>>>> entity beans, the other contains the actual functionality)
>>>> doesn't work. Probably we export the wrong packages from the
>>>> first Jar to the consuming plugin.
>>>>
>>>> Question: what packages from the four Jars need to be exported
>>>> from the plugin containing the jars, so that the consuming plugin
>>>> can run the lookup properly to access the EJBs? If you could give
>>>> us a hint, it would save us many hours of trial-and-error. Good
>>>> practise suggests only to export the required packages (ie.
>>>> package from which classes need to be loaded by consuming
>>>> plugin), rather than exporting hundreds of packages.
>>>>
>>>>
>>>> 2.)
>>>> In JBoss we needed to supply a jndi.properties file in the EAR or
>>>> the EJB3 project. Is this required in GF? If yes, what is the
>>>> format? We used
>>>>
>>>> java
>>>> .naming
>>>> .factory.initial=com.sun.enterprise.naming.SerialInitContextFactory
>>>> java.naming.factory.url.pkgs=com.sun.enterprise.naming
>>>> java.naming.provider.url=iiop://localhost:3700
>>>>
>>>> but I'm not sure it was required.
>>>>
>>>>
>>>> 3.)
>>>> Another question where we didn't find any hints on the web: how
>>>> can you configure an fresh GF instance in batch mode? We have
>>>> various GF instances running on developer machines, test servers,
>>>> client deployments, etc and we would like to find a way to just
>>>> run a script or modify a few xml files (like in JBoss). Everybody
>>>> refers us to the Admin console, but that is not automatable.
>>>>
>>>>
>>>>
>>>> PS: Once all this works, we would be happy to contribute our
>>>> experiences into an updated FAQ to save everybody trying to run
>>>> RCP clients with GF a lot of time.
>>>>
>>>>
>>>>
>>>>
>>>> Thanks in advance and kind regards,
>>>>
>>>> - Andreas Kozma
>>>> www.ansis.com
>>>>
>>>> <ansis_logo.gif>
>>>>
>>>> On May 6, 2009, at 9:10 , Kenneth Saks wrote:
>>>>
>>>>>
>>>>> On May 6, 2009, at 2:18 PM, Andreas Kozma wrote:
>>>>>
>>>>>> Hi Glassfish users!
>>>>>>
>>>>>> We are developing a 300k line EJB3 application using JBoss AS
>>>>>> and the Eclipse RCP platform for our Rich client.
>>>>>>
>>>>>> We would like to move our application server to Glassfish, but
>>>>>> we have difficulty getting our rich client to connect to the AS
>>>>>> by following the instructions on the glassfish: EJB FAQ.
>>>>>>
>>>>>> We have the following problems/questions:
>>>>>>
>>>>>> - is anybody of you using Eclipse RCP to develop your rich
>>>>>> client? if yes, which JARs do put into the plugin containing
>>>>>> the server classes? which packages do export? We were getting
>>>>>> all sorts of strange class cast and verify errors when trying
>>>>>> to set the standalone client mode.
>>>>>>
>>>>>> - as our RCP client needs to run on an unforeseen number of
>>>>>> client machines, we need to be able to set the host name in the
>>>>>> login panel. How do we pass it to the InitialContext?
>>>>>
>>>>> Hi Andreas,
>>>>>
>>>>> The easiest approach is to set the the host as -
>>>>> Dorg.omg.CORBA.ORBInitialHost=<server> when starting the stand-
>>>>> alone client JVM. If you can't do that for whatever reason,
>>>>> then follow the instructions in https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html
>>>>> #nonJavaEEwebcontainerRemoteEJB.
>>>>>
>>>>>
>>>>>> We tried [ env.setProperty(Context.PROVIDER_URL, "iiop://
>>>>>> localhost:3700"); ]
>>>>>
>>>>> You shouldn't use this property with Glassfish's naming provider.
>>>>>
>>>>>>
>>>>>> - is there a way to run an Eclipse or NetBeans RCP app as an
>>>>>> Application Client Component that can directly inject EJB3
>>>>>> resources?
>>>>>
>>>>> There's a separate appclient command for running application
>>>>> client components in GlassFish. I don't know if the IDEs
>>>>> integrate with that.
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thank you very much for your help!
>>>>>>
>>>>>>
>>>>>> Kind regards,
>>>>>>
>>>>>> - Andreas Kozma
>>>>>> www.ansis.com
>>>>>>
>>>>>> <ansis_logo.gif>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> This message has been scanned for viruses and
>>>>> dangerous content by MailScanner, and is
>>>>> believed to be clean.
>>>>
>>>>
>>>> --
>>>> This message has been scanned for viruses and
>>>> dangerous content by MailScanner, and is
>>>> believed to be clean.
>>>
>>>
>>> --
>>> This message has been scanned for viruses and
>>> dangerous content by MailScanner, and is
>>> believed to be clean.
>>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.