January 2013 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-13189) Standalone BrowserSim should create .browsersim/config.cfg folder in user home directory

by Yahor Radtsevich (JIRA)

[ https://issues.jboss.org/browse/JBIDE-13189?page=com.atlassian.jira.plugi... ] Yahor Radtsevich updated JBIDE-13189: ------------------------------------- Summary: Standalone BrowserSim should create .browsersim/config.cfg folder in user home directory (was: standalone browsersim creates org.jboss.tools.vpe.browsersim in current working directory) > Standalone BrowserSim should create .browsersim/config.cfg folder in user home directory > ---------------------------------------------------------------------------------------- > > Key: JBIDE-13189 > URL: https://issues.jboss.org/browse/JBIDE-13189 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: Visual Page Editor core > Reporter: Max Rydahl Andersen > Assignee: Konstantin Marmalyukov > Fix For: 4.1.x > > > org.jboss.tools.vpe.browsersim/devices.cfg is created on every launch. > Couldn't this only be generated if actually did changes ? > and if i'm in standalone couldn't it be stored in like ~/.browsersim/devices.cfg or similar ? -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBDS-2437) Cannot deploy BPEL project

by Andrej Podhradsky (JIRA)

[ https://issues.jboss.org/browse/JBDS-2437?page=com.atlassian.jira.plugin.... ] Andrej Podhradsky closed JBDS-2437. ----------------------------------- Verified with JBDS 5.0.2.GA v20130119-0035-H249-GA > Cannot deploy BPEL project > -------------------------- > > Key: JBDS-2437 > URL: https://issues.jboss.org/browse/JBDS-2437 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: SOA Tooling / Platform > Affects Versions: 5.0.2.GA > Environment: JBDS 5.0.2.CR1 H235 + SOA-P 5.3.0.GA > Reporter: Andrej Podhradsky > Assignee: Rob Stryker > Priority: Blocker > Labels: respin-b > Fix For: 5.0.2.GA > > Attachments: deploy_error.png, jbosstools-diagnostics-20130109091445.zip > > > Cannot deploy a bpel project. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBDS-2448) New ESB wizard - version mismatch errors - and a warning message that is not erased

by Andrej Podhradsky (JIRA)

[ https://issues.jboss.org/browse/JBDS-2448?page=com.atlassian.jira.plugin.... ] Andrej Podhradsky closed JBDS-2448. ----------------------------------- Verified with SOA Tooling 5.0.3.v20130128-1900-H4-GA > New ESB wizard - version mismatch errors - and a warning message that is not erased > ----------------------------------------------------------------------------------- > > Key: JBDS-2448 > URL: https://issues.jboss.org/browse/JBDS-2448 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: SOA Tooling / Platform > Affects Versions: 5.0.3.GA-SOA > Environment: Version: 5.0.2.GA > Build id: v20130119-0035-H249-GA > Build date: 20130119-0035 > md5sum esb.site.zip > 4c149c52a6058edabe0ad84747443877 esb.site.zip > Reporter: Len DiMaggio > Assignee: Brian Fitzpatrick > Fix For: 5.0.3.GA-SOA > > Attachments: JBDS-2448-3.3.x.patch, JBDS-2448-git-4.1.x.patch > > > Steps: > 1) Create new ESB runtime, select the SOA Platform dir path > 2) Accept default version, specify a name for the new run-time > 3) Then - before saving the new ESB runtime change the version number - the results are: > With an SOA-P 5.2 server (ESB 4.10): > * The default ESB version displayed is 4.10 > * If this is changed to 4.11, this warning is displayed: > No exact match found for ESB runtime version 4.10. Assuming compatible with latest version: 4.7. > * If the version is changed back to 4.10, the error is still displayed in the wizard > With an SOA-P 5.3 server (ESB 4.11): > * The default ESB version displayed is 4.11 > * If this is changed to 4.12, this warning is displayed: > No exact match found for ESB runtime version 4.11. Assuming compatible with latest version: 4.12. > * If the version is changed back to 4.11, the error is still displayed in the wizard > With an SOA-P 5.3.1.ER3 server (ESB 4.11.1): > * The default ESB version displayed is 4.11 > * If this is changed to 4.12, this warning is displayed: > No exact match found for ESB runtime version 4.11. Assuming compatible with latest version: 4.12. > * If the version is changed back to 4.11, the error is still displayed in the wizard > With an SOA-P 5.3.1.ER4 server (edited VERSION file in rosetta.jar to be ESB 4.12): > * The default ESB version displayed is 4.12 > * If this is changed to 4.11, this warning is displayed: > No exact match found for ESB runtime version 4.12. Assuming compatible with latest version: 4.11. > * If the version is changed back to 4.12, the error is still displayed in the wizard -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-13442) Increase hibernate plugin minor version and update dependencies versions to dali for kepler

by Denis Golovin (JIRA)

Denis Golovin created JBIDE-13442: ------------------------------------- Summary: Increase hibernate plugin minor version and update dependencies versions to dali for kepler Key: JBIDE-13442 URL: https://issues.jboss.org/browse/JBIDE-13442 Project: Tools (JBoss Tools) Issue Type: Task Components: hibernate Affects Versions: 4.1.0.Alpha1 Reporter: Denis Golovin Assignee: Denis Golovin Priority: Blocker -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTIS-8) JBossTools Integration Stack :: drools: Verify the component configuration of the initial IS tooling release.

by Kris Verlaenen (JIRA)

[ https://issues.jboss.org/browse/JBTIS-8?page=com.atlassian.jira.plugin.sy... ] Kris Verlaenen commented on JBTIS-8: ------------------------------------ Paul, In site.xml, could you update the category "BusinessRules" to "BusinessLogic" with label "Business Process and Rules Tooling" and description "Business Processes and Rules Tooling for Eclipse - includes support for jBPM and Drools" In compositeArtifacts.xml, the version of the drools/jbpm should probably be 5.5.0.Final (instead of 5.4.0) Kris > JBossTools Integration Stack :: drools: Verify the component configuration of the initial IS tooling release. > ------------------------------------------------------------------------------------------------------------- > > Key: JBTIS-8 > URL: https://issues.jboss.org/browse/JBTIS-8 > Project: JBoss Tools Integration Stack > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: drools > Environment: JBT 4.0 > Reporter: Paul Leacu > Assignee: Kris Verlaenen > > Please verify your component configuration of the JBoss Integration Stack for a JBoss Tools 4.0 target. > Also check that all components are compatible with the upstream components defined in the target platform. > ref: > https://github.com/pleacu/jbosstools-integration-stack-proto/blob/master/... > https://github.com/pleacu/jbosstools-integration-stack-proto/blob/master/... - compositeContent.xml > https://github.com/pleacu/jbosstools-integration-stack-proto/blob/master/... > I'm working on getting this project promoted to jbosstools in github. Unitl then please refer to/fork the urls above. There is a best-guess already specified for each component. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-13441) Changing vm for runtime from default to jdk1.7, then back to default, fails

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-13441?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-13441: ------------------------------------- This issue was complicated by the fact that the wtp ui framework only instantiates the wizard fragment once per workspace, and so any state from previous calls ot the fragment will be left around. After discovering this, the issue was a bit clearer. > Changing vm for runtime from default to jdk1.7, then back to default, fails > --------------------------------------------------------------------------- > > Key: JBIDE-13441 > URL: https://issues.jboss.org/browse/JBIDE-13441 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: JBossAS/Servers > Affects Versions: 4.0.0.Final > Reporter: Rob Stryker > Assignee: Rob Stryker > Fix For: 4.1.0.Alpha1 > > > 0) In workspace, ensure workspace has 1.7 jre, then add a 1.6 jre > 1) Create a web app with simple servlet, doGet() has logic: System.out.println(System.getProperty("java.version")); > 2) Create server and runtime, keep vm at default for exec env > 3) Start server, deploy web app, verify 1.6 > 4) Shutdown server > 5) Switch runtime to use 1.7 jre, finish, then save server editor > 6) Start server, verify webapp prints to console 1.7 > 7) Stop server > 8) Edit runtime to use default for 1.6 again > 9) finish wizard, save server editor > 10) start server, run webapp, verify text says 1.6 > FAIL > Step 10 fails, the 1.7 server is still chosen. This is a bug in the UI which is not properly clearing the vm flag, and is only setting it when one is chosen. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-13441) Changing vm for runtime from default to jdk1.7, then back to default, fails

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-13441?page=com.atlassian.jira.plugi... ] Rob Stryker resolved JBIDE-13441. --------------------------------- Resolution: Done pushed in > Changing vm for runtime from default to jdk1.7, then back to default, fails > --------------------------------------------------------------------------- > > Key: JBIDE-13441 > URL: https://issues.jboss.org/browse/JBIDE-13441 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: JBossAS/Servers > Affects Versions: 4.0.0.Final > Reporter: Rob Stryker > Assignee: Rob Stryker > Fix For: 4.1.0.Alpha1 > > > 0) In workspace, ensure workspace has 1.7 jre, then add a 1.6 jre > 1) Create a web app with simple servlet, doGet() has logic: System.out.println(System.getProperty("java.version")); > 2) Create server and runtime, keep vm at default for exec env > 3) Start server, deploy web app, verify 1.6 > 4) Shutdown server > 5) Switch runtime to use 1.7 jre, finish, then save server editor > 6) Start server, verify webapp prints to console 1.7 > 7) Stop server > 8) Edit runtime to use default for 1.6 again > 9) finish wizard, save server editor > 10) start server, run webapp, verify text says 1.6 > FAIL > Step 10 fails, the 1.7 server is still chosen. This is a bug in the UI which is not properly clearing the vm flag, and is only setting it when one is chosen. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-13441) Changing vm for runtime from default to jdk1.7, then back to default, fails

by Rob Stryker (JIRA)

Rob Stryker created JBIDE-13441: ----------------------------------- Summary: Changing vm for runtime from default to jdk1.7, then back to default, fails Key: JBIDE-13441 URL: https://issues.jboss.org/browse/JBIDE-13441 Project: Tools (JBoss Tools) Issue Type: Bug Components: JBossAS/Servers Affects Versions: 4.0.0.Final Reporter: Rob Stryker Assignee: Rob Stryker Fix For: 4.1.0.Alpha1 0) In workspace, ensure workspace has 1.7 jre, then add a 1.6 jre 1) Create a web app with simple servlet, doGet() has logic: System.out.println(System.getProperty("java.version")); 2) Create server and runtime, keep vm at default for exec env 3) Start server, deploy web app, verify 1.6 4) Shutdown server 5) Switch runtime to use 1.7 jre, finish, then save server editor 6) Start server, verify webapp prints to console 1.7 7) Stop server 8) Edit runtime to use default for 1.6 again 9) finish wizard, save server editor 10) start server, run webapp, verify text says 1.6 FAIL Step 10 fails, the 1.7 server is still chosen. This is a bug in the UI which is not properly clearing the vm flag, and is only setting it when one is chosen. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-13425) Enhance astools api to centralize default launch arguments

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-13425?page=com.atlassian.jira.plugi... ] Rob Stryker resolved JBIDE-13425. --------------------------------- Resolution: Done > Enhance astools api to centralize default launch arguments > ----------------------------------------------------------- > > Key: JBIDE-13425 > URL: https://issues.jboss.org/browse/JBIDE-13425 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: JBossAS/Servers > Reporter: Rob Stryker > Assignee: Rob Stryker > Fix For: 4.1.0.Alpha1 > > > Runtime interface, and behavior delegates, are full of code involving default start and stop launch arguments. These should be centralized in an interface accessible via the extended properties model. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-12913) Startup/Shutdown Pollers fails with EAP511

by Martin Malina (JIRA)

[ https://issues.jboss.org/browse/JBIDE-12913?page=com.atlassian.jira.plugi... ] Martin Malina commented on JBIDE-12913: --------------------------------------- I just tried this on Win XP with JBDS 6.0.0.GA and EAP 5.1.1 and sadly I cannot reproduce the issue. It starts just fine (bound to 0.0.0.0). Let's see if Rob has anything to say. > Startup/Shutdown Pollers fails with EAP511 > ------------------------------------------ > > Key: JBIDE-12913 > URL: https://issues.jboss.org/browse/JBIDE-12913 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: JBossAS/Servers > Affects Versions: 4.0.0.Alpha2 > Environment: Windows XP > Reporter: Jesper Skov > Assignee: Rob Stryker > Fix For: 4.0.0.Beta2 > > Attachments: server-startup-poller-problem.png > > > When we use Web Port Startup Poller with EAP511, the server is not started. > We get an error about the port (8080) already being in use. Which it is not (confirmed with netstat). > When changing Startup Poller to JMX, the server starts as expected. > When using the JMX Shutdown Poller, it also fails. This time with failed attempts to access the JMX server after the server has shut down: > Exception in thread "main" javax.naming.CommunicationException: Could not obtain connection to any of these urls: 0.0.0.0:1099 [Root exception is javax.naming.CommunicationException: Failed to connect to server /0.0.0.0:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server /0.0.0.0:1099 [Root exception is java.net.ConnectException: Connection refused: connect]]] > at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1763) > at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:693) > at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:686) > at javax.naming.InitialContext.lookup(Unknown Source) > at org.jboss.Shutdown.main(Shutdown.java:219) > Caused by: javax.naming.CommunicationException: Failed to connect to server /0.0.0.0:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server /0.0.0.0:1099 [Root exception is java.net.ConnectException: Connection refused: connect]] > at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:335) > at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1734) > ... 4 more > Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server /0.0.0.0:1099 [Root exception is java.net.ConnectException: Connection refused: connect] > at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:305) > ... 5 more > Caused by: java.net.ConnectException: Connection refused: connect > at java.net.PlainSocketImpl.socketConnect(Native Method) > at java.net.PlainSocketImpl.doConnect(Unknown Source) > at java.net.PlainSocketImpl.connectToAddress(Unknown Source) > at java.net.PlainSocketImpl.connect(Unknown Source) > at java.net.SocksSocketImpl.connect(Unknown Source) > at java.net.Socket.connect(Unknown Source) > at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:97) > at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:82) > at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:301) > ... 5 more > Using Process Terminated Poller works as expected though. -- 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

13 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-issues January 2013