[JBoss JIRA] (JBIDE-22659) Error marker information should come from the reconciler thread
by Daniel Dekany (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22659?page=com.atlassian.jira.plugi... ]
Daniel Dekany commented on JBIDE-22659:
---------------------------------------
I have solved this (https://github.com/ddekany/jbosstools-freemarker/tree/JBIDE-22659), but I can't make a pull request rebased on Master, because it requires JBIDE-20386 and JBIDE-22656 to be merged first.
> Error marker information should come from the reconciler thread
> ---------------------------------------------------------------
>
> Key: JBIDE-22659
> URL: https://issues.jboss.org/browse/JBIDE-22659
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: freemarker
> Reporter: Daniel Dekany
>
> The template is parsed with the actual FreeMarker parser, and the resulting exception (if any) is translated to an Eclipse error marker. The parsing happens asynchronously. This is fine so far. What's strange is that instead of relying on the standard reconciler mechanism, {{org.jboss.ide.eclipse.freemarker.editor.Editor}} tries to figure out when that information needs to be recalculated by examining the keydown events, instead of real change events. Thus it doesn't work if you are inserting text solely with mouse for example. Also the {{Editor}} tries to do this after each key stroke (unlike the reconciler mechanism, which waits until you stop typing for a moment). Also the asynchronous task execution it does has a flaw because of which sometimes ignores the last few changes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22659) Error marker information should come from the reconciler thread
by Daniel Dekany (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22659?page=com.atlassian.jira.plugi... ]
Daniel Dekany updated JBIDE-22659:
----------------------------------
Summary: Error marker information should come from the reconciler thread (was: Error marker information should comre from the reconciler thread)
> Error marker information should come from the reconciler thread
> ---------------------------------------------------------------
>
> Key: JBIDE-22659
> URL: https://issues.jboss.org/browse/JBIDE-22659
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: freemarker
> Reporter: Daniel Dekany
>
> The template is parsed with the actual FreeMarker parser, and the resulting exception (if any) is translated to an Eclipse error marker. The parsing happens asynchronously. This is fine so far. What's strange is that instead of relying on the standard reconciler mechanism, {{org.jboss.ide.eclipse.freemarker.editor.Editor}} tries to figure out when that information needs to be recalculated by examining the keydown events, instead of real change events. Thus it doesn't work if you are inserting text solely with mouse for example. Also the {{Editor}} tries to do this after each key stroke (unlike the reconciler mechanism, which waits until you stop typing for a moment). Also the asynchronous task execution it does has a flaw because of which sometimes ignores the last few changes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22659) Error marker information should comre from the reconciler thread
by Daniel Dekany (JIRA)
Daniel Dekany created JBIDE-22659:
-------------------------------------
Summary: Error marker information should comre from the reconciler thread
Key: JBIDE-22659
URL: https://issues.jboss.org/browse/JBIDE-22659
Project: Tools (JBoss Tools)
Issue Type: Enhancement
Components: freemarker
Reporter: Daniel Dekany
The template is parsed with the actual FreeMarker parser, and the resulting exception (if any) is translated to an Eclipse error marker. The parsing happens asynchronously. This is fine so far. What's strange is that instead of relying on the standard reconciler mechanism, {{org.jboss.ide.eclipse.freemarker.editor.Editor}} tries to figure out when that information needs to be recalculated by examining the keydown events, instead of real change events. Thus it doesn't work if you are inserting text solely with mouse for example. Also the {{Editor}} tries to do this after each key stroke (unlike the reconciler mechanism, which waits until you stop typing for a moment). Also the asynchronous task execution it does has a flaw because of which sometimes ignores the last few changes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22658) Infinite or very long hang in CDI builder with Payara embedded maven dep
by arjan tijms (JIRA)
arjan tijms created JBIDE-22658:
-----------------------------------
Summary: Infinite or very long hang in CDI builder with Payara embedded maven dep
Key: JBIDE-22658
URL: https://issues.jboss.org/browse/JBIDE-22658
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: cdi
Reporter: arjan tijms
In the latest JBoss Tools for Eclipse Mars .2 (would be great if it was easy to see the main version easily, but I guess it's 4.3.1), the CDI builder either infinitely hangs or takes an enormous amount of time (an hour at least on a core M laptop) when payara embedded is present as (test) dependency in a maven project.
During this hang I took a stack trace, which looks as follows:
{noformat}
"Worker-20" #96 prio=5 os_prio=31 tid=0x0000000101512000 nid=0x14803 runnable [0x0000700003fde000]
java.lang.Thread.State: RUNNABLE
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(ZipFile.java:219)
at java.util.zip.ZipFile.<init>(ZipFile.java:149)
at java.util.zip.ZipFile.<init>(ZipFile.java:163)
at org.eclipse.jdt.internal.core.JavaModelManager.getZipFile(JavaModelManager.java:2678)
at org.eclipse.jdt.internal.core.JavaModelManager.getZipFile(JavaModelManager.java:2644)
at org.eclipse.jdt.internal.core.JarPackageFragmentRoot.getJar(JarPackageFragmentRoot.java:156)
at org.eclipse.jdt.internal.core.ClassFile.getJarBinaryTypeInfo(ClassFile.java:355)
at org.eclipse.jdt.internal.core.ClassFile.getBinaryTypeInfo(ClassFile.java:290)
at org.eclipse.jdt.internal.core.ClassFile.getBinaryTypeInfo(ClassFile.java:284)
at org.eclipse.jdt.internal.core.ClassFile.buildStructure(ClassFile.java:93)
at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java:259)
at org.eclipse.jdt.internal.core.SourceRefElement.generateInfos(SourceRefElement.java:107)
at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:579)
at org.eclipse.jdt.internal.core.BinaryType.getElementInfo(BinaryType.java:287)
at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:302)
at org.eclipse.jdt.internal.core.JavaElement.exists(JavaElement.java:220)
at org.jboss.tools.cdi.internal.core.scanner.ImplementationCollector.process(ImplementationCollector.java:41)
at org.jboss.tools.cdi.internal.core.scanner.ImplementationCollector.<init>(ImplementationCollector.java:32)
at org.jboss.tools.cdi.internal.core.impl.CDIProject.rebuildBeans(CDIProject.java:1309)
at org.jboss.tools.cdi.internal.core.impl.CDIProject.update(CDIProject.java:1216)
- locked <0x000000078ecd93d8> (a org.jboss.tools.cdi.internal.core.impl.CDICache)
at org.jboss.tools.cdi.internal.core.impl.definition.DefinitionContext.applyWorkingCopy(DefinitionContext.java:442)
at org.jboss.tools.cdi.core.CDICoreBuilder.build(CDICoreBuilder.java:267)
at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:734)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:205)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:245)
at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:300)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:303)
at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:359)
at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:382)
at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:144)
at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:235)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
{noformat}
I debugged Eclipse with a second Eclipse, and it appeared that the code is repeatedly opening {{.m2/repository/fish/payara/extras/payara-embedded-all/4.1.1.162/payara-embedded-all-4.1.1.162.jar}} from {{CDIProject#rebuildBeans}}.
The specific line of code is:
{code:java}
ImplementationCollector ic = new ImplementationCollector(typeDefinitions);
{code}
The number of type definitions it seems to go through in {{ImplementationCollector#process}} is *33009* and the loop looks to be making progress, so it's more likely just incredibly slow and not an infinite hang.
The dependency in pom.xml looks as follows:
{code:xml}
<dependency>
<groupId>fish.payara.extras</groupId>
<artifactId>payara-embedded-all</artifactId>
<version>4.1.1.162</version>
<scope>test</scope>
</dependency>
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22657) smart import nullpointer
by Max Rydahl Andersen (JIRA)
Max Rydahl Andersen created JBIDE-22657:
-------------------------------------------
Summary: smart import nullpointer
Key: JBIDE-22657
URL: https://issues.jboss.org/browse/JBIDE-22657
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: easymport
Reporter: Max Rydahl Andersen
when using smartimport to import https://github.com/maxandersen/imapfilter-docker.git from disk I got a NPE in jaxrs:
{code}
java.lang.NullPointerException
at org.jboss.tools.ws.jaxrs.ui.internal.importer.JaxRsConfigurator.canConfigure(JaxRsConfigurator.java:66)
at org.eclipse.ui.internal.wizards.datatransfer.SmartImportJob.importProjectAndChildrenRecursively(SmartImportJob.java:466)
at org.eclipse.ui.internal.wizards.datatransfer.SmartImportJob.run(SmartImportJob.java:242)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22656) Related tag background becomes misplaced when typing
by Daniel Dekany (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22656?page=com.atlassian.jira.plugi... ]
Daniel Dekany commented on JBIDE-22656:
---------------------------------------
Note that I have started working on this before you have assigned it to yourself. I'm just saying to avoid the unlikely situation that we both work on the same thing. (I will see tomorrow if my approach will work at all.)
> Related tag background becomes misplaced when typing
> ----------------------------------------------------
>
> Key: JBIDE-22656
> URL: https://issues.jboss.org/browse/JBIDE-22656
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: freemarker
> Reporter: Daniel Dekany
> Assignee: Alexey Kazakov
> Fix For: 4.4.x
>
>
> When you put the cursor inside an FTL tag, like {{<#if ...>}}, the background color of related tags, like {{<#else>}} and {{</#if>}}, is changed. The problem is that if now you start typing into a such background-colored tag, the offsets of the colored sections after it will become outdated, and so they start to drift left from under the tag. This is because the up to date offsets only become available after the reconciling thread has finished, but the background coloring logic is called directly in the keydown handler. I'm not familiar with plugin development, but I suspect this is architecturally wrong. Perhaps the reconciler should send some kind of event when it's done, and if the editor content is still in the state for which the reconciling was ran, only then should the old background coloring be removed and the new one is added.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22628) Zoom in / out functionality is not working with Visual Page Editor
by Ilya Buziuk (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22628?page=com.atlassian.jira.plugi... ]
Ilya Buziuk commented on JBIDE-22628:
-------------------------------------
[~scabanovich], if it is overriden the following way, zoom in / out functionality is working fine and all tests in jst & vpe are passing:
{code}
@Override
public Object getSelectedPage() {
return sourceEditor != null ? sourceEditor : super.getSelectedPage();
}
{code}
Without overriding it, getSelected page returns either *VpeEditorPartFactory* (jsf) or *VpvEditorPart* (html)
However, I think that checking for suitable adapter, rather than returning null, can not do any harm and is rather reasonable for some editors which can not always provide *AbstractTextEditor* from *getSelectedPage()*. WDYT ?
> Zoom in / out functionality is not working with Visual Page Editor
> --------------------------------------------------------------------
>
> Key: JBIDE-22628
> URL: https://issues.jboss.org/browse/JBIDE-22628
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: visual-page-editor-core
> Affects Versions: 4.4.0.Alpha2
> Reporter: Ilya Buziuk
> Assignee: Ilya Buziuk
> Labels: upstream
> Fix For: 4.4.x
>
>
> New zoom in / out functionality (Cntl + / -) which is available in Neon is not working in Visual Page Editor. The interesting thing, that if you do Zoom in / out in the html editor which supports this functionality and reopen file again in the Visual Editor the new scale will be adjusted
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22656) Related tag background becomes misplaced when typing
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22656?page=com.atlassian.jira.plugi... ]
Alexey Kazakov reassigned JBIDE-22656:
--------------------------------------
Assignee: Alexey Kazakov
> Related tag background becomes misplaced when typing
> ----------------------------------------------------
>
> Key: JBIDE-22656
> URL: https://issues.jboss.org/browse/JBIDE-22656
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: freemarker
> Reporter: Daniel Dekany
> Assignee: Alexey Kazakov
> Fix For: 4.4.x
>
>
> When you put the cursor inside an FTL tag, like {{<#if ...>}}, the background color of related tags, like {{<#else>}} and {{</#if>}}, is changed. The problem is that if now you start typing into a such background-colored tag, the offsets of the colored sections after it will become outdated, and so they start to drift left from under the tag. This is because the up to date offsets only become available after the reconciling thread has finished, but the background coloring logic is called directly in the keydown handler. I'm not familiar with plugin development, but I suspect this is architecturally wrong. Perhaps the reconciler should send some kind of event when it's done, and if the editor content is still in the state for which the reconciling was ran, only then should the old background coloring be removed and the new one is added.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months