August 2014 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-18181) Errors when hibernate.cfg.xml not at classpath root

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18181?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen updated JBIDE-18181: ---------------------------------------- Fix Version/s: 4.2.0.CR1 > Errors when hibernate.cfg.xml not at classpath root > --------------------------------------------------- > > Key: JBIDE-18181 > URL: https://issues.jboss.org/browse/JBIDE-18181 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: hibernate > Environment: Ubuntu Trusty, Eclipse Luna, OpenJDK 7, Hibernate Tools 3.8.0.CR1-v20140826-1536-B599, Hibernate 4.1.12 > Reporter: Luke Maurer > Priority: Blocker > Fix For: 4.2.0.CR1 > > > If a project keeps its hibernate.cfg.xml anywhere besides the root of the classpath, Hibernate Tools will not recognize it. In the Hibernate Configurations tree, expanding either Session Factory or Database gives an error ending in “/hibernate.cfg.xml not found”. (The Configuration subtree appears to work.) > As a workaround, if I go into the directory holding WEB-INF/classes (i.e. where compiled Java bytecode goes) and symlink hibernate.cfg.xml there, it seems to work. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18181) Errors when hibernate.cfg.xml not at classpath root

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18181?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen updated JBIDE-18181: ---------------------------------------- Priority: Blocker (was: Major) > Errors when hibernate.cfg.xml not at classpath root > --------------------------------------------------- > > Key: JBIDE-18181 > URL: https://issues.jboss.org/browse/JBIDE-18181 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: hibernate > Environment: Ubuntu Trusty, Eclipse Luna, OpenJDK 7, Hibernate Tools 3.8.0.CR1-v20140826-1536-B599, Hibernate 4.1.12 > Reporter: Luke Maurer > Priority: Blocker > > If a project keeps its hibernate.cfg.xml anywhere besides the root of the classpath, Hibernate Tools will not recognize it. In the Hibernate Configurations tree, expanding either Session Factory or Database gives an error ending in “/hibernate.cfg.xml not found”. (The Configuration subtree appears to work.) > As a workaround, if I go into the directory holding WEB-INF/classes (i.e. where compiled Java bytecode goes) and symlink hibernate.cfg.xml there, it seems to work. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18209) Autoapply new default JS/CSS library preferences

by Alexey Kazakov (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18209?page=com.atlassian.jira.plugi... ] Alexey Kazakov updated JBIDE-18209: ----------------------------------- Fix Version/s: 4.3.0.Alpha1 (was: 4.2.0.CR2) > Autoapply new default JS/CSS library preferences > ------------------------------------------------ > > Key: JBIDE-18209 > URL: https://issues.jboss.org/browse/JBIDE-18209 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: jsp/jsf/xml/html source editing > Reporter: Viacheslav Kabanovich > Assignee: Viacheslav Kabanovich > Fix For: 4.3.0.Alpha1 > > > Preferences JBossTools->Web->JS/CSS are initially set to default versions declared in extension point org.jboss.tools.jst.web.ui.jscssLibs. User can change some of them and leave some default libraries. New version of JBossTools may change some default libraries and add new. > With current implementation, user would have to go to preferences and use 'Restore Defaults' to get new default libraries. That is not good, new default libraries should replace old default libraries automatically. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18209) Autoapply new default JS/CSS library preferences

by Viacheslav Kabanovich (JIRA)

Viacheslav Kabanovich created JBIDE-18209: --------------------------------------------- Summary: Autoapply new default JS/CSS library preferences Key: JBIDE-18209 URL: https://issues.jboss.org/browse/JBIDE-18209 Project: Tools (JBoss Tools) Issue Type: Enhancement Components: jsp/jsf/xml/html source editing Reporter: Viacheslav Kabanovich Assignee: Viacheslav Kabanovich Fix For: 4.2.0.CR2 Preferences JBossTools->Web->JS/CSS are initially set to default versions declared in extension point org.jboss.tools.jst.web.ui.jscssLibs. User can change some of them and leave some default libraries. New version of JBossTools may change some default libraries and add new. With current implementation, user would have to go to preferences and use 'Restore Defaults' to get new default libraries. That is not good, new default libraries should replace old default libraries automatically. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3131) ensure the website urls for installing from central continues to work for both devstudio domains

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBDS-3131?page=com.atlassian.jira.plugin.... ] Max Rydahl Andersen commented on JBDS-3131: ------------------------------------------- +1 for doing that hardcoding on website for now, but eventually I think we should have a way for an IS release to state which connectors are relevant to show/how they get named...but we can do that later. abuot #281 we still would like devstudio.jboss.com links to work on devstudio 8 IMO. > ensure the website urls for installing from central continues to work for both devstudio domains > ------------------------------------------------------------------------------------------------ > > Key: JBDS-3131 > URL: https://issues.jboss.org/browse/JBDS-3131 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: central, website > Reporter: Max Rydahl Andersen > Fix For: 8.0.0.CR1 > > > with devstudio.jboss.com being replace by devstudio.redhat.com we need central to continue to understand both when url is dragged to it and we can't just hard code the use of redhat.com into the website since that will make the urls invalid for JBDS 7. > https://github.com/jbosstools/jbosstools-website/pull/197 and https://github.com/jbosstools/jbosstools-central/pull/281 are incomplete versions of this that hardcodes devstudio.redhat.com - we need to support both. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3002) JBDS 7.1.1 installer contains jars signed by GTECyberTrust, which may not be installed on all linux systems

by Denis Golovin (JIRA)

[ https://issues.jboss.org/browse/JBDS-3002?page=com.atlassian.jira.plugin.... ] Denis Golovin updated JBDS-3002: -------------------------------- Labels: respin-a (was: ) > JBDS 7.1.1 installer contains jars signed by GTECyberTrust, which may not be installed on all linux systems > ----------------------------------------------------------------------------------------------------------- > > Key: JBDS-3002 > URL: https://issues.jboss.org/browse/JBDS-3002 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: installer, updatesite > Affects Versions: 7.1.1.GA > Reporter: Max Rydahl Andersen > Assignee: Denis Golovin > Priority: Blocker > Labels: respin-a > Fix For: 8.0.0.CR1 > > > We have jars in JBDS 7.1.1.GA which were signed using GTECyberTrust. Some linux installs do not include this root cert, so when installing, p2 rejects the cert: > {code}One or more certificates rejected. Cannot proceed with installation.{code} > Full details: https://community.jboss.org/message/866868 > *Platform details:* > {code} > Debian Jessie 64 bit > $ uname -a: > Linux Name 3.13-1-amd64 #1 SMP Debian 3.13.7-1 (2014-03-25) x86_64 GNU/Linux > $ java -version > java version "1.7.0_51" > OpenJDK Runtime Environment (IcedTea 2.4.5) (7u51-2.4.5-2) > OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode) > {code} > Note that Debian 8.0 "Jessie" is not yet released nor has a date for release been announced [0]. The latest stable Debian [1] is 7.4 "Wheezy", released on Feb 8, 2014. [2] The description for "testing" releases like Jessie is "Security updates are irregular and unreliable." [3] So... I don't think we support this OS yet. :) > [0] http://www.debian.org/releases/jessie/ > [1] http://www.debian.org/releases/ > [2] http://www.debian.org/releases/wheezy/ > [3] https://release.debian.org/ > *Steps to repro on the above platform:* > 1. Downloaded jbdevstudio-product-eap-universal-7.1.1.GA-v20140314-2145-B688.jar > 2. Ran java -jar jbdevstudio-product-eap-universal-7.1.1.GA-v20140314-2145-B688.jar stuck to the defaults and clicked thru > 3. Install failed with an error re certificates not being trusted > 4. Log message in ~/jbdevstudio/studio/p2/director/configuration/1396752621141.log as follows: > !ENTRY org.eclipse.equinox.p2.engine 8 0 2014-04-06 08:21:42.061 > !MESSAGE One or more certificates rejected. Cannot proceed with installation. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-17877) Classe with unbounded type parameter triggers "TypeParameter cannot be cast to IType" exceptions

by Denis Golovin (JIRA)

[ https://issues.jboss.org/browse/JBIDE-17877?page=com.atlassian.jira.plugi... ] Denis Golovin commented on JBIDE-17877: --------------------------------------- There should be no exceptions, but should methods with generics be processed in some way and present in Projects View JAX-RS node. If no processing required, you can just close the issue as Won't fix. Assigning back to Xavier. > Classe with unbounded type parameter triggers "TypeParameter cannot be cast to IType" exceptions > ------------------------------------------------------------------------------------------------ > > Key: JBIDE-17877 > URL: https://issues.jboss.org/browse/JBIDE-17877 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: webservices > Affects Versions: 4.2.0.Beta3 > Reporter: Denis Golovin > Assignee: Denis Golovin > Fix For: 4.2.0.CR1 > > > Exception below was fixed by checking instance of target obect before casting to IType see JBIDE-17716 and skipping the rest of the code. > Do we need to do something extra in this case? > {code} > org.jboss.tools.common > Error > Mon Jun 30 12:28:44 CEST 2014 > org.eclipse.jdt.internal.core.TypeParameter cannot be cast to org.eclipse.jdt.core.IType > org.jboss.tools.common.validation.JBTValidationException: org.eclipse.jdt.internal.core.TypeParameter cannot be cast to org.eclipse.jdt.core.IType > at org.jboss.tools.common.validation.AsYouTypeValidatorManager.validate(AsYouTypeValidatorManager.java:187) > at org.jboss.tools.common.validation.AsYouTypeValidatorManager.validateString(AsYouTypeValidatorManager.java:205) > at org.jboss.tools.common.validation.AsYouTypeValidatorManager.validateString(AsYouTypeValidatorManager.java:200) > at org.jboss.tools.common.validation.java.JavaDirtyRegionProcessor.endProcessing(JavaDirtyRegionProcessor.java:498) > at org.eclipse.wst.sse.ui.internal.reconcile.DirtyRegionProcessor$BackgroundThread.run(DirtyRegionProcessor.java:697) > Caused by: java.lang.ClassCastException: org.eclipse.jdt.internal.core.TypeParameter cannot be cast to org.eclipse.jdt.core.IType > at org.jboss.tools.ws.jaxrs.core.jdt.SourceType.from(SourceType.java:79) > at org.jboss.tools.ws.jaxrs.core.jdt.JdtUtils.getReturnType(JdtUtils.java:1143) > at org.jboss.tools.ws.jaxrs.core.jdt.JdtUtils.resolveMethodSignature(JdtUtils.java:1067) > at org.jboss.tools.ws.jaxrs.core.jdt.JdtUtils.resolveMethodSignatures(JdtUtils.java:1037) > at org.jboss.tools.ws.jaxrs.core.jdt.CompilationUnitsRepository.recordAST(CompilationUnitsRepository.java:112) > at org.jboss.tools.ws.jaxrs.core.jdt.CompilationUnitsRepository.getAST(CompilationUnitsRepository.java:76) > at org.jboss.tools.ws.jaxrs.ui.internal.validation.JaxrsMetamodelValidator.validate(JaxrsMetamodelValidator.java:413) > at org.jboss.tools.common.validation.AsYouTypeValidatorManager.validate(AsYouTypeValidatorManager.java:183) > ... 4 more > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-17877) Classe with unbounded type parameter triggers "TypeParameter cannot be cast to IType" exceptions

by Denis Golovin (JIRA)

[ https://issues.jboss.org/browse/JBIDE-17877?page=com.atlassian.jira.plugi... ] Denis Golovin updated JBIDE-17877: ---------------------------------- Assignee: Xavier Coulon (was: Denis Golovin) > Classe with unbounded type parameter triggers "TypeParameter cannot be cast to IType" exceptions > ------------------------------------------------------------------------------------------------ > > Key: JBIDE-17877 > URL: https://issues.jboss.org/browse/JBIDE-17877 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: webservices > Affects Versions: 4.2.0.Beta3 > Reporter: Denis Golovin > Assignee: Xavier Coulon > Fix For: 4.2.0.CR1 > > > Exception below was fixed by checking instance of target obect before casting to IType see JBIDE-17716 and skipping the rest of the code. > Do we need to do something extra in this case? > {code} > org.jboss.tools.common > Error > Mon Jun 30 12:28:44 CEST 2014 > org.eclipse.jdt.internal.core.TypeParameter cannot be cast to org.eclipse.jdt.core.IType > org.jboss.tools.common.validation.JBTValidationException: org.eclipse.jdt.internal.core.TypeParameter cannot be cast to org.eclipse.jdt.core.IType > at org.jboss.tools.common.validation.AsYouTypeValidatorManager.validate(AsYouTypeValidatorManager.java:187) > at org.jboss.tools.common.validation.AsYouTypeValidatorManager.validateString(AsYouTypeValidatorManager.java:205) > at org.jboss.tools.common.validation.AsYouTypeValidatorManager.validateString(AsYouTypeValidatorManager.java:200) > at org.jboss.tools.common.validation.java.JavaDirtyRegionProcessor.endProcessing(JavaDirtyRegionProcessor.java:498) > at org.eclipse.wst.sse.ui.internal.reconcile.DirtyRegionProcessor$BackgroundThread.run(DirtyRegionProcessor.java:697) > Caused by: java.lang.ClassCastException: org.eclipse.jdt.internal.core.TypeParameter cannot be cast to org.eclipse.jdt.core.IType > at org.jboss.tools.ws.jaxrs.core.jdt.SourceType.from(SourceType.java:79) > at org.jboss.tools.ws.jaxrs.core.jdt.JdtUtils.getReturnType(JdtUtils.java:1143) > at org.jboss.tools.ws.jaxrs.core.jdt.JdtUtils.resolveMethodSignature(JdtUtils.java:1067) > at org.jboss.tools.ws.jaxrs.core.jdt.JdtUtils.resolveMethodSignatures(JdtUtils.java:1037) > at org.jboss.tools.ws.jaxrs.core.jdt.CompilationUnitsRepository.recordAST(CompilationUnitsRepository.java:112) > at org.jboss.tools.ws.jaxrs.core.jdt.CompilationUnitsRepository.getAST(CompilationUnitsRepository.java:76) > at org.jboss.tools.ws.jaxrs.ui.internal.validation.JaxrsMetamodelValidator.validate(JaxrsMetamodelValidator.java:413) > at org.jboss.tools.common.validation.AsYouTypeValidatorManager.validate(AsYouTypeValidatorManager.java:183) > ... 4 more > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-17838) Make discovery-site a Maven module

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBIDE-17838?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-17838: --------------------------------------------- not blocking/related for CR1. > Make discovery-site a Maven module > ---------------------------------- > > Key: JBIDE-17838 > URL: https://issues.jboss.org/browse/JBIDE-17838 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build, discovery > Affects Versions: 4.2.0.Beta3 > Reporter: Mickael Istria > Assignee: Nick Boldt > Priority: Minor > Fix For: 4.2.x > > > Currently, the discovery-site is generated under on of the discovery plugin. Since it's a real artifact that we copy, deploy and that depends on several modules, it would probably be easier to maintain the discovery project if we create a dedicated module for the discovery site. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-17838) Make discovery-site a Maven module

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBIDE-17838?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen updated JBIDE-17838: ---------------------------------------- Fix Version/s: 4.2.x (was: 4.2.0.CR1) > Make discovery-site a Maven module > ---------------------------------- > > Key: JBIDE-17838 > URL: https://issues.jboss.org/browse/JBIDE-17838 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build, discovery > Affects Versions: 4.2.0.Beta3 > Reporter: Mickael Istria > Assignee: Nick Boldt > Priority: Minor > Fix For: 4.2.x > > > Currently, the discovery-site is generated under on of the discovery plugin. Since it's a real artifact that we copy, deploy and that depends on several modules, it would probably be easier to maintain the discovery project if we create a dedicated module for the discovery site. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-issues August 2014