December 2014 - jbosstools-issues

[JBoss JIRA] (JBIDE-18954) JAX-RS Web Services in Project Explorer does not show properly inherited metadata

by Marián Labuda (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18954?page=com.atlassian.jira.plugi... ] Marián Labuda updated JBIDE-18954: ---------------------------------- Description: I have an interface with annotated JAX-RS methods (HTTP method type, path, consumes...) CarResourceInterface and implementation of this interface CarResourceImpl. Inheriting all metadata related to one method should affect processing of this JAX-RS web services - new values from Impl should be used and probably it would be good to show it also in JAX-RS Web Services node in Project Explorer view. Currently there are shown only interface JAX-RS web services and any change in Impl is ignored in this view. was:I have an interface with annotated JAX-RS methods (HTTP method type, path, consumes...) CarResourceInterface and implementation of this interface CarResourceImpl. Inheriting all metadata related to one method should affect processing of this JAX-RS web services - new values from Impl should be used and probably it would be good to show it also in JAX-RS Web Services node in Project Explorer view. Currently there are shown only interface JAX-RS web services and any change in Impl is ignored in this view. > JAX-RS Web Services in Project Explorer does not show properly inherited metadata > --------------------------------------------------------------------------------- > > Key: JBIDE-18954 > URL: https://issues.jboss.org/browse/JBIDE-18954 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: webservices > Affects Versions: 4.2.1.Final > Reporter: Marián Labuda > Assignee: Xavier Coulon > Labels: jax-rs > Fix For: 4.3.x > > > I have an interface with annotated JAX-RS methods (HTTP method type, path, consumes...) CarResourceInterface and implementation of this interface CarResourceImpl. Inheriting all metadata related to one method should affect processing of this JAX-RS web services - new values from Impl should be used and probably it would be good to show it also in JAX-RS Web Services node in Project Explorer view. Currently there are shown only interface JAX-RS web services and any change in Impl is ignored in this view. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15250) Explode utility jars in EAR/WAR deployments

by Christian Beikov (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15250?page=com.atlassian.jira.plugi... ] Christian Beikov commented on JBIDE-15250: ------------------------------------------ I think what he is asking for is for the Server Adapter to deploy projects that are be deployed to EAR/lib, not in the zipped form, but exploded like it is done with modules of the EAR(like web and ejb modules). As soon as a jar file changes, the whole EAR will get redeployed which is a waste of time. I can provide you a maven example project that will reproduce that if you seek to fix this. > Explode utility jars in EAR/WAR deployments > ------------------------------------------- > > Key: JBIDE-15250 > URL: https://issues.jboss.org/browse/JBIDE-15250 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: server > Affects Versions: 4.0.1.Final > Reporter: Kevin Formsma > Assignee: Rob Stryker > Fix For: 4.2.x > > > For larger projects that utilize utility jars within the EAR, it would be nice to have these deployed exploded as well. This would allow hot code replacement for those utility projects. > A current work around is to make the utility projects modules so that the tooling treats them as a EJB module and deploys them exploded. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3291) Support for auto generating jboss-deployment-structure based on JBoss Modules selected in a project

by Mustafa Musaji (JIRA)

[ https://issues.jboss.org/browse/JBDS-3291?page=com.atlassian.jira.plugin.... ] Mustafa Musaji edited comment on JBDS-3291 at 12/16/14 5:17 AM: ---------------------------------------------------------------- Hi Max Okay so not as simple as I first thought. This is going to need some thought and I think this should be more of a helper dialogue perhaps as opposed to a wizard or automated thing. Because we have to consider the following: * Not all modules are 1:1 with artifacts, as some modules include multiple maven artifacts (CXF for example) * Some modules do not contain any artifacts, and simply re-export package paths of others * Some modules have well-known names but varying implementations, e.g. javax.servlet.api where we could change the maven artifact * APIs such as javax.servlet.api do not have an official maven name * Not all modules export all classes in the jars they contain Perhaps [~fbricon] can add his thoughts as I know he's done a lot of the maven work on JBoss Tools? Do you think this is something that's possible that will add value? I think it will and many of our users creating projects on JBDS would find it useful. We may have to put a RFE for EAP to add some additional metadata for the modules somewhere for us to use? Mus was (Author: mmusaji): Hi Max Okay so not as simple as I first thought. This is going to need some thought and I think this should be more of a helper dialogue perhaps as opposed to a wizard or automated thing. Because we have to consider the following: * Not all modules are 1:1 with artifacts, as some modules include multiple maven artifacts (CXF for example) * Some modules do not contain any artifacts, and simply re-export package paths of others * Some modules have well-known names but varying implementations, e.g. javax.servlet.api where we could change the maven artifact * APIs such as javax.servlet.api do not have an official maven name * Not all modules export all classes in the jars they contain Perhaps [~fbricon] can add his thoughts as I know he's done a lot of the maven work on JBoss Tools? Do you think this is something that's possible that will add value? Mus > Support for auto generating jboss-deployment-structure based on JBoss Modules selected in a project > --------------------------------------------------------------------------------------------------- > > Key: JBDS-3291 > URL: https://issues.jboss.org/browse/JBDS-3291 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Feature Request > Components: integration, server > Affects Versions: 8.0.0.GA > Reporter: Mustafa Musaji > Assignee: Max Rydahl Andersen > > If you have a POM for a project that defines the following > {code} > <project> > ... > <dependencyManagement> > <dependencies> > <dependency> > <groupId>org.jboss.bom</groupId> > <artifactId>eap6-supported-artifacts</artifactId> > <version>6.3.1.GA</version> > <scope>import</scope> > <type>pom</type> > </dependency> > </dependencies> > </dependencyManagement> > ... > <dependencies> > <dependency> > <groupId>commons-beanutils</groupId> > <artifactId>commons-beanutils</artifactId> > <scope>provided</scope> > </dependency> > </dependencies> > </project> > {code} > The tooling should create a jboss-deployment-structure.xml that contains the "org.apache.commons.beanutils" dependency automatically. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18269) JMX label providers and extension points need some way to be disposed

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18269?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-18269: ------------------------------------- For QE: Not much to test here. Just make sure when testing JMX view you don't see any errors that you haven't seen before ;) I tested locally but saw no such errors. > JMX label providers and extension points need some way to be disposed > --------------------------------------------------------------------- > > Key: JBIDE-18269 > URL: https://issues.jboss.org/browse/JBIDE-18269 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: jmx, server > Reporter: Rob Stryker > Assignee: Rob Stryker > Fix For: 4.3.0.Alpha1 > > > The various APIs handling JMX images do not follow the proper disposing of label providers. This should at the very least be investigated. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18269) JMX label providers and extension points need some way to be disposed

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18269?page=com.atlassian.jira.plugi... ] Rob Stryker resolved JBIDE-18269. --------------------------------- Assignee: Rob Stryker Resolution: Done pushed to master. API was mostly there, just needed a dispose method. > JMX label providers and extension points need some way to be disposed > --------------------------------------------------------------------- > > Key: JBIDE-18269 > URL: https://issues.jboss.org/browse/JBIDE-18269 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: jmx, server > Reporter: Rob Stryker > Assignee: Rob Stryker > Fix For: 4.3.0.Alpha1 > > > The various APIs handling JMX images do not follow the proper disposing of label providers. This should at the very least be investigated. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3291) Support for auto generating jboss-deployment-structure based on JBoss Modules selected in a project

by Mustafa Musaji (JIRA)

[ https://issues.jboss.org/browse/JBDS-3291?page=com.atlassian.jira.plugin.... ] Mustafa Musaji commented on JBDS-3291: -------------------------------------- Hi Max Okay so not as simple as I first thought. This is going to need some thought and I think this should be more of a helper dialogue perhaps as opposed to a wizard or automated thing. Because we have to consider the following: * Not all modules are 1:1 with artifacts, as some modules include multiple maven artifacts (CXF for example) * Some modules do not contain any artifacts, and simply re-export package paths of others * Some modules have well-known names but varying implementations, e.g. javax.servlet.api where we could change the maven artifact * APIs such as javax.servlet.api do not have an official maven name * Not all modules export all classes in the jars they contain Perhaps [~fbricon] can add his thoughts as I know he's done a lot of the maven work on JBoss Tools? Do you think this is something that's possible that will add value? Mus > Support for auto generating jboss-deployment-structure based on JBoss Modules selected in a project > --------------------------------------------------------------------------------------------------- > > Key: JBDS-3291 > URL: https://issues.jboss.org/browse/JBDS-3291 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Feature Request > Components: integration, server > Affects Versions: 8.0.0.GA > Reporter: Mustafa Musaji > Assignee: Max Rydahl Andersen > > If you have a POM for a project that defines the following > {code} > <project> > ... > <dependencyManagement> > <dependencies> > <dependency> > <groupId>org.jboss.bom</groupId> > <artifactId>eap6-supported-artifacts</artifactId> > <version>6.3.1.GA</version> > <scope>import</scope> > <type>pom</type> > </dependency> > </dependencies> > </dependencyManagement> > ... > <dependencies> > <dependency> > <groupId>commons-beanutils</groupId> > <artifactId>commons-beanutils</artifactId> > <scope>provided</scope> > </dependency> > </dependencies> > </project> > {code} > The tooling should create a jboss-deployment-structure.xml that contains the "org.apache.commons.beanutils" dependency automatically. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3256) JBoss specific Docker Tooling (Basic Integration)

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBDS-3256?page=com.atlassian.jira.plugin.... ] Andre Dietisheim updated JBDS-3256: ----------------------------------- Component/s: openshift > JBoss specific Docker Tooling (Basic Integration) > ------------------------------------------------- > > Key: JBDS-3256 > URL: https://issues.jboss.org/browse/JBDS-3256 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Feature Request > Components: openshift > Reporter: Burr Sutter > Assignee: Andre Dietisheim > > Goal: to allow the Eclipse user to easily discover, pull, run, deploy my .war or .ear to it, stop, commit, push for docker images/containers. > Expected end-user flow 1: > 0) Installation - assumes boot2docker pre-installed on the end-user's machine > 1) I, the Java developer, need to browse a docker registry (either DockerHub or private registry), identify the image that I wish to have local and download (docker pull) for that image+tag. > 2) Assumption: the docker image includes not only the operating system + JVM but also the EAP, Wildfly or Tomcat installed in a 'known' location. > 3) I start (docker run) the image which auto-starts the embedded app server > 4) I can then deploy my .war or .ear to the running app server > 5) I can restart the running app server in debug mode and run the debugger > 6) I can undeploy and redeploy my .war or .ear > 7) I can stop/restart the running, embedded app server > 8) I can then commit (docker commit) > 9) then I can publish my changes (docker push) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18921) release webtools site for Eclipse 4.3 Mars to so WTP 3.7 discovery upstream can find it

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18921?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-18921: ------------------------------------- [~nickboldt] PR says it's merged. Is this jira still relevant? > release webtools site for Eclipse 4.3 Mars to so WTP 3.7 discovery upstream can find it > --------------------------------------------------------------------------------------- > > Key: JBIDE-18921 > URL: https://issues.jboss.org/browse/JBIDE-18921 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: server, updatesite, upstream > Affects Versions: 4.3.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.3.0.Alpha1 > > > Need a semi-working placeholder (even if it's a weak first alpha or copy of JBT 4.2.0's site) so that WTP can resolve a valid site for server adapters. > Content that needs to be copied is here: > http://download.jboss.org/jbosstools/static/updates/JBossTools-4.2.0.Fina... (or something newer?) > Destination folder (new folder hierarchy as of JBDS-3208 reorg): > http://download.jboss.org/jbosstools/mars/stable/updates/webtools/ > Upstream issue: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=454810 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18862) when removing a module from AS runtime marker files are not removed automatically

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18862?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-18862: ------------------------------------- pushed to master. PR for maintenance is https://github.com/jbosstools/jbosstools-server/pull/316 > when removing a module from AS runtime marker files are not removed automatically > --------------------------------------------------------------------------------- > > Key: JBIDE-18862 > URL: https://issues.jboss.org/browse/JBIDE-18862 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: server > Environment: Windiws7 64bit, JDK 8u25 > Reporter: Darryl Miles > Priority: Minor > Fix For: 4.2.2.Final, 4.3.0.Alpha1 > > > module removal does not delete the various marker files relating to it: > *.undeployed > *.dodeploy > The same should be true when ADDING a module, it should clean out any marker files. > Setup an deploy-inhibiting marker file to ensure it won't try to deploy it before the *.ear is full written. > Write out the*.ear file. > Then adjust the marker files as necessary to reflect the intended state of the module (if it should be started then remove the inhibiting marker file in the previous step). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18861) module start action does not delete *.undeployed file

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18861?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-18861: ------------------------------------- pushed to master. PR for maintenance is https://github.com/jbosstools/jbosstools-server/pull/316 > module start action does not delete *.undeployed file > ----------------------------------------------------- > > Key: JBIDE-18861 > URL: https://issues.jboss.org/browse/JBIDE-18861 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: server > Environment: Windows7 64bit, JDK 8u25 > Reporter: Darryl Miles > Priority: Minor > Fix For: 4.2.2.Final, 4.3.0.Alpha1 > > > If you start Wildfly with all modules enabled and started. > Now use STOP action on an EAR module. > Now stop Wildfly. > Now start Wildfly (debug or run). > It will start up without the EAR module running, this is correct behavior at this point. > Now use START on EAR module. It fails to start at all. > This is because the file *.undeployed still exists. If you manually remove the file (using system file manager) the module will start up. > If you perform a "full publish" on the module that appears to cause it to start up as well. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 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 December 2014