[JBoss-dev] [ jboss-Bugs-851138 ] OutOfMemory Exception after multiple RunXDoclet tasks
Bugs item #851138, was opened at 2003-11-29 15:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=851138group_id=22866 Category: JBoss-IDE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Costin (magudexter) Assigned to: Nobody/Anonymous (nobody) Summary: OutOfMemory Exception after multiple RunXDoclet tasks Initial Comment: Hi! This is my platform: OS: WinXP SP 1a VM: J2SDK 1.4.2_01-b06 Eclipse Version: 2.1.2 Build id: 200311030802 I've tried this with XDoclet-1.2b3.jar (default in the IDE) and XDoclet-1.2b4.jar (from the CVS) - in both cases I receive an OutOfMemory Exception after running Run Xdoclet on a project. In the task manager I see how the memory is eaten up (around 10MB at one running) and it the ends craches Eclipse. And I'm talking about more than 128MB of ram here. Costin -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=851138group_id=22866 --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Prescriptions written and filled online
Get ANY Prescription Drug You Want Our US Doctors will Write You a Prescription for FREEYou get it Next Day via FedEx Enter Store To be excluded from the list, Press u owb pwpl
[JBoss-dev] JBoss Building/Testing on Hold while ADSL being upgraded
So have fun... = __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-851172 ] jboss in space charakter path - jasper does not compile jsp
Bugs item #851172, was opened at 2003-11-29 15:23
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=851172group_id=22866
Category: None
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Marcus Schiesser (cartman)
Assigned to: Nobody/Anonymous (nobody)
Summary: jboss in space charakter path - jasper does not compile jsp
Initial Comment:
this bug relate to the new tomcat integration in 3.2.2.
with 3.2.1 this problem did not occur. i am using windows
xp jdk 1.4.1_03.
if jboss is located at some directory containing a space
charakter, jasper is not able to compile jsps correctly.
i think this bug is quite serious, as a lot of people would
use a path that contains a space charakter to jboss in
their development environment (at least i do;-)
the following is the error output:
thx you guys
org.apache.jasper.JasperException: Unable to compile
class for JSP
An error occurred at line: -1 in the jsp file: null
Generated servlet error:
[javac] Compiling 1 source file
[javac] javac: invalid flag: C:\Dokumente
[javac] Usage: javac options source files
[javac] where possible options include:
[javac] -gGenerate all debugging
info
[javac] -g:none Generate no debugging
info
[javac] -g:{lines,vars,source}Generate only some
debugging info
[javac] -nowarn Generate no warnings
[javac] -verbose Output messages
about what the compiler
is doing
[javac] -deprecation Output source
locations where deprecated
APIs are used
[javac] -classpath path Specify where to
find user class files
[javac] -sourcepath pathSpecify where to
find input source files
[javac] -bootclasspath path Override location
of bootstrap class fil
es
[javac] -extdirs dirs Override location of
installed extension
s
[javac] -d directorySpecify where to
place generated class f
iles
[javac] -encoding encoding Specify character
encoding used by sourc
e files
[javac] -source release Provide source
compatibility with specif
ied release
[javac] -target release Generate class files
for specific VM ver
sion
[javac] -help Print a synopsis of
standard options
at org.apache.jasper.compiler.DefaultErrorHandler.
javacError(DefaultErro
rHandler.java:130)
at org.apache.jasper.compiler.ErrorDispatcher.
javacError(ErrorDispatcher
.java:293)
at org.apache.jasper.compiler.Compiler.
generateClass(Compiler.java:353)
at org.apache.jasper.compiler.Compiler.
compile(Compiler.java:370)
at org.apache.jasper.JspCompilationContext.
compile(JspCompilationContext
.java:473)
at org.apache.jasper.servlet.JspServletWrapper.
service(JspServletWrapper
.java:190)
at org.apache.jasper.servlet.JspServlet.
serviceJspFile(JspServlet.java:2
95)
at org.apache.jasper.servlet.JspServlet.
service(JspServlet.java:241)
at javax.servlet.http.HttpServlet.
service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.
internalDoFilter(Appl
icationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.
doFilter(ApplicationF
ilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.
invoke(StandardWrapperV
alve.java:256)
at org.apache.catalina.core.
StandardPipeline$StandardPipelineValveContex
t.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.
invoke(StandardPipeline.jav
a:480)
at org.apache.catalina.core.ContainerBase.
invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContextValve.
invoke(StandardContextV
alve.java:191)
at org.apache.catalina.core.
StandardPipeline$StandardPipelineValveContex
t.invokeNext(StandardPipeline.java:643)
at org.jboss.web.tomcat.security.
JBossSecurityMgrRealm.invoke(JBossSecur
ityMgrRealm.java:220)
at org.apache.catalina.core.
StandardPipeline$StandardPipelineValveContex
t.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.authenticator.
AuthenticatorBase.invoke(Authentica
torBase.java:494)
at org.apache.catalina.core.
StandardPipeline$StandardPipelineValveContex
t.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.valves.CertificatesValve.
invoke(CertificatesValve
.java:246)
at org.apache.catalina.core.
StandardPipeline$StandardPipelineValveContex
t.invokeNext(StandardPipeline.java:641)
at org.jboss.web.tomcat.tc4.statistics.
ContainerStatsValve.invoke(Contai
nerStatsValve.java:76)
at org.apache.catalina.core.
StandardPipeline$StandardPipelineValveContex
t.invokeNext(StandardPipeline.java:641)
at
[JBoss-dev] Jboss-development,sports..movies..tv freee ilrkquofyobz
The ultimate digital cable filter The filter will allow you to receive all the channels that you order with your remove control! payperviews, adult movies,sport events,special events! see now! hyyh vrailzgjtmj udgq g cl q qshcv ahggnem
[JBoss-dev] [ jboss-Bugs-840496 ] Cocoon war dir hot-redeploy causes JBoss Shutdown
Bugs item #840496, was opened at 2003-11-11 23:15 Message generated for change (Comment added) made by dward2 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=840496group_id=22866 Category: JBossWeb Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: David Ward (dward2) Assigned to: Scott M Stark (starksm) Summary: Cocoon war dir hot-redeploy causes JBoss Shutdown Initial Comment: I've discovered a problem that only happens with jboss 3.0 + tomcat + cocoon 2.0 + expanded war directory, relating to hot-redeploy. Basically, if you have a cocoon.war/ *directory* web application, and touch it's web.xml file, JBoss shuts down! Here are the steps to re-create: 1) Download a completely fresh jboss-3.0.7_tomcat-4.1.24 from sourceforge. 2) Download a completely fresh cocoon-2.0.4 (vm14) from apache. 3) Dropped cocoon.war in jboss' deploy directory. 4) Started up jboss. 5) Hit the cocoon servlet (got a sitemap error but didn't care) 6) touch cocoon.war. 7) NO REDEPLOY PROBLEM 8) Hit the cocoon servlet (got same sitemap error but still didn't care - at least could still hit it). 9) Stop jboss. 10) Delete the db, tmp and log dirs to be completely clean distro again. 11) Explode the cocoon.war file into cocoon.war/ *DIRECTORY INSTEAD*. 12) Start up jboss. 13) Hit the cocoon servlet (sitemap error; still don't care) 14) touch cocoon.war/WEB-INF/web.xml 15) *** REDEPLOY PROBLEM: jboss shuts down!! *** JBoss/Jetty does not do this. JBoss 3.2.x does not do this. A JBoss/Tomcat webapp without Cocoon does not do this. JBoss/Tomcat with a Cocoon war *file* does not do this. It has to be JBoss 3.0/Tomcat with a Cocoon 2.0 war *directory*, and you touch it's web.xml file to cause a redeploy. I have tested it on many different combinations, and here is the breakdown: 1) jboss-3.0.7_tomcat-4.1.24 + cocoon-2.0.4 - FAILED 2) jboss-3.0.8_tomcat-4.1.24 + cocoon-2.0.4 - FAILED 3) jboss-3.0.8_tomcat-4.1.27 + cocoon-2.0.4 - FAILED 4) jboss-3.0.8_tomcat-4.1.29 + cocoon-2.0.4 - FAILED 5) jboss-3.2.2 (tomcat_4.1.27) + cocoon-2.0.4 - PASSED 6) jboss-3.0.8_tomcat-4.1.24 + cocoon-2.1.2 - PASSED, though 500 errors Something was fixed in JBoss 3.2.2 / Tomcat that fixed this problem. Does anyone have any idea what this was? Unfortunately, we cannot upgrade to JBoss 3.2.2 right now. If the fix is known, can it be backported back to 3.0? A jboss-3.0.9_tomcat-4.1.29 with the backported fix would be awesome and greatly appreciated! BTW, with JBoss 3.2.2, it looks like the shutdown was intercepted; here's a line from the console: 22:43:58,980 INFO [STDOUT] Mon Nov 03 22:43:58 EST 2003 SHUTDOWN : System.exit() was not called When I see that line with 3.2.2, the redeploy finishes and JBoss does not shutdown. Maybe find where that log is done and see what can be similarly done in 3.0.x to intercept the shutdown? Last bit of info: This is using Sun JDK 1.4.1 and 1.4.2. It is recreateable on Windows; not sure about Linux and MacOSX. Thanks! David -- Comment By: David Ward (dward2) Date: 2003-11-29 12:22 Message: Logged In: YES user_id=526282 Hi Scott, I will try that next. I do have more helpful information, though. Using the jboss-3.0.8_tomcat-4.1.24 + cocoon-2.0.4 configuration on WinXP-Pro with Sun JDK 1.4.2_02, I changed cocoon.war/WEB-INF/web.xml to use the sevlet 2.3 spec instead of 2.2. I could then add a custom TestServletContextListener with the listener-class element. I put a printStackTrace() in the contextDestroyed method. When I touch web.xml, I see it (contextDestroyed) being called twice. The first time was triggered by AbstractDeploymentScanner$ScannerTrhead.run() - which I would expect because I touched web.xml. However the second time is the one I didn't want to happen, and that was triggered by ServerImpl$ShutdownHook.run(). I am attaching a server.log file. Search for the text contextDestroyed called to find the 2 stack traces. Again, the first is expected, the second shouldn't have happened. Thanks again, David -- Comment By: Scott M Stark (starksm) Date: 2003-11-12 19:13 Message: Logged In: YES user_id=175228 Put the server in a debugger and set a break point on the System.exit call and show the stack trace to see who is calling it. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=840496group_id=22866 --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL
[JBoss-dev] [ jboss-Bugs-840496 ] Cocoon war dir hot-redeploy causes JBoss Shutdown
Bugs item #840496, was opened at 2003-11-11 23:15 Message generated for change (Comment added) made by dward2 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=840496group_id=22866 Category: JBossWeb Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: David Ward (dward2) Assigned to: Scott M Stark (starksm) Summary: Cocoon war dir hot-redeploy causes JBoss Shutdown Initial Comment: I've discovered a problem that only happens with jboss 3.0 + tomcat + cocoon 2.0 + expanded war directory, relating to hot-redeploy. Basically, if you have a cocoon.war/ *directory* web application, and touch it's web.xml file, JBoss shuts down! Here are the steps to re-create: 1) Download a completely fresh jboss-3.0.7_tomcat-4.1.24 from sourceforge. 2) Download a completely fresh cocoon-2.0.4 (vm14) from apache. 3) Dropped cocoon.war in jboss' deploy directory. 4) Started up jboss. 5) Hit the cocoon servlet (got a sitemap error but didn't care) 6) touch cocoon.war. 7) NO REDEPLOY PROBLEM 8) Hit the cocoon servlet (got same sitemap error but still didn't care - at least could still hit it). 9) Stop jboss. 10) Delete the db, tmp and log dirs to be completely clean distro again. 11) Explode the cocoon.war file into cocoon.war/ *DIRECTORY INSTEAD*. 12) Start up jboss. 13) Hit the cocoon servlet (sitemap error; still don't care) 14) touch cocoon.war/WEB-INF/web.xml 15) *** REDEPLOY PROBLEM: jboss shuts down!! *** JBoss/Jetty does not do this. JBoss 3.2.x does not do this. A JBoss/Tomcat webapp without Cocoon does not do this. JBoss/Tomcat with a Cocoon war *file* does not do this. It has to be JBoss 3.0/Tomcat with a Cocoon 2.0 war *directory*, and you touch it's web.xml file to cause a redeploy. I have tested it on many different combinations, and here is the breakdown: 1) jboss-3.0.7_tomcat-4.1.24 + cocoon-2.0.4 - FAILED 2) jboss-3.0.8_tomcat-4.1.24 + cocoon-2.0.4 - FAILED 3) jboss-3.0.8_tomcat-4.1.27 + cocoon-2.0.4 - FAILED 4) jboss-3.0.8_tomcat-4.1.29 + cocoon-2.0.4 - FAILED 5) jboss-3.2.2 (tomcat_4.1.27) + cocoon-2.0.4 - PASSED 6) jboss-3.0.8_tomcat-4.1.24 + cocoon-2.1.2 - PASSED, though 500 errors Something was fixed in JBoss 3.2.2 / Tomcat that fixed this problem. Does anyone have any idea what this was? Unfortunately, we cannot upgrade to JBoss 3.2.2 right now. If the fix is known, can it be backported back to 3.0? A jboss-3.0.9_tomcat-4.1.29 with the backported fix would be awesome and greatly appreciated! BTW, with JBoss 3.2.2, it looks like the shutdown was intercepted; here's a line from the console: 22:43:58,980 INFO [STDOUT] Mon Nov 03 22:43:58 EST 2003 SHUTDOWN : System.exit() was not called When I see that line with 3.2.2, the redeploy finishes and JBoss does not shutdown. Maybe find where that log is done and see what can be similarly done in 3.0.x to intercept the shutdown? Last bit of info: This is using Sun JDK 1.4.1 and 1.4.2. It is recreateable on Windows; not sure about Linux and MacOSX. Thanks! David -- Comment By: David Ward (dward2) Date: 2003-11-29 13:19 Message: Logged In: YES user_id=526282 Hi again Scott, I am now running the same jboss/java/os version as described in my last comment (where I referenced server.log), except I launched it from Ecplipse 2.1.1 using JBoss-IDE 1.2.2. I set a breakpoint in java.lang.System.exit(int) as you suggested, halting the VM when it reached the only line in that method, Runtime.getRuntime().exit(int). On the Debug view tab, I see this: Thread [Thread-29] (Suspended (breakpoint at line 715 in System)) System.exit(int) line: 715 ServerConnection.run() line: 146 I'm assuming ServerConnection.run() line: 146 is JBoss source, as Eclipse can't find the source. Does this help you debug the problem? Is it enough, or should I download the jboss source for the version I'm using and get a more detailed trace? Thanks yet again, David -- Comment By: David Ward (dward2) Date: 2003-11-29 12:22 Message: Logged In: YES user_id=526282 Hi Scott, I will try that next. I do have more helpful information, though. Using the jboss-3.0.8_tomcat-4.1.24 + cocoon-2.0.4 configuration on WinXP-Pro with Sun JDK 1.4.2_02, I changed cocoon.war/WEB-INF/web.xml to use the sevlet 2.3 spec instead of 2.2. I could then add a custom TestServletContextListener with the listener-class element. I put a printStackTrace() in the contextDestroyed method. When I touch web.xml, I see it (contextDestroyed) being called twice. The first time was triggered by AbstractDeploymentScanner$ScannerTrhead.run() - which I would expect because I touched web.xml. However the second time is the one I didn't want to happen, and that was triggered by ServerImpl$ShutdownHook.run(). I am attaching a server.log file. Search for the text contextDestroyed called to
[JBoss-dev] cvs lock?
I was trying to do an anonymous checkout of jboss-head and it loooks like there is a lock in the cvs: cvs server: [11:24:21] waiting for anoncvs_jboss's lock in /cvsroot/jboss/ jbosstest/src/main/org/jboss/test/jmx/invoker I've retried several times with no luck. Anybody experienced the same problem? Ricardo Argüello --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-840496 ] Cocoon war dir hot-redeploy causes JBoss Shutdown
Bugs item #840496, was opened at 2003-11-11 23:15 Message generated for change (Comment added) made by dward2 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=840496group_id=22866 Category: JBossWeb Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: David Ward (dward2) Assigned to: Scott M Stark (starksm) Summary: Cocoon war dir hot-redeploy causes JBoss Shutdown Initial Comment: I've discovered a problem that only happens with jboss 3.0 + tomcat + cocoon 2.0 + expanded war directory, relating to hot-redeploy. Basically, if you have a cocoon.war/ *directory* web application, and touch it's web.xml file, JBoss shuts down! Here are the steps to re-create: 1) Download a completely fresh jboss-3.0.7_tomcat-4.1.24 from sourceforge. 2) Download a completely fresh cocoon-2.0.4 (vm14) from apache. 3) Dropped cocoon.war in jboss' deploy directory. 4) Started up jboss. 5) Hit the cocoon servlet (got a sitemap error but didn't care) 6) touch cocoon.war. 7) NO REDEPLOY PROBLEM 8) Hit the cocoon servlet (got same sitemap error but still didn't care - at least could still hit it). 9) Stop jboss. 10) Delete the db, tmp and log dirs to be completely clean distro again. 11) Explode the cocoon.war file into cocoon.war/ *DIRECTORY INSTEAD*. 12) Start up jboss. 13) Hit the cocoon servlet (sitemap error; still don't care) 14) touch cocoon.war/WEB-INF/web.xml 15) *** REDEPLOY PROBLEM: jboss shuts down!! *** JBoss/Jetty does not do this. JBoss 3.2.x does not do this. A JBoss/Tomcat webapp without Cocoon does not do this. JBoss/Tomcat with a Cocoon war *file* does not do this. It has to be JBoss 3.0/Tomcat with a Cocoon 2.0 war *directory*, and you touch it's web.xml file to cause a redeploy. I have tested it on many different combinations, and here is the breakdown: 1) jboss-3.0.7_tomcat-4.1.24 + cocoon-2.0.4 - FAILED 2) jboss-3.0.8_tomcat-4.1.24 + cocoon-2.0.4 - FAILED 3) jboss-3.0.8_tomcat-4.1.27 + cocoon-2.0.4 - FAILED 4) jboss-3.0.8_tomcat-4.1.29 + cocoon-2.0.4 - FAILED 5) jboss-3.2.2 (tomcat_4.1.27) + cocoon-2.0.4 - PASSED 6) jboss-3.0.8_tomcat-4.1.24 + cocoon-2.1.2 - PASSED, though 500 errors Something was fixed in JBoss 3.2.2 / Tomcat that fixed this problem. Does anyone have any idea what this was? Unfortunately, we cannot upgrade to JBoss 3.2.2 right now. If the fix is known, can it be backported back to 3.0? A jboss-3.0.9_tomcat-4.1.29 with the backported fix would be awesome and greatly appreciated! BTW, with JBoss 3.2.2, it looks like the shutdown was intercepted; here's a line from the console: 22:43:58,980 INFO [STDOUT] Mon Nov 03 22:43:58 EST 2003 SHUTDOWN : System.exit() was not called When I see that line with 3.2.2, the redeploy finishes and JBoss does not shutdown. Maybe find where that log is done and see what can be similarly done in 3.0.x to intercept the shutdown? Last bit of info: This is using Sun JDK 1.4.1 and 1.4.2. It is recreateable on Windows; not sure about Linux and MacOSX. Thanks! David -- Comment By: David Ward (dward2) Date: 2003-11-29 16:17 Message: Logged In: YES user_id=526282 Okay - found the problem. ServerConnection is an hsqldb class, org.hsqldb.ServerConnection. In hsqldb 1.61, there is a call to System.exit(0); in ServerConnection, just under a System.out.println(The database is shutdown). If you look at the server.log I had previously attached, you will see these lines: 2003-11-29 12:07:29,799 INFO [org.jboss.deployment.MainDeployer] Starting deployment of package: file:/C:/Temp/jboss-3.0.8_tomcat-4.1.24/server/default/deploy/ cocoon.war/^M 2003-11-29 12:07:29,940 INFO [STDOUT] The database is shutdown^M 2003-11-29 12:07:29,940 INFO [STDOUT] The database is shutdown^M 2003-11-29 12:07:29,950 INFO [org.jboss.system.server.Server] Undeploying all packages^M 2003-11-29 12:07:29,950 INFO [org.jboss.deployment.MainDeployer] Undeploying file:/C:/Temp/jboss-3.0.8_tomcat-4.1.24/server/default/deploy/jmx-console.war/^M I'm pretty sure it's hsqldb that's shutting down the server. It looks like there's a fix in hsqldb 1.7.0 that fixes this: //[EMAIL PROTECTED] 20020424 - patch 1.7.0 by fredt - shutdown without exit Looking at the source for 1.7.1, there is no more System.exit(0) called in ServerConnection.java. There is in Server.java (same package), but only if it is supposed to. Here's a noe from the class javadoc: If the server is embedded in an application server, such as when DataSource or HsqlServerFactory classes are used, it is necessary to avoid calling System.exit() when the HSQLDB is shutdown with an SQL command.br For this, the server.no_system_exit property can be set either on the command line or in server.properties file. This ensures that System.exit() is not called at the end. All that is left for the embedder application server is to release the empty Server object and create another one to
Re: [JBoss-dev] cvs lock?
use your user id to checkout instead, anonymous access is flakey -- Juha On Sat, 29 Nov 2003, Ricardo Argüello wrote: I was trying to do an anonymous checkout of jboss-head and it loooks like there is a lock in the cvs: cvs server: [11:24:21] waiting for anoncvs_jboss's lock in /cvsroot/jboss/ jbosstest/src/main/org/jboss/test/jmx/invoker I've retried several times with no luck. Anybody experienced the same problem? Ricardo Argüello --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-840496 ] Cocoon war dir hot-redeploy causes JBoss Shutdown
Bugs item #840496, was opened at 2003-11-11 23:15 Message generated for change (Comment added) made by dward2 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=840496group_id=22866 Category: JBossWeb Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: David Ward (dward2) Assigned to: Scott M Stark (starksm) Summary: Cocoon war dir hot-redeploy causes JBoss Shutdown Initial Comment: I've discovered a problem that only happens with jboss 3.0 + tomcat + cocoon 2.0 + expanded war directory, relating to hot-redeploy. Basically, if you have a cocoon.war/ *directory* web application, and touch it's web.xml file, JBoss shuts down! Here are the steps to re-create: 1) Download a completely fresh jboss-3.0.7_tomcat-4.1.24 from sourceforge. 2) Download a completely fresh cocoon-2.0.4 (vm14) from apache. 3) Dropped cocoon.war in jboss' deploy directory. 4) Started up jboss. 5) Hit the cocoon servlet (got a sitemap error but didn't care) 6) touch cocoon.war. 7) NO REDEPLOY PROBLEM 8) Hit the cocoon servlet (got same sitemap error but still didn't care - at least could still hit it). 9) Stop jboss. 10) Delete the db, tmp and log dirs to be completely clean distro again. 11) Explode the cocoon.war file into cocoon.war/ *DIRECTORY INSTEAD*. 12) Start up jboss. 13) Hit the cocoon servlet (sitemap error; still don't care) 14) touch cocoon.war/WEB-INF/web.xml 15) *** REDEPLOY PROBLEM: jboss shuts down!! *** JBoss/Jetty does not do this. JBoss 3.2.x does not do this. A JBoss/Tomcat webapp without Cocoon does not do this. JBoss/Tomcat with a Cocoon war *file* does not do this. It has to be JBoss 3.0/Tomcat with a Cocoon 2.0 war *directory*, and you touch it's web.xml file to cause a redeploy. I have tested it on many different combinations, and here is the breakdown: 1) jboss-3.0.7_tomcat-4.1.24 + cocoon-2.0.4 - FAILED 2) jboss-3.0.8_tomcat-4.1.24 + cocoon-2.0.4 - FAILED 3) jboss-3.0.8_tomcat-4.1.27 + cocoon-2.0.4 - FAILED 4) jboss-3.0.8_tomcat-4.1.29 + cocoon-2.0.4 - FAILED 5) jboss-3.2.2 (tomcat_4.1.27) + cocoon-2.0.4 - PASSED 6) jboss-3.0.8_tomcat-4.1.24 + cocoon-2.1.2 - PASSED, though 500 errors Something was fixed in JBoss 3.2.2 / Tomcat that fixed this problem. Does anyone have any idea what this was? Unfortunately, we cannot upgrade to JBoss 3.2.2 right now. If the fix is known, can it be backported back to 3.0? A jboss-3.0.9_tomcat-4.1.29 with the backported fix would be awesome and greatly appreciated! BTW, with JBoss 3.2.2, it looks like the shutdown was intercepted; here's a line from the console: 22:43:58,980 INFO [STDOUT] Mon Nov 03 22:43:58 EST 2003 SHUTDOWN : System.exit() was not called When I see that line with 3.2.2, the redeploy finishes and JBoss does not shutdown. Maybe find where that log is done and see what can be similarly done in 3.0.x to intercept the shutdown? Last bit of info: This is using Sun JDK 1.4.1 and 1.4.2. It is recreateable on Windows; not sure about Linux and MacOSX. Thanks! David -- Comment By: David Ward (dward2) Date: 2003-11-29 16:37 Message: Logged In: YES user_id=526282 Another note - I see in jboss-3.2.2, in server/default/deploy/hsqldb-ds.xml, that there is a *commented out* mbean block for org.jboss.jdbc.HypersonicDatabase with attribute name=No_system_exittrue/attribute. I wonder how this is working, even though it's commented out... The fact that it's there sounds to me that jboss-3.2.2 uses hsqldb 1.7.x. A-ha! Looking at the jboss 3.2.2 source, org.jboss.jdbc.HypersonicDatabase has a no_system_exit property that *defaults* to true! It has a javadoc comment over it that says New embedded support in 1.7. S... I'm guessing the only way to backport this fix to jboss-3.0.x is to also upgrade hsqldb to 1.7.x? Is that feasible? Still, still - I don't understand why the shutdown on redeploy only happens when cocoon.war is in expanded form. Scott, now that you know who's calling the exit, can you make a guess at what the difference might be (expanded dir vs. not)? Maybe to patch this for jboss 3.0.x we don't need the newer hsqldb, as long as we can figure why jboss is handling the expanded cocoon deployment differently... Could it be some classloading difference, maybe compounded with the confusion that cocoon.war also contains it's own copy of hsqldb? Thanks, David -- Comment By: David Ward (dward2) Date: 2003-11-29 16:17 Message: Logged In: YES user_id=526282 Okay - found the problem. ServerConnection is an hsqldb class, org.hsqldb.ServerConnection. In hsqldb 1.61, there is a call to System.exit(0); in ServerConnection, just under a System.out.println(The database is shutdown). If you look at the server.log I had previously attached, you will see these lines: 2003-11-29 12:07:29,799 INFO [org.jboss.deployment.MainDeployer]
[JBoss-dev] Investment Opportunity
DEAR SIR. PLEASE I AM A GIRL OF 25 YEARS AND I AM LOOKING FOR INVESTMENT OPPORTUNITY. I INTENDED TO INVEST THE SUM OF TWENTY MILLION UNITED STATES DOLLARS INHERITED BY MY LATE FATHER.I AM FROM ZIMBABWE.BUT I AM LIVING IN THE NETHERLANDS (EUROPE) AT THE MOMENT FOR MORE INFORMATION REACH ME ON MY NUMBER 0031612730214806 OR THROUGH THE EMAIL [EMAIL PROTECTED] BEST REGARDS DAYA MATOMBO
