[JBoss JIRA] Created: (JBIDE-5820) SeamAllTests.testButton test fails with java.util.ConcurrentModificationException
by Nick Boldt (JIRA)
SeamAllTests.testButton test fails with java.util.ConcurrentModificationException
---------------------------------------------------------------------------------
Key: JBIDE-5820
URL: https://jira.jboss.org/jira/browse/JBIDE-5820
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: Seam
Affects Versions: 3.1.0.CR2
Reporter: Nick Boldt
Assignee: Max Rydahl Andersen
Stack trace:
java.util.ConcurrentModificationException
at org.eclipse.emf.common.util.ArrayDelegatingEList$EIterator.checkModCount(ArrayDelegatingEList.java:885)
at org.eclipse.emf.common.util.AbstractEList$EIterator.doNext(AbstractEList.java:710)
at org.eclipse.emf.common.util.AbstractEList$EIterator.next(AbstractEList.java:696)
at org.eclipse.emf.common.notify.impl.AdapterFactoryImpl.adapt(AdapterFactoryImpl.java:86)
at org.eclipse.wst.dtd.core.internal.contentmodel.DTDImpl$DTDAdapterFactoryImpl.adapt(DTDImpl.java:139)
at org.eclipse.wst.dtd.core.internal.contentmodel.DTDImpl.getAdapter(DTDImpl.java:97)
at org.eclipse.wst.dtd.core.internal.contentmodel.DTDImpl$DTDFileAdapter.getElements(DTDImpl.java:661)
at org.eclipse.wst.html.core.internal.modelquery.CMDocumentForBuddySystem.getElements(CMDocumentForBuddySystem.java:90)
at org.eclipse.wst.xml.core.internal.contentmodel.modelqueryimpl.SimpleAssociationProvider.getCMElementDeclaration(SimpleAssociationProvider.java:45)
at org.eclipse.wst.xml.core.internal.contentmodel.modelqueryimpl.ModelQueryImpl.getCMElementDeclaration(ModelQueryImpl.java:116)
at org.eclipse.wst.html.core.internal.modelquery.HTMLModelQueryImpl.getCMElementDeclaration(HTMLModelQueryImpl.java:149)
at org.eclipse.wst.html.core.internal.validate.CMUtil.getDeclaration(CMUtil.java:47)
at org.eclipse.wst.html.core.internal.validate.HTMLAttributeValidator.validate(HTMLAttributeValidator.java:99)
at org.eclipse.wst.html.core.internal.validate.CompositeValidator.validate(CompositeValidator.java:54)
at org.eclipse.wst.xml.core.internal.validate.AbstractPropagatingValidator.validate(AbstractPropagatingValidator.java:38)
at org.eclipse.wst.xml.core.internal.validate.AbstractPropagatingValidator.propagateToChildElements(AbstractPropagatingValidator.java:60)
at org.eclipse.wst.xml.core.internal.validate.AbstractPropagatingValidator.validate(AbstractPropagatingValidator.java:40)
at org.eclipse.wst.html.core.internal.validate.DocumentPropagatingValidator.validate(DocumentPropagatingValidator.java:32)
at org.eclipse.wst.html.internal.validation.HTMLValidator.validate(HTMLValidator.java:432)
at org.eclipse.wst.html.internal.validation.HTMLValidator.validateFile(HTMLValidator.java:494)
at org.eclipse.wst.html.internal.validation.HTMLValidator.validateDelta(HTMLValidator.java:476)
at org.eclipse.wst.html.internal.validation.HTMLValidator.validate(HTMLValidator.java:239)
at org.eclipse.wst.sse.ui.internal.reconcile.validator.ReconcileStepForValidator.validate(ReconcileStepForValidator.java:292)
at org.eclipse.wst.sse.ui.internal.reconcile.validator.ReconcileStepForValidator.reconcileModel(ReconcileStepForValidator.java:258)
at org.eclipse.jface.text.reconciler.AbstractReconcileStep.reconcile(AbstractReconcileStep.java:95)
at org.eclipse.wst.sse.ui.internal.reconcile.validator.ValidatorStrategy.reconcile(ValidatorStrategy.java:257)
at org.eclipse.wst.sse.ui.internal.reconcile.DocumentRegionProcessor.process(DocumentRegionProcessor.java:199)
at org.eclipse.wst.sse.ui.internal.reconcile.StructuredRegionProcessor.process(StructuredRegionProcessor.java:221)
at org.eclipse.wst.sse.ui.internal.reconcile.DirtyRegionProcessor.run(DirtyRegionProcessor.java:641)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
http://hudson.qa.jboss.com/hudson/view/DevStudio/job/jbosstools-nightly-3...
Test has been failing for 8 builds.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 4 months
[JBoss JIRA] Created: (JBIDE-5863) "Make Deployable" should be persisted together with the project
by Max Rydahl Andersen (JIRA)
"Make Deployable" should be persisted together with the project
---------------------------------------------------------------
Key: JBIDE-5863
URL: https://jira.jboss.org/jira/browse/JBIDE-5863
Project: Tools (JBoss Tools)
Issue Type: Feature Request
Components: JBossAS
Affects Versions: 3.1.0.GA
Reporter: Max Rydahl Andersen
Assignee: Rob Stryker
Fix For: 3.2.next
Today "Make Deployable" seem to only be stored locally in workspace data or together with a server.
This causes problems when importing an existing project from svn, filesystem, project examples etc. that the files that already have been marked as deployable
does not continue to be so.
Shouldn't the status of being "Deployable" be something we persist per resource/project and then pick it up when you import such a project?
(not sure if this is a duplicate, but couldn't find it)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 4 months
[JBoss JIRA] Created: (JBIDE-5821) RichFacesAllTests.testContextMenu fails with java.util.ConcurrentModificationException
by Nick Boldt (JIRA)
RichFacesAllTests.testContextMenu fails with java.util.ConcurrentModificationException
--------------------------------------------------------------------------------------
Key: JBIDE-5821
URL: https://jira.jboss.org/jira/browse/JBIDE-5821
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: Visual Page Editor core
Affects Versions: 3.1.0.CR2
Reporter: Nick Boldt
Assignee: Max Rydahl Andersen
Stacktrace
java.util.ConcurrentModificationException
at org.eclipse.emf.common.util.ArrayDelegatingEList$EIterator.checkModCount(ArrayDelegatingEList.java:885)
at org.eclipse.emf.common.util.AbstractEList$EIterator.doNext(AbstractEList.java:710)
at org.eclipse.emf.common.util.AbstractEList$EIterator.next(AbstractEList.java:696)
at org.eclipse.emf.common.notify.impl.AdapterFactoryImpl.adapt(AdapterFactoryImpl.java:86)
at org.eclipse.wst.dtd.core.internal.contentmodel.DTDImpl$DTDAdapterFactoryImpl.adapt(DTDImpl.java:139)
at org.eclipse.wst.dtd.core.internal.contentmodel.DTDImpl.getAdapter(DTDImpl.java:97)
at org.eclipse.wst.dtd.core.internal.contentmodel.DTDImpl$DTDFileAdapter.getElements(DTDImpl.java:661)
at org.eclipse.wst.html.core.internal.modelquery.CMDocumentForBuddySystem.getElements(CMDocumentForBuddySystem.java:90)
at org.eclipse.wst.xml.core.internal.contentmodel.modelqueryimpl.SimpleAssociationProvider.getCMElementDeclaration(SimpleAssociationProvider.java:45)
at org.eclipse.wst.xml.core.internal.contentmodel.modelqueryimpl.ModelQueryImpl.getCMElementDeclaration(ModelQueryImpl.java:116)
at org.eclipse.wst.html.core.internal.modelquery.HTMLModelQueryImpl.getCMElementDeclaration(HTMLModelQueryImpl.java:149)
at org.eclipse.wst.html.core.internal.validate.CMUtil.getDeclaration(CMUtil.java:47)
at org.eclipse.wst.html.core.internal.validate.HTMLAttributeValidator.validate(HTMLAttributeValidator.java:99)
at org.eclipse.wst.html.core.internal.validate.CompositeValidator.validate(CompositeValidator.java:54)
at org.eclipse.wst.xml.core.internal.validate.AbstractPropagatingValidator.validate(AbstractPropagatingValidator.java:38)
at org.eclipse.wst.xml.core.internal.validate.AbstractPropagatingValidator.propagateToChildElements(AbstractPropagatingValidator.java:60)
at org.eclipse.wst.xml.core.internal.validate.AbstractPropagatingValidator.validate(AbstractPropagatingValidator.java:40)
at org.eclipse.wst.html.core.internal.validate.DocumentPropagatingValidator.validate(DocumentPropagatingValidator.java:32)
at org.eclipse.wst.html.internal.validation.HTMLValidator.validate(HTMLValidator.java:432)
at org.eclipse.wst.html.internal.validation.HTMLValidator.validateFile(HTMLValidator.java:494)
at org.eclipse.wst.html.internal.validation.HTMLValidator.validateDelta(HTMLValidator.java:476)
at org.eclipse.wst.html.internal.validation.HTMLValidator.validate(HTMLValidator.java:239)
at org.eclipse.wst.sse.ui.internal.reconcile.validator.ReconcileStepForValidator.validate(ReconcileStepForValidator.java:292)
at org.eclipse.wst.sse.ui.internal.reconcile.validator.ReconcileStepForValidator.reconcileModel(ReconcileStepForValidator.java:258)
at org.eclipse.jface.text.reconciler.AbstractReconcileStep.reconcile(AbstractReconcileStep.java:95)
at org.eclipse.wst.sse.ui.internal.reconcile.validator.ValidatorStrategy.reconcile(ValidatorStrategy.java:257)
at org.eclipse.wst.sse.ui.internal.reconcile.DocumentRegionProcessor.process(DocumentRegionProcessor.java:199)
at org.eclipse.wst.sse.ui.internal.reconcile.StructuredRegionProcessor.process(StructuredRegionProcessor.java:221)
at org.eclipse.wst.sse.ui.internal.reconcile.DirtyRegionProcessor.run(DirtyRegionProcessor.java:641)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 4 months
[JBoss JIRA] Created: (JBIDE-5460) VPE NPE exception during bundle loading
by Yura Zhishko (JIRA)
VPE NPE exception during bundle loading
---------------------------------------
Key: JBIDE-5460
URL: https://jira.jboss.org/jira/browse/JBIDE-5460
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: Visual Page Editor core
Affects Versions: 3.1.0.CR1
Reporter: Yura Zhishko
Assignee: Yura Zhishko
Fix For: 3.1.0.GA
1) Import TestComp5.zip project as jsf project into workspace
2) Extract second project and rename it to TestComp5 as a first project
3) Open loacally workspace directory and remove TestComp5 project from a first step
4) Copy TestComp5 from a second step to workspace directory
5) Go to Package Explorer
6) Refresh TestComp5 project
7) Open WebContent -> pages -> allComponents.xhtml
RESULT: VE preview is empty and exception in error log
org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.NullPointerException)
at org.eclipse.swt.SWT.error(SWT.java:3884)
at org.eclipse.swt.SWT.error(SWT.java:3799)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:137)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3855)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3476)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2405)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2369)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2221)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:500)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:493)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:194)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:368)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514)
at org.eclipse.equinox.launcher.Main.run(Main.java:1311)
at org.eclipse.equinox.launcher.Main.main(Main.java:1287)
Caused by: java.lang.NullPointerException
at org.jboss.tools.vpe.editor.bundle.BundleMap.refreshRegisteredBundles(BundleMap.java:100)
at org.jboss.tools.vpe.editor.bundle.BundleMap.refresh(BundleMap.java:343)
at org.jboss.tools.vpe.editor.VpeController.refreshTemplates(VpeController.java:1689)
at org.jboss.tools.vpe.editor.VpeEditorPart$ActivationListener.handleActivation(VpeEditorPart.java:1075)
at org.jboss.tools.vpe.editor.VpeEditorPart$ActivationListener.access$1(VpeEditorPart.java:1064)
at org.jboss.tools.vpe.editor.VpeEditorPart$ActivationListener$1.run(VpeEditorPart.java:1059)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134)
... 23 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 4 months
[JBoss JIRA] Created: (JBIDE-5850) JBT Project Examples only includes SEAM & RESTEasy (& BPEL)
by Brian Fitzpatrick (JIRA)
JBT Project Examples only includes SEAM & RESTEasy (& BPEL)
-----------------------------------------------------------
Key: JBIDE-5850
URL: https://jira.jboss.org/jira/browse/JBIDE-5850
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: project-examples
Reporter: Brian Fitzpatrick
Assignee: Snjezana Peco
Priority: Critical
Fix For: 3.1.0.CR2
So in the latest build (JBossTools-Update-3.1.0.v201002121842M-H244-CR2.zip), when you install all of JBT, we're only seeing BPEL, SEAM, & RESTEasy examples when we should be seeing many more.
I spoke with Max and we're wondering if you copied all the JBDS examples to the JBT site but didn't leave them also in the JBT site. JBDS should be a subset of the examples available for JBT, not the other way around. :)
Can we copy the JBDS examples back to JBT and just not include the JBT-only examples (like BPEL) for JBDS?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 4 months
[JBoss JIRA] Commented: (JBDS-1110) reconfigure .htaccess rules for devstudio.jboss.com
by Nick Boldt (JIRA)
[ https://jira.jboss.org/jira/browse/JBDS-1110?page=com.atlassian.jira.plug... ]
Nick Boldt commented on JBDS-1110:
----------------------------------
02/22/2010, from helpdesk
> I'm routing to the AMS team. I think they have an idea on how to help.
> Best Regards,
> Matthew Mosesohn
02/22/2010, from nboldt
> I'm happy to "own" the maintenance of this server... at least as far as I can. But bear in mind I'm not co-located where the server is, nor do I have physical access to it. > So really the best approach here is IMHO to have a defined process for me to make simple tech support requests of the IT personnel who do have root access to this box.
> The last time we had a problem, the server had run out of space - not something I could fix with my limited sftp access.
> This time the issue is .htaccess file updates. I can put the files myself on the wallace server, but I cannot guarantee they'll arrive on devstudio.jboss.com; if your rsync rule excludes .dotfiles, I'm stuck filing helpdesk tickets like this one. :)
02/23/2010, from helpdesk
> I would recommend that we turn on overrides on that directory for authentication and authorization configurations. Then you will be able to create .htaccess files and control access through that. Would that be acceptable to you?
02/23/2010, from nboldt
> If by "that directory" you mean nboldt@wallace.redhat.com:/mnt/devstudio/, then by all means. If I can push changes to these dirs myself, then I need not inconvenience you guys, and everyone wins. :)
> Can you guarantee that changes I make to the .htaccess files in that folder (and its children) will be synched to http(s)://devstudio.jboss.com/ (and its children) ?
02/23/2010, from helpdesk
> The directory on wallace is synced out to the datacenter and served from the proxies as is. Thus, when you add .htaccess files on wallace, it should take effect on the proxies after a short delay.
> I will put the change request in to make this happen. But we won't be able to enable it till after March 10th due to the End of Quarter Freeze. Will this work for you? If not we can seek approval from the CIO. Thanks.
02/23/2010, from nboldt
> When *can* it be enabled, if not by March 10? A week later? April 1?
> Alternatively, how long would CIO approval take?
02/23/2010, from helpdesk
> It could be done by the Monday of the next week (March 15th) with out any problems. If you need it before then we could look into completing it on March 11th.
> CIO approval can happen as business needs dictate. Basically if you need it done before March 11th, let me know when you need it by and I'll let you know what will be needed on your part. Contact with your organization's IT Relationship Manager will be needed at a minimum for a EOQ Freeze change.
02/23/2010, from nboldt
> Mar 15 is fine. Thanks!
> reconfigure .htaccess rules for devstudio.jboss.com
> ---------------------------------------------------
>
> Key: JBDS-1110
> URL: https://jira.jboss.org/jira/browse/JBDS-1110
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Task
> Components: updatesite
> Affects Versions: 3.0.0.CR3
> Reporter: Nick Boldt
> Assignee: prakash aradhya
> Priority: Critical
> Fix For: 3.0.1.GA
>
>
> Problem
> -----------
> Currently we host update site files and some Early Access (EA) JBoss Dev Studio (JBDS) installers (.jar) on http(s)://devstudio.jboss.com.
> Everyone using the site shares the same access, which is somewhat painful for several reasons:
> a) No one can "discover" what's on the site because the root folder is restricted.
> b) EA users and existing registered JBDS users may not be the same folks; in fact, we may want to provide *FREE* EA access to encourage people to try-before-buy the forthcoming JBDS release, independent of possibly being an existing subscriber.
> c) Each annual release of JBDS gets a year of updates, but only for the product for which they subscribed; thus each year's update site should be differently restricted rather than using the shared across-the-board login.
> Ideally, username/password restriction would be fed by information in the CSP so that users would only need a single login, which would expire the minute their subscription expired, rather than using shared passwords via .htaccess; however, that requires significantly (?) more effort than the solution proposed below.
> Solution
> -----------
> a) remove .htaccess username/password restriction for these folders:
> http://devstudio.jboss.com/
> http://devstudio.jboss.com/updates/
> http://devstudio.jboss.com/earlyaccess/
> b) add .htaccess username/password restriction for these folders:
> http://devstudio.jboss.com/updates/2.1/ (use existing username/password)
> http://devstudio.jboss.com/updates/3.0/ (create new username/password)
> http://devstudio.jboss.com/earlyaccess/builds/ (use existing username/password + create second new username/password)
> I will send the current login details & proposed new ones along in an email to helpdesk@ so that they're not copied publicly here.
> Note that JBDS 3.0 is scheduled to be released March 10, and we need to get these changes in place before then.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 4 months