Startup Error Using Eclipse
I've seen some previous posts about similar issues so I thought this would be a good place to start. ( I have also posted on The MyEclipse forum) I'm running MyEclipseIDE 7.5 on MacBookPro JDK 1.5. I can start Geronimo( geronimo-tomcat6-javaee5-2.1.4) manually using the command line but when I use Eclipse ( without a project ) I get an error as listed below: Here is the program args from the launch config screen: /Applications/geronimo-tomcat6-javaee5-2.1.4/bin/server.jar -long -Djava.library.path=/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin -Dorg.apache.geronimo.base.dir=/Applications/geronimo-tomcat6-javaee5-2.1.4 -Djava.io.tmpdir=/Applications/geronimo-tomcat6-javaee5-2.1.4/var/temp -Djava.ext.dirs=/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/jre/lib/ext:"/Applications/geronimo-tomcat6-javaee5-2.1.4/lib/ext" -Djava.endorsed.dirs=/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/jre/lib/endorsed:"/Applications/geronimo-tomcat6-javaee5-2.1.4/lib/endorsed" Thanks for any insight. Wade Module 52/69 org.apache.geronimo.plugins/console-tomcat/2.1.4/car 2009-09-29 15:29:06,296 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName="org.apache.geronimo.plugins/console-tomcat/2.1.4/car?J2EEApplication=org.apache.geronimo.plugins/console-tomcat/2.1.4/car,j2eeType=JACCManager,name=JACCManager" java.lang.ExceptionInInitializerErrorat org.apache.geronimo.security.jacc.ApplicationPolicyConfigurationManager.(ApplicationPolicyConfigurationManager.java:109) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:501)at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:948) 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:541) 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:555) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:456) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:188) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:563) at sun.reflect.GeneratedMethodAccessor27.invoke(Unknown Source)at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:592)at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:832) 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.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$20d003ce.startConfiguration() at org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:162) at org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:79) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigu
Re: Building Daytrader trunk fails
You guessed right, being maven-illiterate I ran deploy. Thanks for your help.
OK, with install the build went fine (I needed
JAVA_OPTS=-XX:MaxPermSize=256m). But when I tried to install the ear with
the derby plan there is
2009-09-29 22:28:51,895 ERROR [[/daytrader]] Exception sending context
initialized event to listener instance of class
org.apache.geronimo.samples.daytrader.web.TradeWebContextListener
java.lang.NoClassDefFoundError:
org/apache/geronimo/samples/daytrader/direct/TradeDirect
at
org.apache.geronimo.samples.daytrader.web.TradeWebContextListener.contextInitialized(TradeWebContextListener.java:32)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3930)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4419)
djencks wrote:
>
> there is no missing dependency shown... it just thinks this is the
> first time the snapshot has been uploaded.
>
> Either someone messed up the pom by setting a default goal to
> "deploy" (I don't know if this is even possible) or you ran mvn clean
> deploy instead of mvn clean install.
>
> As you are not a committer you don't have permissions to upload
> snapshots to the apache snapshot repo.
>
> thanks
> david jencks
>
> On Sep 29, 2009, at 11:58 AM, Juergen Weber wrote:
>
>>
>> Hi,
>>
>> I tried to build Daytrader trunk, but it fails with the missing
>> dependency
>> below. Could somebody please fix this? And why is it Uploading ?
>>
>> Thanks very much,
>> Juergen
>>
>> [INFO] Installing /projekte/geronimo-src/geronimo/daytrader/trunk/
>> pom.xml to
>> /projekte/m2repository/org/apache/geronimo/daytrader/daytrader-
>> parent/2.2-SNAPSHOT/daytrader-parent-2.2-SNAPSHOT.pom
>> [INFO] [deploy:deploy {execution: default-deploy}]
>> [INFO] Retrieving previous build number from apache.snapshots.https
>> [INFO] repository metadata for: 'snapshot
>> org.apache.geronimo.daytrader:daytrader-parent:2.2-SNAPSHOT' could
>> not be
>> found on repository: apache.snapshots.https, so will be created
>> Uploading:
>> https://repository.apache.org/content/repositories/snapshots/org/apache/geronimo/daytrader/daytrader-parent/2.2-SNAPSHOT/daytrader-parent-2.2-20090929.185350-1.pom
>> [INFO]
>>
>> [ERROR] BUILD ERROR
>> [INFO]
>>
>> [INFO] Error deploying artifact: Failed to transfer file:
>> https://repository.apache.org/content/repositories/snapshots/org/apache/geronimo/daytrader/daytrader-parent/2.2-SNAPSHOT/daytrader-parent-2.2-20090929.185350-1.pom
>>
>> .
>> Return code is: 401
>>
>> [INFO]
>>
>> [INFO] Trace
>> org.apache.maven.lifecycle.LifecycleExecutionException: Error
>> deploying
>> artifact: Failed to transfer file:
>> https://repository.apache.org/content/repositories/snapshots/org/apache/geronimo/daytrader/daytrader-parent/2.2-SNAPSHOT/daytrader-parent-2.2-20090929.185350-1.pom
>>
>> .
>> Return code is: 401
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Building-Daytrader-trunk-fails-tp25668904s134p25668904.html
>> Sent from the Apache Geronimo - Users mailing list archive at
>> Nabble.com.
>>
>
>
>
--
View this message in context:
http://www.nabble.com/Building-Daytrader-trunk-fails-tp25668904s134p25670449.html
Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: Building Daytrader trunk fails
there is no missing dependency shown... it just thinks this is the
first time the snapshot has been uploaded.
Either someone messed up the pom by setting a default goal to
"deploy" (I don't know if this is even possible) or you ran mvn clean
deploy instead of mvn clean install.
As you are not a committer you don't have permissions to upload
snapshots to the apache snapshot repo.
thanks
david jencks
On Sep 29, 2009, at 11:58 AM, Juergen Weber wrote:
Hi,
I tried to build Daytrader trunk, but it fails with the missing
dependency
below. Could somebody please fix this? And why is it Uploading ?
Thanks very much,
Juergen
[INFO] Installing /projekte/geronimo-src/geronimo/daytrader/trunk/
pom.xml to
/projekte/m2repository/org/apache/geronimo/daytrader/daytrader-
parent/2.2-SNAPSHOT/daytrader-parent-2.2-SNAPSHOT.pom
[INFO] [deploy:deploy {execution: default-deploy}]
[INFO] Retrieving previous build number from apache.snapshots.https
[INFO] repository metadata for: 'snapshot
org.apache.geronimo.daytrader:daytrader-parent:2.2-SNAPSHOT' could
not be
found on repository: apache.snapshots.https, so will be created
Uploading:
https://repository.apache.org/content/repositories/snapshots/org/apache/geronimo/daytrader/daytrader-parent/2.2-SNAPSHOT/daytrader-parent-2.2-20090929.185350-1.pom
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error deploying artifact: Failed to transfer file:
https://repository.apache.org/content/repositories/snapshots/org/apache/geronimo/daytrader/daytrader-parent/2.2-SNAPSHOT/daytrader-parent-2.2-20090929.185350-1.pom
.
Return code is: 401
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error
deploying
artifact: Failed to transfer file:
https://repository.apache.org/content/repositories/snapshots/org/apache/geronimo/daytrader/daytrader-parent/2.2-SNAPSHOT/daytrader-parent-2.2-20090929.185350-1.pom
.
Return code is: 401
--
View this message in context:
http://www.nabble.com/Building-Daytrader-trunk-fails-tp25668904s134p25668904.html
Sent from the Apache Geronimo - Users mailing list archive at
Nabble.com.
Building Daytrader trunk fails
Hi,
I tried to build Daytrader trunk, but it fails with the missing dependency
below. Could somebody please fix this? And why is it Uploading ?
Thanks very much,
Juergen
[INFO] Installing /projekte/geronimo-src/geronimo/daytrader/trunk/pom.xml to
/projekte/m2repository/org/apache/geronimo/daytrader/daytrader-parent/2.2-SNAPSHOT/daytrader-parent-2.2-SNAPSHOT.pom
[INFO] [deploy:deploy {execution: default-deploy}]
[INFO] Retrieving previous build number from apache.snapshots.https
[INFO] repository metadata for: 'snapshot
org.apache.geronimo.daytrader:daytrader-parent:2.2-SNAPSHOT' could not be
found on repository: apache.snapshots.https, so will be created
Uploading:
https://repository.apache.org/content/repositories/snapshots/org/apache/geronimo/daytrader/daytrader-parent/2.2-SNAPSHOT/daytrader-parent-2.2-20090929.185350-1.pom
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error deploying artifact: Failed to transfer file:
https://repository.apache.org/content/repositories/snapshots/org/apache/geronimo/daytrader/daytrader-parent/2.2-SNAPSHOT/daytrader-parent-2.2-20090929.185350-1.pom.
Return code is: 401
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying
artifact: Failed to transfer file:
https://repository.apache.org/content/repositories/snapshots/org/apache/geronimo/daytrader/daytrader-parent/2.2-SNAPSHOT/daytrader-parent-2.2-20090929.185350-1.pom.
Return code is: 401
--
View this message in context:
http://www.nabble.com/Building-Daytrader-trunk-fails-tp25668904s134p25668904.html
Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: How does the Client Container work?
I think if it would just become possible to have the container wrapped
by a remote server instance, then JNLP is just around the corner.
Unfortunately JNLP only supports shipping JARs. But there are 2 ways
to get geronimo to then work with JNLP.
First would be if geronimo would do all it's file handling through
URLs, it would make it easier to have everything shipped in JARs. The
biggest problem here is probably the repository and {GERONIMO}/var.
You would have to use the JNLP API to get places for these
directories, but if this were to generalized into an plugin and API,
you could have 2 separate plugins, one for the standard server and one
for the JNLP server. The JNLP server would use JNLP api to get a local
directory for it's caches, derby, etc.
The easiest solution, which requires no changes to Geronimo would
require a signed JAR though. This JAR would then have the
tag, and once executed would "install" geronimo into
a local directory on the machine. If it's already installed it would
just execute it. JNLP purists disagree with this. I myself don't see
anything wrong with this, as it fits perfectly into the "deployment
science" theories.
Quintin Beukes
On Tue, Sep 29, 2009 at 6:02 PM, David Jencks wrote:
> As you have discovered, app client containers are not very thoroughly
> specified. And as various pieces of documentation indicate, ours currently
> works only on the same machine as the server and there may be problems
> extracting just the bits you need to run an app client. However I still
> think that the problems of extracting a minimal client assembly and
> configuring it to talk to a remote server are pretty easy to solve.
>
> I'm not very familiar with jnlp but wonder just how suitable it would be for
> this in geronimo. Geronimo tends to have a lot of small jar files and
> various configuration files arranged in a particular directory structure
> (that it maintains) and that are related through geronimo classloaders. My
> understanding of jnlp is that it is more oriented towards downloading plain
> jar files that are maintained by the jnlp infrastructure. I would think
> that the most convenient way to get a geronimo app client would be to
> generate a client assembly, package it, download it, and unpack it in a
> suitable location on the client machine. I don't know if something like
> this is practical with jnlp. I guess it might be possible to do something
> like putting the entire server in a jar and write more classloaders to
> access everything from inside the jar. I think ClassWorlds tries to do this
> but all my attempts in this line haven't worked very well.
>
> thanks
> david jencks
>
> On Sep 29, 2009, at 3:31 AM, Quintin Beukes wrote:
>
>> Interesting thing though. At the end of the spec it says:
>>
>> EE.12.1 JNLP (JavaTM Web Start)
>> The Java Network Launch Protocol defines a mechanism for deploying Java
>> applications on a server and launching them from a client. A future
>> version of this
>> specification may require that Java EE products be able to deploy
>> application clients
>> in a way that allows them to be launched by a JNLP client, and that
>> application
>> client containers be able to launch application clients deployed using the
>> JNLP
>> technology. JavaTM Web Start is the reference implementation of a JNLP
>> client.
>> More information on JNLP is available at http://jcp.org/en/jsr/
>> detail?id=056; more information on Java Web Start is available at http://
>> java.sun.com/products/javawebstart.
>>
>>
>> Quintin Beukes
>>
>>
>>
>> On Tue, Sep 29, 2009 at 12:24 PM, Quintin Beukes
>> wrote:
>>>
>>> Hey,
>>>
>>> If you go read the JavaEE 5.0 spec regarding Application Clients, they
>>> do specify the following:
>>> As with all Java EE components, application clients use JNDI to look
>>> up enterprise
>>> beans, get access to resource managers, reference configurable parameters
>>> set at
>>> deployment time, and so on. Application clients use the java: JNDI
>>> namespace to
>>> access these items (see Chapter EE.5, “Resources, Naming, and Injection”
>>> for
>>> details).
>>>
>>> That is the closest they get to "remote". They do mention that the
>>> method of deployment/installation on a client is implementation
>>> specific, and it doesn't matter how they do it. So I guess my
>>> explanation is suitable for Geronimo, and Geronimo is on spec.
>>>
>>> It provides the authentication, and it is possible to do
>>> authentication against a remote server by configuring the security
>>> realm as such.
>>>
>>> Then you setup your server and deploy your application client.
>>> Further, any remote EJBs would be declared and defined as such, and
>>> there you have your fully JavaEE on-spec application client.
>>>
>>> If you think about it, this is a very logical design. Try and think of
>>> an application client as any other EJB jar. Have you ever asked
>>> yourself how to deploy an EJB jar in one server but have it wrapped by
>>> "another
Re: ejb pool stays at 20 threads?
On Sep 29, 2009, at 7:23 AM, Russell Collins wrote:
When will Geronimo 2.2 be released?
I was hoping for last week :-)
What's left:
make sure latest openejb works and release it (no code changes
expected)
confirm small problems in activemq are fixed and release it ("any day
now", they say)
confirm recent tranql changes are working ok and release it (not sure
if we've located a jdbc expert to review our list of non-fatal
SQLCodes. What we have is an improvement, so we can release it if we
can't find an expert)
mark all the open 2.2 jira issues "wish list" unless someone fixes
them real quick.
check the legal goo.
start trying to build a release.
So, I hope next week we'll be able to vote.
thanks
david jencks
Russell Collins
Sr. Software Engineer
McLane Advanced Technology
"Do or do not, there is no try." - Yoda
-Original Message-
From: David Blevins [mailto:david.blev...@visi.com]
Sent: Monday, September 28, 2009 3:05 PM
To: user@geronimo.apache.org
Subject: Re: ejb pool stays at 20 threads?
Hi Eric,
The PoolSize number you adjusted is for the stateless container and
affects the number of stateless bean instances we will instantiate and
keep ready for method invocations. You want to adjust the
EJBNetworkService 'threads' attribute as shown below:
On Sep 19, 2009, at 11:04 AM, ericp56 wrote:
from config.xml:
${OpenEJBPort + PortOffset}
${ServerHostname}
100
PoolSize=100
StrictPooling=true
And just as a general note, the performance of the remote client code
in the coming Geronimo 2.2 is *way* faster. If you're able to
upgrade, I'd check it out.
-David
Re: How does the Client Container work?
As you have discovered, app client containers are not very thoroughly specified. And as various pieces of documentation indicate, ours currently works only on the same machine as the server and there may be problems extracting just the bits you need to run an app client. However I still think that the problems of extracting a minimal client assembly and configuring it to talk to a remote server are pretty easy to solve. I'm not very familiar with jnlp but wonder just how suitable it would be for this in geronimo. Geronimo tends to have a lot of small jar files and various configuration files arranged in a particular directory structure (that it maintains) and that are related through geronimo classloaders. My understanding of jnlp is that it is more oriented towards downloading plain jar files that are maintained by the jnlp infrastructure. I would think that the most convenient way to get a geronimo app client would be to generate a client assembly, package it, download it, and unpack it in a suitable location on the client machine. I don't know if something like this is practical with jnlp. I guess it might be possible to do something like putting the entire server in a jar and write more classloaders to access everything from inside the jar. I think ClassWorlds tries to do this but all my attempts in this line haven't worked very well. thanks david jencks On Sep 29, 2009, at 3:31 AM, Quintin Beukes wrote: Interesting thing though. At the end of the spec it says: EE.12.1 JNLP (JavaTM Web Start) The Java Network Launch Protocol defines a mechanism for deploying Java applications on a server and launching them from a client. A future version of this specification may require that Java EE products be able to deploy application clients in a way that allows them to be launched by a JNLP client, and that application client containers be able to launch application clients deployed using the JNLP technology. JavaTM Web Start is the reference implementation of a JNLP client. More information on JNLP is available at http://jcp.org/en/jsr/ detail?id=056; more information on Java Web Start is available at http:// java.sun.com/products/javawebstart. Quintin Beukes On Tue, Sep 29, 2009 at 12:24 PM, Quintin Beukes > wrote: Hey, If you go read the JavaEE 5.0 spec regarding Application Clients, they do specify the following: As with all Java EE components, application clients use JNDI to look up enterprise beans, get access to resource managers, reference configurable parameters set at deployment time, and so on. Application clients use the java: JNDI namespace to access these items (see Chapter EE.5, “Resources, Naming, and Injection” for details). That is the closest they get to "remote". They do mention that the method of deployment/installation on a client is implementation specific, and it doesn't matter how they do it. So I guess my explanation is suitable for Geronimo, and Geronimo is on spec. It provides the authentication, and it is possible to do authentication against a remote server by configuring the security realm as such. Then you setup your server and deploy your application client. Further, any remote EJBs would be declared and defined as such, and there you have your fully JavaEE on-spec application client. If you think about it, this is a very logical design. Try and think of an application client as any other EJB jar. Have you ever asked yourself how to deploy an EJB jar in one server but have it wrapped by "another server"? The name "Application Client" sort of makes one feel this is a given, but it's misunderstood. Other application servers do provide this facility, and it would definitely be a nice-to-have. Though it's not a much used feature, and spending resources on other things is probably more important. After all, it's not impossible to achieve remoting. You just need to do it like you would with any other JavaEE component. Finally, I think the biggest motivation for an application client in the spec was for the same reasons as providing web based applications. A web based app is a UI into your application back ends. Just like this an application client is a UI into your application back ends. Both of them run inside a container, and uses whatever methods is available to access those back ends. The spec does specify security in the container is a requirement, so this helps out a bit with having the client be "very standalone". Quintin Beukes On Tue, Sep 29, 2009 at 11:56 AM, Quintin Beukes > wrote: I posted a link to the book on a new thread. Quintin Beukes On Tue, Sep 29, 2009 at 11:46 AM, Quintin Beukes > wrote: Then further, a book written by IBM states: With WASCE, the following considerations apply: Unlike other Java EE application servers, WASCE does not provide a unique Application Client container. Instead, you must install the full server package
Re: Geronimo Book
Quintin Beukes wrote: Hey, For anyone interested, this book together with the docs, help me a lot these days: http://www.redbooks.ibm.com/abstracts/SG247639.html I haven't seen it linked on the Geronimo docs (compared to Aaron Mulder's book which is linked there). Quintin Beukes Quintin, This is the WebSphere Community Edition 2.1 redbook but it is a really great resource for Geronimo users. WAS CE 2.1.1.3 is built from Geronimo 2.1.4 + some additional patches from Geronimo trunk. Significant differences between CE and G: a) Logos on in the admin console changed from 'Geronimo' to 'CE' b) CE uses Tomcat/Axis (rather than Jetty/CXF). In other words, not much technical difference. If you're the guy carrying the pager, you will also appreciate that an annually renewable IBM support contract for CE gives you access to stable service stream support (access to critical security/bug fixes w/o a bunch of new stuff creeping in that could destabilize your production environment). CE service streams last 3 years and can be extended on request. Some other resources... a) Most of the CE documentation is developed and generated directly from the Geronimo wiki pages... collected into the usual IBM format and translated into multiple languages: http://publib.boulder.ibm.com/wasce/Front_en.html b) There's a Websphere community edition forum on IBM Developerworks that can be useful: http://www.ibm.com/developerworks/forums/forum.jspa?forumID=541 c) The WAS CE team also maintains a 'CHANGES' file with each CE release. If you are familiar with the CHANGES file maintained by Apache HTTP Server project (http://www.apache.org/dist/httpd/CHANGES_2.2.13) the CE CHANGES file should not look too foreign. http://publib.boulder.ibm.com/wasce/changes/2113/CHANGES.txt d) wasce.org (redirects to an IBM devworks space) - various stuff I maintain. Want to see something here, let me know. Bill
RE: ejb pool stays at 20 threads?
When will Geronimo 2.2 be released?
Russell Collins
Sr. Software Engineer
McLane Advanced Technology
"Do or do not, there is no try." - Yoda
-Original Message-
From: David Blevins [mailto:david.blev...@visi.com]
Sent: Monday, September 28, 2009 3:05 PM
To: user@geronimo.apache.org
Subject: Re: ejb pool stays at 20 threads?
Hi Eric,
The PoolSize number you adjusted is for the stateless container and
affects the number of stateless bean instances we will instantiate and
keep ready for method invocations. You want to adjust the
EJBNetworkService 'threads' attribute as shown below:
On Sep 19, 2009, at 11:04 AM, ericp56 wrote:
>
> from config.xml:
>
>
>
>${OpenEJBPort + PortOffset} attribute>
>${ServerHostname}
100
>
>
>
> PoolSize=100
> StrictPooling=true
>
>
>
And just as a general note, the performance of the remote client code
in the coming Geronimo 2.2 is *way* faster. If you're able to
upgrade, I'd check it out.
-David
Re: How does the Client Container work?
Interesting thing though. At the end of the spec it says: EE.12.1 JNLP (JavaTM Web Start) The Java Network Launch Protocol defines a mechanism for deploying Java applications on a server and launching them from a client. A future version of this specification may require that Java EE products be able to deploy application clients in a way that allows them to be launched by a JNLP client, and that application client containers be able to launch application clients deployed using the JNLP technology. JavaTM Web Start is the reference implementation of a JNLP client. More information on JNLP is available at http://jcp.org/en/jsr/ detail?id=056; more information on Java Web Start is available at http:// java.sun.com/products/javawebstart. Quintin Beukes On Tue, Sep 29, 2009 at 12:24 PM, Quintin Beukes wrote: > Hey, > > If you go read the JavaEE 5.0 spec regarding Application Clients, they > do specify the following: > As with all Java EE components, application clients use JNDI to look > up enterprise > beans, get access to resource managers, reference configurable parameters set > at > deployment time, and so on. Application clients use the java: JNDI namespace > to > access these items (see Chapter EE.5, “Resources, Naming, and Injection” for > details). > > That is the closest they get to "remote". They do mention that the > method of deployment/installation on a client is implementation > specific, and it doesn't matter how they do it. So I guess my > explanation is suitable for Geronimo, and Geronimo is on spec. > > It provides the authentication, and it is possible to do > authentication against a remote server by configuring the security > realm as such. > > Then you setup your server and deploy your application client. > Further, any remote EJBs would be declared and defined as such, and > there you have your fully JavaEE on-spec application client. > > If you think about it, this is a very logical design. Try and think of > an application client as any other EJB jar. Have you ever asked > yourself how to deploy an EJB jar in one server but have it wrapped by > "another server"? The name "Application Client" sort of makes one feel > this is a given, but it's misunderstood. Other application servers do > provide this facility, and it would definitely be a nice-to-have. > > Though it's not a much used feature, and spending resources on other > things is probably more important. After all, it's not impossible to > achieve remoting. You just need to do it like you would with any other > JavaEE component. > > Finally, I think the biggest motivation for an application client in > the spec was for the same reasons as providing web based applications. > A web based app is a UI into your application back ends. Just like > this an application client is a UI into your application back ends. > Both of them run inside a container, and uses whatever methods is > available to access those back ends. The spec does specify security in > the container is a requirement, so this helps out a bit with having > the client be "very standalone". > > Quintin Beukes > > > > On Tue, Sep 29, 2009 at 11:56 AM, Quintin Beukes > wrote: >> I posted a link to the book on a new thread. >> Quintin Beukes >> >> >> >> On Tue, Sep 29, 2009 at 11:46 AM, Quintin Beukes >> wrote: >>> Then further, a book written by IBM states: >>> >>> With WASCE, the following considerations apply: >>> Unlike other Java EE application servers, WASCE does not provide a unique >>> Application Client container. Instead, you must install the full >>> server package >>> if you want to run an application client. >>> This is compliant with the Java EE specification, which does not require >>> that >>> you provide a unique installation process for the Application >>> Client container >>> (the specification only requires that it exists). Also, because WASCE has >>> a >>> very small server footprint of around 150 MB, the net disk space >>> savings for a >>> special Application Client container most likely outweighs the >>> realized benefit >>> of disk space. >>> >>> It doesn't say you need to be on the same installation, but it does >>> say it needs to be deployed on a full installation. I did once try to >>> extra the client as a plugin, but failed to then install the plugin. I >>> think it's because the client is never really in a "started" state. >>> Maybe you can deploy the "server side" of the plugin? But on geronimo >>> it's 2 separate repo items. and you can't export them as a single >>> plugin. >>> >>> Further, I once tried running the appclient from a separate >>> installation, and all this achieved was port conflicts. >>> >>> From my struggles, this is what my conclusion was: >>> I don't think the application client was really meant to be a way for >>> remote clients to access the server, but rather for a local >>> application to gain the benefits of JavaEE. Any "remoting" has to >>> happen on the server layer, i
Re: How does the Client Container work?
Hey, If you go read the JavaEE 5.0 spec regarding Application Clients, they do specify the following: As with all Java EE components, application clients use JNDI to look up enterprise beans, get access to resource managers, reference configurable parameters set at deployment time, and so on. Application clients use the java: JNDI namespace to access these items (see Chapter EE.5, “Resources, Naming, and Injection” for details). That is the closest they get to "remote". They do mention that the method of deployment/installation on a client is implementation specific, and it doesn't matter how they do it. So I guess my explanation is suitable for Geronimo, and Geronimo is on spec. It provides the authentication, and it is possible to do authentication against a remote server by configuring the security realm as such. Then you setup your server and deploy your application client. Further, any remote EJBs would be declared and defined as such, and there you have your fully JavaEE on-spec application client. If you think about it, this is a very logical design. Try and think of an application client as any other EJB jar. Have you ever asked yourself how to deploy an EJB jar in one server but have it wrapped by "another server"? The name "Application Client" sort of makes one feel this is a given, but it's misunderstood. Other application servers do provide this facility, and it would definitely be a nice-to-have. Though it's not a much used feature, and spending resources on other things is probably more important. After all, it's not impossible to achieve remoting. You just need to do it like you would with any other JavaEE component. Finally, I think the biggest motivation for an application client in the spec was for the same reasons as providing web based applications. A web based app is a UI into your application back ends. Just like this an application client is a UI into your application back ends. Both of them run inside a container, and uses whatever methods is available to access those back ends. The spec does specify security in the container is a requirement, so this helps out a bit with having the client be "very standalone". Quintin Beukes On Tue, Sep 29, 2009 at 11:56 AM, Quintin Beukes wrote: > I posted a link to the book on a new thread. > Quintin Beukes > > > > On Tue, Sep 29, 2009 at 11:46 AM, Quintin Beukes > wrote: >> Then further, a book written by IBM states: >> >> With WASCE, the following considerations apply: >> Unlike other Java EE application servers, WASCE does not provide a unique >> Application Client container. Instead, you must install the full >> server package >> if you want to run an application client. >> This is compliant with the Java EE specification, which does not require >> that >> you provide a unique installation process for the Application >> Client container >> (the specification only requires that it exists). Also, because WASCE has a >> very small server footprint of around 150 MB, the net disk space >> savings for a >> special Application Client container most likely outweighs the >> realized benefit >> of disk space. >> >> It doesn't say you need to be on the same installation, but it does >> say it needs to be deployed on a full installation. I did once try to >> extra the client as a plugin, but failed to then install the plugin. I >> think it's because the client is never really in a "started" state. >> Maybe you can deploy the "server side" of the plugin? But on geronimo >> it's 2 separate repo items. and you can't export them as a single >> plugin. >> >> Further, I once tried running the appclient from a separate >> installation, and all this achieved was port conflicts. >> >> From my struggles, this is what my conclusion was: >> I don't think the application client was really meant to be a way for >> remote clients to access the server, but rather for a local >> application to gain the benefits of JavaEE. Any "remoting" has to >> happen on the server layer, inside EJBs and what not. >> >> So you would develop your thick application client which is linked to >> the EJBs in the server. This is why there are 2 components to the >> application client, the server and client component. The client >> component runs inside the thick application container, and works with >> the server components to create a JavaEE environment for it. It's not >> meant to directly communicate with remote EJBs as if being a remote >> client. >> >> So to summarise (i'm probably repeating myself a lot here - having >> difficulty in explaining this - hope you understand). You get 2 types >> of JavaEE clients, thin clients and thick clients. Thin clients are >> directly connected to the remote server via a remote InitialContext, >> using corba/ejbd. Thick clients run inside a JavaEE environment, and >> is connected to remote clients using traditional JavaEE "remoting" >> techniques, such as remote EJBs. This is done inside the EJB layer. >> The actual "
Geronimo Book
Hey, For anyone interested, this book together with the docs, help me a lot these days: http://www.redbooks.ibm.com/abstracts/SG247639.html I haven't seen it linked on the Geronimo docs (compared to Aaron Mulder's book which is linked there). Quintin Beukes
Re: How does the Client Container work?
I posted a link to the book on a new thread. Quintin Beukes On Tue, Sep 29, 2009 at 11:46 AM, Quintin Beukes wrote: > Then further, a book written by IBM states: > > With WASCE, the following considerations apply: > Unlike other Java EE application servers, WASCE does not provide a unique > Application Client container. Instead, you must install the full > server package > if you want to run an application client. > This is compliant with the Java EE specification, which does not require > that > you provide a unique installation process for the Application > Client container > (the specification only requires that it exists). Also, because WASCE has a > very small server footprint of around 150 MB, the net disk space > savings for a > special Application Client container most likely outweighs the > realized benefit > of disk space. > > It doesn't say you need to be on the same installation, but it does > say it needs to be deployed on a full installation. I did once try to > extra the client as a plugin, but failed to then install the plugin. I > think it's because the client is never really in a "started" state. > Maybe you can deploy the "server side" of the plugin? But on geronimo > it's 2 separate repo items. and you can't export them as a single > plugin. > > Further, I once tried running the appclient from a separate > installation, and all this achieved was port conflicts. > > From my struggles, this is what my conclusion was: > I don't think the application client was really meant to be a way for > remote clients to access the server, but rather for a local > application to gain the benefits of JavaEE. Any "remoting" has to > happen on the server layer, inside EJBs and what not. > > So you would develop your thick application client which is linked to > the EJBs in the server. This is why there are 2 components to the > application client, the server and client component. The client > component runs inside the thick application container, and works with > the server components to create a JavaEE environment for it. It's not > meant to directly communicate with remote EJBs as if being a remote > client. > > So to summarise (i'm probably repeating myself a lot here - having > difficulty in explaining this - hope you understand). You get 2 types > of JavaEE clients, thin clients and thick clients. Thin clients are > directly connected to the remote server via a remote InitialContext, > using corba/ejbd. Thick clients run inside a JavaEE environment, and > is connected to remote clients using traditional JavaEE "remoting" > techniques, such as remote EJBs. This is done inside the EJB layer. > The actual "application client" part is purely for wrapping the > application's parts inside the EE container. > > Quintin Beukes > > > > On Tue, Sep 29, 2009 at 11:31 AM, Quintin Beukes > wrote: >> There is a book Apache Geronimo Development and Deployment by Aaron Mulder >> >> It states: >> As of Milestone 4, the client container must run from the same >> Geronimo installation as the server, >> which also means that it must be run on the same machine, using the >> bin/client.jar file in the >> server's Geronimo directory. The command line to start a J2EE >> application client looks like this: >> java -jar bin/client.jar ConfigName [arg1] [arg2] [arg3] ... >> >> I found the same problems with this, which is why I eventually ended >> up building my own client framework using Spring. It's not as dynamic, >> but I get similar features (ie. dependency injection, security, etc.). >> >> Quintin Beukes >> >> >> >> On Tue, Sep 29, 2009 at 9:17 AM, David Jencks wrote: >>> >>> On Sep 28, 2009, at 11:45 PM, Juergen Weber wrote: >>> OK, thanks, so that is consistent to the way Weblogic server does it, you http://download.oracle.com/docs/cd/E12840_01/wls/docs103/client/thinclient.html#wp1079680 start the Weblogic client container which then starts your client application. The Geronimo Wiki says: You can run the Application Client with this command: %GERONIMO_HOME%/bin/client JEE5/EXAMPLEClient/2.1/car But how do you run the client container from a remote machine where there is no Geronimo installation? client -h shows no way to argument a Geronimo location. >>> >>> So far no one has shown enough interest in app client containers to set this >>> up well. I think that you can use the "extract a server" feature to create >>> a geronimo assembly that contains your app client plugin and everything >>> needed to run it. You could then unpack this on the remote client machine. >>> This part should be easy to try out and any problems would most likely be >>> minor bugs in dependencies in geronimo plugins. This ought to work right >>> now. >>> >>> However, IIRC the last time I looked there was no obvious way to configure >>> the app client with the server IP address (or port), so it would really only >>> run on the sam
Re: How does the Client Container work?
Then further, a book written by IBM states: With WASCE, the following considerations apply: Unlike other Java EE application servers, WASCE does not provide a unique Application Client container. Instead, you must install the full server package if you want to run an application client. This is compliant with the Java EE specification, which does not require that you provide a unique installation process for the Application Client container (the specification only requires that it exists). Also, because WASCE has a very small server footprint of around 150 MB, the net disk space savings for a special Application Client container most likely outweighs the realized benefit of disk space. It doesn't say you need to be on the same installation, but it does say it needs to be deployed on a full installation. I did once try to extra the client as a plugin, but failed to then install the plugin. I think it's because the client is never really in a "started" state. Maybe you can deploy the "server side" of the plugin? But on geronimo it's 2 separate repo items. and you can't export them as a single plugin. Further, I once tried running the appclient from a separate installation, and all this achieved was port conflicts. >From my struggles, this is what my conclusion was: I don't think the application client was really meant to be a way for remote clients to access the server, but rather for a local application to gain the benefits of JavaEE. Any "remoting" has to happen on the server layer, inside EJBs and what not. So you would develop your thick application client which is linked to the EJBs in the server. This is why there are 2 components to the application client, the server and client component. The client component runs inside the thick application container, and works with the server components to create a JavaEE environment for it. It's not meant to directly communicate with remote EJBs as if being a remote client. So to summarise (i'm probably repeating myself a lot here - having difficulty in explaining this - hope you understand). You get 2 types of JavaEE clients, thin clients and thick clients. Thin clients are directly connected to the remote server via a remote InitialContext, using corba/ejbd. Thick clients run inside a JavaEE environment, and is connected to remote clients using traditional JavaEE "remoting" techniques, such as remote EJBs. This is done inside the EJB layer. The actual "application client" part is purely for wrapping the application's parts inside the EE container. Quintin Beukes On Tue, Sep 29, 2009 at 11:31 AM, Quintin Beukes wrote: > There is a book Apache Geronimo Development and Deployment by Aaron Mulder > > It states: > As of Milestone 4, the client container must run from the same > Geronimo installation as the server, > which also means that it must be run on the same machine, using the > bin/client.jar file in the > server's Geronimo directory. The command line to start a J2EE > application client looks like this: > java -jar bin/client.jar ConfigName [arg1] [arg2] [arg3] ... > > I found the same problems with this, which is why I eventually ended > up building my own client framework using Spring. It's not as dynamic, > but I get similar features (ie. dependency injection, security, etc.). > > Quintin Beukes > > > > On Tue, Sep 29, 2009 at 9:17 AM, David Jencks wrote: >> >> On Sep 28, 2009, at 11:45 PM, Juergen Weber wrote: >> >>> >>> OK, thanks, so that is consistent to the way Weblogic server does it, you >>> >>> http://download.oracle.com/docs/cd/E12840_01/wls/docs103/client/thinclient.html#wp1079680 >>> start the Weblogic client container which then starts your client >>> application. >>> >>> The Geronimo Wiki says: >>> You can run the Application Client with this command: >>> >>> %GERONIMO_HOME%/bin/client JEE5/EXAMPLEClient/2.1/car >>> >>> But how do you run the client container from a remote machine where there >>> is >>> no Geronimo installation? >>> >>> client -h shows no way to argument a Geronimo location. >> >> So far no one has shown enough interest in app client containers to set this >> up well. I think that you can use the "extract a server" feature to create >> a geronimo assembly that contains your app client plugin and everything >> needed to run it. You could then unpack this on the remote client machine. >> This part should be easy to try out and any problems would most likely be >> minor bugs in dependencies in geronimo plugins. This ought to work right >> now. >> >> However, IIRC the last time I looked there was no obvious way to configure >> the app client with the server IP address (or port), so it would really only >> run on the same machine as the server. I think this would be an easy thing >> to change, and I think the code would be somewhere in geronimo-client. I'm >> not sure what a good way to _tell_ the app client where the server is might >> be. Any ideas? >> >> thanks >> david jencks >> >
Re: How does the Client Container work?
I opened https://issues.apache.org/jira/browse/GERONIMO-4899. Thanks, Juergen -- View this message in context: http://www.nabble.com/How-does-the-Client-Container-work--tp25632603s134p25659838.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: How does the Client Container work?
There is a book Apache Geronimo Development and Deployment by Aaron Mulder It states: As of Milestone 4, the client container must run from the same Geronimo installation as the server, which also means that it must be run on the same machine, using the bin/client.jar file in the server's Geronimo directory. The command line to start a J2EE application client looks like this: java -jar bin/client.jar ConfigName [arg1] [arg2] [arg3] ... I found the same problems with this, which is why I eventually ended up building my own client framework using Spring. It's not as dynamic, but I get similar features (ie. dependency injection, security, etc.). Quintin Beukes On Tue, Sep 29, 2009 at 9:17 AM, David Jencks wrote: > > On Sep 28, 2009, at 11:45 PM, Juergen Weber wrote: > >> >> OK, thanks, so that is consistent to the way Weblogic server does it, you >> >> http://download.oracle.com/docs/cd/E12840_01/wls/docs103/client/thinclient.html#wp1079680 >> start the Weblogic client container which then starts your client >> application. >> >> The Geronimo Wiki says: >> You can run the Application Client with this command: >> >> %GERONIMO_HOME%/bin/client JEE5/EXAMPLEClient/2.1/car >> >> But how do you run the client container from a remote machine where there >> is >> no Geronimo installation? >> >> client -h shows no way to argument a Geronimo location. > > So far no one has shown enough interest in app client containers to set this > up well. I think that you can use the "extract a server" feature to create > a geronimo assembly that contains your app client plugin and everything > needed to run it. You could then unpack this on the remote client machine. > This part should be easy to try out and any problems would most likely be > minor bugs in dependencies in geronimo plugins. This ought to work right > now. > > However, IIRC the last time I looked there was no obvious way to configure > the app client with the server IP address (or port), so it would really only > run on the same machine as the server. I think this would be an easy thing > to change, and I think the code would be somewhere in geronimo-client. I'm > not sure what a good way to _tell_ the app client where the server is might > be. Any ideas? > > thanks > david jencks > >> >> Thanks, >> Juergen >> >> >> David Blevins wrote: >>> >>> >>> Right. You boot the app client container from the command line, the >>> app client container does all the work to setup the environment, >>> injects the required things into your main class, then calls your main >>> method. >>> >>> For all intense purposes the app client is really like a mini-server >>> with a little Geronimo kernel and everything. >>> >>> -David >>> >>> >>> >> >> -- >> View this message in context: >> http://www.nabble.com/How-does-the-Client-Container-work--tp25632603s134p25657764.html >> Sent from the Apache Geronimo - Users mailing list archive at Nabble.com. >> > >
Re: How does the Client Container work?
On Sep 28, 2009, at 11:45 PM, Juergen Weber wrote: OK, thanks, so that is consistent to the way Weblogic server does it, you http://download.oracle.com/docs/cd/E12840_01/wls/docs103/client/thinclient.html#wp1079680 start the Weblogic client container which then starts your client application. The Geronimo Wiki says: You can run the Application Client with this command: %GERONIMO_HOME%/bin/client JEE5/EXAMPLEClient/2.1/car But how do you run the client container from a remote machine where there is no Geronimo installation? client -h shows no way to argument a Geronimo location. So far no one has shown enough interest in app client containers to set this up well. I think that you can use the "extract a server" feature to create a geronimo assembly that contains your app client plugin and everything needed to run it. You could then unpack this on the remote client machine. This part should be easy to try out and any problems would most likely be minor bugs in dependencies in geronimo plugins. This ought to work right now. However, IIRC the last time I looked there was no obvious way to configure the app client with the server IP address (or port), so it would really only run on the same machine as the server. I think this would be an easy thing to change, and I think the code would be somewhere in geronimo-client. I'm not sure what a good way to _tell_ the app client where the server is might be. Any ideas? thanks david jencks Thanks, Juergen David Blevins wrote: Right. You boot the app client container from the command line, the app client container does all the work to setup the environment, injects the required things into your main class, then calls your main method. For all intense purposes the app client is really like a mini-server with a little Geronimo kernel and everything. -David -- View this message in context: http://www.nabble.com/How-does-the-Client-Container-work--tp25632603s134p25657764.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
