[JBoss JIRA] (JBIDE-24048) Import application: would like to be able to provide context-dir
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-24048?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-24048:
-------------------------------------
Attachment: CONTEXT_DIR.png
> Import application: would like to be able to provide context-dir
> ----------------------------------------------------------------
>
> Key: JBIDE-24048
> URL: https://issues.jboss.org/browse/JBIDE-24048
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.4.4.AM1
> Reporter: Andre Dietisheim
> Attachments: CONTEXT_DIR.png, jboss-kitchensink.png
>
>
> We're missing the ability to provide a context dir within a git repo when importing an application from OpenShift. The application wizard allows the user to set a context dir, which is used when importing right after the successfull creation. The (standalone) import is lacking this.
> steps to reproduce:
> # EXEC: launch openshift application wizard and pick "eap64-basic-s2i"
> # ASSERT: in the next page make sure there is "kitchensink" set to the CONTEXT_DIR template parameter
> # EXEC: finish the wizard and once the resources are created, simply confirm the import dialog that pops up
> # ASSERT: you get a "jboss-kitchensink" in your workspace. The import actually cloned the whole repo "jboss-eap-quickstarts" and imported the project within the "kitchensink" (the CONTEXT_DIR) folder as a workspace project
> # EXEC: in OpenShift Explorer: kill your workspace project, select the "eap-app" service and choose "Import Application" in the context-menu.
> # EXEC: in the upcoming import wizard, check "reuse existing repository" and then hit "Finish"
> Result:
> You get a project "jboss-eap-quickstart". There was no way to provide a context dir. To get the kitchensink project you need to remove the jboss-eap-quickstart" project, checkout the correct branch and reimport "kitchensink" (kitchensink only exists in the 6.4.x branch, not in the 7.x branches) manually as an existing maven project.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (JBIDE-24048) Import application: would like to be able to provide context-dir
by Andre Dietisheim (JIRA)
Andre Dietisheim created JBIDE-24048:
----------------------------------------
Summary: Import application: would like to be able to provide context-dir
Key: JBIDE-24048
URL: https://issues.jboss.org/browse/JBIDE-24048
Project: Tools (JBoss Tools)
Issue Type: Enhancement
Components: openshift
Affects Versions: 4.4.4.AM1
Reporter: Andre Dietisheim
We're missing the ability to provide a context dir within a git repo when importing an application from OpenShift. The application wizard allows the user to set a context dir, which is used when importing right after the successfull creation. The (standalone) import is lacking this.
steps to reproduce:
# EXEC: launch openshift application wizard and pick "eap64-basic-s2i"
# ASSERT: in the next page make sure there is "kitchensink" set to the CONTEXT_DIR template parameter
# EXEC: finish the wizard and once the resources are created, simply confirm the import dialog that pops up
# ASSERT: you get a "jboss-kitchensink" in your workspace. The import actually cloned the whole repo "jboss-eap-quickstarts" and imported the project within the "kitchensink" (the CONTEXT_DIR) folder as a workspace project
# EXEC: in OpenShift Explorer: kill your workspace project, select the "eap-app" service and choose "Import Application" in the context-menu.
# EXEC: in the upcoming import wizard, check "reuse existing repository" and then hit "Finish"
Result:
You get a project "jboss-eap-quickstart". There was no way to provide a context dir. To get the kitchensink project you need to remove the jboss-eap-quickstart" project, checkout the correct branch and reimport "kitchensink" (kitchensink only exists in the 6.4.x branch, not in the 7.x branches) manually as an existing maven project.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (JBIDE-18496) Importing EAP "ws*" quickstarts raise errors
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18496?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-18496:
-------------------------------
Fix Version/s: 4.4.4.AM2
(was: 4.4.4.AM1)
> Importing EAP "ws*" quickstarts raise errors
> --------------------------------------------
>
> Key: JBIDE-18496
> URL: https://issues.jboss.org/browse/JBIDE-18496
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: upstream
> Affects Versions: 4.2.0.CR1
> Environment: JBDS 8.0.CR1
> Java 1.7 - OpenJDK
> RHEL6
> Reporter: Len DiMaggio
> Assignee: Fred Bricon
> Fix For: 4.4.4.AM2
>
>
> Steps to recreate issue:
> * Dowload, unzip EAP quickstarts from - http://www.jboss.org/quickstarts/eap
> * Install JBDS8.0.CR1
> * Import-> Existing Maven Projects - select the quickstart
> It looks like this error was logged here - JBIDE-17859 - and was believed to be fixed - but it is still present for these quickstarts.
> The quickstarts are:
> jboss-wsat-simple
> jboss-wsba-coordinator-completion-simple
> jboss-wsba-participant-completion-simple
> cvc-elt.1: Cannot find the declaration of element 'handler-chains'. context-handlers.xml /jboss-wsat-simple/src/main/webapp/WEB-INF/classes line 20 XML Problem
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (JBIDE-17710) error importing kitchensink angularjs quickstart when no jboss-eap runtime available
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17710?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-17710:
-------------------------------
Fix Version/s: 4.4.4.AM2
(was: 4.4.4.AM1)
> error importing kitchensink angularjs quickstart when no jboss-eap runtime available
> ------------------------------------------------------------------------------------
>
> Key: JBIDE-17710
> URL: https://issues.jboss.org/browse/JBIDE-17710
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: hibernate, upstream
> Affects Versions: 4.2.0.Beta2
> Environment: Linux 64 (Fedora 18), JDK 1.8
> Reporter: Nick Boldt
> Assignee: Radim Hopp
> Priority: Critical
> Fix For: 4.4.4.AM2
>
> Attachments: config-jboss-maven.png, error-quickstart-kitchensink-angularjs.png, install-jpa2-NPE.txt, jbds8b3a-jdk8-quickstart-angularjs-launch-NPE-thrown.log.txt, jbds8b3a-jdk8-quickstart-angularjs-launch-no-NPE-thrown-simpler-settings.xml.png, jbds8b3a-jdk8-quickstart-angularjs-launch-no-server-runtime-found-imports-fine-only-1-warning-compiles-ok.png, jbds8b3a-jdk8-quickstart-angularjs-launch-no-server-runtime-found.png, settings.xml
>
>
> 1. install JBDS 8.0.0.Beta2-v20140617-2058-B166 from update site into Eclipse 4.4.0.R Luna JEE bundle.
> 2. Install Arquillian from JBoss Central EA site (using -D flags above)
> 3. launch kitchensink-angularjs quickstart.
> 4. Get NPE installing JPA 2.0
> 5. Get numerous import problems in MemberRegistrationTest.java and other source files; quickfixes don't work.
> Also had the same issues with JBT 4.2.0.Beta2, so it doesn't seem this is a JBDS only issue.
> !error-quickstart-kitchensink-angularjs.png!
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (JBIDE-18983) Project cannot be built. Possible open file handle
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18983?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-18983:
-------------------------------
Fix Version/s: 4.4.4.Final
(was: 4.4.4.AM1)
> Project cannot be built. Possible open file handle
> --------------------------------------------------
>
> Key: JBIDE-18983
> URL: https://issues.jboss.org/browse/JBIDE-18983
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: jsp/jsf/xml/html-source-editing, maven
> Affects Versions: 4.2.1.Final
> Environment: luna x64 windows 8.1 x64
> java 8u25 x64
> Reporter: Cody Lerum
> Assignee: Jeff MAURY
> Fix For: 4.4.4.Final
>
>
> Frequently when working in a Java EE7 project I will get an error like.
> "The project was not built due to "Could not delete '/gp-server/target/classes/META-INF`.". Fix the problem, then try refreshing this project and building since it may be inconsistent.
> I've looked into a process explorer in windows and then this case is happening there is always a javaw.exe process with a file handle to "V:\workspace\gp-server\target\classes\META-INF\persistence.xml
> It looks like either jboss tools or eclipse is holding on to a file handle for this.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (JBIDE-19225) java.lang.IllegalArgumentException: null source after importing WFK Spring projects
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19225?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-19225:
-------------------------------
Fix Version/s: 4.4.4.Final
(was: 4.4.4.AM1)
> java.lang.IllegalArgumentException: null source after importing WFK Spring projects
> -----------------------------------------------------------------------------------
>
> Key: JBIDE-19225
> URL: https://issues.jboss.org/browse/JBIDE-19225
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: project-examples, upstream
> Affects Versions: 4.2.2.Final
> Reporter: Jiri Peterka
> Assignee: Fred Bricon
> Fix For: 4.4.4.Final
>
>
> {code}
> java.lang.IllegalArgumentException: null source
> at java.util.EventObject.<init>(EventObject.java:56)
> at org.springframework.ide.eclipse.core.model.ModelChangeEvent.<init>(ModelChangeEvent.java:43)
> at org.springframework.ide.eclipse.core.model.AbstractModel.notifyListeners(AbstractModel.java:43)
> at org.springframework.ide.eclipse.beans.core.internal.model.BeansModel$ResourceChangeEventHandler.configAdded(BeansModel.java:598)
> at org.springframework.ide.eclipse.beans.core.internal.model.resources.BeansResourceChangeListener$BeansResourceVisitor.resourceAdded(BeansResourceChangeListener.java:97)
> at org.springframework.ide.eclipse.core.internal.model.resources.SpringResourceChangeListener$SpringResourceVisitor.visit(SpringResourceChangeListener.java:145)
> at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:69)
> at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80)
> at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80)
> at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80)
> at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80)
> at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80)
> at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80)
> at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80)
> at org.springframework.ide.eclipse.core.internal.model.resources.SpringResourceChangeListener.resourceChanged(SpringResourceChangeListener.java:83)
> at org.eclipse.core.internal.events.NotificationManager$1.run(NotificationManager.java:291)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:285)
> at org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:149)
> at org.eclipse.core.internal.resources.Workspace.broadcastBuildEvent(Workspace.java:364)
> at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:146)
> at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (JBIDE-19182) Incremental Publish after Full Publish WRT dodeploy markers
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19182?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-19182:
-------------------------------
Fix Version/s: 4.4.4.Final
(was: 4.4.4.AM1)
> 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
> Assignee: Rob Stryker
> Fix For: 4.4.4.Final
>
>
> 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
(v7.2.3#72005)
9 years
[JBoss JIRA] (JBIDE-19368) File not deployed to server on Windows
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19368?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-19368:
-------------------------------
Fix Version/s: 4.4.4.AM2
(was: 4.4.4.AM1)
> 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.4.AM2
>
> 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
(v7.2.3#72005)
9 years
[JBoss JIRA] (JBIDE-19454) Malformed strings when starting a remote host via localhost
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19454?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-19454:
-------------------------------
Fix Version/s: 4.4.4.AM2
(was: 4.4.4.AM1)
> 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.4.AM2
>
>
> 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
(v7.2.3#72005)
9 years