Problem with start/stop of jboss as - is that on an a newly created server or an existing one already configured in your eclipse workspace ?
Looks like the server configuration some how is missing the location of the server and just uses root. Where does the error show up ? In eclipse ? In the console output ?
The ALL never included all of eclipse afaik; only the bundle one did. Anyhow the preconfigured all ready to go option is what RHDS provides; JBoss Tools is "just" the plugins.
Packaging has changed to archiving - need to get that better documented apparently.
The JBoss AS-configuration has been done in beta2 and worked fine there. After installing beta, I just took over the existing workspace - with the JBoss configuration in it. And now it breaks on startup with the following Eclipse-console-output:
11:48:33,062 INFO [Server] Starting JBoss (MX MicroKernel)... 11:48:33,062 INFO [Server] Release ID: JBoss [Trinity] 4.2.1.GA (build: SVNTag=JBoss_4_2_1_GA date=200707131605) 11:48:33,062 INFO [Server] Home Dir: F:\jboss-4.2.1.GA 11:48:33,062 INFO [Server] Home URL: file:/F:/jboss-4.2.1.GA/ 11:48:33,078 INFO [Server] Patch URL: null 11:48:33,078 INFO [Server] Server Name: 11:48:33,078 INFO [Server] Server Home Dir: F:\jboss-4.2.1.GA\server 11:48:33,078 INFO [Server] Server Home URL: file:/ 11:48:33,078 INFO [Server] Server Log Dir: F:\jboss-4.2.1.GA\server\log 11:48:33,078 INFO [Server] Server Temp Dir: F:\jboss-4.2.1.GA\server\tmp 11:48:33,078 INFO [Server] Root Deployment Filename: jboss-service.xml 11:48:34,265 INFO [ServerInfo] Java version: 1.5.0_10,Sun Microsystems Inc. 11:48:34,265 INFO [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.5.0_10-b03,Sun Microsystems Inc. 11:48:34,265 INFO [ServerInfo] OS-System: Windows XP 5.1,x86 11:48:34,671 INFO [Server] Core system initialized Failed to boot JBoss: org.jboss.deployment.DeploymentException: url file:/conf/jboss-service.xml could not be opened, does it exist? at org.jboss.deployment.DeploymentInfo.<init>(DeploymentInfo.java:214) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:781) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy5.deploy(Unknown Source) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362) at org.jboss.Main.boot(Main.java:200) at org.jboss.Main$1.run(Main.java:508) at java.lang.Thread.run(Unknown Source) 11:48:34,687 INFO [Server] Runtime shutdown hook called, forceHalt: true 11:48:34,687 INFO [Server] JBoss SHUTDOWN: Undeploying all packages 11:48:34,687 INFO [Server] Shutdown complete Shutdown complete Halting VM
The exception is printed red, what means it comes probably through System.err. I will test if a newly created Server-configuration will do the trick.
A newly created Server-configuration solves the problem.
Now I'll try to dig me through the new Archiving ...
Thank you very much!
you didn't get a wizard on the first start to convert your projects/server setups ?
There should be an automatic conversion wizard.
Ok, the Packaging-Problem first occured in beta2 exists in beta3, too. When I configure "Packaging Archives" and press the button "Apply" (or in beta2 choose "Run Packaging") a popup occurs "An internal error occured. See error log for details.". In error log view I found te following exception:
java.lang.IllegalArgumentException: Attempted to beginRule: F/Cube Frontoffice/.metadata/.plugins/org.eclipse.debug.core/.launches, does not match outer scope rule: P/Cube Server at org.eclipse.core.runtime.Assert.isLegal(Assert.java:62) at org.eclipse.core.internal.jobs.ThreadJob.illegalPush(ThreadJob.java:116) at org.eclipse.core.internal.jobs.ThreadJob.push(ThreadJob.java:225) at org.eclipse.core.internal.jobs.ImplicitJobs.begin(ImplicitJobs.java:80) at org.eclipse.core.internal.jobs.JobManager.beginRule(JobManager.java:219) at org.eclipse.core.internal.resources.WorkManager.checkIn(WorkManager.java:96) at org.eclipse.core.internal.resources.Workspace.prepareOperation(Workspace.java:1684) at org.eclipse.core.internal.resources.Resource.delete(Resource.java:681) at org.eclipse.core.internal.resources.Resource.delete(Resource.java:667) at org.eclipse.debug.internal.core.LaunchConfiguration.delete(LaunchConfiguration.java:210) at org.jboss.ide.eclipse.packaging.ui.actions.PackagingRunAction$1.run(PackagingRunAction.java:185) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
Project "Cube Frontoffice" depends on Project "Cube Server". I tried to package the Project "Cube Server". Both Projects reside in a Workspace on drive F:, a drive P: does not exist - and apparently did never exist on my computer, because I'm far, far away from using P: as drive-letter ;). Running the packaging-build.xml as ant-file works without problems. Turning Packaging off and newly configuring it, did no solve the problem.
So, do you have any suggestions? The problem is not critical because there is a working work-around, but using the built-in Packaging-mechanism was very convenient for me.
F means file
P means project
nothing related to drive letter ;)
You should report in jira the steps to reproduce this - thanks.
Why don't you change the Packaging mechanism? The original Packaging mechanism is excellent and we(we are the partner of RedHat) promoted to our client, the client also appreciate this Packaging mechanism.
Right now, the packaging mechanism is totally changed without any documentation and not user friendly anymore. I afraid the client won't approach JBOSS anymore.
I think JBOSS have to think about the workaround how to make the Packaging mechanism more user friendly.
The packaging was changed because it was slow (e.g. not incremental,dependent on ant, no exploded packaging option) and cumbersome to setup (I personally could not figure out the old packaging without docs)
If you find the old packaging easy to setup then please tell us what is broken with the new one.
e.g. I just went back and retried archiving and I could only find one issue that was trivial to work around.
Here are the steps I did:
Open Archives View
complete wizard/Press Finish
The generated war has one issue, lib has a folder called lib with jars instead of in root so I just changed the **/*.jar filter to look in lib folder directly instead of root project.
And if i change the war to be exploded I can browse it easily and the war is constantly uptodate; i don't have to cnostantly press archive/packaging.
Please tell me what is wrong with that.
Is it the ant integration you are missing the docs for or ?