[JBoss JIRA] (JBIDE-11104) ConcurrentModificationException
by Xavier Coulon (JIRA)
Xavier Coulon created JBIDE-11104:
-------------------------------------
Summary: ConcurrentModificationException
Key: JBIDE-11104
URL: https://issues.jboss.org/browse/JBIDE-11104
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: Webservices
Affects Versions: 3.3.0.Beta1
Reporter: Xavier Coulon
Assignee: Xavier Coulon
Fix For: 3.3.0.CR1
Create an OpenShift application. After it has been imported, the project is built, resulting in
{code}
!MESSAGE Errors running builder 'JAX-RS Builder' on project 'sample2'.
!STACK 0
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.remove(HashMap.java:811)
at org.jboss.tools.ws.jaxrs.core.internal.metamodel.domain.JaxrsMetamodel.unindexElement(JaxrsMetamodel.java:253)
at org.jboss.tools.ws.jaxrs.core.internal.metamodel.domain.JaxrsMetamodel.indexElement(JaxrsMetamodel.java:177)
at org.jboss.tools.ws.jaxrs.core.internal.metamodel.domain.JaxrsMetamodel.add(JaxrsMetamodel.java:158)
at org.jboss.tools.ws.jaxrs.core.internal.metamodel.builder.ResourceChangedProcessor.postProcessHttpMethod(ResourceChangedProcessor.java:479)
at org.jboss.tools.ws.jaxrs.core.internal.metamodel.builder.ResourceChangedProcessor.processHttpMethodChangesOnScopeAdditionOrChange(ResourceChangedProcessor.java:387)
at org.jboss.tools.ws.jaxrs.core.internal.metamodel.builder.ResourceChangedProcessor.processEvent(ResourceChangedProcessor.java:176)
at org.jboss.tools.ws.jaxrs.core.internal.metamodel.builder.ResourceChangedProcessor.processEntireProject(ResourceChangedProcessor.java:108)
at org.jboss.tools.ws.jaxrs.core.internal.metamodel.builder.ResourceChangedProcessor.processAffectedResources(ResourceChangedProcessor.java:83)
at org.jboss.tools.ws.jaxrs.core.internal.metamodel.builder.JaxrsMetamodelBuilder.build(JaxrsMetamodelBuilder.java:123)
at org.jboss.tools.ws.jaxrs.core.internal.metamodel.builder.JaxrsMetamodelBuilder.build(JaxrsMetamodelBuilder.java:83)
at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:728)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:239)
at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:292)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:295)
at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:351)
at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:374)
at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143)
at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] (JBIDE-11308) server adapter adds .dodeploy before Clean/publish has finished
by Max Rydahl Andersen (JIRA)
Max Rydahl Andersen created JBIDE-11308:
-------------------------------------------
Summary: server adapter adds .dodeploy before Clean/publish has finished
Key: JBIDE-11308
URL: https://issues.jboss.org/browse/JBIDE-11308
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: JBossAS/Servers
Reporter: Max Rydahl Andersen
Assignee: Rob Stryker
Priority: Critical
Fix For: 3.3.0.Beta2
EXECUTE: import decent sized project, i.e. GWT project from central and follo the readme regarding tooling
EXECUTE: after Run As have been done, right click server and press Clean...
ASSERT: clean is done and publish goes on and then in the end .dodeploy file occurrs
What actually seem to happen is deploymen is removed, dir added, then .dodeploy and *then* file copying occurs - causing the scanner to pickup partially deployed project.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Created: (JBIDE-9356) NLS.bind vs MessageFormat.format
by Rob Stryker (JIRA)
NLS.bind vs MessageFormat.format
--------------------------------
Key: JBIDE-9356
URL: https://issues.jboss.org/browse/JBIDE-9356
Project: Tools (JBoss Tools)
Issue Type: Task
Components: Cleanup
Affects Versions: 3.3.0.M3
Reporter: Rob Stryker
Assignee: Max Rydahl Andersen
Fix For: 3.3.0.Final
A substantial number of classes use NLS.bind(Messages.SomeString, name) to bind message strings. Another subset of the classes use MessageFormat.format(etc).
I believe NLS.bind() is the correct solution which works properly with eclipse osgi and all that jazz. Should this be standardized? Is it confusing to be using two interchangable APIs?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months