[JBoss JIRA] (JBDS-2404) JBDS crashes at startup when a BPEL diagram was open upon previous shutdown
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-2404?page=com.atlassian.jira.plugin.... ]
Nick Boldt updated JBDS-2404:
-----------------------------
Fix Version/s: 5.0.6.GA-SOA
(was: 5.0.4.GA-SOA)
> JBDS crashes at startup when a BPEL diagram was open upon previous shutdown
> ---------------------------------------------------------------------------
>
> Key: JBDS-2404
> URL: https://issues.jboss.org/browse/JBDS-2404
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Integration Platform
> Affects Versions: 5.0.0.GA, 5.0.1.GA
> Environment: Linux (Ubuntu 12.10, 64-bit), Oracle JVM (1.6.0_37 and 1.7.0_09, 64-bit)
> Also 32 bit ubuntu 12.10
> Reporter: Maurice de Chateau
> Assignee: Robert (Bob) Brodt
> Fix For: 5.0.6.GA-SOA
>
> Attachments: crash with BPEL diagram.log, crash with jdk 6.log, CreditReport.wsdl, CreditReportProcess.bpel
>
>
> In JBDS 5.0.x with ´SOA and Data Services Tooling´ installed, the IDE cannot be started up once it was previously closed with a BPEL diagram still opened.
--
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] (JBDS-2471) JBDS6 sets lower default memory settings for SOA server start than are defined in SOA run.conf
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-2471?page=com.atlassian.jira.plugin.... ]
Nick Boldt updated JBDS-2471:
-----------------------------
Fix Version/s: 5.0.6.GA-SOA
(was: 5.0.4.GA-SOA)
> JBDS6 sets lower default memory settings for SOA server start than are defined in SOA run.conf
> ----------------------------------------------------------------------------------------------
>
> Key: JBDS-2471
> URL: https://issues.jboss.org/browse/JBDS-2471
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Integration Platform
> Affects Versions: 5.0.2.GA
> Environment: Version: 5.0.2.GA
> Build id: v20130119-0035-H249-GA
> Build date: 20130119-0035
> http://www.qa.jboss.com/binaries/RHDS/updates/development/5.0.3.GA.soa-to...
> Reporter: Len DiMaggio
> Assignee: Douglas Palmer
> Fix For: 5.0.6.GA-SOA, 6.0.2.GA
>
>
> JBDS6:
> "-Dprogram.name=JBossTools: JBoss SOA 531_ER4 Runtime"
> -server -Xms256m -Xmx768m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true
> -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 "-Djava.endorsed.dirs=/jboss/local/SOA_servers/531_ER4/jboss-soa-p-5/jboss-as/lib/endorsed"
> SOA 5.3.1 run.conf:
> if [ "x$JAVA_OPTS" = "x" ]; then
> JAVA_OPTS="-Xms1303m -Xmx1303m -XX:MaxPermSize=256m -Djava.awt.headless=true -Dorg.apache.xml.dtm.DTMManager=org.apache.xml.dtm.ref.DTMManagerDefault -Dorg.jboss.net.protocol.file.useURI=false -Dorg.jboss.resolver.warning
> =true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Dsun.lang.ClassLoader.allowArraySyntax=true"
> fi
--
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-15392) Add api in server needed for source lookup
by Snjezana Peco (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15392?page=com.atlassian.jira.plugi... ]
Snjezana Peco edited comment on JBIDE-15392 at 9/3/13 10:29 AM:
----------------------------------------------------------------
{quote}
1) why doesn't your requirements need the "client" folder for AS <= 6.x? We add the client folder to all of our as<=6.x providers.
{quote}
Client jars aren't included in the server classpath.
{quote}
2) I have not found any distribution which has a server/default/deploy/lib. So I'm not sure why you'd need that folder
{quote}
If so, "server/default/deploy/lib" can be removed. If you add a non-existing file/folder, nothing will happen.
{quote}
3) Why do you need jboss-modules.jar? Do you think it should also be added a dynamic web project's classpath as well?
{quote}
All the jars that server uses need to be included into the search lookup. That isn't related either to a dynamic or any other project within Eclipse.
{quote}
> common, lib, server , server/default/lib, server/default/deploy/lib, server/default/deployers, server/default/deploy/jbossweb.sar for AS <= 6.x.
I note that you say it should use server/default/lib, but, often times, the chosen server or runtime is not in default mode. This seems a very bad assumption. Current code in as.classpath makes sure to factor in the current configuration (server/all, server/default, server/default2, etc)
{quote}
We don't know a server configuration when debugging. server/default/lib is the best assumption we can make.
We only know a server home directory so we have to recognize directories/jars based on that directory. That's why I mean this method should be added to JBossServerType which is also used in the runtime detection plugin.
{quote}
I think we should discuss any and all discrepencies between what the current classpath code does and the jars you are looking for. Is there a valid use case reason why any one jar would belong to your result set but NOT to my result set (or vice versa?) Or should the two result sets basically be identical?
{quote}
For example, only some of the org and javax modules are included in the JBoss AS 7.1 classpath. The Source Lookup plugin requires all jars/modules (asm, org, com, javax, net ...)
{quote}
Here's a summary of the use cases as Fred and I understand them. Please correct any information that seems wrong so that I can proceed with the patch:
{quote}
JBIDE-13581 is related to the Java search lookup. The PR provides creating a specific Java project that includes all AS jars (filtered by the Source Lookup preferences) and adds them to the Java Search.
That's all. The Java Search Lookup engine is doing everything we need.
The PDE search lookup uses this technique.
was (Author: snjeza):
{quote}
1) why doesn't your requirements need the "client" folder for AS <= 6.x? We add the client folder to all of our as<=6.x providers.
{quote}
Client jars aren't included in the server classpath.
{quote}
2) I have not found any distribution which has a server/default/deploy/lib. So I'm not sure why you'd need that folder
{quote}
If so, "server/default/deploy/lib" can be removed. If you add a non-existing file/folder, nothing will happen.
{quote}
3) Why do you need jboss-modules.jar? Do you think it should also be added a dynamic web project's classpath as well?
{quote}
All the jars that server uses need to be included into the search lookup. That isn't related either to a dynamic or any other project within Eclipse.
{quote}
> common, lib, server , server/default/lib, server/default/deploy/lib, server/default/deployers, server/default/deploy/jbossweb.sar for AS <= 6.x.
I note that you say it should use server/default/lib, but, often times, the chosen server or runtime is not in default mode. This seems a very bad assumption. Current code in as.classpath makes sure to factor in the current configuration (server/all, server/default, server/default2, etc)
{quote}
We don't know a server configuration when debugging. server/default/lib is the best assumption we can make.
We only know a server home directory so we have to recognize directories/jars based on that directory. That's why I mean this method should be added to JBossServerType which is also used in the runtime detection plugin.
{quote}
I think we should discuss any and all discrepencies between what the current classpath code does and the jars you are looking for. Is there a valid use case reason why any one jar would belong to your result set but NOT to my result set (or vice versa?) Or should the two result sets basically be identical?
{quote}
For example, only some of the org and javax modules are included in the JBoss AS 7.1 classpath. The Source Lookup plugin requires all jars/modules (asm, org, com, javax, net ...)
{quote}
Here's a summary of the use cases as Fred and I understand them. Please correct any information that seems wrong so that I can proceed with the patch:
{quote}
JBIDE-13581 is related to the Java search lookup. The PR provides creating a specific Java project that includes all AS jars (filtered by the Source Lookup preferences) and adds them to the Java Search.
That's all. The Java Search Lookup engine doing everything we need.
The PDE search lookup uses this technique.
> Add api in server needed for source lookup
> ------------------------------------------
>
> Key: JBIDE-15392
> URL: https://issues.jboss.org/browse/JBIDE-15392
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: maven, server
> Reporter: Max Rydahl Andersen
> Assignee: Rob Stryker
>
> As uncovered in https://github.com/jbosstools/jbosstools-central/pull/128/files#L5L120 we got a problem with source lookup code always having to play catchup with server changes.
> We need to define a stable api that can be used here.
> lets outline what api is actually needed and then subjiras for the specifics.
> For me it looks like server lookup needs a few things:
> 0. know exact version of server
> 1. know the file structure of a certain server
> 2. get dir or directories that contain jar that is the "runtime"
> My guess is that #2 might just be sufficient for source code lookup.
> Any comments ?
--
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-15392) Add api in server needed for source lookup
by Snjezana Peco (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15392?page=com.atlassian.jira.plugi... ]
Snjezana Peco commented on JBIDE-15392:
---------------------------------------
{quote}
1) why doesn't your requirements need the "client" folder for AS <= 6.x? We add the client folder to all of our as<=6.x providers.
{quote}
Client jars aren't included in the server classpath.
{quote}
2) I have not found any distribution which has a server/default/deploy/lib. So I'm not sure why you'd need that folder
{quote}
If so, "server/default/deploy/lib" can be removed. If you add a non-existing file/folder, nothing will happen.
{quote}
3) Why do you need jboss-modules.jar? Do you think it should also be added a dynamic web project's classpath as well?
{quote}
All the jars that server uses need to be included into the search lookup. That isn't related either to a dynamic or any other project within Eclipse.
{quote}
> common, lib, server , server/default/lib, server/default/deploy/lib, server/default/deployers, server/default/deploy/jbossweb.sar for AS <= 6.x.
I note that you say it should use server/default/lib, but, often times, the chosen server or runtime is not in default mode. This seems a very bad assumption. Current code in as.classpath makes sure to factor in the current configuration (server/all, server/default, server/default2, etc)
{quote}
We don't know a server configuration when debugging. server/default/lib is the best assumption we can make.
We only know a server home directory so we have to recognize directories/jars based on that directory. That's why I mean this method should be added to JBossServerType which is also used in the runtime detection plugin.
{quote}
I think we should discuss any and all discrepencies between what the current classpath code does and the jars you are looking for. Is there a valid use case reason why any one jar would belong to your result set but NOT to my result set (or vice versa?) Or should the two result sets basically be identical?
{quote}
For example, only some of the org and javax modules are included in the JBoss AS 7.1 classpath. The Source Lookup plugin requires all jars/modules (asm, org, com, javax, net ...)
{quote}
Here's a summary of the use cases as Fred and I understand them. Please correct any information that seems wrong so that I can proceed with the patch:
{quote}
JBIDE-13581 is related to the Java search lookup. The PR provides creating a specific Java project that includes all AS jars (filtered by the Source Lookup preferences) and adds them to the Java Search.
That's all. The Java Search Lookup engine doing everything we need.
The PDE search lookup uses this technique.
> Add api in server needed for source lookup
> ------------------------------------------
>
> Key: JBIDE-15392
> URL: https://issues.jboss.org/browse/JBIDE-15392
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: maven, server
> Reporter: Max Rydahl Andersen
> Assignee: Rob Stryker
>
> As uncovered in https://github.com/jbosstools/jbosstools-central/pull/128/files#L5L120 we got a problem with source lookup code always having to play catchup with server changes.
> We need to define a stable api that can be used here.
> lets outline what api is actually needed and then subjiras for the specifics.
> For me it looks like server lookup needs a few things:
> 0. know exact version of server
> 1. know the file structure of a certain server
> 2. get dir or directories that contain jar that is the "runtime"
> My guess is that #2 might just be sufficient for source code lookup.
> Any comments ?
--
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-14529) Support 'Open Declaration(F3)' on Resource lookup in Deployment methods
by Snjezana Peco (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14529?page=com.atlassian.jira.plugi... ]
Snjezana Peco commented on JBIDE-14529:
---------------------------------------
The Java editor registers the OpenAction(F3) when opening a Java file.
There is no an easy way to change this action or contribute our action.
The issue can be solved in the way similar to the issue described in JBIDE-14530 (by creating a separate editor for Arquillian JUnit classes)
Aslak, Max,
WDYT?
> Support 'Open Declaration(F3)' on Resource lookup in Deployment methods
> -----------------------------------------------------------------------
>
> Key: JBIDE-14529
> URL: https://issues.jboss.org/browse/JBIDE-14529
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Components: testing-tools
> Reporter: Aslak Knutsen
> Assignee: Snjezana Peco
> Fix For: 4.1.x, 4.2.x
>
>
> Given a deployment method with resource references
> When pressing 'open declaration(F3)'
> Then open the source file for the reference
> Not sure if this makes sense in Eclipse lingo, but I personally navigate code via F3 (Open Declaration) a lot. Navigating to JavaArchive.class via F3 but having to do 'Ctrl+Mouse Click' to get to the resource reference seems clumsy.
--
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