[JBoss JIRA] (JBIDE-16717) CLONE - Seam 2.3 Portlet deployment error on JPP 6
by Snjezana Peco (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16717?page=com.atlassian.jira.plugi... ]
Snjezana Peco commented on JBIDE-16717:
---------------------------------------
You should use seam 2.3.2 (see JBIDE-16095) and deploy resources/*-ds.xml
After that, the seam portlet will be shown in the Registry page.
You will face such issues if you try to deploy a seam project on JBoss EAP.
I am not sure if the seam portlet is supported by JPP 6.1.
> CLONE - Seam 2.3 Portlet deployment error on JPP 6
> --------------------------------------------------
>
> Key: JBIDE-16717
> URL: https://issues.jboss.org/browse/JBIDE-16717
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: portal-gatein
> Affects Versions: 4.1.2.CR1
> Reporter: Radoslav Rábara
> Assignee: Snjezana Peco
> Priority: Critical
> Labels: respin-a
> Fix For: 4.1.2.CR1
>
>
> Deployment of Seam Portal Project ends with error when it's deployed to JPP 6.
> As far as I know, we have quickstarts for portal development on JPP 6. So is creating Portal Project via Dynamic Web Project supported only for older versions of EPP?
--
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, 3 months
[JBoss JIRA] (JBIDE-16689) Crash after CTRL + rightclick + find implementation
by Victor Rubezhny (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16689?page=com.atlassian.jira.plugi... ]
Victor Rubezhny edited comment on JBIDE-16689 at 3/7/14 12:08 PM:
------------------------------------------------------------------
[~velteyn],
I can reproduce Marco's exception on JBDS 6.0.1 (installed from jbdevstudio-product-eap-universal-6.0.1.GA-v20130327-2052-B361.jar). So, yes JSDT Core (that comes from WTP v.3.4.2) has an issue, and that issue is fixed in latest version of JSDT Core. In short, JSDT Core doesn't catch SelectionNodeFound Exception while it should catch this exception for its proper work. In your case this means that Hover probably will not be shown for your method. (It's not about 'find declaration', but it's about a hover that is to be shown when you're holding your mouse cursor for a second or two over some variable or function in the editor. It often is displayed at the moment when you are opening a ctrl-rc context menu, just by an occasion.)
But this exception is not a fatal error, so it shouldn't lead to exiting from JBDS. We can provide you with a fixed version of org.eclipse.wst.jdbs.core, but IMHO it will not solve your initial 'crash' situation.
IMHO, there are some other reasons for JBDS to be exited. For example, an OutOfMemory exception (I didn't see such an exception in your logs, but you provided a truncated log only, so it might be there). Some features of JDBS (and particulary JSDT) are very demanding in terms of memory. 64-bit applications require more memory to run comparing to the 32-bit ones. You wrote that your project is a big one, so probably you should tune your JBDS to use more memory. For example, you may increase the setings in your <jbds>/studio/jbdevstudio.ini:
{code}
-vmargs
-Xms512m
-Xmx1024m
{code}
Another possible reason could be an access violations in JVM. In this case you can find dump files, named like hs_err_pid<PID of JBDS>.log as I described above, in:
- JBDS installation folder
- In your home folder
The labels like "Problematic Frame" may tell you the library or executable which is probably caused the crash.
I'd started with searching for the dumps stored on your system, investigating your full .log file and increasing the memory settings for JBDS.
was (Author: vrubezhny):
[~velteyn],
I can reproduce Marco's exception on JBDS 6.0.1 (installed from jbdevstudio-product-eap-universal-6.0.1.GA-v20130327-2052-B361.jar). So, yes JSDT Core (that comes from WTP v.3.4.2) has an issue, and that issue is fixed in latest version of JSDT Core. In short, JSDT Core doesn't catch SelectionNodeFound Exception while it should catch this exception for its proper work. In your case this means that Hover probably will not be shown for your method. (It's not about 'find declaration, but it's about a hover that is to be shown when you're holding your mouse cursor for a second or two over some variable or function in the editor. It often is displayed at the moment when you are opening a ctrl-rc context menu, just by an occasion.)
But this exception is not a fatal error, so it shouldn't lead to exiting from JBDS. We can provide you with a fixed version of org.eclipse.wst.jdbs.core, but IMHO it will not solve your initial 'crash' situation.
IMHO, there are some other reasons for JBDS to be exited. For example, an OutOfMemory exception (I didn't see such an exception in your logs, but you provided a truncated log only, so it might be there). Some features of JDBS (and particulary JSDT) are very demanding in terms of memory. 64-bit applications require more memory to run comparing to the 32-bit ones. You wrote that your project is a big one, so probably you should tune your JBDS to use more memory. For example, you may increase the setings in your <jbds>/studio/jbdevstudio.ini:
{code}
-vmargs
-Xms512m
-Xmx1024m
{code}
Another possible reason could be an access violations in JVM. In this case you can find dump files, named like hs_err_pid<PID of JBDS>.log as I described above, in:
- JBDS installation folder
- In your home folder
The labels like "Problematic Frame" may tell you the library or executable which is probably caused the crash.
I'd started with searching for the dumps stored on your system, investigating your full .log file and increasing the memory settings for JBDS.
> Crash after CTRL + rightclick + find implementation
> ---------------------------------------------------
>
> Key: JBIDE-16689
> URL: https://issues.jboss.org/browse/JBIDE-16689
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: upstream
> Reporter: Edoardo Barolo
>
--
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, 3 months
[JBoss JIRA] (JBIDE-16689) Crash after CTRL + rightclick + find implementation
by Victor Rubezhny (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16689?page=com.atlassian.jira.plugi... ]
Victor Rubezhny commented on JBIDE-16689:
-----------------------------------------
[~velteyn],
I can reproduce Marco's exception on JBDS 6.0.1 (installed from jbdevstudio-product-eap-universal-6.0.1.GA-v20130327-2052-B361.jar). So, yes JSDT Core (that comes from WTP v.3.4.2) has an issue, and that issue is fixed in latest version of JSDT Core. In short, JSDT Core doesn't catch SelectionNodeFound Exception while it should catch this exception for its proper work. In your case this means that Hover probably will not be shown for your method. (It's not about 'find declaration, but it's about a hover that is to be shown when you're holding your mouse cursor for a second or two over some variable or function in the editor. It often is displayed at the moment when you are opening a ctrl-rc context menu, just by an occasion.)
But this exception is not a fatal error, so it shouldn't lead to exiting from JBDS. We can provide you with a fixed version of org.eclipse.wst.jdbs.core, but IMHO it will not solve your initial 'crash' situation.
IMHO, there are some other reasons for JBDS to be exited. For example, an OutOfMemory exception (I didn't see such an exception in your logs, but you provided a truncated log only, so it might be there). Some features of JDBS (and particulary JSDT) are very demanding in terms of memory. 64-bit applications require more memory to run comparing to the 32-bit ones. You wrote that your project is a big one, so probably you should tune your JBDS to use more memory. For example, you may increase the setings in your <jbds>/studio/jbdevstudio.ini:
{code}
-vmargs
-Xms512m
-Xmx1024m
{code}
Another possible reason could be an access violations in JVM. In this case you can find dump files, named like hs_err_pid<PID of JBDS>.log as I described above, in:
- JBDS installation folder
- In your home folder
The labels like "Problematic Frame" may tell you the library or executable which is probably caused the crash.
I'd started with searching for the dumps stored on your system, investigating your full .log file and increasing the memory settings for JBDS.
> Crash after CTRL + rightclick + find implementation
> ---------------------------------------------------
>
> Key: JBIDE-16689
> URL: https://issues.jboss.org/browse/JBIDE-16689
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: upstream
> Reporter: Edoardo Barolo
>
--
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, 3 months
[JBoss JIRA] (JBIDE-16249) Offline groovy script not working - FileNotFoundException
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16249?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-16249:
---------------------------------------
[~fbricon] the result is that the generated errai archetype does not work. At least from what Radim tried. He will file a bug on Monday. But at this point we probably don't want this to delay the build.
> Offline groovy script not working - FileNotFoundException
> ----------------------------------------------------------
>
> Key: JBIDE-16249
> URL: https://issues.jboss.org/browse/JBIDE-16249
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: central, project-examples
> Affects Versions: 4.1.1.CR1
> Environment: JBDS 7.1.0.CR1a B560
> OS X
> Groovy Version: 2.1.8 JVM: 1.7.0_45 Vendor: Oracle Corporation OS: Mac OS X (installed via mac ports)
> Reporter: Martin Malina
> Assignee: Fred Bricon
> Fix For: 4.1.2.CR1
>
> Attachments: groovy.log
>
>
> I tried to run the offline examples groovy script today (Preferences -> JBoss Tools -> Project Examples -> Offline Support).
> When I ran the script I saw a couple of errors along the way, see at the end of email. I was told that it could have to do with WFK 2.4 not being available in the online repo yet.
> But ultimately the script failed this exception:
> java.io.FileNotFoundException: /Users/rasp/jbossqa/runtimes/zip/offline/workDir/jboss-javaee6-webapp-blank-archetype/my-jboss-javaee6-webapp-blank-archetype
> I had jboss nexus and http://maven.repository.redhat.com/techpreview/all/ in my settings.xml. After the script finished, the offline dir was 536M big.
--
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, 3 months
[JBoss JIRA] (JBIDE-16722) JMX connection hangs for remote EAP 6.2
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16722?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-16722:
---------------------------------------
It turns out this is not a regression in 4.1.2 - I can reproduce the same in JBDS 7.1.0 (JBT 4.1.1). It may have to do with this: JBIDE-15651 - this was a fix for local EAP 6.1+, but it might have done something to remote servers. Not sure though.
> JMX connection hangs for remote EAP 6.2
> ---------------------------------------
>
> Key: JBIDE-16722
> URL: https://issues.jboss.org/browse/JBIDE-16722
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.1.2.CR1
> Environment: JBDS 7.1.1.CR1 B672
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Priority: Critical
> Labels: respin-a
> Fix For: 4.1.2.CR1
>
>
> I tried out JMX connection with a remote EAP 6.2.
> I set up the server with default settings and started it. I was surprised to see that the IDE didn't ask me for password as is usual. Deployment worked.
> So I tried Show in MBean Explorer. And that hanged once I expanded the server connection there - there was an Unhandled Event Loop error in the error log and the IDE has been eating up all of my CPU for about 10 mins now - I will have to kill it.
> I know that this happened in the past when the tooling things the connection is established, but it isn't. One thing is finding out why it doesn't work now. But another thing we absolutely need fixed is the unhandled loop - this shouldn't happen under no circumstances.
--
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, 3 months