[JBoss JIRA] (JBIDE-16272) Having both RichFaces 4.5 and 5.x taglibs in one JSF project malfunction components auto completion
by Juraj Húska (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16272?page=com.atlassian.jira.plugi... ]
Juraj Húska updated JBIDE-16272:
--------------------------------
Affects Version/s: 4.1.1.Final
(was: 4.1.0.1.Final)
> Having both RichFaces 4.5 and 5.x taglibs in one JSF project malfunction components auto completion
> ---------------------------------------------------------------------------------------------------
>
> Key: JBIDE-16272
> URL: https://issues.jboss.org/browse/JBIDE-16272
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: jsf
> Affects Versions: 4.1.1.Final
> Reporter: Juraj Húska
> Assignee: Alexey Kazakov
> Fix For: 4.2.x
>
> Attachments: a4jTagLibCtrlClick.png, jbtca.png, jbthtml.png, jsfTagProposals.png, myAutocompletion1.png, myAutocompletion2.png, myAutocompletion3.png, scr.png, scr2.png, scr3.png, taglib2.png, tagLibraries1.png
>
>
> When I create new JSF project, where I add RichFaces libraries needed to create _RichFaces 4.5_ (a special version which should be some kind of bridge between RichFaces 4 and 5) application:
> * richfaces-5.0.0.Alpha2.jar
> * richfaces-components-a4j-4.5.0.Alpha1.jar
> * richfaces-components-rich-4.5.0.Alpha1.jar
> Then if you have all supported namespaces included, auto completion triggered e.g. on {{<a4j:}} will provides also non existing components, like {{<a4j:calendar}} (it should be {{<rich:calendar}} )
> Please see steps to reproduce.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBIDE-16272) Having both RichFaces 4.5 and 5.x taglibs in one JSF project malfunction components auto completion
by Juraj Húska (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16272?page=com.atlassian.jira.plugi... ]
Juraj Húska updated JBIDE-16272:
--------------------------------
Attachment: jsfTagProposals.png
> Having both RichFaces 4.5 and 5.x taglibs in one JSF project malfunction components auto completion
> ---------------------------------------------------------------------------------------------------
>
> Key: JBIDE-16272
> URL: https://issues.jboss.org/browse/JBIDE-16272
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: jsf
> Affects Versions: 4.1.0.1.Final
> Reporter: Juraj Húska
> Assignee: Alexey Kazakov
> Fix For: 4.2.x
>
> Attachments: a4jTagLibCtrlClick.png, jbtca.png, jbthtml.png, jsfTagProposals.png, myAutocompletion1.png, myAutocompletion2.png, myAutocompletion3.png, scr.png, scr2.png, scr3.png, taglib2.png, tagLibraries1.png
>
>
> When I create new JSF project, where I add RichFaces libraries needed to create _RichFaces 4.5_ (a special version which should be some kind of bridge between RichFaces 4 and 5) application:
> * richfaces-5.0.0.Alpha2.jar
> * richfaces-components-a4j-4.5.0.Alpha1.jar
> * richfaces-components-rich-4.5.0.Alpha1.jar
> Then if you have all supported namespaces included, auto completion triggered e.g. on {{<a4j:}} will provides also non existing components, like {{<a4j:calendar}} (it should be {{<rich:calendar}} )
> Please see steps to reproduce.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBIDE-16272) Having both RichFaces 4.5 and 5.x taglibs in one JSF project malfunction components auto completion
by Juraj Húska (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16272?page=com.atlassian.jira.plugi... ]
Juraj Húska commented on JBIDE-16272:
-------------------------------------
I have fresh unzip of Eclipse Kepler SR1, and only JBoss Tools *4.1.1.Final* installed from [here|http://marketplace.eclipse.org/node/876523#.UrA4vnWJBgo].
These are the my JSF tag proposals, when I follow your guide. I still can see the {{<aj4:calendar>}}.
> Having both RichFaces 4.5 and 5.x taglibs in one JSF project malfunction components auto completion
> ---------------------------------------------------------------------------------------------------
>
> Key: JBIDE-16272
> URL: https://issues.jboss.org/browse/JBIDE-16272
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: jsf
> Affects Versions: 4.1.0.1.Final
> Reporter: Juraj Húska
> Assignee: Alexey Kazakov
> Fix For: 4.2.x
>
> Attachments: a4jTagLibCtrlClick.png, jbtca.png, jbthtml.png, jsfTagProposals.png, myAutocompletion1.png, myAutocompletion2.png, myAutocompletion3.png, scr.png, scr2.png, scr3.png, taglib2.png, tagLibraries1.png
>
>
> When I create new JSF project, where I add RichFaces libraries needed to create _RichFaces 4.5_ (a special version which should be some kind of bridge between RichFaces 4 and 5) application:
> * richfaces-5.0.0.Alpha2.jar
> * richfaces-components-a4j-4.5.0.Alpha1.jar
> * richfaces-components-rich-4.5.0.Alpha1.jar
> Then if you have all supported namespaces included, auto completion triggered e.g. on {{<a4j:}} will provides also non existing components, like {{<a4j:calendar}} (it should be {{<rich:calendar}} )
> Please see steps to reproduce.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBIDE-15807) Eclipe 4.4M3 with jbosstoolstarget-4.40.0.Alpa1-SNAPSHOT target platform does not start
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15807?page=com.atlassian.jira.plugi... ]
Mickael Istria updated JBIDE-15807:
-----------------------------------
Priority: Minor (was: Blocker)
> Eclipe 4.4M3 with jbosstoolstarget-4.40.0.Alpa1-SNAPSHOT target platform does not start
> ---------------------------------------------------------------------------------------
>
> Key: JBIDE-15807
> URL: https://issues.jboss.org/browse/JBIDE-15807
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: target-platform
> Affects Versions: 4.2.0.Alpha1
> Reporter: Daniel Azarov
> Assignee: Denis Golovin
> Priority: Minor
> Fix For: 4.2.0.Alpha1
>
> Attachments: mat.png, scr.png
>
>
> 1. I tried to run JBDS from developer's environment with vm args - -XX:MaxPermSize=512m -Xms1024m -Xmx2048m with all plugins from my workspace
> and I got follow exception:
> {code}
> java.lang.OutOfMemoryError: Java heap space
> at java.util.HashMap.createEntry(HashMap.java:869)
> at java.util.HashMap.addEntry(HashMap.java:856)
> at java.util.HashMap.put(HashMap.java:484)
> at org.apache.felix.resolver.Candidates.copy(Candidates.java:1002)
> at org.apache.felix.resolver.ResolverImpl.checkDynamicPackageSpaceConsistency(ResolverImpl.java:1288)
> at org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1083)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:261)
> at org.eclipse.osgi.container.ModuleResolver$ResolveProcess.resolve(ModuleResolver.java:652)
> at org.eclipse.osgi.container.ModuleResolver.resolveDelta(ModuleResolver.java:75)
> at org.eclipse.osgi.container.ModuleContainer.resolveAndApply(ModuleContainer.java:451)
> at org.eclipse.osgi.container.ModuleContainer.resolve(ModuleContainer.java:409)
> at org.eclipse.osgi.container.ModuleContainer.refresh(ModuleContainer.java:877)
> at org.eclipse.osgi.storage.Storage.discardBundlesOnLoad(Storage.java:206)
> at org.eclipse.osgi.storage.Storage.createStorage(Storage.java:87)
> at org.eclipse.osgi.internal.framework.EquinoxContainer.<init>(EquinoxContainer.java:75)
> at org.eclipse.osgi.launch.Equinox.<init>(Equinox.java:31)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:287)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:222)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1450)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1426)
> {code}
> 2. If I try to run new run configuration with only plugins from target platform I got follow stack trace:
> {code}
> !SESSION 2013-10-28 10:29:47.350 -----------------------------------------------
> eclipse.buildId=unknown
> java.version=1.6.0_24
> java.vendor=Sun Microsystems Inc.
> BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
> Framework arguments: -product org.eclipse.platform.ide
> Command-line arguments: -product org.eclipse.platform.ide -data /home/daniel/workspaces/JBDS_GIT/../runtime-New_configuration(2) -dev file:/home/daniel/workspaces/JBDS_GIT/.metadata/.plugins/org.eclipse.pde.core/New_configuration (2)/dev.properties -os linux -ws gtk -arch x86_64 -consoleLog
> !ENTRY org.eclipse.equinox.simpleconfigurator 4 0 2013-10-28 10:36:19.748
> !MESSAGE FrameworkEvent ERROR
> !STACK 0
> org.osgi.framework.BundleException: Exception in org.eclipse.equinox.internal.simpleconfigurator.Activator.start() of bundle org.eclipse.equinox.simpleconfigurator.
> at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:782)
> at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:717)
> at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:869)
> at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:257)
> at org.eclipse.osgi.container.Module.doStart(Module.java:556)
> at org.eclipse.osgi.container.Module.start(Module.java:427)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1455)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1438)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1416)
> at org.eclipse.osgi.container.SystemModule.startWorker(SystemModule.java:216)
> at org.eclipse.osgi.container.Module.doStart(Module.java:556)
> at org.eclipse.osgi.container.Module.start(Module.java:427)
> at org.eclipse.osgi.container.SystemModule.start(SystemModule.java:151)
> at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:347)
> at org.eclipse.osgi.launch.Equinox.start(Equinox.java:115)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:310)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:222)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1450)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1426)
> Caused by: java.lang.OutOfMemoryError: Java heap space
> at java.util.HashMap.addEntry(HashMap.java:770)
> at java.util.HashMap.put(HashMap.java:402)
> at org.apache.felix.resolver.ResolverImpl.mergeUses(ResolverImpl.java:960)
> at org.apache.felix.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:787)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:252)
> at org.eclipse.osgi.container.ModuleResolver$ResolveProcess.resolve(ModuleResolver.java:652)
> at org.eclipse.osgi.container.ModuleResolver.resolveDelta(ModuleResolver.java:75)
> at org.eclipse.osgi.container.ModuleContainer.resolveAndApply(ModuleContainer.java:451)
> at org.eclipse.osgi.container.ModuleContainer.resolve(ModuleContainer.java:409)
> at org.eclipse.osgi.container.ModuleContainer.resolve(ModuleContainer.java:399)
> at org.eclipse.osgi.container.Module.start(Module.java:406)
> at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:347)
> at org.eclipse.equinox.internal.simpleconfigurator.ConfigApplier.startBundles(ConfigApplier.java:427)
> at org.eclipse.equinox.internal.simpleconfigurator.ConfigApplier.install(ConfigApplier.java:109)
> at org.eclipse.equinox.internal.simpleconfigurator.SimpleConfiguratorImpl.applyConfiguration(SimpleConfiguratorImpl.java:182)
> at org.eclipse.equinox.internal.simpleconfigurator.SimpleConfiguratorImpl.applyConfiguration(SimpleConfiguratorImpl.java:196)
> at org.eclipse.equinox.internal.simpleconfigurator.Activator.start(Activator.java:48)
> at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:761)
> at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:754)
> at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:717)
> at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:869)
> at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:257)
> at org.eclipse.osgi.container.Module.doStart(Module.java:556)
> at org.eclipse.osgi.container.Module.start(Module.java:427)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1455)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1438)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1416)
> at org.eclipse.osgi.container.SystemModule.startWorker(SystemModule.java:216)
> at org.eclipse.osgi.container.Module.doStart(Module.java:556)
> at org.eclipse.osgi.container.Module.start(Module.java:427)
> Root exception:
> java.lang.OutOfMemoryError: Java heap space
> at java.util.HashMap.addEntry(HashMap.java:770)
> at java.util.HashMap.put(HashMap.java:402)
> at org.apache.felix.resolver.ResolverImpl.mergeUses(ResolverImpl.java:960)
> at org.apache.felix.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:787)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:252)
> at org.eclipse.osgi.container.ModuleResolver$ResolveProcess.resolve(ModuleResolver.java:652)
> at org.eclipse.osgi.container.ModuleResolver.resolveDelta(ModuleResolver.java:75)
> at org.eclipse.osgi.container.ModuleContainer.resolveAndApply(ModuleContainer.java:451)
> at org.eclipse.osgi.container.ModuleContainer.resolve(ModuleContainer.java:409)
> at org.eclipse.osgi.container.ModuleContainer.resolve(ModuleContainer.java:399)
> at org.eclipse.osgi.container.Module.start(Module.java:406)
> at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:347)
> at org.eclipse.equinox.internal.simpleconfigurator.ConfigApplier.startBundles(ConfigApplier.java:427)
> at org.eclipse.equinox.internal.simpleconfigurator.ConfigApplier.install(ConfigApplier.java:109)
> at org.eclipse.equinox.internal.simpleconfigurator.SimpleConfiguratorImpl.applyConfiguration(SimpleConfiguratorImpl.java:182)
> at org.eclipse.equinox.internal.simpleconfigurator.SimpleConfiguratorImpl.applyConfiguration(SimpleConfiguratorImpl.java:196)
> at org.eclipse.equinox.internal.simpleconfigurator.Activator.start(Activator.java:48)
> at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:761)
> at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:754)
> at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:717)
> at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:869)
> at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:257)
> at org.eclipse.osgi.container.Module.doStart(Module.java:556)
> at org.eclipse.osgi.container.Module.start(Module.java:427)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1455)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1438)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1416)
> at org.eclipse.osgi.container.SystemModule.startWorker(SystemModule.java:216)
> at org.eclipse.osgi.container.Module.doStart(Module.java:556)
> at org.eclipse.osgi.container.Module.start(Module.java:427)
> {code}
> 3. If I try same as 2. but with "Running Platform" as target platform - eclipse starts
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBIDE-16280) VPE/XulRunner crashes workbench
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16280?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-16280:
----------------------------------------
Doesn't Fedora provide XulRunner binaries compiled against GTK3?
[~krzysztofdaniel] Do you have any hint? Our problem is that the xulrunner binaries we provide aren't working with GTK3 and we'd like to have some that work.
> VPE/XulRunner crashes workbench
> -------------------------------
>
> Key: JBIDE-16280
> URL: https://issues.jboss.org/browse/JBIDE-16280
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: xulrunner
> Affects Versions: 4.2.0.Alpha1
> Reporter: Mickael Istria
> Priority: Critical
> Fix For: 4.2.0.Alpha1
>
> Attachments: hs_err_pid20688.log
>
>
> After an install of JBDS 8.0.0.Alpha1 from installer (built locally with fixes from JBDS-2861), the application crashes a few seconds after startup.
> JVM creates me a thread dump, that you can find attached. Here is the header:
> {code}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGSEGV (0xb) at pc=0x00007fdea49f3255, pid=18578, tid=140596949411584
> #
> # JRE version: 7.0_25-b30
> # Java VM: OpenJDK 64-Bit Server VM (23.7-b01 mixed mode linux-amd64 compressed oops)
> # Problematic frame:
> # C [libxul.so+0xc81255] JSD_DebuggerOnForUser+0x978a2
> #
> {code}
> I'm running on Ubuntu 12.04.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBIDE-16308) Cannot start JBT 4.2.0.Alpha1 on Fedora 19
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16308?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-16308:
----------------------------------------
That's something to discuss with [~maxandersen], but I don't think we can't tell users to set SWT_GTK3 setting in their Eclipse IDE when they install JBoss Tools.
GTK3 is the biggest part of migration to Luna, and Alpha1 is meant to provide minimal compatibility with Luna (and then GTK3). So let's say that Alpha1 is not ready until XulRunner gets recompiled against GTK3.
> Cannot start JBT 4.2.0.Alpha1 on Fedora 19
> ------------------------------------------
>
> Key: JBIDE-16308
> URL: https://issues.jboss.org/browse/JBIDE-16308
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, xulrunner
> Affects Versions: 4.2.0.Alpha1
> Environment: JBT 4.2.Alpha1, L64, Fedora 19, 64-bit, Open JDK 1.7
> Reporter: Jiri Peterka
> Priority: Blocker
> Fix For: 4.2.0.Alpha1
>
> Attachments: hs_err_pid17371.log, hs_err_pid18745.log
>
>
> Installing JBT on Eclipse -4.4.M4- 4.4.M3 JEE package (linux_64), after JBT installation update site and restart I have:
> {code}
> !ENTRY org.eclipse.osgi 4 0 2013-12-16 15:35:03.535
> !MESSAGE FrameworkEvent ERROR
> !STACK 0
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> at java.util.ArrayList.iterator(ArrayList.java:814)
> at org.apache.felix.resolver.ResolverImpl.mergeUses(ResolverImpl.java:962)
> at org.apache.felix.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:787)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:252)
> at org.eclipse.osgi.container.ModuleResolver$ResolveProcess.resolve(ModuleResolver.java:652)
> at org.eclipse.osgi.container.ModuleResolver.resolveDelta(ModuleResolver.java:75)
> at org.eclipse.osgi.container.ModuleContainer.resolveAndApply(ModuleContainer.java:454)
> at org.eclipse.osgi.container.ModuleContainer.resolve(ModuleContainer.java:412)
> at org.eclipse.osgi.container.ModuleContainer.resolve(ModuleContainer.java:402)
> at org.eclipse.osgi.container.Module.start(Module.java:406)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1530)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1510)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1481)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1424)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
> at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
> at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
> {code}
> Even if I raise a memory for JVM, Eclipse doesn't start but not error message is written
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBIDE-16308) Cannot start JBT 4.2.0.Alpha1 on Fedora 19
by Jiri Peterka (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16308?page=com.atlassian.jira.plugi... ]
Jiri Peterka commented on JBIDE-16308:
--------------------------------------
Nick, I can confirm it works for me with eclipse-SDK-4.4M4-linux-gtk-x86_64.tar.gz when SWT_GTK3=0 is set (without it it crashes). With M3 (JEE) it hangs (regardless to SWT_GTK3 setting).
> Cannot start JBT 4.2.0.Alpha1 on Fedora 19
> ------------------------------------------
>
> Key: JBIDE-16308
> URL: https://issues.jboss.org/browse/JBIDE-16308
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, xulrunner
> Affects Versions: 4.2.0.Alpha1
> Environment: JBT 4.2.Alpha1, L64, Fedora 19, 64-bit, Open JDK 1.7
> Reporter: Jiri Peterka
> Priority: Blocker
> Fix For: 4.2.0.Alpha1
>
> Attachments: hs_err_pid17371.log, hs_err_pid18745.log
>
>
> Installing JBT on Eclipse -4.4.M4- 4.4.M3 JEE package (linux_64), after JBT installation update site and restart I have:
> {code}
> !ENTRY org.eclipse.osgi 4 0 2013-12-16 15:35:03.535
> !MESSAGE FrameworkEvent ERROR
> !STACK 0
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> at java.util.ArrayList.iterator(ArrayList.java:814)
> at org.apache.felix.resolver.ResolverImpl.mergeUses(ResolverImpl.java:962)
> at org.apache.felix.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:787)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:252)
> at org.eclipse.osgi.container.ModuleResolver$ResolveProcess.resolve(ModuleResolver.java:652)
> at org.eclipse.osgi.container.ModuleResolver.resolveDelta(ModuleResolver.java:75)
> at org.eclipse.osgi.container.ModuleContainer.resolveAndApply(ModuleContainer.java:454)
> at org.eclipse.osgi.container.ModuleContainer.resolve(ModuleContainer.java:412)
> at org.eclipse.osgi.container.ModuleContainer.resolve(ModuleContainer.java:402)
> at org.eclipse.osgi.container.Module.start(Module.java:406)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1530)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1510)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1481)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1424)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
> at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
> at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
> {code}
> Even if I raise a memory for JVM, Eclipse doesn't start but not error message is written
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBIDE-16286) CDI builder (not import, workspace rebuild) is very slow in wildfly
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16286?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-16286 at 12/17/13 4:09 AM:
--------------------------------------------------------------------
here's my env:
1) java version "1.7.0_09-icedtea", FC16 64bit
2) -Xmx2048m (the only custom change I did)
3) no Luna TP, using Kepler SR1 and binary plugins
I also have undertow (*git@github.com:undertow-io/undertow-io-site.git*) checked out and imported into my workspace. When changing parent pom I do:
{code}
<version.io.undertow>1.0.0.Beta26</version.io.undertow>
{code}
to
{code}
<version.io.undertow>1.0.0.Beta28-SNAPSHOT></version.io.undertow>
{code}
was (Author: adietish):
here's my env:
1) java version "1.7.0_09-icedtea", FC16 64bit
2) -XX:MaxPermSize=256m
-Xms40m
-Xmx2048m
3) no Luna TP, using Kepler SR1 and binary plugins
I also have undertow (*git@github.com:undertow-io/undertow-io-site.git*) checked out and imported into my workspace. When changing parent pom I do:
{code}
<version.io.undertow>1.0.0.Beta26</version.io.undertow>
{code}
to
{code}
<version.io.undertow>1.0.0.Beta28-SNAPSHOT></version.io.undertow>
{code}
> CDI builder (not import, workspace rebuild) is very slow in wildfly
> -------------------------------------------------------------------
>
> Key: JBIDE-16286
> URL: https://issues.jboss.org/browse/JBIDE-16286
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdi
> Affects Versions: 4.1.1.Final
> Reporter: Andre Dietisheim
> Assignee: Viacheslav Kabanovich
> Priority: Critical
> Labels: performance
> Fix For: 4.1.2.Final, 4.2.0.Alpha2
>
> Attachments: cdi-builder.ogv, cleanBuild.png, maven-preferences-hide-children.png, thread-dump-7_05.txt, thread-dump-7_19.txt, updatingPom.png, VisualVM 1.3.2 _083.png
>
>
> When working in a wildfly workspace with all wildfly projects imported and CDI builder enabled, workspace rebuilds (that you trigger by changing poms and then do maven update project) are a lot slower than without it. Re-building the whole workspace can easily take up to 20 minutes for me.
> Hard to give more general purpose details, I did a quick screencast to give an impression how slow things are for me.
> [^cdi-builder.ogv]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBIDE-16286) CDI builder (not import, workspace rebuild) is very slow in wildfly
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16286?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-16286 at 12/17/13 4:08 AM:
--------------------------------------------------------------------
here's my env:
1) java version "1.7.0_09-icedtea", FC16 64bit
2) -XX:MaxPermSize=256m
-Xms40m
-Xmx2048m
3) no Luna TP, using Kepler SR1 and binary plugins
I also have undertow (*git@github.com:undertow-io/undertow-io-site.git*) checked out and imported into my workspace. When changing parent pom I do:
{code}
<version.io.undertow>1.0.0.Beta26</version.io.undertow>
{code}
to
{code}
<version.io.undertow>1.0.0.Beta28-SNAPSHOT></version.io.undertow>
{code}
was (Author: adietish):
here's my env:
1) java version "1.7.0_09-icedtea", FC16 64bit
2) -XX:MaxPermSize=256m
-Xms40m
-Xmx2048m
3) no Luna TP, using Kepler SR1 and binary plugins
I also have undertow (git@github.com:undertow-io/undertow-io-site.git) checked out and imported into my workspace. When changing parent pom I do:
{code}
<version.io.undertow>1.0.0.Beta26</version.io.undertow>
{code}
to
{code}
<version.io.undertow>1.0.0.Beta28-SNAPSHOT></version.io.undertow>
{code}
> CDI builder (not import, workspace rebuild) is very slow in wildfly
> -------------------------------------------------------------------
>
> Key: JBIDE-16286
> URL: https://issues.jboss.org/browse/JBIDE-16286
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdi
> Affects Versions: 4.1.1.Final
> Reporter: Andre Dietisheim
> Assignee: Viacheslav Kabanovich
> Priority: Critical
> Labels: performance
> Fix For: 4.1.2.Final, 4.2.0.Alpha2
>
> Attachments: cdi-builder.ogv, cleanBuild.png, maven-preferences-hide-children.png, thread-dump-7_05.txt, thread-dump-7_19.txt, updatingPom.png, VisualVM 1.3.2 _083.png
>
>
> When working in a wildfly workspace with all wildfly projects imported and CDI builder enabled, workspace rebuilds (that you trigger by changing poms and then do maven update project) are a lot slower than without it. Re-building the whole workspace can easily take up to 20 minutes for me.
> Hard to give more general purpose details, I did a quick screencast to give an impression how slow things are for me.
> [^cdi-builder.ogv]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBIDE-16286) CDI builder (not import, workspace rebuild) is very slow in wildfly
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16286?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-16286:
------------------------------------------
here's my env:
1) java version "1.7.0_09-icedtea", FC16 64bit
2) -XX:MaxPermSize=256m
-Xms40m
-Xmx2048m
3) no Luna TP, using Kepler SR1 and binary plugins
I also have undertow (git@github.com:undertow-io/undertow-io-site.git) checked out and imported into my workspace. When changing parent pom I do:
{code}
<version.io.undertow>1.0.0.Beta26</version.io.undertow> -> <version.io.undertow>1.0.0.Beta28-SNAPSHOT></version.io.undertow>
{code}
> CDI builder (not import, workspace rebuild) is very slow in wildfly
> -------------------------------------------------------------------
>
> Key: JBIDE-16286
> URL: https://issues.jboss.org/browse/JBIDE-16286
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdi
> Affects Versions: 4.1.1.Final
> Reporter: Andre Dietisheim
> Assignee: Viacheslav Kabanovich
> Priority: Critical
> Labels: performance
> Fix For: 4.1.2.Final, 4.2.0.Alpha2
>
> Attachments: cdi-builder.ogv, cleanBuild.png, maven-preferences-hide-children.png, thread-dump-7_05.txt, thread-dump-7_19.txt, updatingPom.png, VisualVM 1.3.2 _083.png
>
>
> When working in a wildfly workspace with all wildfly projects imported and CDI builder enabled, workspace rebuilds (that you trigger by changing poms and then do maven update project) are a lot slower than without it. Re-building the whole workspace can easily take up to 20 minutes for me.
> Hard to give more general purpose details, I did a quick screencast to give an impression how slow things are for me.
> [^cdi-builder.ogv]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months