Placing JARs in the lib/ext directory is dangerous. I'd recommend
placing application library JARs in the app itself, or using the --
library deploy option.
If the JAR is a JDBC driver (more an extension to GlassFish than to
the application), you can place it in the glassfish install or domain
lib/ directory (not lib/ext).
Which GlassFish v3 version precisely are you using?
-Alexis
On Aug 12, 2009, at 10:08, glassfish_at_javadesktop.org wrote:
> Hello Glassfish Team,
>
> I have set up the Glassfih v3 server on my development machine and
> it is working fine. The development machine is Windows XP SP2 with
> Java 1.6 update 4. Everything works fine on the development machine,
> database connectivity, virtual directory (mapping to a directory
> outside of the server), etc.
>
> Now, we have decided to migrate the Tomcat 6 on the production
> server to Glassfish v3. Now the problem is after doing a clean
> install and creating a service for Glassfish the admin console does
> not wants to load. At first it shows the admin console is being
> loaded then it gives a 404 error. On doing a refresh 1-2 times the
> admin console loaded on the fresh install. Then I created a
> connection pool to connect to Oracle, after which a restart of the
> server was required. After restarting the server I again received
> the 404 error. Now,.refreshing the page does not loads the admin
> console as well. I have tried to reinstall the server on the machine
> but the problem is still there. The server runs on Windows Server
> 2000 SP4 with Java 1.6 update 14. I had even copied all the jars
> required by the app into the lib/ext directory.
>
> The error that I received in the server.log file for the domain is
> as below:
> [#|2009-08-12T12:50:03.312+0530|WARNING|glassfish|
> com.sun.grizzly.config.GrizzlyServiceListener|
> _ThreadID=16;_ThreadName=Thread-1;|Invalid URL: /
> java.lang.ClassCastException:
> org.apache.catalina.core.StandardWrapper cannot be cast to
> com.sun.enterprise.v3.services.impl.ContainerMapper$ContextRootInfo
> at
> com
> .sun
> .enterprise
> .v3.services.impl.ContainerMapper.map(ContainerMapper.java:267)
> at
> com
> .sun
> .enterprise
> .v3.services.impl.ContainerMapper.service(ContainerMapper.java:171)
> at
> com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:
> 746)
> at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:
> 655)
> at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:905)
> at
> com
> .sun
> .grizzly
> .http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:161)
> at
> com
> .sun
> .grizzly
> .DefaultProtocolChain
> .executeProtocolFilter(DefaultProtocolChain.java:136)
> at
> com
> .sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:
> 103)
> at
> com
> .sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:
> 89)
> at
> com
> .sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
> at
> com
> .sun
> .grizzly
> .ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
> at
> com
> .sun
> .grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
> at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
> at java.util.concurrent.ThreadPoolExecutor
> $Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor
> $Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)
> |#]
>
> Everything works on the development machine and I was looking
> forward to shift to Glassfish which is a J2EE server from Sun. I had
> even tried Apache Geronimo / IBM Websphere Community Edition before
> deciding to switch over to Glassfish. Glassfish appeared to be a
> better option. Please advise.
> [Message sent by forum member 'harkiran' (harkiran)]
>
> http://forums.java.net/jive/thread.jspa?messageID=360028
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>