[JBoss JIRA] (JBIDE-17715) JAX-RS metamodel failed to build/refresh due to StringIndexOutOfBoundsException
by Xavier Coulon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17715?page=com.atlassian.jira.plugi... ]
Xavier Coulon commented on JBIDE-17715:
---------------------------------------
[~rrabara],
Can you still reproduce the issue with the latest changes ? If so, can you put the content of the class being edited, so that I can reproduce the problem ?
Thanks
> JAX-RS metamodel failed to build/refresh due to StringIndexOutOfBoundsException
> -------------------------------------------------------------------------------
>
> Key: JBIDE-17715
> URL: https://issues.jboss.org/browse/JBIDE-17715
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: webservices
> Affects Versions: 4.2.0.Beta3
> Environment: JBoss WebServices Tools 1.7.0.Beta3-v20140628-0157-B555
> Reporter: Radoslav Rábara
> Assignee: Xavier Coulon
> Fix For: 4.2.0.Beta3
>
>
> While editing bean class, an error occurred: "Failed to build or refresh the JAX-RS metamodel".
> {code}
> java.lang.StringIndexOutOfBoundsException: String index out of range: -9
> at java.lang.String.substring(String.java:1911)
> at org.jboss.tools.ws.jaxrs.core.internal.metamodel.domain.JaxrsEndpoint.getDisplayablePathTemplate(JaxrsEndpoint.java:446)
> at org.jboss.tools.ws.jaxrs.core.internal.metamodel.domain.JaxrsEndpoint.refreshUriPathTemplate(JaxrsEndpoint.java:327)
> at org.jboss.tools.ws.jaxrs.core.internal.metamodel.domain.JaxrsEndpoint.update(JaxrsEndpoint.java:234)
> at org.jboss.tools.ws.jaxrs.core.internal.metamodel.builder.JaxrsElementChangedProcessorDelegate.processChange(JaxrsElementChangedProcessorDelegate.java:394)
> at org.jboss.tools.ws.jaxrs.core.internal.metamodel.builder.JaxrsElementChangedProcessorDelegate.processEvent(JaxrsElementChangedProcessorDelegate.java:100)
> at org.jboss.tools.ws.jaxrs.core.internal.metamodel.domain.JaxrsMetamodel.processElementChange(JaxrsMetamodel.java:712)
> at org.jboss.tools.ws.jaxrs.core.internal.metamodel.domain.JaxrsMetamodel.update(JaxrsMetamodel.java:734)
> at org.jboss.tools.ws.jaxrs.core.internal.metamodel.domain.JaxrsJavaElement.updateAnnotation(JaxrsJavaElement.java:223)
> at org.jboss.tools.ws.jaxrs.core.internal.metamodel.domain.JaxrsMetamodel.processJavaAnnotationChange(JaxrsMetamodel.java:492)
> at org.jboss.tools.ws.jaxrs.core.internal.metamodel.domain.JaxrsMetamodel.processJavaElementChange(JaxrsMetamodel.java:421)
> at org.jboss.tools.ws.jaxrs.core.internal.metamodel.builder.JavaElementChangedBuildJob.run(JavaElementChangedBuildJob.java:75)
> at org.jboss.tools.ws.jaxrs.core.internal.metamodel.builder.JavaElementChangedBuildJob.execute(JavaElementChangedBuildJob.java:44)
> at org.jboss.tools.ws.jaxrs.core.internal.metamodel.builder.JavaElementChangedListener.elementChanged(JavaElementChangedListener.java:69)
> at org.eclipse.jdt.internal.core.DeltaProcessor$4.run(DeltaProcessor.java:1695)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.jdt.internal.core.DeltaProcessor.notifyListeners(DeltaProcessor.java:1685)
> at org.eclipse.jdt.internal.core.DeltaProcessor.fireReconcileDelta(DeltaProcessor.java:1537)
> at org.eclipse.jdt.internal.core.DeltaProcessor.fire(DeltaProcessor.java:1496)
> at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:770)
> at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:789)
> at org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUnit.java:1247)
> at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:126)
> at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.access$0(JavaReconcilingStrategy.java:108)
> at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy$1.run(JavaReconcilingStrategy.java:89)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:87)
> at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:151)
> at org.eclipse.jdt.internal.ui.text.CompositeReconcilingStrategy.reconcile(CompositeReconcilingStrategy.java:86)
> at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile(JavaCompositeReconcilingStrategy.java:104)
> at org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:77)
> at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:206)
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBDS-3078) 7 icon(s) not replaced in laucher.exe @ com.jboss.devstudio.core.site
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBDS-3078?page=com.atlassian.jira.plugin.... ]
Mickael Istria commented on JBDS-3078:
--------------------------------------
I don't know how important this error can be. I'll have a look at Tycho code.
What we can try as a workaround is to delete the /tmp/p2.branding* folders locally and on CI. WDYT?
> 7 icon(s) not replaced in laucher.exe @ com.jboss.devstudio.core.site
> ---------------------------------------------------------------------
>
> Key: JBDS-3078
> URL: https://issues.jboss.org/browse/JBDS-3078
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: installer, updatesite
> Affects Versions: 8.0.0.Beta3
> Reporter: Nick Boldt
> Assignee: Mickael Istria
>
> Building locally:
> {code}
> [INFO] --- tycho-p2-publisher-plugin:0.20.0:publish-products (default-publish-products) @ com.jboss.devstudio.core.site ---
> Error - 7 icon(s) not replaced in /tmp/p2.brandingIron9054877340821028927/launcher.exe using /home/nboldt/eclipse/workspace-jboss/jbdevstudio-github-master/jbdevstudio-product/site/target/products/com.jboss.devstudio.core.package/jbds.ico
> Error - 7 icon(s) not replaced in /tmp/p2.brandingIron489909634983575622/launcher.exe using /home/nboldt/eclipse/workspace-jboss/jbdevstudio-github-master/jbdevstudio-product/site/target/products/com.jboss.devstudio.core.package/jbds.ico
> {code}
> Building in Jenkins:
> {code}
> [INFO] --- tycho-p2-publisher-plugin:0.20.0:publish-products (default-publish-products) @ com.jboss.devstudio.core.site ---
> Error - 7 icon(s) not replaced in /tmp/p2.brandingIron5040285231221120320/launcher.exe using /qa/hudson_workspace/workspace/devstudio.product_master/sources/product/site/target/products/com.jboss.devstudio.core.package/jbds.ico
> Error - 7 icon(s) not replaced in /tmp/p2.brandingIron8242740933405392439/launcher.exe using /qa/hudson_workspace/workspace/devstudio.product_master/sources/product/site/target/products/com.jboss.devstudio.core.package/jbds.ico{code}
> Is this a problem?
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBDS-3071) JBDS Installer shouldn't contain source features/plugins
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBDS-3071?page=com.atlassian.jira.plugin.... ]
Mickael Istria commented on JBDS-3071:
--------------------------------------
Shouldn't the IUs added by commit https://github.com/nickboldt/jbdevstudio-product/commit/5328748223f7c7ccd... be added to product definition instead of added to the mirror operatiion?
What did you compare? The content of the jars or the output of the installation?
> JBDS Installer shouldn't contain source features/plugins
> --------------------------------------------------------
>
> Key: JBDS-3071
> URL: https://issues.jboss.org/browse/JBDS-3071
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: installer
> Affects Versions: 8.0.0.Beta2
> Reporter: Fred Bricon
> Assignee: Nick Boldt
> Fix For: 8.0.0.Beta3
>
>
> {quote}
> So the basic JBDS installer is 70MB fatter. From my understanding it's because we now ship a *huge* forge2 runtime (50MB), Tern, the JVM Monitor and probably some other minor stuff.
> Fair enough. But do we *really* need to add all the source features/plugins to the installer? *If* we're legally bound to provide sources for JBoss plugins, couldn't we provide them via an other way? (p2 only).
> I reckon we could save ~37 MB by not shipping sources in the installer. I know storage is cheap and d/l speeds are faster but that's not an excuse.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBIDE-17668) JBoss 4.2.3 Hot Deployment does not work (worked with 4.1.x)
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17668?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-17668:
-------------------------------------
I literally just committed the patch 10 seconds ago... so unless you're running from source and just did a git pull, you won't notice any changes.
In terms of incremental deployment, I did not notice any issues, nor did Martin (I believe). Admittedly I wasn't using large deployments, but, I verified that we did not touch the application.xml (which would force the server to redeploy the application). We only touch the application.xml if a module is being full published, so the fact that we're not touching it now verifies that it's not doing a full publish. Console output upon changing a xml or html file shows that the module is not being redeployed. (ie, no console output. If its being redeployed, we get console output). And tracing shows its only copying the changed files.
> JBoss 4.2.3 Hot Deployment does not work (worked with 4.1.x)
> ------------------------------------------------------------
>
> Key: JBIDE-17668
> URL: https://issues.jboss.org/browse/JBIDE-17668
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.0.Beta2
> Environment: Win7 x64, Eclipse Luna 4.4 RC3, JBoss 4.2.3GA
> Reporter: Nero M
> Assignee: Rob Stryker
> Priority: Blocker
> Fix For: 4.2.0.Beta3
>
> Attachments: duplicate-scanner.png
>
>
> When i start JBoss 4.2.3GA i get this:
> org.jboss.deployment.DeploymentException: Trying to install an already registered mbean: jboss.remoting:type=Connector,name=DefaultEjb3Connector,handler=ejb3
> at org.jboss.system.ServiceCreator.install(ServiceCreator.java:103)
> Then when i change any file (just an xhtml for instance) The Server shuts down. Instead it should just hot-deploy that file like it did with Kepler + AS Tools 4.1. But here it seems a full deployment is being done (Not just the file) resulting in a Server reboot
> 12:09:29,452 INFO [EARDeployer] Undeploying J2EE application, destroy step: file:/C:/server/jboss/............ear
> 12:09:29,452 INFO [EARDeployer] Undeployed J2EE application: file:/C:/server/jboss/..........................ear
> Thanks for any help :( If this is not fixed, we cannot move to Luna. unfortunately i cant move to a different application server
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBIDE-17668) JBoss 4.2.3 Hot Deployment does not work (worked with 4.1.x)
by Nero M (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17668?page=com.atlassian.jira.plugi... ]
Nero M commented on JBIDE-17668:
--------------------------------
Hi, did you also look at the problem about the deployment ?
http://abload.de/img/untitled5m5kfx.png
Its still taking long for me (using Nightly build - or does it take a while to reflect here ) ?
Thanks
> JBoss 4.2.3 Hot Deployment does not work (worked with 4.1.x)
> ------------------------------------------------------------
>
> Key: JBIDE-17668
> URL: https://issues.jboss.org/browse/JBIDE-17668
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.0.Beta2
> Environment: Win7 x64, Eclipse Luna 4.4 RC3, JBoss 4.2.3GA
> Reporter: Nero M
> Assignee: Rob Stryker
> Priority: Blocker
> Fix For: 4.2.0.Beta3
>
> Attachments: duplicate-scanner.png
>
>
> When i start JBoss 4.2.3GA i get this:
> org.jboss.deployment.DeploymentException: Trying to install an already registered mbean: jboss.remoting:type=Connector,name=DefaultEjb3Connector,handler=ejb3
> at org.jboss.system.ServiceCreator.install(ServiceCreator.java:103)
> Then when i change any file (just an xhtml for instance) The Server shuts down. Instead it should just hot-deploy that file like it did with Kepler + AS Tools 4.1. But here it seems a full deployment is being done (Not just the file) resulting in a Server reboot
> 12:09:29,452 INFO [EARDeployer] Undeploying J2EE application, destroy step: file:/C:/server/jboss/............ear
> 12:09:29,452 INFO [EARDeployer] Undeployed J2EE application: file:/C:/server/jboss/..........................ear
> Thanks for any help :( If this is not fixed, we cannot move to Luna. unfortunately i cant move to a different application server
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBIDE-17668) JBoss 4.2.3 Hot Deployment does not work (worked with 4.1.x)
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17668?page=com.atlassian.jira.plugi... ]
Rob Stryker resolved JBIDE-17668.
---------------------------------
Resolution: Done
This has been pushed to master.
> JBoss 4.2.3 Hot Deployment does not work (worked with 4.1.x)
> ------------------------------------------------------------
>
> Key: JBIDE-17668
> URL: https://issues.jboss.org/browse/JBIDE-17668
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.0.Beta2
> Environment: Win7 x64, Eclipse Luna 4.4 RC3, JBoss 4.2.3GA
> Reporter: Nero M
> Assignee: Rob Stryker
> Priority: Blocker
> Fix For: 4.2.0.Beta3
>
> Attachments: duplicate-scanner.png
>
>
> When i start JBoss 4.2.3GA i get this:
> org.jboss.deployment.DeploymentException: Trying to install an already registered mbean: jboss.remoting:type=Connector,name=DefaultEjb3Connector,handler=ejb3
> at org.jboss.system.ServiceCreator.install(ServiceCreator.java:103)
> Then when i change any file (just an xhtml for instance) The Server shuts down. Instead it should just hot-deploy that file like it did with Kepler + AS Tools 4.1. But here it seems a full deployment is being done (Not just the file) resulting in a Server reboot
> 12:09:29,452 INFO [EARDeployer] Undeploying J2EE application, destroy step: file:/C:/server/jboss/............ear
> 12:09:29,452 INFO [EARDeployer] Undeployed J2EE application: file:/C:/server/jboss/..........................ear
> Thanks for any help :( If this is not fixed, we cannot move to Luna. unfortunately i cant move to a different application server
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBDS-3030) Spring conflicting handler message after Spring perspective is reset
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBDS-3030?page=com.atlassian.jira.plugin.... ]
Fred Bricon updated JBDS-3030:
------------------------------
Fix Version/s: 8.0.0.CR1
(was: 8.0.0.Beta3)
> Spring conflicting handler message after Spring perspective is reset
> --------------------------------------------------------------------
>
> Key: JBDS-3030
> URL: https://issues.jboss.org/browse/JBDS-3030
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: 3rd-party-certification, upstream
> Affects Versions: 8.0.0.Beta1
> Reporter: Jiri Peterka
> Assignee: Fred Bricon
> Priority: Minor
> Fix For: 8.0.0.CR1
>
>
> Conflicting handlers for AUTOGEN:::org.springsource.ide.eclipse.commons.launch.actionSet/org.springsource.ide.eclipse.commons.launch.relaunch.action: {ActionDelegateHandlerProxy(null,org.springsource.ide.eclipse.commons.ui.launch.StopProcessPullDownToolbarDelegate)} vs {ActionDelegateHandlerProxy(null,org.springsource.ide.eclipse.commons.ui.launch.RelaunchProcessPullDownToolbarDelegate)}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBIDE-17610) In JBoss Central rename 'Enable Early Access' check box
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17610?page=com.atlassian.jira.plugi... ]
Fred Bricon commented on JBIDE-17610:
-------------------------------------
So I take it we stick with 'Enable Early Access'? (without hyphen)
> In JBoss Central rename 'Enable Early Access' check box
> -------------------------------------------------------
>
> Key: JBIDE-17610
> URL: https://issues.jboss.org/browse/JBIDE-17610
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: central
> Affects Versions: 4.2.0.Beta2
> Reporter: Michelle Murray
> Assignee: Fred Bricon
> Labels: early-access
> Fix For: 4.2.0.Beta3
>
>
> The label for the 'Enable Early Access' check box (JBIDE-17392) should be changed.
> It should be labelled 'Show Early Access'.
> * This makes it consistent with the 'Show Installed' check box
> * And by selecting the check box you aren't actually _enabling_ Early Access features - you are merely showing them and still have to install them
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBIDE-17696) Enabling Maven Dependency Management job waits forever
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17696?page=com.atlassian.jira.plugi... ]
Denis Golovin commented on JBIDE-17696:
---------------------------------------
I was playing with it today and I did see job mentioned above taking to much time, but in my case it ended eventually without any exceptions. After that I didn't managed to get it stuck again.
> Enabling Maven Dependency Management job waits forever
> ------------------------------------------------------
>
> Key: JBIDE-17696
> URL: https://issues.jboss.org/browse/JBIDE-17696
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: maven
> Affects Versions: 4.2.0.Beta2
> Environment: OpenJDK 1.7, 64b
> Ubuntu 12.04, 64b
> Reporter: Rastislav Wagner
> Attachments: jstack1.out, jstack2.out, jstack_mvn.out, mvn.png, wait1.png, wait2.png
>
>
> I dont have exact steps to reproduce because this usually occurs after longer work. I'm testing various configurators (CDI/Seam/JAXRS..) using this scenario:
> 1. Create Dynamic Web Project
> 2. Convert to maven project (using Configure -> Convert to maven..)
> 3. Add some dependency
> 4. check if proper facet was enabled
> 5. delete project and repeat
> After trying this 10-15 times (sometimes more, sometimes less), during step 2 "Enabling Maven Dependency Management" job is waiting and never ends - see screenshot - there's always "Setting classpath containers".
> JVM thread dump attached.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
