[JBoss JIRA] (JBIDE-19368) File not deployed to server on Windows
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19368?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-19368:
-------------------------------------
Marking as minor since it only appears to affect tests for now.
> File not deployed to server on Windows
> --------------------------------------
>
> Key: JBIDE-19368
> URL: https://issues.jboss.org/browse/JBIDE-19368
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.2.Final
> Environment: Windows 7, JBDS 4.2.2, EAP 6.4 ER1
> Reporter: Lucia Jelinkova
> Assignee: Lucia Jelinkova
> Priority: Minor
> Fix For: 4.4.x
>
> Attachments: deployments.zip, jsp-project.zip, workspace.zip
>
>
> Sometimes our automated EAP <-> JBDS compatibility UI tests fail on windows machine because one java file of the tested project is not deployed to the server (and is not in the deployment folder either).
> The tests runs like this:
> # Create server and start it
> # Import project with JSP file from ZIP into the workspace
> # Add server as targeted runtime via Properites
> # Right-click server and via Add/Remove modules add the imported project to the server
> # Open module's web page (right click + open in web browser)
> RESULT: JSP file compilation fails because it is not able to resolve HelloWorld.java class
> I have not seen any errors in server's console (except for the compilation error).
> {code}
> 05:25:04,990 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.4.Final-redhat-1
> 05:25:05,678 INFO [org.jboss.msc] (main) JBoss MSC version 1.1.5.Final-redhat-1
> 05:25:05,850 INFO [org.jboss.as] (MSC service thread 1-4) JBAS015899: JBoss EAP 6.4.0.Alpha1 (AS 7.5.0.Final-redhat-11) starting
> 05:25:08,568 INFO [org.xnio] (MSC service thread 1-4) XNIO Version 3.0.11.GA-redhat-2
> 05:25:08,584 INFO [org.xnio.nio] (MSC service thread 1-4) XNIO NIO Implementation Version 3.0.11.GA-redhat-2
> 05:25:08,600 INFO [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
> 05:25:08,787 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 45) JBAS010153: Node identifier property is set to the default value. Please make sure it is unique.
> 05:25:08,803 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 30) JBAS010280: Activating Infinispan subsystem.
> 05:25:08,850 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 38) JBAS011800: Activating Naming Subsystem
> 05:25:08,881 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 36) JBAS012605: Activated the following JSF Implementations: [main, 1.2]
> 05:25:08,928 INFO [org.jboss.as.security] (ServerService Thread Pool -- 43) JBAS013171: Activating Security Subsystem
> 05:25:08,975 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 47) JBAS015537: Activating WebServices Extension
> 05:25:09,131 INFO [org.jboss.as.security] (MSC service thread 1-3) JBAS013170: Current PicketBox version=4.1.0.Beta1-redhat-1
> 05:25:09,381 INFO [org.jboss.remoting] (MSC service thread 1-4) JBoss Remoting version 3.3.4.Final-redhat-1
> 05:25:09,584 INFO [org.jboss.as.naming] (MSC service thread 1-4) JBAS011802: Starting Naming Service
> 05:25:09,600 INFO [org.jboss.as.mail.extension] (MSC service thread 1-4) JBAS015400: Bound mail session [java:jboss/mail/Default]
> 05:25:09,725 INFO [org.jboss.as.connector.logging] (MSC service thread 1-4) JBAS010408: Starting JCA Subsystem (IronJacamar 1.0.29.Final-redhat-1)
> 05:25:10,334 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 15) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 05:25:10,412 INFO [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-2) JBWEB003001: Coyote HTTP/1.1 initializing on : http-localhost/127.0.0.1:8080
> 05:25:10,553 INFO [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-2) JBWEB003000: Coyote HTTP/1.1 starting on: http-localhost/127.0.0.1:8080
> 05:25:10,881 INFO [org.jboss.as.remoting] (MSC service thread 1-3) JBAS017100: Listening on 127.0.0.1:9999
> 05:25:10,881 INFO [org.jboss.as.remoting] (MSC service thread 1-3) JBAS017100: Listening on 127.0.0.1:4447
> 05:25:10,928 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-4) JBAS015012: Started FileSystemDeploymentService for directory W:\workspace\eap-6x-jbds-compatibility-jbosstools-4.2.x-windows\8b0502d6\tests\org.jboss.ide.eclipse.as.ui.bot.test\target\requirements\jboss-eap-6.4\standalone\deployments
> 05:25:11,287 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> 05:25:12,100 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 4.3.1.Final-redhat-1
> 05:25:12,272 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
> 05:25:12,272 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
> 05:25:12,272 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss EAP 6.4.0.Alpha1 (AS 7.5.0.Final-redhat-11) started in 9016ms - Started 152 of 190 services (57 services are lazy, passive or on-demand)
> 05:25:25,990 INFO [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015003: Found jsp-project.war in deployment directory. To trigger deployment create a file called jsp-project.war.dodeploy
> 05:25:26,084 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015876: Starting deployment of "jsp-project.war" (runtime-name: "jsp-project.war")
> 05:25:26,881 INFO [org.jboss.web] (ServerService Thread Pool -- 24) JBAS018210: Register web context: /jsp-project
> 05:25:27,318 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "jsp-project.war" (runtime-name : "jsp-project.war")
> 05:25:39,693 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/jsp-project].[jsp]] (http-localhost/127.0.0.1:8080-1) JBWEB000236: Servlet.service() for servlet jsp threw exception: org.apache.jasper.JasperException: JBWEB004062: Unable to compile class for JSP:
> JBWEB004060: An error occurred at line: 4 in the jsp file: /index.jsp
> HelloWorld cannot be resolved
> 1: <%@ page language="java" import="org.jboss.tools.tests.as.*" errorPage="" %>
> 2: <html>
> 3: <body>
> 4: <%=HelloWorld.sayHello()%>
> 5: </body>
> 6: </html>
> JBWEB004211: Stacktrace:
> at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:85) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:69) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:461) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:361) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:339) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:326) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:606) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:308) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:309) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:242) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.5.0.Final-redhat-11.jar:7.5.0.Final-redhat-11]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.5.0.Beta4.jar:7.5.0.Beta4]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> {code}
> Do you have any idea why this could happen or how to continue with locating the problem?
> I am attaching the imported project as ZIP file, the workspace after import and also the content of deployments folder.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBIDE-19182) Incremental Publish after Full Publish WRT dodeploy markers
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19182?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-19182:
--------------------------------
Fix Version/s: 4.4.x
(was: 4.3.x)
> Incremental Publish after Full Publish WRT dodeploy markers
> -----------------------------------------------------------
>
> Key: JBIDE-19182
> URL: https://issues.jboss.org/browse/JBIDE-19182
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.0.Final
> Reporter: Rob Stryker
> Fix For: 4.4.x
>
>
> THis issue is opened in regards to comments by [~dlmiles] on https://issues.jboss.org/browse/JBIDE-18862
> I am saying you should block all 'deployment directory' file modifications when you know the AS is busy using the 'deployment directory' to "deploy" (a.k.a. starting) or "undeploy" (a.k.a. stopping) of a module (or the AS itself is starting/stopping in certain scenarios). Ideally you use a file watcher API when available so there is no busy/wait loop adding additional milliseconds of delays because the wait part is never instant.
> But in an example scenario where you perform a Full Publish then 2 additional Incremental Publish ops immediately after, there is no reason to block the incrementals if you know the AS has not picked up the original Full Publish yet. You can effectively merge those two incrementals into the full publish operation behind the back of the AS.
> But you are presented with a race scenario, you have already laid down the *.dodeploy at the end of the original Full Publish. So Eclipse needs to effectively notice that scenario exists, revoke and remember that instruction to the AS in an atomic way (what I mean by this is Eclipse knows for sure if it cancelled it in time, or if it was too late and the AS got to the full publish first and started deploying).
> You need to do this so Eclipse can make file change modifications to the 'deployment directory' again.
> Once Eclipse has completed the file change operations, if takes that remembered state and puts back the *.dodeploy file (even though this is an Incremental Publish operation). You can think of this like a "save state" and "restore state" pattern if that helps. Or you can think of this like the Eclipse target goal state for the AS (such as "AS:started" and "module.abc:started") is compared to the actual AS state (such as "AS: started" and "module.abc:stopped"), and Eclipse then brings them into alignment to do this it realizes it needs to lay down the *.dodeploy marker file (even though this is an incremental publish).
> I think with the current marker file arrangements there maybe a tiny window of time where Eclipse IDE will get things wrong in respect of the AS ? But maybe ensuring both Eclipse IDE and the AS check the return value of the file delete for *.dodeploy whomever was successful in deleting the file wins, whichever party got the error "No Such File" loses and performs a rollback/cleanup of the situation to ensure it tries again soon.
> So you can speak for the JBIDE side but can someone check the AS side ? File#delete(new File("foobar.dodeploy")) != true. The AS has to delete the command instruction file before it starts to process that command, but after it has laid down a state change file (*.isdeploying).
> One of the goals of the marker files is that at no point in time is there a snapshot of the files that exist in the directory; that would leave an observer to interpret the wrong state. For example deleting one marker file before laying down the next would be bad, because there is a snapshot of time when no state marker file exists in the directory, leaving the observer to interpret that nothing is happening with that module. The alternative is to lay both the new file first then delete the old one, now there is a window of time when 2 marker files indicate state for 1 module, this is good and valid since the observer can clearly see the correct state.
> So if you got here and are still with me, then you can see how things should only slow down, when they need to slow down.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBIDE-20153) Docker server adapter
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20153?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-20153:
--------------------------------
Fix Version/s: (was: 4.3.x)
> Docker server adapter
> ---------------------
>
> Key: JBIDE-20153
> URL: https://issues.jboss.org/browse/JBIDE-20153
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: docker, server
> Reporter: Max Rydahl Andersen
> Assignee: Rob Stryker
> Priority: Critical
> Fix For: 4.4.x
>
>
> I've been wondering for a time what would be the best way to integrate docker with our server adapters.
> I initially first thought it should be an additional profile to the existing local or remote profiles - but I think that option actually ends up being too limiting. To start - the server inside the docker then is assumed to always be a wildfly server; and I think for docker that is too limiting.
> Watching Eclipse Che demo at EclipseCon I realized their approach for "Runners" actually fits perfectly.
> What they do is that they don't actually have any insight into what servers they are running - they simply just have an associated DockerFile for a "runner" which they build and then run before launching.
> Once launched they then know where the server port is, where the possible debug port is, where files are mounted etc.
> So this Docker Server Adapter can be made to run *any* kind of application.
> WildFly, Tomcat, Python, even plain java apps.
> And actually it is not just a DockerFile that is associated with the run but a templated dockerfile. A file where certain variables will be replaced; like:
> {code}
> VOLUME /deployments
> ADD $app$ /deployments
> {code}
> will add the packaged app (i.e. wonka.war) into the /deployments folder and /deployments is mounted.
> And actually the /deployments can then be updated incrementally if wanted to.
> Even greater is that if we could support the same syntax and semantics of the templating we can simply reuse the templates defined by Che at https://github.com/codenvy/dockerfiles/
> You can see more complete info on what codenvy/che does http://docs.codenvy.com/user/builders-and-runners/#custom-machines
> This would cover all the usecases I can currently think of with launching docker from eclipse - but not be tied to any specific server type.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBIDE-20362) Extracting of a download runtime is slow on Mac
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20362?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-20362:
--------------------------------
Fix Version/s: 4.4.x
(was: 4.3.x)
> Extracting of a download runtime is slow on Mac
> -----------------------------------------------
>
> Key: JBIDE-20362
> URL: https://issues.jboss.org/browse/JBIDE-20362
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: runtime-detection
> Affects Versions: 4.3.0.Beta2
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.4.x
>
>
> While playing with the Download runtime fuctionality, I noticed that once a runtime (e.g. EAP 6.2) is downloaded, the extraction takes very long. I think it used to be fast and the extraction was done without any progress reporting. But now it seems that every subdirectory in the archive is being printed out which slows it down.
> This extraction process took 1 min 23 sec for EAP 6.2 and I have an SSD. On a command line, this would take a few seconds.
> I think the solution may be to simply show "Extracting" without printing out each file/directory that is being extracted.
> (Furthermore, the progress bar does not reflect the progress - it seems there is still only perhaps 5 % done and then it's suddenly over.)
> I can record a screencast if you like, but I think this should be easy to replicate.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBIDE-9794) Add a CLI batch file feature
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-9794?page=com.atlassian.jira.plugin... ]
Rob Stryker updated JBIDE-9794:
-------------------------------
Fix Version/s: LATER
(was: 4.3.x)
> Add a CLI batch file feature
> ----------------------------
>
> Key: JBIDE-9794
> URL: https://issues.jboss.org/browse/JBIDE-9794
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: server
> Affects Versions: 3.3.0.M3
> Environment: AS7
> Reporter: Scott Stark
> Labels: help_wanted
> Fix For: LATER
>
>
> This is a feature request to support a "CLI Batch" file that contains a collection of admin commands that will be run through the cli interface. There will need to be a remote/local notion to support the openshift case of having this file be in the application git repo and applied when pushed vs applied to a local server by invoking the cli tool.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBIDE-9794) Add a CLI batch file feature
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-9794?page=com.atlassian.jira.plugin... ]
Rob Stryker updated JBIDE-9794:
-------------------------------
Labels: help_wanted (was: )
> Add a CLI batch file feature
> ----------------------------
>
> Key: JBIDE-9794
> URL: https://issues.jboss.org/browse/JBIDE-9794
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: server
> Affects Versions: 3.3.0.M3
> Environment: AS7
> Reporter: Scott Stark
> Labels: help_wanted
> Fix For: LATER
>
>
> This is a feature request to support a "CLI Batch" file that contains a collection of admin commands that will be run through the cli interface. There will need to be a remote/local notion to support the openshift case of having this file be in the application git repo and applied when pushed vs applied to a local server by invoking the cli tool.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBIDE-20711) Changing deploy-name in component xml file will not take effect
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20711?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-20711:
--------------------------------
Fix Version/s: (was: 4.3.x)
> Changing deploy-name in component xml file will not take effect
> ---------------------------------------------------------------
>
> Key: JBIDE-20711
> URL: https://issues.jboss.org/browse/JBIDE-20711
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server, upstream
> Affects Versions: 4.3.0.CR1
> Reporter: Rob Stryker
> Assignee: Rob Stryker
> Fix For: 4.4.x
>
>
> Steps to replicate:
> 1) Create a dynamic web project TestProject
> 2) Create a server
> 3) Add/Remove action in servers view. You will see the module name is TestProject
> 4) Open the component.xml file in .settings folder and change deploy-name to some new value (RobsTest)
> 5) Add/Remove, note module name didn't change
> 6) Publish deployment, note its still deploying as TestProject
> 7) Close project, then re-open it
> 8) Add/Remove action, note the module now reads TestProject (RobsTest) (or similar)
> 9) Publish, note module is deployed as RobsTest.war
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBIDE-19454) Malformed strings when starting a remote host via localhost
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19454?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-19454:
--------------------------------
Fix Version/s: 4.4.x
(was: 4.3.x)
> Malformed strings when starting a remote host via localhost
> -----------------------------------------------------------
>
> Key: JBIDE-19454
> URL: https://issues.jboss.org/browse/JBIDE-19454
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.3.Beta1
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.4.x
>
>
> This is strange.
> When I create a remote WildFly 8.2 server on a remote server (I use a SSH-only remote host), everything works fine.
> But when I try to create a remote host that is actually localhost and then start WildFly, I get errors because some of the strings are broken.
> This is in the console in Eclipse:
> {code}
> echo $PWD'>'
> echo $PWD'>'
> java "-Dprogram.name=JBossTools: WildFly 8 remote localhost" -Xms64m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Djava.net.preferIPv4Stack=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true "-Dorg.jboss.boot.log.file=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone/log/boot.log" "-Dlogging.configuration=file:/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone/configuration/logging.properties" "-Djboss.home.dir=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final" -Dorg.jboss.logmanager.nocolor=true -Djboss.bind.address.management=LOCALHOST -jar /Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/jboss-modules.jar -mp "/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/modules" -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -b 0.0.0.0 --server-config=standalone.xml -Djboss.server.base.dir=/Users/rasp/jbossqa/runtimes/wildfly-nattura:/ rasp$
> nattura:/ rasp$ cd /
> echo $PWD'>'
> echo $PWD'>'
> java "-Dprogram.name=JBossTools: WildFly 8 remote localhost" -Xms64m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Djava.net.preferIPv4Stack=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true "-Dorg.jboss.boot.log.file=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone/log/boot.log" "-Dlogging.configuration=file:/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone/configuration/logging.properties" "-Djboss.home.dir=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final" -Dorg.jboss.logmanager.nocolor=true -Djboss.bind.address.management=LOCALHOST -jar /Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/jboss-modules.jar -mp "/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/modules" -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -b 0.0.0.0 --server-config=standalone.xml -Djboss.server.base.dir=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.janattura:/ rasp$
> nattura:/ rasp$ echo $PWD'>'
> echo $PWD'>'
> java "-Dprogram.name=JBossTools: WildFly 8 remote localhost" -Xms64m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Djava.net.preferIPv4Stack=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true "-Dorg.jboss.boot.log.file=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone/log/boot.log" "-Dlogging.configuration=file:/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone/configuration/logging.properties" "-Djboss.home.dir=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final" -Dorg.jboss.logmanager.nocolor=true -Djboss.bind.address.management=LOCALHOST -jar /Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/jboss-modules.jar -mp "/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/modules" -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -b 0.0.0.0 --server-config=standalone.xml -Djboss.server.base.dir=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.javal/java "-Dne&/>
> nattura:/ rasp$ echo $PWD'>'
> />
> java "-Dprogram.name=JBossTools: WildFly 8 remote localhost" -Xms64m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Djava.net.preferIPv4Stack=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true "-Dorg.jboss.boot.log.file=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone/log/boot.log" "-Dlogging.configuration=file:/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone/configuration/logging.properties" "-Djboss.home.dir=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final" -Dorg.jboss.logmanager.nocolor=true -Djboss.bind.address.management=LOCALHOST -jar /Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/jboss-modules.jar -mp "/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/modules" -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -b 0.0.0.0 --server-config=standalone.xml -Djboss.server.base.dir=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.javal/java "-Dne&
> eeeeeeeeTOOLnattura:/ rasp$ java "-Dprogram.name=JBossTools: WildFly 8 remote localhost" -Xm s64m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Djava.net. preferIPv4Stack=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.serve r.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.he adless=true "-Dorg.jboss.boot.log.file=/Users/rasp/jbossqa/runtimes/wildfly-8.2. 0.Final/standalone/log/boot.log" "-Dlogging.configuration=file:/Users/rasp/jboss qa/runtimes/wildfly-8.2.0.Final/standalone/configuration/logging.properties" "-D jboss.home.dir=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final" -Dorg.jboss.log manager.nocolor=true -Djboss.bind.address.management=LOCALHOST -jar /Users/rasp/ jbossqa/runtimes/wildfly-8.2.0.Final/jboss-modules.jar -mp "/Users/rasp/jbossqa /runtimes/wildfly-8.2.0.Final/modules" -jaxpmodule javax.xml.jaxp-provider org.j boss.as.standalone -b 0.0.0.0 --server-config=standalone.xml -Djboss.server.base .dir=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.javal/java "-Dne&
> > eeeeeeeeTOOLS_SERVER_START_CMD:WildFly 8 remote localhost:"$!
> 13:51:37,472 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.3.Final
> java.lang.IllegalStateException: JBAS018702: Server base directory does not exist: /Users/rasp/jbossqa/runtimes/wildfly-8.2.0.javal/java
> at org.jboss.as.server.ServerEnvironment.<init>(ServerEnvironment.java:365)
> at org.jboss.as.server.Main.determineEnvironment(Main.java:262)
> at org.jboss.as.server.Main.main(Main.java:92)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.modules.Module.run(Module.java:312)
> at org.jboss.modules.Main.main(Main.java:460)
> nattura:/ rasp$
> {code}
> The correct path to the server is /Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final as was set up. But for some reason, some of the strings are wrong in the startup command. Most notably this: -Djboss.server.base.dir=/Users/rasp/jbossqa/runtimes/wildfly-8.2.0.javal/java
> PS: I'm on OS X, so it might have something to do with that.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months