Re: Weekly: Geronimo 1.2-r465304
On Oct 18, 2006, at 6:59 PM, Kevan Miller wrote: On Oct 18, 2006, at 5:19 PM, Dain Sundstrom wrote: Geronimo 1.2-r465304 - Oct 18, 2006 http://people.apache.org/dist/geronimo/unstable/1.2-r465304/ ... NOTE: This build is not an official release, nor tested, and should be considered unstable. Dain, The jetty-j2ee server does not start for me. Does it work for you? I test started all of the binaries before uploading, but I'll download geronimo-jetty-j2ee-1.2-r465304.tar.gz and try to start it. -dain
Re: Weekly: Geronimo 1.2-r465304
On Oct 19, 2006, at 9:22 AM, Dain Sundstrom wrote: On Oct 18, 2006, at 6:59 PM, Kevan Miller wrote: On Oct 18, 2006, at 5:19 PM, Dain Sundstrom wrote: Geronimo 1.2-r465304 - Oct 18, 2006 http://people.apache.org/dist/geronimo/unstable/1.2-r465304/ ... NOTE: This build is not an official release, nor tested, and should be considered unstable. Dain, The jetty-j2ee server does not start for me. Does it work for you? I test started all of the binaries before uploading, but I'll download geronimo-jetty-j2ee-1.2-r465304.tar.gz and try to start it. It works for me on my mac: $ wget http://people.apache.org/dist/geronimo/unstable/1.2-r465304/ geronimo-jetty-j2ee-1.2-r465304.tar.gz 09:22:36 (528.97 KB/s) - `geronimo-jetty-j2ee-1.2-r465304.tar.gz' saved [49455963/49455963] $ tar -zxf geronimo-jetty-j2ee-1.2-r465304.tar.gz tar: A lone zero block at 122798 $ java -jar geronimo-jetty-j2ee-1.2-r465304/bin/server.jar [] 100% 42s Startup complete Geronimo Application Server started -dain
Re: Weekly: Geronimo 1.2-r465304
In 1.1.1, the majority of the startup delay is in the console module. Dain suggested it's because we precompile the JSPs, so each one becomes a servlet, so each one becomes a GBean, and starting GBeans is what's slow. I found it hard to believe they're *that* slow, but I don't have any factual basis for disputing the claim... :) In any case, it would be great to investigate and optimize the startup time, or maybe introduce an option for a module that would kick it's startup into a background task or something. Thanks, Aaron On 10/19/06, Guillaume Nodet [EMAIL PROTECTED] wrote: On my windows box, it takes roughtly one minute and a half. It seems that it spends at least 30 seconds stucked at 85% ... On 10/19/06, Kevan Miller [EMAIL PROTECTED] wrote: On Oct 19, 2006, at 12:26 PM, Dain Sundstrom wrote: On Oct 19, 2006, at 9:22 AM, Dain Sundstrom wrote: It works for me on my mac: $ wget http://people.apache.org/dist/geronimo/unstable/1.2-r465304/ geronimo-jetty-j2ee-1.2-r465304.tar.gz 09:22:36 (528.97 KB/s) - `geronimo-jetty-j2ee-1.2-r465304.tar.gz' saved [49455963/49455963] $ tar -zxf geronimo-jetty-j2ee-1.2-r465304.tar.gz tar: A lone zero block at 122798 $ java -jar geronimo-jetty-j2ee-1.2-r465304/bin/server.jar [] 100% 42s Startup complete Ah. I was using a 1.4 JRE. I switched to 1.5 and it starts OK. Wow. Startup time is way slower than 1.1.1. Starting the webconsole config took over 30 seconds. Anybody know what's going on? --kevan -- Cheers, Guillaume Nodet
VTD-XML 1.7 released
Version 1.7 of VTD-XML, the next generation XML parser that goes beyond DOM and SAX, under GPL. VTD-XML is getting faster, leaner, more stable and complete with this release. Please visit http://vtd-xml.sf.net for the latest release. For further reading, please refer to the following articles:For further reading, please refer to the following articles: Simplify XML Processing with VTD-XMLhttp://www.javaworld.com/javaworld/jw-03-2006/jw-0327-simplify.htmlCut, Paste, Assemble and Split XML files with VTD-XMLhttp://www.javaworld.com/javaworld/jw-07-2006/jw-0724-vtdxml.htmlXML on a Chiphttp://www.xml.com/pub/a/2005/03/09/chip.htmlProcess Large XML Files with VTD-XMLhttp://www.devx.com/xml/Article/30484The performance Woe of Binary XMLhttp://webservices.sys-con.com/read/250512.htmVTD-XML: The Next Generation XML Parserhttp://www.thedelphimagazine.com/conts/conts132.php
Re: Webapps exposed on distinct ports
Hi Mark, thanks for bringing this up. I also noted the sample is not working and I'm working on it to fix it. Not sure why it's failing now so I could use some help too. Cheers! Hernan Mark Bradley wrote: I'm still stuck on this, and unfortunately I cannot deploy my applications in production with Geronimo until I get this working. Has anyone been able to deploy two different applications to two different tomcat connectors in the same Geronimo instance? As shown below, the example on the wiki does not work! Thanks, -Mark Well, I thought that I might be able to take the example in wiki (http://cwiki.apache.org/GMOxDOC11/exposing-web-applications-on- distinct-ports.html) and whittle it down to what I need, but I can't even deploy the example .ear( appPerPort.ear). I get this error: geronimo-1.1.1% java -jar bin/deployer.jar deploy appPerPort.ear Error: Unable to distribute appPerPort.ear: Cannot deploy the requested application module because no deployer is able to handle it. This can happen if you have omitted the J2EE deployment descriptor, disabled a deployer module, or if, for example, you are trying to deploy an EJB module on a minimal Geronimo server that does not have EJB support installed. (moduleFile=/Users/mark/Programs/geronimo-1.1.1/var/temp/ geronimo-deployer4506.tmpdir/appPerPort.ear) and here is the stack trace in the log: Deployer operation failed: Cannot deploy the requested application module because no deployer is able to handle it. This can happen if you have omitted the J2EE deployment descriptor, disabled a deployer module, or if, for example, you are trying to deploy an EJB module on a minimal Geronimo server that does not have EJB support installed. (moduleFile=/Users/mark/Programs/geronimo-1.1.1/var/temp/geronimo- deployer4504.tmpdir/appperport.ear) org.apache.geronimo.common.DeploymentException: Cannot deploy the requested application module because no deployer is able to handle it. This can happen if you have omitted the J2EE deployment descriptor, disabled a deployer module, or if, for example, you are trying to deploy an EJB module on a minimal Geronimo server that does not have EJB support installed. (moduleFile=/Users/mark/Programs/ geronimo-1.1.1/var/temp/geronimo-deployer4504.tmpdir/appperport.ear) at org.apache.geronimo.deployment.Deployer.deploy (Deployer.java:239) at org.apache.geronimo.deployment.Deployer.deploy (Deployer.java:124) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$ $734a235d.invoke(generated) 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:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke (BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDepl oy(AbstractDeployCommand.java:106) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run (DistributeCommand.java:60) at java.lang.Thread.run(Thread.java:613) Any ideas?
Re: Weekly: Geronimo 1.2-r465304
On Oct 19, 2006, at 11:27 AM, Aaron Mulder wrote: In 1.1.1, the majority of the startup delay is in the console module. Dain suggested it's because we precompile the JSPs, so each one becomes a servlet, so each one becomes a GBean, and starting GBeans is what's slow. I found it hard to believe they're *that* slow, but I don't have any factual basis for disputing the claim... :) In any case, it would be great to investigate and optimize the startup time, or maybe introduce an option for a module that would kick it's startup into a background task or something. I've timed it before. Starting each gbean takes a very very long time. I'd also guess that as you add more gbeans it gets slower. If I had to bet, I'd blame AbstractName and AbstractNameQuery. When we used object names we indexed the names so queries were faster, and now we do a liner compare for each life-cycle event fired. -dain
Re: Weekly: Geronimo 1.2-r465304
On Oct 19, 2006, at 2:27 PM, Aaron Mulder wrote: In 1.1.1, the majority of the startup delay is in the console module. Dain suggested it's because we precompile the JSPs, so each one becomes a servlet, so each one becomes a GBean, and starting GBeans is what's slow. I found it hard to believe they're *that* slow, but I don't have any factual basis for disputing the claim... :) In any case, it would be great to investigate and optimize the startup time, or maybe introduce an option for a module that would kick it's startup into a background task or something. Agreed that some optimization would be nice. However, this isn't really a case of optimization, I think. Something has changed quite drastically between 1.1.1 and 1.2-SNAPSHOT. We've more than doubled our startup time... --kevan
Re: Weekly: Geronimo 1.2-r465304
On Oct 19, 2006, at 12:22 PM, Kevan Miller wrote: On Oct 19, 2006, at 2:01 PM, Dain Sundstrom wrote: I'm using Java 1.4.2_09. Me too. :-) 'java -jar server.jar' on 1.4.2 works for me. './geronimo.sh run' on 1.4.2 does not work for me './geronimo.sh run' on 1.5 works for me. geronimo.sh run works for me in Java 1.4 $ geronimo-jetty-j2ee-1.2-r465304/bin/geronimo.sh run Using GERONIMO_BASE: /Users/dain/t/geronimo-jetty-j2ee-1.2-r465304 Using GERONIMO_HOME: /Users/dain/t/geronimo-jetty-j2ee-1.2-r465304 Using GERONIMO_TMPDIR: /Users/dain/t/geronimo-jetty-j2ee-1.2-r465304/ var/temp Using JRE_HOME:/System/Library/Frameworks/JavaVM.framework/ Versions/CurrentJDK/Home Booting Geronimo Kernel (in Java 1.4.2_09)... Starting Geronimo Application Server v1.2-r465304 [] 100% 39s Startup complete -dain
Re: Weekly: Geronimo 1.2-r465304
On Oct 19, 2006, at 12:26 PM, Kevan Miller wrote: On Oct 19, 2006, at 2:27 PM, Aaron Mulder wrote: In 1.1.1, the majority of the startup delay is in the console module. Dain suggested it's because we precompile the JSPs, so each one becomes a servlet, so each one becomes a GBean, and starting GBeans is what's slow. I found it hard to believe they're *that* slow, but I don't have any factual basis for disputing the claim... :) In any case, it would be great to investigate and optimize the startup time, or maybe introduce an option for a module that would kick it's startup into a background task or something. Agreed that some optimization would be nice. However, this isn't really a case of optimization, I think. Something has changed quite drastically between 1.1.1 and 1.2-SNAPSHOT. We've more than doubled our startup time... My guess is we have doubled the number of jsp pages and thus the number of GBeans. -dain Here are the numbers from 1.2 jetty: Module 1/22 org.apache.geronimo.configs/rmi-naming/1.2-r465304/ car started in .274s Module 2/22 org.apache.geronimo.configs/j2ee-server/1.2-r465304/ car started in .143s Module 3/22 org.apache.geronimo.configs/transaction/1.2-r465304/ car started in .243s Module 4/22 org.apache.geronimo.configs/j2ee-security/1.2-r465304/ car started in .333s Module 5/22 org.apache.geronimo.configs/axis/1.2-r465304/ carstarted in .044s Module 6/22 org.apache.geronimo.configs/openejb/1.2-r465304/ car started in 1.785s Module 7/22 org.apache.geronimo.configs/system-database/1.2-r465304/ car started in .000s Module 9/22 org.apache.geronimo.configs/activemq/1.2-r465304/ carstarted in .239s Module 10/22 org.apache.geronimo.configs/jetty/1.2-r465304/ car started in .533s Module 11/22 org.apache.geronimo.configs/geronimo-gbean-deployer/1.2- r465304/car started in .183s Module 12/22 org.apache.geronimo.configs/j2ee-deployer/1.2-r465304/ car started in .203s Module 13/22 org.apache.geronimo.configs/connector-deployer/1.2- r465304/car started in .128s Module 14/22 org.apache.geronimo.configs/openejb-deployer/1.2-r465304/ carstarted in .302s Module 15/22 org.apache.geronimo.configs/client-deployer/1.2-r465304/ car started in .067s Module 16/22 org.apache.geronimo.configs/axis-deployer/1.2-r465304/ car started in .585s Module 17/22 org.apache.geronimo.configs/sharedlib/1.2-r465304/ car started in .007s Module 18/22 org.apache.geronimo.configs/jetty-deployer/1.2-r465304/ car started in .259s Module 19/22 org.apache.geronimo.configs/welcome-jetty/1.2-r465304/ car started in .452s Module 20/22 org.apache.geronimo.configs/webconsole-jetty/1.2-r465304/ carstarted in 27.210s Module 21/22 org.apache.geronimo.configs/remote-deploy-jetty/1.2- r465304/car started in .190s Module 22/22 org.apache.geronimo.configs/hot-deployer/1.2-r465304/ carstarted in .278s And from 1.1 jetty; Booting Geronimo Kernel (in Java 1.4.2_09)... Module 1/20 geronimo/rmi-naming/1.1.1/car started in . 206s Module 2/20 geronimo/j2ee-server/1.1.1/car started in . 350s Module 3/20 geronimo/j2ee-security/1.1.1/car started in . 339s Module 4/20 geronimo/axis/1.1.1/carstarted in . 049s Module 5/20 geronimo/openejb/1.1.1/car started in . 232s Module 6/20 geronimo/system-database/1.1.1/car started in 1.521s Module 7/20 geronimo/activemq-broker/1.1.1/car started in . 810s Module 8/20 geronimo/activemq/1.1.1/carstarted in . 218s Module 9/20 geronimo/jetty/1.1.1/car started in . 445s Module 10/20 geronimo/geronimo-gbean-deployer/1.1.1/car started in . 180s Module 11/20 geronimo/j2ee-deployer/1.1.1/car started in . 163s Module 12/20 geronimo/openejb-deployer/1.1.1/carstarted in . 187s Module 13/20 geronimo/client-deployer/1.1.1/car started in . 036s Module 14/20 geronimo/axis-deployer/1.1.1/car started in . 050s Module 15/20 geronimo/sharedlib/1.1.1/car started in . 005s Module 16/20 geronimo/jetty-deployer/1.1.1/car started in . 181s Module 17/20 geronimo/welcome-jetty/1.1.1/car started in . 441s Module 18/20 geronimo/webconsole-jetty/1.1.1/carstarted in 7.797s Module 19/20 geronimo/remote-deploy-jetty/1.1.1/car started in . 165s Module 20/20 geronimo/hot-deployer/1.1.1/carstarted in . 220s And tomcat 1.2 Module 1/22 org.apache.geronimo.configs/rmi-naming/1.2-r465304/ car started in .282s Module 2/22 org.apache.geronimo.configs/j2ee-server/1.2-r465304/ car started in .142s Module 3/22
Re: Weekly: Geronimo 1.2-r465304
On Oct 19, 2006, at 1:31 PM, Aaron Mulder wrote: Looking at the 1.2 results: webconsole-jetty in 27s and webconsole-tomcat in 5s That suggests GBeans aren't the whole problem... Actually that suggests gbeans are the problem since jetty has gbeans for each servlet, servlet filter, etc etc, whereas tomcat doesn't, just one that basically holds the web.xml. thanks david jencks Thanks, Aaron On 10/19/06, Dain Sundstrom [EMAIL PROTECTED] wrote: On Oct 19, 2006, at 12:26 PM, Kevan Miller wrote: On Oct 19, 2006, at 2:27 PM, Aaron Mulder wrote: In 1.1.1, the majority of the startup delay is in the console module. Dain suggested it's because we precompile the JSPs, so each one becomes a servlet, so each one becomes a GBean, and starting GBeans is what's slow. I found it hard to believe they're *that* slow, but I don't have any factual basis for disputing the claim... :) In any case, it would be great to investigate and optimize the startup time, or maybe introduce an option for a module that would kick it's startup into a background task or something. Agreed that some optimization would be nice. However, this isn't really a case of optimization, I think. Something has changed quite drastically between 1.1.1 and 1.2-SNAPSHOT. We've more than doubled our startup time... My guess is we have doubled the number of jsp pages and thus the number of GBeans. -dain Here are the numbers from 1.2 jetty: Module 1/22 org.apache.geronimo.configs/rmi-naming/1.2-r465304/ car started in .274s Module 2/22 org.apache.geronimo.configs/j2ee-server/1.2-r465304/ car started in .143s Module 3/22 org.apache.geronimo.configs/transaction/1.2-r465304/ car started in .243s Module 4/22 org.apache.geronimo.configs/j2ee-security/1.2-r465304/ car started in .333s Module 5/22 org.apache.geronimo.configs/axis/1.2-r465304/ carstarted in .044s Module 6/22 org.apache.geronimo.configs/openejb/1.2-r465304/ car started in 1.785s Module 7/22 org.apache.geronimo.configs/system-database/1.2-r465304/ car started in .000s Module 9/22 org.apache.geronimo.configs/activemq/1.2-r465304/ carstarted in .239s Module 10/22 org.apache.geronimo.configs/jetty/1.2-r465304/ car started in .533s Module 11/22 org.apache.geronimo.configs/geronimo-gbean-deployer/1.2- r465304/car started in .183s Module 12/22 org.apache.geronimo.configs/j2ee-deployer/1.2-r465304/ car started in .203s Module 13/22 org.apache.geronimo.configs/connector-deployer/1.2- r465304/car started in .128s Module 14/22 org.apache.geronimo.configs/openejb-deployer/1.2- r465304/ carstarted in .302s Module 15/22 org.apache.geronimo.configs/client-deployer/1.2-r465304/ car started in .067s Module 16/22 org.apache.geronimo.configs/axis-deployer/1.2-r465304/ car started in .585s Module 17/22 org.apache.geronimo.configs/sharedlib/1.2-r465304/ car started in .007s Module 18/22 org.apache.geronimo.configs/jetty-deployer/1.2-r465304/ car started in .259s Module 19/22 org.apache.geronimo.configs/welcome-jetty/1.2-r465304/ car started in .452s Module 20/22 org.apache.geronimo.configs/webconsole-jetty/1.2- r465304/ carstarted in 27.210s Module 21/22 org.apache.geronimo.configs/remote-deploy-jetty/1.2- r465304/car started in .190s Module 22/22 org.apache.geronimo.configs/hot-deployer/1.2-r465304/ carstarted in .278s And from 1.1 jetty; Booting Geronimo Kernel (in Java 1.4.2_09)... Module 1/20 geronimo/rmi-naming/1.1.1/car started in . 206s Module 2/20 geronimo/j2ee-server/1.1.1/car started in . 350s Module 3/20 geronimo/j2ee-security/1.1.1/car started in . 339s Module 4/20 geronimo/axis/1.1.1/carstarted in . 049s Module 5/20 geronimo/openejb/1.1.1/car started in . 232s Module 6/20 geronimo/system-database/1.1.1/car started in 1.521s Module 7/20 geronimo/activemq-broker/1.1.1/car started in . 810s Module 8/20 geronimo/activemq/1.1.1/carstarted in . 218s Module 9/20 geronimo/jetty/1.1.1/car started in . 445s Module 10/20 geronimo/geronimo-gbean-deployer/1.1.1/car started in . 180s Module 11/20 geronimo/j2ee-deployer/1.1.1/car started in . 163s Module 12/20 geronimo/openejb-deployer/1.1.1/carstarted in . 187s Module 13/20 geronimo/client-deployer/1.1.1/car started in . 036s Module 14/20 geronimo/axis-deployer/1.1.1/car started in . 050s Module 15/20 geronimo/sharedlib/1.1.1/car started in . 005s Module 16/20 geronimo/jetty-deployer/1.1.1/car started in . 181s Module 17/20 geronimo/welcome-jetty/1.1.1/car started in .
Re: Weekly: Geronimo 1.2-r465304
On 10/19/06, David Jencks [EMAIL PROTECTED] wrote: On Oct 19, 2006, at 1:31 PM, Aaron Mulder wrote: Looking at the 1.2 results: webconsole-jetty in 27s and webconsole-tomcat in 5s That suggests GBeans aren't the whole problem... Actually that suggests gbeans are the problem since jetty has gbeans for each servlet, servlet filter, etc etc, whereas tomcat doesn't, just one that basically holds the web.xml. Aha! I had forgotten that. Thanks, Aaron
Re: Webapps exposed on distinct ports
Hi Mark, I still haven't fixed the sample on the wiki and the workaround I found is not the definitive way to do it but may help you momentarily. This is a geronimo-web.xml I just successfully tested in Geronimo v1.1.1 with a single web application, I tried the HelloWorld sample. This plan defines a new virtual host, web container and a single web connector on port 8081. Since the virtual host is mapped to the same host name as the default host you are not seeing any particular benefit from the virtual host itself. This is not the prettiest way to configure it but it work for now ;-) I'll look for the right way to do it and then will update the sample on the wiki. ?xml version=1.0 encoding=UTF-8? web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-1.1; environment moduleId groupIdsamples.applications/groupId artifactIdHelloWorldApp/artifactId version1.1/version /moduleId /environment context-root/hello1/context-root web-container gbean-linkTomcatWebContainer1/gbean-link /web-container gbean name=TomcatWebConnector1 class=org.apache.geronimo.tomcat.ConnectorGBean attribute name=nameHTTP/attribute attribute name=hostlocalhost/attribute attribute name=port8081/attribute attribute name=maxHttpHeaderSizeBytes8192/attribute attribute name=maxThreads150/attribute attribute name=minSpareThreads25/attribute attribute name=maxSpareThreads75/attribute attribute name=hostLookupEnabledfalse/attribute attribute name=redirectPort8453/attribute attribute name=acceptQueueSize100/attribute attribute name=connectionTimeoutMillis2/attribute attribute name=uploadTimeoutEnabledfalse/attribute reference name=TomcatContainer nameTomcatWebContainer1/name /reference /gbean gbean name=TomcatWebContainer1 class=org.apache.geronimo.tomcat.TomcatContainer attribute name=catalinaHomevar/catalina/attribute reference name=EngineGBean nameTomcatEngine1/name /reference reference name=ServerInfo nameServerInfo/name /reference reference name=WebManager nameTomcatWebManager/name /reference /gbean gbean name=TomcatEngine1 class=org.apache.geronimo.tomcat.EngineGBean attribute name=classNameorg.apache.geronimo.tomcat.TomcatEngine/attribute attribute name=initParams name=Geronimo1 /attribute reference name=DefaultHost nameTomcatHost1/name /reference references name=Hosts pattern nameTomcatHost1/name /pattern /references reference name=RealmGBean nameTomcatJAASRealm/name /reference /gbean gbean name=TomcatHost1 class=org.apache.geronimo.tomcat.HostGBean attribute name=classNameorg.apache.catalina.core.StandardHost/attribute attribute name=initParams name=localhost appBase= workDir=work /attribute /gbean /web-app Cheers! Hernan Mark Bradley wrote: I'm still stuck on this, and unfortunately I cannot deploy my applications in production with Geronimo until I get this working. Has anyone been able to deploy two different applications to two different tomcat connectors in the same Geronimo instance? As shown below, the example on the wiki does not work! Thanks, -Mark Well, I thought that I might be able to take the example in wiki (http://cwiki.apache.org/GMOxDOC11/exposing-web-applications-on- distinct-ports.html) and whittle it down to what I need, but I can't even deploy the example .ear( appPerPort.ear). I get this error: geronimo-1.1.1% java -jar bin/deployer.jar deploy appPerPort.ear Error: Unable to distribute appPerPort.ear: Cannot deploy the requested application module because no deployer is able to handle it. This can happen if you have omitted the J2EE deployment descriptor, disabled a deployer module, or if, for example, you are trying to deploy an EJB module on a minimal Geronimo server that does not have EJB support installed. (moduleFile=/Users/mark/Programs/geronimo-1.1.1/var/temp/ geronimo-deployer4506.tmpdir/appPerPort.ear) and here is the stack trace in the log: Deployer operation failed: Cannot deploy the requested application module because no deployer is able to handle it. This can happen if you have omitted the J2EE deployment descriptor, disabled a deployer module, or if, for example, you are trying to deploy an EJB module on a minimal Geronimo server that does not have EJB support installed. (moduleFile=/Users/mark/Programs/geronimo-1.1.1/var/temp/geronimo- deployer4504.tmpdir/appperport.ear) org.apache.geronimo.common.DeploymentException: Cannot deploy the requested
Custom Login Module,Custom Callback handler
Hi all, I am trying to invoke my custom login module in a Servlet Filter. Logincontext lc = new logincontext(configname,mycallbackhandler). In the login module I try to case the callbackhandler to mycallbackhandler and it throws a class case exception. When I did some digging I found that the instance is of DecouplingCallbackHandler. Can someone please tell me how to work with Geronimo when I have customLoginModules and CustomCallbackhandlers? I have been stuck with this for quite sometime now. Appreciate your time. Thanks, Priya __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
