Re: geronimo sucessfully installed and running, but am not able to log on two server
something's wrong with how you started geronimo, the java.endorsed.dirs property needs to include lib/endorsed. I don't use windows so I'm not exactly sure what is appropriate I would try bin/startup.bat and use the 1.5 jdk first. A command line that works for me on osx is java -Djava.endorsed.dirs=lib/endorsed -javaagent:bin/jpa.jar -jar bin/server.jar --long you might be able to adapt it for windows if you can't get the .bat file to work. thanks david jencks On Sep 14, 2007, at 5:58 PM, amrog wrote: My specs are: Windows Vista Home Premium JRE 1.6.0_02 Jdk 1.5.0_12 System Environment Variables VariableVALUE Classpath: .;C:\Program Files\Java\jre1.6.0\lib\ext\QTJava.zip \JRE_HOME JRE_HOMEC:\Program Files\Java\jdk1.5.0_12\jre I am able to get to the, "http://localhost:8080/console"; screen but i'm am not able to go much further in the logon process. Here is the complete log file: 17:05:36,170 ERROR [[/]] "Restricted listeners property file not found 17:05:47,209 ERROR [NameService] Incorrect level of org.omg.CORBA classes found. Likely cause is an incorrect java.endorsed.dirs configuration 17:05:47,215 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName="org.apache.geronimo.configs/j2ee-corba-yoko/2.0.1/car? ServiceModule=org.apache.geronimo.configs/j2ee-corba-yoko/2.0.1/ car,j2eeType=CORBANameService,name=NameServer" org.apache.geronimo.gbean.InvalidConfigurationException: CORBA usage requires Yoko CORBA spec classes in java.endorsed.dirs classpath at org.apache.geronimo.corba.NameService.doStart(NameService.java: 168) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance (GBeanInstance.java:996) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart( GBeanInstanceState.java:268) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start (GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start (GBeanInstance.java:539) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart (GBeanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget (GBeanDependency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running (GBeanDependency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEven t(BasicLifecycleMonitor.java :176) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300 (BasicLifecycleMonitor.java:44) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor $RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java :254) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart( GBeanInstanceState.java:294) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start (GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive (GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive (GBeanInstance.java:553) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean (BasicKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfiguration GBeans(ConfigurationUtil.java:448) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start (KernelConfigurationManager.java:187) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConf iguration(SimpleConfigurationManager.java:530) at org.apache.geronimo.kernel.config.SimpleConfigurationManager$ $FastClassByCGLIB$$ce77a924.invoke () at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke (FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:830) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke (RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke (RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept (ProxyMethodInterceptor.java:96) at org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$ $425ac6b6.startConfiguration () at org.apache.geronimo.system.main.EmbeddedDaemon.doStartup (EmbeddedDaemon.java:156) at org.apache.geronimo.system.main.EmbeddedDaemon.execute (EmbeddedDaemon.java:78) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main (MainConfigurationBootstrapper.java:45) at org.apache.geronimo.cli.AbstractCLI.executeMain (AbstractCLI.java:67) at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30) Caused by: java.lang.NoSuchMethodError : org.omg.PortableInterceptor.IORInterceptor_3_0.adapter_manager_state_c hanged(Ljava/lang/String;S)V at org.apache.yoko.orb.OB.PIManager.adapterManagerStateChange (PIManager.java:532) at org.apache.yoko.orb
geronimo sucessfully installed and running, but am not able to log on two server
My specs are: Windows Vista Home Premium JRE 1.6.0_02 Jdk 1.5.0_12 System Environment Variables VariableVALUE Classpath: .;C:\Program Files\Java\jre1.6.0\lib\ext\QTJava.zip\JRE_HOME JRE_HOMEC:\Program Files\Java\jdk1.5.0_12\jre I am able to get to the, "http://localhost:8080/console"; screen but i'm am not able to go much further in the logon process. Here is the complete log file: 17:05:36,170 ERROR [[/]] "Restricted listeners property file not found 17:05:47,209 ERROR [NameService] Incorrect level of org.omg.CORBA classes found. Likely cause is an incorrect java.endorsed.dirs configuration 17:05:47,215 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName="org.apache.geronimo.configs/j2ee-corba-yoko/2.0.1/car?ServiceModule=org.apache.geronimo.configs/j2ee-corba-yoko/2.0.1/car,j2eeType=CORBANameService,name=NameServer" org.apache.geronimo.gbean.InvalidConfigurationException: CORBA usage requires Yoko CORBA spec classes in java.endorsed.dirs classpath at org.apache.geronimo.corba.NameService.doStart(NameService.java:168) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance (GBeanInstance.java:996) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:539) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget (GBeanDependency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java :176) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java :254) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:294) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive (GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:553) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:448) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:530) at org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke () at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke (RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$$425ac6b6.startConfiguration () at org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:156) at org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:78) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main (MainConfigurationBootstrapper.java:45) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30) Caused by: java.lang.NoSuchMethodError : org.omg.PortableInterceptor.IORInterceptor_3_0.adapter_manager_state_changed(Ljava/lang/String;S)V at org.apache.yoko.orb.OB.PIManager.adapterManagerStateChange(PIManager.java:532) at org.apache.yoko.orb.OBPortableServer.POAManager_impl.activate (POAManager_impl.java:213) at org.apache.yoko.orb.CosNaming.tnaming.TransientNameService.initialize(TransientNameService.java:130) at org.apache.yoko.orb.CosNaming.tnaming.TransientNameService.run(TransientNameService.java :115) at org.apache.geronimo.yoko.ORBConfigAdapter.createNameService(ORBConfigAdapter.java:175) at org.apache.geronimo.yoko.ORBConfigAdapter$$FastClassByCGLIB$$76e4a002.invoke() at net.sf.cglib.reflect.FastMethod.invoke (FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo
Re: jndi lookup in remote client for geronimo v2
Thanks for the examples - Is there any difference between the Context Lookup
in an EJB-JAR vs an EAR ?
I'm still getting a naming exception and I followed both the examples
exactly. Here are some files associated with my configuration =
---
If my geronimo-application.xml =
http://geronimo.apache.org/xml/ns/j2ee/application-1.2";>
http://geronimo.apache.org/xml/ns/deployment-1.2";>
com.mydomain.ejbtest
EjbTest
1.0o
ear
---
openejb-jar.xml =
http://www.openejb.org/xml/ns/openejb-jar-2.1";>
http://geronimo.apache.org/xml/ns/deployment-1.2";>
com.mydomain.ejbtest
TheEJB
1.1
car
com.mydomain.ejbtest
MyQueueConnectionFactory
1.0
rar
com.mydomain.ejbtest
MysqlDatabase
1.0
rar
---
The EJB Bean =
@Stateless(name="TheBean")
@Remote(TheInterface.class)
public class TheBean implements TheInterface{
---
The Interface =
@Remote
public interface TheInterface {
---
The Client =
Properties ejbprop = new Properties();
ejbprop.put("java.naming.factory.initial","org.apache.openejb.client.RemoteInitialContextFactory");
ejbprop.put("java.naming.provider.url", "ejbd://127.0.0.1:4201");
javax.naming.InitialContext ctx = new javax.naming.InitialContext(EJBprops);
TheInterface obj =
(TheInterface)ctx.lookup("TheEJB/TheBean/com.mydomain.ejbtest.TheInterface");
Jarek Gawor-2 wrote:
>
> I have some tests in Geronimo that might help.
>
> If you have a EJB 2.x take a look at:
> http://svn.apache.org/viewvc/geronimo/server/trunk/testsuite/webservices-testsuite/jaxrpc-tests/jaxrpc-ejb/
>
> And for the client take a look at the testEJB() function in
> http://svn.apache.org/viewvc/geronimo/server/trunk/testsuite/webservices-testsuite/jaxrpc-tests/jaxrpc-ejb/src/test/java/org/apache/geronimo/testsuite/testset/JaxRPCTest.java?view=markup
>
> If you have EJB 3.0 take a look at:
> http://svn.apache.org/viewvc/geronimo/server/trunk/testsuite/webservices-testsuite/jaxws-tests/jaxws-ejb/
>
> And for the client take a look at the testEJB() function in
> http://svn.apache.org/viewvc/geronimo/server/trunk/testsuite/webservices-testsuite/jaxws-tests/jaxws-ejb/src/test/java/org/apache/geronimo/testsuite/testset/JaxWSTest.java?view=markup
>
> Jarek
>
> On 9/14/07, vrm <[EMAIL PROTECTED]> wrote:
>>
>> I'm having the exact same issue. I've spent 2 days looking around and
>> there
>> is no examples or documentations available for a Remote openejb client
>> accessing an EJB on Geronimo 2.
>>
>> Anybody have an EAR for Geronimo2 and an Openejb-Client app accessing it?
>>
>> The Exception I get =
>> javax.naming.NameNotFoundException: /TheBean does not exist in the
>> system.
>> Check that the app was successfully deployed.
>>
>> I've tried the following for InitialContext.lookup =
>> (artifactid)/(TheBean)/(TheInterface)
>> (artifactid)/(Interface)
>> (ejbBean)/(Interface)
>> (artifactid)/(TheBean)/(Full Path to Interface)
>> ...and many more variations of this
>>
>>
>> My EJB Interface =
>>
>> @Remote
>> public interface TheInterface {
>>
>>
>> My Bean =
>> @Stateless
>> public class TheBean implements TheInterface {
>>
>>
>> Anybody get this to work or have examples, please post.
>>
>>
>>
>>
>> Xiao-fei Song wrote:
>> >
>> > Hi,
>> >
>> > Just wanted to let you know I modified a little bit about the code:
>> >
>> > props.setProperty("java.naming.factory.initial",
>> > "org.apache.openejb.client.RemoteInitialContextFactory");
>> > props.setProperty("java.naming.provider.url",
>> "127.0.0.1:4201");
>> > props.setProperty("java.naming.security.principal", "system");
>> > props.setProperty("java.naming.security.credentials",
>> "manager");
>> >
>> > Context ic = new InitialContext(props);
>> > System.out.println("ic = " + ic);
>> >
>> > Object objRef = ic.lookup("MySessionRemoteHome");
>> > System.out.println("objRef = " + objRef);
>> >
>> > test.abc.MySessionRemoteHome home =
>> > (test.abc.MySessionRemoteHome)PortableRemoteObject.narrow(objRef,
>> > test.abc.MySessionRemoteHome.class);
>> > System.out.println("home = " + home);
>> >
>> > test.abc.MySessionRemote remote = home.create();
>> > System.out.println("remote = " + remote);
>> >
>> > String message = remote.getString();
>> > System.out.println("message = " + message);
>> >
>> >
>> > and it works okay on geronimo 1.2 beta. So this really makes me
>> confused,
>> > is this a regression o
Re: jndi lookup in remote client for geronimo v2
On Sep 14, 2007, at 10:48 AM, vrm wrote:
I'm having the exact same issue. I've spent 2 days looking around
and there
is no examples or documentations available for a Remote openejb client
accessing an EJB on Geronimo 2.
Anybody have an EAR for Geronimo2 and an Openejb-Client app
accessing it?
The Exception I get =
javax.naming.NameNotFoundException: /TheBean does not exist in the
system.
Check that the app was successfully deployed.
I've tried the following for InitialContext.lookup =
(artifactid)/(TheBean)/(TheInterface)
(artifactid)/(Interface)
(ejbBean)/(Interface)
(artifactid)/(TheBean)/(Full Path to Interface)
...and many more variations of this
My EJB Interface =
@Remote
public interface TheInterface {
My Bean =
@Stateless
public class TheBean implements TheInterface {
Anybody get this to work or have examples, please post.
I have an example here:
http://people.apache.org/~dblevins/tmp/examples/
Works in 2.0.1. You deploy the prebuilt SimpleApp-1.0.jar, then you
can run the EchoImplTest.java.
-David
Re: Problems with Geronimo Logging...
On Sep 14, 2007, at 2:11 PM, Kevan Miller wrote: I'm not entirely certain how an external CLASSPATH and MANIFEST.MF might interact. I do seem to recall that if you use 'java -jar server.jar', the jre ignores your external CLASSPATH setting and only observes the MANIFEST.MF setting... I hoped that invoking java as 'java ' would avoid this issue, but could easily be mistaken... That's right, the class path setting in the manifest trumps the external setting. I just encountered this today when I needed to add some jars to the classpath for deploy.sh. I ended up having to add them to deployer.jar!META-INF/MANIFEST.MF. There was already an entry in the manifest for ext-dir that I tried to use instead of altering the manifest: Extension-Dirs: lib/ext But placing jars into $G/lib/ext didn't seem to have any effect. Maybe that manifest entry should instead be: Extension-Dirs: ../lib/ext like the other paths to lib that are listed in the manifest? Best wishes, Paul
Re: jndi lookup in remote client for geronimo v2
I have some tests in Geronimo that might help.
If you have a EJB 2.x take a look at:
http://svn.apache.org/viewvc/geronimo/server/trunk/testsuite/webservices-testsuite/jaxrpc-tests/jaxrpc-ejb/
And for the client take a look at the testEJB() function in
http://svn.apache.org/viewvc/geronimo/server/trunk/testsuite/webservices-testsuite/jaxrpc-tests/jaxrpc-ejb/src/test/java/org/apache/geronimo/testsuite/testset/JaxRPCTest.java?view=markup
If you have EJB 3.0 take a look at:
http://svn.apache.org/viewvc/geronimo/server/trunk/testsuite/webservices-testsuite/jaxws-tests/jaxws-ejb/
And for the client take a look at the testEJB() function in
http://svn.apache.org/viewvc/geronimo/server/trunk/testsuite/webservices-testsuite/jaxws-tests/jaxws-ejb/src/test/java/org/apache/geronimo/testsuite/testset/JaxWSTest.java?view=markup
Jarek
On 9/14/07, vrm <[EMAIL PROTECTED]> wrote:
>
> I'm having the exact same issue. I've spent 2 days looking around and there
> is no examples or documentations available for a Remote openejb client
> accessing an EJB on Geronimo 2.
>
> Anybody have an EAR for Geronimo2 and an Openejb-Client app accessing it?
>
> The Exception I get =
> javax.naming.NameNotFoundException: /TheBean does not exist in the system.
> Check that the app was successfully deployed.
>
> I've tried the following for InitialContext.lookup =
> (artifactid)/(TheBean)/(TheInterface)
> (artifactid)/(Interface)
> (ejbBean)/(Interface)
> (artifactid)/(TheBean)/(Full Path to Interface)
> ...and many more variations of this
>
>
> My EJB Interface =
>
> @Remote
> public interface TheInterface {
>
>
> My Bean =
> @Stateless
> public class TheBean implements TheInterface {
>
>
> Anybody get this to work or have examples, please post.
>
>
>
>
> Xiao-fei Song wrote:
> >
> > Hi,
> >
> > Just wanted to let you know I modified a little bit about the code:
> >
> > props.setProperty("java.naming.factory.initial",
> > "org.apache.openejb.client.RemoteInitialContextFactory");
> > props.setProperty("java.naming.provider.url", "127.0.0.1:4201");
> > props.setProperty("java.naming.security.principal", "system");
> > props.setProperty("java.naming.security.credentials", "manager");
> >
> > Context ic = new InitialContext(props);
> > System.out.println("ic = " + ic);
> >
> > Object objRef = ic.lookup("MySessionRemoteHome");
> > System.out.println("objRef = " + objRef);
> >
> > test.abc.MySessionRemoteHome home =
> > (test.abc.MySessionRemoteHome)PortableRemoteObject.narrow(objRef,
> > test.abc.MySessionRemoteHome.class);
> > System.out.println("home = " + home);
> >
> > test.abc.MySessionRemote remote = home.create();
> > System.out.println("remote = " + remote);
> >
> > String message = remote.getString();
> > System.out.println("message = " + message);
> >
> >
> > and it works okay on geronimo 1.2 beta. So this really makes me confused,
> > is this a regression or intended to be. Can someone in this alias please
> > respond me?
> >
> > Thanks,
> > Chris
> >
> >
> > Xiao-fei Song wrote:
> >>
> >> Hi Mark,
> >>
> >> Thanks for your response.
> >>
> >> 1. For the time being, I don't really care if the client is really
> >> "remote". From my tests, it looks like only "127.0.0.1" is accepted
> >> otherwise the connects just failed. I don't know where the documentation
> >> can be found on this.
> >>
> >> 2. Yes I assume all the libraries are there for the EJB call. And they
> >> are:
> >>
> >> cglig-nodep
> >> geronimo-kernel
> >> openejb-core
> >> openejb-client
> >> j2ee.jar (from j2ee ri)
> >>
> >> 3. Unfortunately it does not work with "ejb/MySessionRemoteHome" and here
> >> is what I got:
> >>
> >> ic = [EMAIL PROTECTED]
> >> Exception in thread "main" javax.naming.NameNotFoundException:
> >> /ejb/MySessionRemoteHome does not exist in the system. Check that the
> >> app was successfully deployed.
> >> at
> >> org.apache.openejb.client.JNDIContext.lookup(JNDIContext.java:231)
> >> at javax.naming.InitialContext.lookup(Unknown Source)
> >> at apachegclient.TestClient.main(TestClient.java:43)
> >>
> >>
> >> I would say my first experiences with Genonimo is frustrated because I
> >> just spent a whole day on a very simple task. Anyway, if you have the
> >> sample code (both the ejb and the ejb client) that works with geronimo
> >> v2, please send it to my email address.
> >>
> >> Thanks,
> >> Chris
> >>
> >>
> >>
> >> Mark Aufdencamp wrote:
> >>>
> >>> Hi Chris,
> >>>
> >>> I'll give it a shot at helping you. I've been able to do this thanks to
> >>> much help from others on this list.
> >>>
> >>> Are you truly doing this as a remote client from a different machine
> >>> than the server? If so, the IP addres your using for the naming
> >>> provider should be the server address, rather than the local loopback
> >>> address.
> >>>
> >>> Do you have all of the required remote client libraries in the class
>
Re: Problems with Geronimo Logging...
On Sep 14, 2007, at 1:49 PM, EJLeVin1 wrote: Kevan, Thanks for the info. I wasn't able to get the modification to the .bat/.sh files working properly with the -classpath options (although I might have been setting something wrong); however, changing the MANIFEST.MF file in the server.jar did do the trick (which was kind of nice because I could just copy it to our linux distro), and I was able to add my custom jars to the classpath through that means. I think I might go ahead and make a Jira for this -- I think it would be a nice thing to be able to do moving forward in a much easier fashion. Thanks again for your help! Hi Eric, No problem. I'm glad to hear you got things working. Please do raise a jira -- I'd really like to see us improve these pain points... I'm not entirely certain how an external CLASSPATH and MANIFEST.MF might interact. I do seem to recall that if you use 'java -jar server.jar', the jre ignores your external CLASSPATH setting and only observes the MANIFEST.MF setting... I hoped that invoking java as 'java ' would avoid this issue, but could easily be mistaken... --kevan
Re: Creation of new threads after closing response writer in Servlet in Little-G Jetty 2.0.1
The new Treads are created by more than one Servlet requests
when loading a page. The page itself and also serving some
static files.
The new Threads appear all at the same time because of a
synchronized block in SelectChannelEndPoint.undispatch();
Which is called at the line number mentioned in my last mail.
All that looks like normal behaviour. The problem I see is
that all newly created Threads stay alive and none of theses
Threads is reused after that.
I guess there is some problem reusing the Threads in the pool and
every request creates new Threads. The number of 10 new threads
mentioned before relates magically to exact 10 servlet requests
in my test case. On other pages there are lesser or more.
So the number means nothing.
I have no idea about the Thread pool management and don't know
where to start so I give the ball back to you guys on the list.
Thanks,
Mario
Mario Ruebsam wrote:
Ok, I will download or checkout the Jetty 6.1.5 sources to do some further
investigation on it.
Thanks,
Mario
Paul McMahan wrote:
Mario, thanks for doing the extra debugging to narrow down where the
problem is at. Yes the jetty version is 6.1.5. You can also find
the version number of a component in the admin console's System
modules portlet or by the directory name in Geronimo's repository, in
this case $G/repository/org/mortbay/jetty/jetty/6.1.5
Best wishes,
Paul
On Sep 14, 2007, at 11:34 AM, Mario Ruebsam wrote:
I did some debugging and followed the code until:
SelectChannelConnector$ConnectorEndPoint(SelectChannelEndPoint).run()
line: 422
when this line is called the Treads will be created.
I guess this is Jetty code because I could not found it
in the Geronimo sources.
Which Jetty version is used is Geronimo 2.0.1?
When I look in the sources pom.xml it is 6.1.5, is this the used
Version?
Thanks,
Mario
Mario Ruebsam wrote:
Hello,
after migrating successful from Little-G Jetty 1.1 to Little-G Jetty
2.0.1
I detected some strange behavior when closing the Servlets response
writer.
Every time the writer is closed Geronimo or Jetty creates 10 new
Threads
in the DefaultThreadPool. The code snippet is below.
In G 1.1 the same code has no impact on threads.
Does anybody has the same experience? Is this a Jetty or a Geronimo
problem?
public void doGet(HttpServletRequest pRequest, HttpServletResponse
pResponse) throws IOException, ServletException {
<... do some stuff ...>
PrintWriter tOut = pResponse.getWriter();
tOut.write(tData);
tOut.close();
}
Thanks,
Mario
Training session: Securing Java EE Applications in Apache Geronimo
Hi, I will be conducting a training session titled "Securing Java EE Applications in Apache Geronimo" at ApacheCon US 2007 to be held in Atlanta and OS Summit Asia 2007 to be held in Hongkong in November. The following links provide details of the topics covered and training schedule. http://us.apachecon.com/us2007/program/talk/1977 http://www.ossummit.com/2007/program/talk/15 If you are interested, you can register for the training sessions. There is also a discount on the fee if registered before 22nd Sep for the US conference. I hope this information is helpful. Thanks and best regards, Vamsi Committer and Member of Apache Geronimo PMC
Re: Problems with Geronimo Logging...
Kevan, Thanks for the info. I wasn't able to get the modification to the .bat/.sh files working properly with the -classpath options (although I might have been setting something wrong); however, changing the MANIFEST.MF file in the server.jar did do the trick (which was kind of nice because I could just copy it to our linux distro), and I was able to add my custom jars to the classpath through that means. I think I might go ahead and make a Jira for this -- I think it would be a nice thing to be able to do moving forward in a much easier fashion. Thanks again for your help! -Eric Kevan Miller wrote: > > > On Sep 12, 2007, at 9:11 PM, EJLeVin1 wrote: > >> >> Ok, so first off I want to apologize if this is kind of a newbie >> question, >> but we are making the migration from Tomcat to Geronimo, and I am >> having a >> hard time moving some of our application's logging. We have written a >> custom log4j appender that utilizes both our custom jar, and 3x 3rd >> party >> jars. My original intent was to just add these three jars to >> GERONIMO_HOME/lib and then configure the >> GERONIMO_HOME/var/logs/server-log4j.properties file to make use of >> this >> appender with a filter to our namespace; however, this failed with >> getting a >> class not found error. > > Hi Eric, > Good question... I may be proven wrong, but I don't know of a really > clean way to provide the function you're after... I have some options > that should get you running. However, would be helpful if you created > a Jira that suggests we make this easier/cleaner... > > FYI, unlike Tomcat, mere presence of a jar in the lib/ directory will > not cause the jar to be added to the CLASSPATH of a Geronimo server. > Instead, META-INF/MANIFEST.MF in bin/server.jar is controlling the > CLASSPATH. > > So, one straight-forward, but pretty dirty way of solving your > problem is to hack the MANIFEST.MF in server.jar. > Slightly better (?) is to set CLASSPATH via environment variable or - > cp command option. I think this means that you can't use 'java -jar > server.jar' (which is also used by geronimo.sh when starting > geronimo). So you'd have to do invoke java directly or update > geronimo.sh to do something like: > > java -cp my-custom-logger.jar:bin/server.jar -javaagent:bin/jpa.jar - > Djava.endorsed.dirs=lib/endorsed > org.apache.geronimo.cli.daemon.DaemonCLI > > That's totally untested... > > You can always load and configure your logger on a per application > basis, but it sounds like you want this to be server wide... I guess > you could create a module which contains your custom appender, but > again that's not server wide... > >> I also tried adding these to the repository and it >> didn't seem to work either. I am not sure whether this is the >> correct route >> to take (as in digging further into the GBean -- it would seem nice >> to be >> able to add our appender functionality by loading/unloading a GBean >> within >> Geronimo), but seemed to be the easiest. I was wondering if anyone >> could >> give an example of / knew how to do either of the following methods: >> >> 1) Adding the 3rd party jars to the j2ee-server module so that the >> custom >> appender can be resolved when loading log4j > > Right. IMO, that's the way you want to solve this, but I don't know > how. Unless you build the server from source (which is another option). > >> >> 2) Getting a handle on the running log4j instance (I think the >> beans name is >> "ServerLog"), and being able to add the appender/classes to the >> configuration by means of a GBean. >> >> Thanks anyone for your help, as I have been looking at this now for >> quite >> some time, and can't seem to find an answer anywhere. > > --kevan > > > > -- View this message in context: http://www.nabble.com/Problems-with-Geronimo-Logging...-tf4432954s134.html#a12680635 Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
RE: jndi lookup in remote client for geronimo v2
I'm having the exact same issue. I've spent 2 days looking around and there
is no examples or documentations available for a Remote openejb client
accessing an EJB on Geronimo 2.
Anybody have an EAR for Geronimo2 and an Openejb-Client app accessing it?
The Exception I get =
javax.naming.NameNotFoundException: /TheBean does not exist in the system.
Check that the app was successfully deployed.
I've tried the following for InitialContext.lookup =
(artifactid)/(TheBean)/(TheInterface)
(artifactid)/(Interface)
(ejbBean)/(Interface)
(artifactid)/(TheBean)/(Full Path to Interface)
...and many more variations of this
My EJB Interface =
@Remote
public interface TheInterface {
My Bean =
@Stateless
public class TheBean implements TheInterface {
Anybody get this to work or have examples, please post.
Xiao-fei Song wrote:
>
> Hi,
>
> Just wanted to let you know I modified a little bit about the code:
>
> props.setProperty("java.naming.factory.initial",
> "org.apache.openejb.client.RemoteInitialContextFactory");
> props.setProperty("java.naming.provider.url", "127.0.0.1:4201");
> props.setProperty("java.naming.security.principal", "system");
> props.setProperty("java.naming.security.credentials", "manager");
>
> Context ic = new InitialContext(props);
> System.out.println("ic = " + ic);
>
> Object objRef = ic.lookup("MySessionRemoteHome");
> System.out.println("objRef = " + objRef);
>
> test.abc.MySessionRemoteHome home =
> (test.abc.MySessionRemoteHome)PortableRemoteObject.narrow(objRef,
> test.abc.MySessionRemoteHome.class);
> System.out.println("home = " + home);
>
> test.abc.MySessionRemote remote = home.create();
> System.out.println("remote = " + remote);
>
> String message = remote.getString();
> System.out.println("message = " + message);
>
>
> and it works okay on geronimo 1.2 beta. So this really makes me confused,
> is this a regression or intended to be. Can someone in this alias please
> respond me?
>
> Thanks,
> Chris
>
>
> Xiao-fei Song wrote:
>>
>> Hi Mark,
>>
>> Thanks for your response.
>>
>> 1. For the time being, I don't really care if the client is really
>> "remote". From my tests, it looks like only "127.0.0.1" is accepted
>> otherwise the connects just failed. I don't know where the documentation
>> can be found on this.
>>
>> 2. Yes I assume all the libraries are there for the EJB call. And they
>> are:
>>
>> cglig-nodep
>> geronimo-kernel
>> openejb-core
>> openejb-client
>> j2ee.jar (from j2ee ri)
>>
>> 3. Unfortunately it does not work with "ejb/MySessionRemoteHome" and here
>> is what I got:
>>
>> ic = [EMAIL PROTECTED]
>> Exception in thread "main" javax.naming.NameNotFoundException:
>> /ejb/MySessionRemoteHome does not exist in the system. Check that the
>> app was successfully deployed.
>> at
>> org.apache.openejb.client.JNDIContext.lookup(JNDIContext.java:231)
>> at javax.naming.InitialContext.lookup(Unknown Source)
>> at apachegclient.TestClient.main(TestClient.java:43)
>>
>>
>> I would say my first experiences with Genonimo is frustrated because I
>> just spent a whole day on a very simple task. Anyway, if you have the
>> sample code (both the ejb and the ejb client) that works with geronimo
>> v2, please send it to my email address.
>>
>> Thanks,
>> Chris
>>
>>
>>
>> Mark Aufdencamp wrote:
>>>
>>> Hi Chris,
>>>
>>> I'll give it a shot at helping you. I've been able to do this thanks to
>>> much help from others on this list.
>>>
>>> Are you truly doing this as a remote client from a different machine
>>> than the server? If so, the IP addres your using for the naming
>>> provider should be the server address, rather than the local loopback
>>> address.
>>>
>>> Do you have all of the required remote client libraries in the class
>>> path for the remote EJB call? I can look back at my notes and provide
>>> these if you need them.
>>>
>>> I believe the remote name will probably be proceeded by "ejb". As in
>>> "ejb/MySessionRemoteHome".
>>>
>>> I can dig up some code of my own that works if you'ld like.
>>>
>>> Hope this helps some.
>>>
>>> Mark Aufdencamp
>>> [EMAIL PROTECTED]
>>>
Original Message
Subject: jndi lookup in remote client for geronimo v2
From: Xiao-fei Song <[EMAIL PROTECTED]>
Date: Fri, June 29, 2007 7:04 am
To: user@geronimo.apache.org
Hi guys,
I have developed an EJB 2.x stateless session using netbeans, and I
want to write a very simple stand alone ejb client to access it in
geronimo v2. The code looks like below:
props.setProperty("java.naming.factory.initial",
"org.openejb.client.RemoteInitialContextFactory");
props.setProperty("java.naming.provider.url",
"127.0.0.1:4201");
//props.setProperty("java.nam
Re: Creation of new threads after closing response writer in Servlet in Little-G Jetty 2.0.1
Ok, I will download or checkout the Jetty 6.1.5 sources to do some further
investigation on it.
Thanks,
Mario
Paul McMahan wrote:
Mario, thanks for doing the extra debugging to narrow down where the
problem is at. Yes the jetty version is 6.1.5. You can also find the
version number of a component in the admin console's System modules
portlet or by the directory name in Geronimo's repository, in this case
$G/repository/org/mortbay/jetty/jetty/6.1.5
Best wishes,
Paul
On Sep 14, 2007, at 11:34 AM, Mario Ruebsam wrote:
I did some debugging and followed the code until:
SelectChannelConnector$ConnectorEndPoint(SelectChannelEndPoint).run()
line: 422
when this line is called the Treads will be created.
I guess this is Jetty code because I could not found it
in the Geronimo sources.
Which Jetty version is used is Geronimo 2.0.1?
When I look in the sources pom.xml it is 6.1.5, is this the used Version?
Thanks,
Mario
Mario Ruebsam wrote:
Hello,
after migrating successful from Little-G Jetty 1.1 to Little-G Jetty
2.0.1
I detected some strange behavior when closing the Servlets response
writer.
Every time the writer is closed Geronimo or Jetty creates 10 new Threads
in the DefaultThreadPool. The code snippet is below.
In G 1.1 the same code has no impact on threads.
Does anybody has the same experience? Is this a Jetty or a Geronimo
problem?
public void doGet(HttpServletRequest pRequest, HttpServletResponse
pResponse) throws IOException, ServletException {
<... do some stuff ...>
PrintWriter tOut = pResponse.getWriter();
tOut.write(tData);
tOut.close();
}
Thanks,
Mario
Re: JOSSO with Geronimo
I looked at the JOSSO documentation really quickly and think that there won't be an advantage to using the tomcat realm rather than the default jacc based realm. I think you can configure the josso login module in a geronimo security realm with no problems. The only possible tricky parts are installing the JOSSO valve and running the josso agent. There are instructions available somewhere on how to install a valve in geronimo-tomcat. I don't understand from the docs if you are supposed to run a separate agent: if so you will probably have to write a gbean to start/stop it. hope this overly brief comment is of some help... david jencks On Sep 14, 2007, at 12:15 PM, Kevan Miller wrote: On Sep 14, 2007, at 10:56 AM, Carver wrote: Yes, I can. What's the advantage of using Geronimo 2.0.1? Is it easy to config the Tomcat Realm? Heh. Well, not necessarily, but we'll definitely be more interested in helping you... ;-) For me to help you, I'd need to do some investigation. I won't be able to get to it, today. Maybe somebody else is willing to lend a hand... --kevan
Re: Creation of new threads after closing response writer in Servlet in Little-G Jetty 2.0.1
Mario, thanks for doing the extra debugging to narrow down where the
problem is at. Yes the jetty version is 6.1.5. You can also find
the version number of a component in the admin console's System
modules portlet or by the directory name in Geronimo's repository,
in this case $G/repository/org/mortbay/jetty/jetty/6.1.5
Best wishes,
Paul
On Sep 14, 2007, at 11:34 AM, Mario Ruebsam wrote:
I did some debugging and followed the code until:
SelectChannelConnector$ConnectorEndPoint(SelectChannelEndPoint).run
() line: 422
when this line is called the Treads will be created.
I guess this is Jetty code because I could not found it
in the Geronimo sources.
Which Jetty version is used is Geronimo 2.0.1?
When I look in the sources pom.xml it is 6.1.5, is this the used
Version?
Thanks,
Mario
Mario Ruebsam wrote:
Hello,
after migrating successful from Little-G Jetty 1.1 to Little-G
Jetty 2.0.1
I detected some strange behavior when closing the Servlets
response writer.
Every time the writer is closed Geronimo or Jetty creates 10 new
Threads
in the DefaultThreadPool. The code snippet is below.
In G 1.1 the same code has no impact on threads.
Does anybody has the same experience? Is this a Jetty or a
Geronimo problem?
public void doGet(HttpServletRequest pRequest, HttpServletResponse
pResponse) throws IOException, ServletException {
<... do some stuff ...>
PrintWriter tOut = pResponse.getWriter();
tOut.write(tData);
tOut.close();
}
Thanks,
Mario
Re: JOSSO with Geronimo
On Sep 14, 2007, at 10:56 AM, Carver wrote: Yes, I can. What's the advantage of using Geronimo 2.0.1? Is it easy to config the Tomcat Realm? Heh. Well, not necessarily, but we'll definitely be more interested in helping you... ;-) For me to help you, I'd need to do some investigation. I won't be able to get to it, today. Maybe somebody else is willing to lend a hand... --kevan
Re: Creation of new threads after closing response writer in Servlet in Little-G Jetty 2.0.1
On Sep 14, 2007, at 11:34 AM, Mario Ruebsam wrote: I did some debugging and followed the code until: SelectChannelConnector$ConnectorEndPoint(SelectChannelEndPoint).run () line: 422 when this line is called the Treads will be created. Nice. Thanks for digging into this Mario! I guess this is Jetty code because I could not found it in the Geronimo sources. Correct. Which Jetty version is used is Geronimo 2.0.1? When I look in the sources pom.xml it is 6.1.5, is this the used Version? Yes, we use 6.1.5. See geronimo-jetty6-jee5-2.0.1/repository/org/ mortbay/jetty/jetty/6.1.5/jetty-6.1.5.jar in your installation... Perhaps Jan or Greg can comment on the behavior you're seeing... --kevan
Re: Creation of new threads after closing response writer in Servlet in Little-G Jetty 2.0.1
I did some debugging and followed the code until:
SelectChannelConnector$ConnectorEndPoint(SelectChannelEndPoint).run() line: 422
when this line is called the Treads will be created.
I guess this is Jetty code because I could not found it
in the Geronimo sources.
Which Jetty version is used is Geronimo 2.0.1?
When I look in the sources pom.xml it is 6.1.5, is this the used Version?
Thanks,
Mario
Mario Ruebsam wrote:
Hello,
after migrating successful from Little-G Jetty 1.1 to Little-G Jetty 2.0.1
I detected some strange behavior when closing the Servlets response writer.
Every time the writer is closed Geronimo or Jetty creates 10 new Threads
in the DefaultThreadPool. The code snippet is below.
In G 1.1 the same code has no impact on threads.
Does anybody has the same experience? Is this a Jetty or a Geronimo
problem?
public void doGet(HttpServletRequest pRequest, HttpServletResponse
pResponse) throws IOException, ServletException {
<... do some stuff ...>
PrintWriter tOut = pResponse.getWriter();
tOut.write(tData);
tOut.close();
}
Thanks,
Mario
Re: Creation of new threads after closing response writer in Servlet in Little-G Jetty 2.0.1
I did some debugging and followed the code until:
SelectChannelConnector$ConnectorEndPoint(SelectChannelEndPoint).run() line: 422
when this line is called the Treads will be created.
I guess this is Jetty code because I could not found it
in the Geronimo sources.
Which Jetty version is used is Geronimo 2.0.1?
When I look in the sources pom.xml it is 6.1.5, is this the used Version?
Thanks,
Mario
Mario Ruebsam wrote:
Hello,
after migrating successful from Little-G Jetty 1.1 to Little-G Jetty 2.0.1
I detected some strange behavior when closing the Servlets response writer.
Every time the writer is closed Geronimo or Jetty creates 10 new Threads
in the DefaultThreadPool. The code snippet is below.
In G 1.1 the same code has no impact on threads.
Does anybody has the same experience? Is this a Jetty or a Geronimo
problem?
public void doGet(HttpServletRequest pRequest, HttpServletResponse
pResponse) throws IOException, ServletException {
<... do some stuff ...>
PrintWriter tOut = pResponse.getWriter();
tOut.write(tData);
tOut.close();
}
Thanks,
Mario
Re: JOSSO with Geronimo
Yes, I can. What's the advantage of using Geronimo 2.0.1? Is it easy to config the Tomcat Realm? -- View this message in context: http://www.nabble.com/JOSSO-with-Geronimo-tf4430200s134.html#a12676582 Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: Problem with referencing to beans from other ejb-jars
I found, that JARFILE#BeanName allow to refer to independent jars, but... it's still not working -- View this message in context: http://www.nabble.com/Problem-with-referencing-to-beans-from-other-ejb-jars-tf4435740s134.html#a12676579 Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: Problem with referencing to beans from other ejb-jars
David Blevins wrote: > > Hi Tomasz, > > I created a doc for you that describes the missing parts. > >http://cwiki.apache.org/OPENEJB/ejb-refs.html > > Keep what you have with the openejb-jar and add the parts described > in this to your ejb-jar.xml. > > Unfortunately, while looking into this I discovered that our code for > overriding an @EJB annotation with an in the xml is not > implemented, thus if you have @EJB and the corresponding as > described in the first section of the document, you'll end up with > two refs and not one as you should. > > We'll get this fixed asap, but until then follow the technique > described in the second part of the doc and in the next version of > Geronimo you'll be able to delete some of that xml and readd the @EJB > annotation. > > -David > > David, this example doesn't want working. I found text below in ejb-jar specification: The ejb-link element is used in the ejb-ref element to specify that an EJB reference is linked to another enterprise bean in the ejb-jar file. The value of the ejb-link element must be the ejb-name of an enterprise bean in the same ejb-jar file, or in another ejb-jar file in the same J2EE application unit. I suspect it's not correct way :-| Beniamin -- View this message in context: http://www.nabble.com/Problem-with-referencing-to-beans-from-other-ejb-jars-tf4435740s134.html#a12676146 Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Enabling sticky sessions in Geronimo 2.0.1
Does anyone know how to enable sticky sessions in Geronimo 2.0.1? I tried using the method that worked in previous Geronimo versions, adding the following to the config.xml file: name="Geronimo" jvmRoute="node1" This did not seem to have any effect on the composition of the JSESSIONID, hence no sticky sessions. When I looked up the docs on Tomcat 6 as it pertains to clustering, the instructions indicate that the server.xml file should be modified to enable this feature. The Tomcat being used in Geronimo does not seem to have this file. I assume that the Tomcat instance is being configured using code. Is there anyway to configure the Tomcat instance that Geronimo starts? Dennis
Creation of new threads after closing response writer in Servlet in Little-G Jetty 2.0.1
Hello,
after migrating successful from Little-G Jetty 1.1 to Little-G Jetty 2.0.1
I detected some strange behavior when closing the Servlets response writer.
Every time the writer is closed Geronimo or Jetty creates 10 new Threads
in the DefaultThreadPool. The code snippet is below.
In G 1.1 the same code has no impact on threads.
Does anybody has the same experience? Is this a Jetty or a Geronimo problem?
public void doGet(HttpServletRequest pRequest, HttpServletResponse pResponse)
throws IOException, ServletException {
<... do some stuff ...>
PrintWriter tOut = pResponse.getWriter();
tOut.write(tData);
tOut.close();
}
Thanks,
Mario
