February 2015 - jbosstools-issues

[JBoss JIRA] (JBTIS-392) Generate jbdsis target platform without community bits

by Paul Leacu (JIRA)

[ https://issues.jboss.org/browse/JBTIS-392?page=com.atlassian.jira.plugin.... ] Paul Leacu closed JBTIS-392. ---------------------------- Resolution: Duplicate Issue dupl JBTIS-388 > Generate jbdsis target platform without community bits > ------------------------------------------------------ > > Key: JBTIS-392 > URL: https://issues.jboss.org/browse/JBTIS-392 > Project: JBoss Tools Integration Stack > Issue Type: Bug > Components: target-platform > Affects Versions: 4.2.1.CR1-TP > Reporter: Paul Leacu > Assignee: Paul Leacu > > Currently the JBDSIS production target platform repo is a copy of the JBTIS target platform repo. This introduces community bits where they don't belong. e.g. > <unit id="org.jboss.tools.community.central.feature.feature.group" version="1.3.0.Final-v20141016-1914-B105"/> > <unit id="org.jboss.tools.community.project.examples.feature.feature.group" version="2.0.0.Final-v20141016-1914-B105"/> > *Reason:* ... > *Project page/sources:* ... > *Version:* .... > *License and owner:* ... > *Original p2 repo:* http://third-party-vendor.com/path/to/updates-site/ > *JBoss mirror:* http://downloads.jboss.org/jbosstools/updates/requirements/<projectName> > *Include Sources:* Yes|No > *Affected projects:* > *Include in JBDS:* Yes|No > *Type of dependency:* testing|central-only|distribution > *List of bundles added/removed:* > {code} > suggested diff on the .target files > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTIS-388) Establish a separate JBDSIS target platform with no community-specific bits.

by Paul Leacu (JIRA)

[ https://issues.jboss.org/browse/JBTIS-388?page=com.atlassian.jira.plugin.... ] Paul Leacu updated JBTIS-388: ----------------------------- Description: Currently the JBDSIS target platform is a straight copy of the JBTIS TP. The JBTIS TP includes community.target which has dependent features which should not be picked up in the JBDSIS production target platform repository. e.g. <unit id="org.jboss.tools.community.central.feature.feature.group" version="1.3.0.Final-v20141016-1914-B105"/> <unit id="org.jboss.tools.community.project.examples.feature.feature.group" version="2.0.0.Final-v20141016-1914-B105"/> Solution is to have the target-platform pom create the jbdsis target platform (without merging the community.target file). Reason: ... Project page/sources: ... Version: .... License and owner: ... Original p2 repo: http://third-party-vendor.com/path/to/updates-site/ JBoss mirror: http://downloads.jboss.org/jbosstools/updates/requirements/<projectName> Include Sources: Yes|No Affected projects: Include in JBDS: Yes|No Type of dependency: testing|central-only|distribution List of bundles added/removed: was: Currently the JBDSIS target platform is a straight copy of the JBTIS TP. The JBTIS TP includes community.target which has dependent features which should not be picked up in the JBDSIS production target platform repository. Solution is to have the target-platform pom create the jbdsis target platform (without merging the community.target file). > Establish a separate JBDSIS target platform with no community-specific bits. > ---------------------------------------------------------------------------- > > Key: JBTIS-388 > URL: https://issues.jboss.org/browse/JBTIS-388 > Project: JBoss Tools Integration Stack > Issue Type: Feature Request > Components: target-platform > Affects Versions: 4.2.1.Final-TP > Reporter: Paul Leacu > Assignee: Paul Leacu > > Currently the JBDSIS target platform is a straight copy of the JBTIS TP. The JBTIS TP includes community.target which has dependent features which should not be picked up in the JBDSIS production target platform repository. > e.g. > <unit id="org.jboss.tools.community.central.feature.feature.group" version="1.3.0.Final-v20141016-1914-B105"/> > <unit id="org.jboss.tools.community.project.examples.feature.feature.group" version="2.0.0.Final-v20141016-1914-B105"/> > Solution is to have the target-platform pom create the jbdsis target platform (without merging the community.target file). > Reason: ... > Project page/sources: ... > Version: .... > License and owner: ... > Original p2 repo: http://third-party-vendor.com/path/to/updates-site/ > JBoss mirror: http://downloads.jboss.org/jbosstools/updates/requirements/<projectName> > Include Sources: Yes|No > Affected projects: > Include in JBDS: Yes|No > Type of dependency: testing|central-only|distribution > List of bundles added/removed: -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTIS-387) Incorporate new version for 4.2.0.CR2/ 8.0.0.CR2

by Paul Leacu (JIRA)

[ https://issues.jboss.org/browse/JBTIS-387?page=com.atlassian.jira.plugin.... ] Paul Leacu closed JBTIS-387. ---------------------------- Resolution: Rejected No need - the new teiid designer kept the same version number. > Incorporate new version for 4.2.0.CR2/ 8.0.0.CR2 > ------------------------------------------------ > > Key: JBTIS-387 > URL: https://issues.jboss.org/browse/JBTIS-387 > Project: JBoss Tools Integration Stack > Issue Type: Task > Components: distribution > Affects Versions: 4.2.0.CR2, 8.0.0.CR2 > Reporter: Paul Leacu > Assignee: Paul Leacu > > new teiid designer -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 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 resolved JBIDE-18862. --------------------------------- Resolution: Done Everything [~dlmiles] says is relevant and I've opened https://issues.jboss.org/browse/JBIDE-19182 to track that issue. I believe this issue specifically (marker files when deleting a module) has been solved. [~mmalina] also had a niche case that I feel doesn't apply to this jira directly and would be better tracked in the new one. Pushed to maintenance. > 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: Bug > Components: server > Environment: Windiws7 64bit, JDK 8u25 > Reporter: Darryl Miles > Assignee: Rob Stryker > Fix For: 4.2.3.Beta1, 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, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19182) Incremental Publish after Full Publish WRT dodeploy markers

by Rob Stryker (JIRA)

Rob Stryker created JBIDE-19182: ----------------------------------- Summary: Incremental Publish after Full Publish WRT dodeploy markers Key: JBIDE-19182 URL: https://issues.jboss.org/browse/JBIDE-19182 Project: Tools (JBoss Tools) Issue Type: Bug Components: server Affects Versions: 4.2.0.Final Reporter: Rob Stryker THis issue is opened in regards to comments by [~dlmiles] on https://issues.jboss.org/browse/JBIDE-18862 I am saying you should block all 'deployment directory' file modifications when you know the AS is busy using the 'deployment directory' to "deploy" (a.k.a. starting) or "undeploy" (a.k.a. stopping) of a module (or the AS itself is starting/stopping in certain scenarios). Ideally you use a file watcher API when available so there is no busy/wait loop adding additional milliseconds of delays because the wait part is never instant. But in an example scenario where you perform a Full Publish then 2 additional Incremental Publish ops immediately after, there is no reason to block the incrementals if you know the AS has not picked up the original Full Publish yet. You can effectively merge those two incrementals into the full publish operation behind the back of the AS. But you are presented with a race scenario, you have already laid down the *.dodeploy at the end of the original Full Publish. So Eclipse needs to effectively notice that scenario exists, revoke and remember that instruction to the AS in an atomic way (what I mean by this is Eclipse knows for sure if it cancelled it in time, or if it was too late and the AS got to the full publish first and started deploying). You need to do this so Eclipse can make file change modifications to the 'deployment directory' again. Once Eclipse has completed the file change operations, if takes that remembered state and puts back the *.dodeploy file (even though this is an Incremental Publish operation). You can think of this like a "save state" and "restore state" pattern if that helps. Or you can think of this like the Eclipse target goal state for the AS (such as "AS:started" and "module.abc:started") is compared to the actual AS state (such as "AS: started" and "module.abc:stopped"), and Eclipse then brings them into alignment to do this it realizes it needs to lay down the *.dodeploy marker file (even though this is an incremental publish). I think with the current marker file arrangements there maybe a tiny window of time where Eclipse IDE will get things wrong in respect of the AS ? But maybe ensuring both Eclipse IDE and the AS check the return value of the file delete for *.dodeploy whomever was successful in deleting the file wins, whichever party got the error "No Such File" loses and performs a rollback/cleanup of the situation to ensure it tries again soon. So you can speak for the JBIDE side but can someone check the AS side ? File#delete(new File("foobar.dodeploy")) != true. The AS has to delete the command instruction file before it starts to process that command, but after it has laid down a state change file (*.isdeploying). One of the goals of the marker files is that at no point in time is there a snapshot of the files that exist in the directory; that would leave an observer to interpret the wrong state. For example deleting one marker file before laying down the next would be bad, because there is a snapshot of time when no state marker file exists in the directory, leaving the observer to interpret that nothing is happening with that module. The alternative is to lay both the new file first then delete the old one, now there is a window of time when 2 marker files indicate state for 1 module, this is good and valid since the observer can clearly see the correct state. So if you got here and are still with me, then you can see how things should only slow down, when they need to slow down. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTIS-386) Target Platform is missing some source plugins when generating with sources

by Paul Leacu (JIRA)

[ https://issues.jboss.org/browse/JBTIS-386?page=com.atlassian.jira.plugin.... ] Paul Leacu commented on JBTIS-386: ---------------------------------- Forgot the main pom: https://github.com/fusesource/fuseide/commit/03dad9027c881c7ad98ebf71e131... > Target Platform is missing some source plugins when generating with sources > --------------------------------------------------------------------------- > > Key: JBTIS-386 > URL: https://issues.jboss.org/browse/JBTIS-386 > Project: JBoss Tools Integration Stack > Issue Type: Bug > Components: target-platform > Affects Versions: 4.2.0.Final-TP > Reporter: Lars Heinemann > Assignee: Paul Leacu > Priority: Critical > > when mirroring the TP locally with sources some of the source plugins are missing. for instance org.eclipse.wst.server.ui.source. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 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 resolved JBIDE-18861. --------------------------------- Resolution: Done I've merged the PR to maintenance since I feel it works as close to expected as possible. > 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 > Assignee: Rob Stryker > Priority: Minor > Fix For: 4.2.3.Beta1, 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, 2 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: ------------------------------------- > Shouldn't it say [Stopped, Synchronized]? If this a bug it'd be better off in a new jira so that we don't lose it for master. > 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 > Assignee: Rob Stryker > Priority: Minor > Fix For: 4.2.3.Beta1, 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, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-12352) Remote management connection to servers cannot be established with IPv6

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-12352?page=com.atlassian.jira.plugi... ] Rob Stryker resolved JBIDE-12352. --------------------------------- Assignee: Rob Stryker Fix Version/s: 4.2.3.Beta1 (was: 4.2.x) Resolution: Done I'm not able to replicate this at this time. "Remote management connections" being a remote connection to the local machine (ie RSE). [~mmalina] please test for both master and maintenance. > Remote management connection to servers cannot be established with IPv6 > ----------------------------------------------------------------------- > > Key: JBIDE-12352 > URL: https://issues.jboss.org/browse/JBIDE-12352 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: server > Affects Versions: 3.3.1.Final > Environment: JBDS 5.0.1 > Fedora 17 32bit > OpenJDK 1.6 > Reporter: Martin Malina > Assignee: Rob Stryker > Priority: Critical > Fix For: 4.2.3.Beta1, 4.3.0.Alpha1 > > > After creating JBIDE-12351 for JMX connection, I found out that the connection cannot be established at all - even when you don't try to connect via JMX. > When you set up a remote as7/eap6 server accessible over IPv6 and start the server, the remote connection will fail with this error: > {code} > Jul 20, 2012 3:14:57 PM org.xnio.Xnio <clinit> > INFO: XNIO Version 3.0.3.GA > Jul 20, 2012 3:14:57 PM org.xnio.nio.NioXnio <clinit> > INFO: XNIO NIO Implementation Version 3.0.3.GA > Jul 20, 2012 3:14:57 PM org.jboss.remoting3.EndpointImpl <clinit> > INFO: JBoss Remoting version 3.2.7.GA > Jul 20, 2012 3:15:46 PM org.jboss.remoting3.remote.RemoteConnection handleException > ERROR: JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed > Jul 20, 2012 3:15:46 PM org.jboss.remoting3.remote.RemoteConnection handleException > ERROR: JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed > Jul 20, 2012 3:15:51 PM org.xnio.Xnio <clinit> > INFO: XNIO Version 3.0.4.GA-redhat-1 > Jul 20, 2012 3:15:51 PM org.xnio.nio.NioXnio <clinit> > INFO: XNIO NIO Implementation Version 3.0.4.GA-redhat-1 > Jul 20, 2012 3:15:51 PM org.jboss.remoting3.EndpointImpl <clinit> > INFO: JBoss Remoting version 3.2.8.GA-redhat-1 > Jul 20, 2012 3:15:52 PM org.jboss.remoting3.remote.RemoteConnection handleException > ERROR: JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTIS-386) Target Platform is missing some source plugins when generating with sources

by Paul Leacu (JIRA)

[ https://issues.jboss.org/browse/JBTIS-386?page=com.atlassian.jira.plugin.... ] Paul Leacu commented on JBTIS-386: ---------------------------------- Hey [~lhein] - please try rebuilding now. I won't have Mickael's change in until next week (other stuff changing too) - I just updated the fuseide TP JBTIS TP reference - builds okay for me: https://github.com/fusesource/fuseide/commit/e04d729775270abc2e39cd05e650... Please let me know if you're building okay. > Target Platform is missing some source plugins when generating with sources > --------------------------------------------------------------------------- > > Key: JBTIS-386 > URL: https://issues.jboss.org/browse/JBTIS-386 > Project: JBoss Tools Integration Stack > Issue Type: Bug > Components: target-platform > Affects Versions: 4.2.0.Final-TP > Reporter: Lars Heinemann > Assignee: Paul Leacu > Priority: Critical > > when mirroring the TP locally with sources some of the source plugins are missing. for instance org.eclipse.wst.server.ui.source. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 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 February 2015