I haven't really played with JBoss 4.0 as it is still a Developer Release. Possibly the deployment issue is a bug as what you have described works fine in the 3.2.x releases - you can check the JBoss SourceForge buglist to see if it has been logged. You may want to try variations like undeploy (delete) and copy the new one in. It may be a workaround, and you can log a bug if it hasn't already been reported.
The configuration for Tomcat will probably exist in server/instance/deploy/jbossweb-tomcat.sar/META-INF/jboss-service.xml. You should find your listener definitions there including port bindings. The SAR may have changed to jbossweb-tomcat41.sar. You should be able to identify the Tomcat service deployment (SAR) and from there the corresponding jboss-service.xml.
Hope that helps.
Well, I can't see why a feature that works in a previous version would not work in a later version, even though 4 is a developers release.
Anyway, does JBoss 3 support JMS?
hi, For the configuration of Tomcat port you open the:
You search the tag:
you modifie the port attribute with 80.
For JBoss Error try to delete the old .war and copy the new or there is duplicated directory or file!
Is it possible to undeploy a WAR or EAR from the jmx-console?
I don't know, but you can do it directly by removing the WAR or EAR from the %JBOSS_DIST%\server\default\deploy directory.
I undeploy my EJB (.jar files) directly by removing them.
I have exactly the same problem with my wars, and I tried to delete them before copying the new one but it didn't change anything, even the deletion of the temp directory didn't work.
But thanks for the idea, I will go to the buglist to see if anything like this has been reported.
For now, I have to rename my new war each time I need to redeploy. And something funny, I can redeploy my war with the same name if I restart JBoss.
OK. Sounds like a bug. After a reboot, it probably will redeploy the new image. Doesn't seem like it undeploys cleanly from memory - perhaps a classloading issue. Rebooting the JVM is probably clearing that.
Why might a major release version change operation? In terms of a bug, perhaps a refactoring has introduced a problem that previously didn't exist. Sometimes, a major release may intentionally change operation - I don't think that is the case here.
A Developer Release as from a commercial vendor is bleeding edge technology. However, here you have the source code so you can delve through the issues and try to solve them yourself. It also exposes to you new features - EJB 2.1, AOP and so on. It's nice enough to play around with if you can live with some possibly broken or incomplete bits and report them so it is repaired in the production release - but it is not something you'd take to clients.
I don't think the jmx-console currently supports any deployment actions. Deployment is handled through the deployment scanner detecting changes in critical file timestamps.
Yes, 3.2.x supports JMS.
3.0.x supports JMS as well. But 3.2.x has some cleaner configuration and is closer to 4.0 configuration practices.