[JBoss JIRA] (JBIDE-19391) Properties File editor does not work properly
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19391?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-19391:
-------------------------------
Fix Version/s: 4.4.3.AM1
(was: 4.3.x)
> Properties File editor does not work properly
> ---------------------------------------------
>
> Key: JBIDE-19391
> URL: https://issues.jboss.org/browse/JBIDE-19391
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: common
> Reporter: Ali Hopyar
> Assignee: Viacheslav Kabanovich
> Fix For: 4.4.3.AM1
>
> Attachments: messages_en.properties
>
>
> On eclipse luna, I can not use JBoss editor for properties files. When I clicked add button nothing happens. When I click source tab and try to add some property, it is disappears when saved. Also if I open a property file that has been written before, also its content disappears.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[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.3.AM1
(was: 4.4.x)
> 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.3.AM1
>
> 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, 3 months
[JBoss JIRA] (JBIDE-19342) Update code to cope with generics added to org.eclipse.core.runtime package API
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19342?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-19342:
-------------------------------
Fix Version/s: 4.5.0.AM1
(was: 4.4.x)
> Update code to cope with generics added to org.eclipse.core.runtime package API
> --------------------------------------------------------------------------------
>
> Key: JBIDE-19342
> URL: https://issues.jboss.org/browse/JBIDE-19342
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: aerogear-hybrid, archives, batch, bean-validation, birt, browsersim, cdi, cdi-extensions, central, common, cordovasim, forge, hibernate, integration-platform, jmx, jsf, jsp/jsf/xml/html-source-editing
> Affects Versions: 4.3.0.Alpha2
> Reporter: Fred Bricon
> Priority: Minor
> Fix For: 4.5.0.AM1
>
>
> We need to detect and address any part of our code affected by generics added to the org.eclipse.core.runtime package API.
> From https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg11590.html :
> {quote}
> See https://bugs.eclipse.org/bugs/show_bug.cgi?id=442021
> Markus Keller wrote up an nice summary of what consumers should do to fix any warnings that may be caused by this change at https://bugs.eclipse.org/bugs/show_bug.cgi?id=442021#c25
> Here is a copy of the recommendations if you are going to compile against the latest version of org.eclipse.equinox.common:
> 1. In MANIFEST.MF, update your Require-Bundle: org.eclipse.core.runtime;bundle-version="[3.11.0,4.0.0)", or org.eclipse.equinox.common;bundle-version="[3.7.0,4.0.0)", or update your Import-Package: org.eclipse.core.runtime; version="[3.5,4.0)"
> 2. If your bundle re-exports one of these bundles, then you also have to make sure the minor version is incremented.
> 3. Remove unnecessary casts (Clean Up, or Problems view > Quick Fix > Select All)
> 4. Update implementations of IAdaptable#getAdapter(Class<T>), unless you override another implementation of that method that still uses the old signature.
> Typical change:
> Old:
> {code}
> public Object getAdapter(Class adapter) {
> if (ICompilationUnit.class.equals(adapter))
> return getCompilationUnit();
> return null;
> }
> {code}
> New:
> {code}
> public <T> T getAdapter(Class<T> adapter) {
> if (ICompilationUnit.class.equals(adapter))
> return adapter.cast(getCompilationUnit());
> return null;
> }
> {code}
> 5. Update implementations of IAdapterFactory
> Hint for 4. & 5.:
> - Open Type Hierarchy on IAdaptable, etc.
> - In the view menu, select a working set that contains your projects
> - In the methods list of the Type Hierarchy view, select the methods, and then click the first toolbar button (Lock View and Show Members in Hierarchy)
> {quote}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (JBIDE-23641) Jboss AS Eclipse plugin freezes STS on Mac OS Sierra
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23641?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-23641:
---------------------------------------
[~fedepia], I'm not really sure, perhaps [~jeffmaury] will have some ideas.
Maybe you could try to start your Eclipse with a new workspace and see if it still freezes?
> Jboss AS Eclipse plugin freezes STS on Mac OS Sierra
> ----------------------------------------------------
>
> Key: JBIDE-23641
> URL: https://issues.jboss.org/browse/JBIDE-23641
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server, upstream
> Reporter: fede pia
> Assignee: Rob Stryker
> Priority: Blocker
> Fix For: 4.4.3.AM1
>
> Attachments: eclipse.log
>
>
> When installing Jboss Tool 4.4.2 (only Jboss AS plugin) in Spring Tool Suite in a Mac, the Eclipse hangs up and needs to be killed
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[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.3.AM1
(was: 4.4.x)
> 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.3.AM1
>
>
> {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, 3 months
[JBoss JIRA] (JBIDE-19181) correct naming of internal packages so that they're consistent across all openshift plugins
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19181?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-19181:
-------------------------------
Fix Version/s: 4.5.0.AM1
(was: 4.4.x)
> correct naming of internal packages so that they're consistent across all openshift plugins
> -------------------------------------------------------------------------------------------
>
> Key: JBIDE-19181
> URL: https://issues.jboss.org/browse/JBIDE-19181
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: openshift
> Affects Versions: 4.3.0.Alpha1
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Fix For: 4.5.0.AM1
>
>
> Internal packages across the openshift plugins are non-consistent:
> ex.
> org.jboss.tools.openshift.client: org.jboss.tools.openshift.client.internal
> org.jboss.tools.openshift.express.client: org.jboss.tools.openshift.express.client.internal
> the base is imho org.jboss.tools.openshift and thus internal packages should always be at org.jboss.tools.openshift.internal across plugins.
> For reference, here's the official Eclipse documentation on the topic: http://wiki.eclipse.org/index.php/Naming_Conventions#Java_Packages
> {quote}
> org.eclipse.jdt.internal.core.compiler - Correct usage
> org.eclipse.jdt.core.internal.compiler - Incorrect. internal should immediately follow subproject name.
> org.eclipse.core.internal.resources - Correct usage
> org.eclipse.internal.core.resources - Incorrect. internal should never immediately follow org.eclipse.
> org.eclipse.core.resources.internal - Incorrect. internal should immediately follow Eclipse Platform component name.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[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.3.AM1
(was: 4.4.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.3.AM1
>
>
> 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, 3 months
[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.3.AM1
(was: 4.2.x)
(was: 4.3.x)
> 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
> Fix For: 4.4.3.AM1
>
>
> 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, 3 months