[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.AM2
(was: 4.4.3.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.3.AM2
>
>
> {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, 2 months
[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.AM2
(was: 4.4.3.AM1)
> 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.AM2
>
> 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, 2 months
[JBoss JIRA] (JBIDE-20711) Changing deploy-name in component xml file will not take effect
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20711?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-20711:
-------------------------------
Fix Version/s: 4.4.3.AM2
(was: 4.4.3.AM1)
> 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.3.AM2
>
>
> 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
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JBIDE-22805) Add Scale... menus on Pod resources
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22805?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-22805:
-------------------------------
Fix Version/s: 4.4.3.AM2
(was: 4.4.3.AM1)
> Add Scale... menus on Pod resources
> -----------------------------------
>
> Key: JBIDE-22805
> URL: https://issues.jboss.org/browse/JBIDE-22805
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.4.1.AM1
> Reporter: Fred Bricon
> Assignee: Viacheslav Kabanovich
> Labels: new_and_noteworthy
> Fix For: 4.4.3.AM2
>
>
> I'm regularly confused/frustrated to not find the Scale... menus on the running pods. Each time I need to slap myself in the face to remind me I need to go to the Service level.
> I think it'd be more intuitive if the scale menus were present on the running pods (not on the build ones).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 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.AM2
(was: 4.4.3.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
> Fix For: 4.4.3.AM2
>
>
> 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, 2 months
[JBoss JIRA] (JBIDE-17698) Server view could show all deployed modules, obtained from the server
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17698?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-17698:
-------------------------------
Fix Version/s: 4.4.3.AM2
(was: 4.4.3.AM1)
> Server view could show all deployed modules, obtained from the server
> ---------------------------------------------------------------------
>
> Key: JBIDE-17698
> URL: https://issues.jboss.org/browse/JBIDE-17698
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: server
> Affects Versions: 4.2.0.Beta2
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.4.3.AM2
>
>
> Pavol Srna pointed out to me that when he deletes a project in workspace while it's deployed on a running AS7, it disappears from the server view and he can't undeploy it from Eclipse.
> I understand that this is somewhat expected, but we have a suggestion: Could the server view get its deployed modules from the server via the management api and use that to show the modules? Similar to what the web console of AS7/WildFly/EAP6 shows.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 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.AM2
(was: 4.4.3.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.3.AM2
>
>
> 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, 2 months
[JBoss JIRA] (JBIDE-20346) Jts quickstart (EAP 6.4) contains XML validation errors
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20346?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-20346:
-------------------------------
Fix Version/s: 4.4.3.AM2
(was: 4.4.3.AM1)
> Jts quickstart (EAP 6.4) contains XML validation errors
> -------------------------------------------------------
>
> Key: JBIDE-20346
> URL: https://issues.jboss.org/browse/JBIDE-20346
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: project-examples, upstream
> Affects Versions: 4.3.0.Beta2
> Environment: JBDS 9.0.0.Beta2
> Reporter: Radim Hopp
> Fix For: 4.4.3.AM2
>
>
> jts quickstart contains XML validation errors after import:
> {noformat}
> cvc-complex-type.2.4.a: Invalid content was found starting with element 'iiop:binding-name'. One of '{"urn:iiop":ejb-name}' is expected. jboss-ejb3.xml /jboss-jts-application-component-2/src/main/resources/META-INF line 30 XML Problem
> {noformat}
> {noformat}
> Referenced file contains errors (jar:file:/home/rhopp/eclipse/jbdevstudio-9.0.0.Beta2/studio/plugins/org.jboss.tools.as.catalog_3.1.0.Beta2-v20150716-2030-B26.jar!/schema/xsd/jboss-ejb3-spec-2_0.xsd). For more information, right click on the message in the Problems View and select "Show Details..." jboss-ejb3.xml /jboss-jts-application-component-2/src/main/resources/META-INF line 1 XML Problem
> {noformat}
> The same error was once reported in JBIDE-17871, but that jira was closed as duplicate (of JBIDE-12990), but this error is not in the original (JBIDE-12990) issue.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months