[JBoss JIRA] (JBTIS-675) can't install JBoss SOA 5.x Development connector from JBDS 9.1.0.GA central
by Paul Leacu (JIRA)
[ https://issues.jboss.org/browse/JBTIS-675?page=com.atlassian.jira.plugin.... ]
Paul Leacu commented on JBTIS-675:
----------------------------------
looking now
> can't install JBoss SOA 5.x Development connector from JBDS 9.1.0.GA central
> ----------------------------------------------------------------------------
>
> Key: JBTIS-675
> URL: https://issues.jboss.org/browse/JBTIS-675
> Project: JBoss Tools Integration Stack
> Issue Type: Bug
> Components: distribution
> Affects Versions: 4.3.0.CR1
> Reporter: Nick Boldt
> Assignee: Paul Leacu
> Fix For: 4.3.0.Final
>
>
> Tried to install everything in Central from JBDS 9.1.0.GA, after enabling Early Access.
> {code}
> !MESSAGE The following connectors are not available: JBoss SOA 5.x Development
> (id=org.eclipse.bpel.apache.ode.runtime.feature.feature.group,
> org.jboss.tools.esb.feature.feature.group,
> org.jboss.tools.runtime.esb.detector.feature.feature.group,
> org.jboss.tools.jbpm.common.feature.feature.group,
> org.jboss.tools.jbpm.convert.feature.feature.group,
> org.jboss.tools.jbpm3.feature.feature.group,
> org.jbpm.gd.jpdl.feature.feature.group,
> site=https://devstudio.redhat.com/9.0/stable/updates/)
> {code}
> Is it possible I have an old version of earlyaccess properties ?
> https://devstudio.redhat.com/9.0/stable/updates/discovery.earlyaccess/9.1...
> I can see the features here:
> https://devstudio.redhat.com/9.0/stable/updates/integration-stack/earlyac...
> * org.jboss.tools.runtime.esb.detector.feature.feature.group 1.5.530.Final-v20150310-1957-B70
> * org.eclipse.bpel.apache.ode.runtime.feature.feature.group 1.0.5.Final (two copies)
> * org.jboss.tools.runtime.esb.detector.feature.feature.group 1.5.530.Final-v20150310-1957-B70
> * ...
> Or... why is Central looking at
> {code}jboss.discovery.site.url|devstudio|9=https://devstudio.redhat.com/9.0/stable/updates/{code}
> instead of
> {code}jboss.discovery.earlyaccess.site.url|devstudio|9=https://devstudio.redhat.com/9.0/stable/updates/earlyaccess/{code}
> [~fbricon] any idea?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (JBTIS-675) can't install JBoss SOA 5.x Development connector from JBDS 9.1.0.GA central
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBTIS-675?page=com.atlassian.jira.plugin.... ]
Nick Boldt updated JBTIS-675:
-----------------------------
Description:
Tried to install everything in Central from JBDS 9.1.0.GA, after enabling Early Access.
{code}
!MESSAGE The following connectors are not available: JBoss SOA 5.x Development
(id=org.eclipse.bpel.apache.ode.runtime.feature.feature.group,
org.jboss.tools.esb.feature.feature.group,
org.jboss.tools.runtime.esb.detector.feature.feature.group,
org.jboss.tools.jbpm.common.feature.feature.group,
org.jboss.tools.jbpm.convert.feature.feature.group,
org.jboss.tools.jbpm3.feature.feature.group,
org.jbpm.gd.jpdl.feature.feature.group,
site=https://devstudio.redhat.com/9.0/stable/updates/)
{code}
Is it possible I have an old version of earlyaccess properties ?
https://devstudio.redhat.com/9.0/stable/updates/discovery.earlyaccess/9.1...
I can see the features here:
https://devstudio.redhat.com/9.0/stable/updates/integration-stack/earlyac...
* org.jboss.tools.runtime.esb.detector.feature.feature.group 1.5.530.Final-v20150310-1957-B70
* org.eclipse.bpel.apache.ode.runtime.feature.feature.group 1.0.5.Final (two copies)
* org.jboss.tools.runtime.esb.detector.feature.feature.group 1.5.530.Final-v20150310-1957-B70
* ...
Or... why is Central looking at
{code}jboss.discovery.site.url|devstudio|9=https://devstudio.redhat.com/9.0/stable/updates/{code}
instead of
{code}jboss.discovery.earlyaccess.site.url|devstudio|9=https://devstudio.redhat.com/9.0/stable/updates/earlyaccess/{code}
[~fbricon] any idea?
was:
Tried to install everything in Central from JBDS 9.1.0.GA, after enabling Early Access.
{code}
!MESSAGE The following connectors are not available: JBoss SOA 5.x Development (id=org.eclipse.bpel.apache.ode.runtime.feature.feature.group, org.jboss.tools.esb.feature.feature.group, org.jboss.tools.runtime.esb.detector.feature.feature.group, org.jboss.tools.jbpm.common.feature.feature.group, org.jboss.tools.jbpm.convert.feature.feature.group, org.jboss.tools.jbpm3.feature.feature.group, org.jbpm.gd.jpdl.feature.feature.group, site=https://devstudio.redhat.com/9.0/stable/updates/)
{code}
Is it possible I have an old version of earlyaccess properties ?
https://devstudio.redhat.com/9.0/stable/updates/discovery.earlyaccess/9.1...
I can see the features here:
https://devstudio.redhat.com/9.0/stable/updates/integration-stack/earlyac...
* org.jboss.tools.runtime.esb.detector.feature.feature.group 1.5.530.Final-v20150310-1957-B70
* org.eclipse.bpel.apache.ode.runtime.feature.feature.group 1.0.5.Final (two copies)
* org.jboss.tools.runtime.esb.detector.feature.feature.group 1.5.530.Final-v20150310-1957-B70
* ...
> can't install JBoss SOA 5.x Development connector from JBDS 9.1.0.GA central
> ----------------------------------------------------------------------------
>
> Key: JBTIS-675
> URL: https://issues.jboss.org/browse/JBTIS-675
> Project: JBoss Tools Integration Stack
> Issue Type: Bug
> Components: distribution
> Affects Versions: 4.3.0.CR1
> Reporter: Nick Boldt
> Assignee: Paul Leacu
> Fix For: 4.3.0.Final
>
>
> Tried to install everything in Central from JBDS 9.1.0.GA, after enabling Early Access.
> {code}
> !MESSAGE The following connectors are not available: JBoss SOA 5.x Development
> (id=org.eclipse.bpel.apache.ode.runtime.feature.feature.group,
> org.jboss.tools.esb.feature.feature.group,
> org.jboss.tools.runtime.esb.detector.feature.feature.group,
> org.jboss.tools.jbpm.common.feature.feature.group,
> org.jboss.tools.jbpm.convert.feature.feature.group,
> org.jboss.tools.jbpm3.feature.feature.group,
> org.jbpm.gd.jpdl.feature.feature.group,
> site=https://devstudio.redhat.com/9.0/stable/updates/)
> {code}
> Is it possible I have an old version of earlyaccess properties ?
> https://devstudio.redhat.com/9.0/stable/updates/discovery.earlyaccess/9.1...
> I can see the features here:
> https://devstudio.redhat.com/9.0/stable/updates/integration-stack/earlyac...
> * org.jboss.tools.runtime.esb.detector.feature.feature.group 1.5.530.Final-v20150310-1957-B70
> * org.eclipse.bpel.apache.ode.runtime.feature.feature.group 1.0.5.Final (two copies)
> * org.jboss.tools.runtime.esb.detector.feature.feature.group 1.5.530.Final-v20150310-1957-B70
> * ...
> Or... why is Central looking at
> {code}jboss.discovery.site.url|devstudio|9=https://devstudio.redhat.com/9.0/stable/updates/{code}
> instead of
> {code}jboss.discovery.earlyaccess.site.url|devstudio|9=https://devstudio.redhat.com/9.0/stable/updates/earlyaccess/{code}
> [~fbricon] any idea?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (JBDS-3841) Installer Sets Path for Wrong User
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3841?page=com.atlassian.jira.plugin.... ]
Denis Golovin commented on JBDS-3841:
-------------------------------------
Vagrant and VirtualBox are MSI installers and they require administrative privileges to continue with installation.
Also in case of target installation folder is outside of %USERPROFILE% installer would require administrative account to be able to continue.
Finally elevated privileges comes form 7zip.sfx which is really executable that expects be part of self executable archive.
I think the possible solution here is to run as current user and then vagrant and virtualbox request for administrative privileges when we start them with msiexec. Installer should also validate if target location is inside current user profile. In case vagrant and virtualbox installed there would be no requests from UAC at all. That scenario would be called "Single user installation".
To support "install for everybody" we would need to fix several issues related to how installer changes the environment and skip JBDS Start in the end to avoid creating configuration files for eclipse with administrative access rights.
> Installer Sets Path for Wrong User
> ----------------------------------
>
> Key: JBDS-3841
> URL: https://issues.jboss.org/browse/JBDS-3841
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: installer
> Affects Versions: 9.x
> Environment: Windows 10
> Reporter: Thomas Mäder
> Assignee: Denis Golovin
> Priority: Blocker
> Fix For: 10.0.0.Alpha1
>
>
> When I run the offline installer from my non-privileged account, I am prompted by UAC for an administrator login. When I enter my admin login and proceed, tools like vagrant, etc. will not be available from the command line in my non-privileged account. It turns out, the necessary path entries were added to the user-specific path of the admin user, not the user starting the installer.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (JBIDE-21857) Hot class reload doesn't work on OpenShift
by Thomas Mäder (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21857?page=com.atlassian.jira.plugi... ]
Thomas Mäder commented on JBIDE-21857:
--------------------------------------
[~rob.stryker] & me figured it out...Turns out having a breakpoint in the class keeps the original class form being garbage collected.
> Hot class reload doesn't work on OpenShift
> ------------------------------------------
>
> Key: JBIDE-21857
> URL: https://issues.jboss.org/browse/JBIDE-21857
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.Beta2
> Reporter: Fred Bricon
> Assignee: Rob Stryker
> Priority: Blocker
> Fix For: 4.4.0.Alpha1
>
> Attachments: HCRFailure.zip
>
>
> When enabling debug mode on an EAP server deployed on OpenShift, locally changing a class file will :
> - work sometimes when only the content of the method changed, but could fail in some other occasions with the Debugger saying the JDK is out of sync
> - will always fail if a method signature changed, the debugger saying JDK is out of sync
> Restarting the deployed module (with the .dodeploy flag) doesn't fixes the issue (as opposed to the same tweak ahen running on a local EAP server)
> This may be caused by running OpenJDK? Does it support the same level of debugging as Oracle JDK?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (TOOLSDOC-708) JBDS 9.1 GA: Update support page with fedora and os x versions
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/TOOLSDOC-708?page=com.atlassian.jira.plug... ]
Martin Malina commented on TOOLSDOC-708:
----------------------------------------
Great, thanks a lot for the clarification, [~dbhole]. So we will stick with "OpenJDK" for now.
> JBDS 9.1 GA: Update support page with fedora and os x versions
> --------------------------------------------------------------
>
> Key: TOOLSDOC-708
> URL: https://issues.jboss.org/browse/TOOLSDOC-708
> Project: Documentation for JBoss Tools and Developer Studio
> Issue Type: Bug
> Components: General documentation issues
> Affects Versions: 9.1 Beta2
> Reporter: Misha Ali
> Assignee: Misha Ali
> Labels: Support
> Fix For: 9.1 GA
>
> Attachments: screenshot_support.png, Screenshot_support_update.png
>
>
> We should update the support matrix of JBDS to include the latest Fedora releases: 22 and 23. At the same time, 21 can be dropped.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (JBIDE-22201) Error contacting OpenShift after CDK is started
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22201?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-22201:
-------------------------------------
As I recall, there was previously an issue that despite starting up the CDK, sometimes openshift wasn't available. I was asked to add a check to /healthz just so users would be alerted to the problem. Obviously checking /healthz doesn't FIX the problem, but rather allows us to display an error when the problem exists.
You indicate that simply pasting the url into a browser shows the URL is available, so maybe it's the case that it wasn't available when we first try to make the connection? ie, we're trying to check /healthz too quickly? As I understood it, /healthz should be 100% available once the vagrant up command completes. I was told that absolutely nothing done during vagrant up is asynchronous.
The code used is here:
{code}
Exception e = null;
IHttpClient client = builder.client();
try {
String ret = client.get(new URL(url), timeout);
if( "ok".equals(ret))
return true;
} catch(HttpClientException hce) {
e = hce;
} catch( SocketTimeoutException ste) {
e = ste;
} catch(MalformedURLException murle) {
e = murle;
}
throw new OpenShiftNotReadyPollingException(CDKCoreActivator.statusFactory().errorStatus(CDKCoreActivator.PLUGIN_ID,
"The CDK VM is up and running, but OpenShift is unreachable at url " + url, e,
OpenShiftNotReadyPollingException.OPENSHIFT_UNREACHABLE_CODE));
{code}
So either there should be a nested exception in the log (is there? a caused-by?), or, /healthz *did* return but did not return "ok".
> Error contacting OpenShift after CDK is started
> -----------------------------------------------
>
> Key: JBIDE-22201
> URL: https://issues.jboss.org/browse/JBIDE-22201
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk, openshift
> Affects Versions: 4.3.1.Final
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Priority: Blocker
>
> Today Marian and I started seeing this issue: When we start CDK, it will start and everything seems to work, but an error pops up:
> {code}
> Error contacting OpenShift
> org.jboss.tools.openshift.cdk.server.core.internal.adapter.VagrantPoller$OpenShiftNotReadyPollingException: The CDK VM is up and running, but OpenShift is unreachable at url https://10.1.2.2:8443/healthz/ready
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.VagrantPoller.checkOpenShiftHealth(VagrantPoller.java:209)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.VagrantPoller.checkOpenShiftHealth(VagrantPoller.java:186)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.VagrantPoller.onePing(VagrantPoller.java:170)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.VagrantPoller.onePingSafe(VagrantPoller.java:150)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.VagrantPoller.getCurrentStateSynchronous(VagrantPoller.java:129)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.controllers.CDKLaunchController.handleProcessTerminated(CDKLaunchController.java:248)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.controllers.CDKLaunchController.access$2(CDKLaunchController.java:240)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.controllers.CDKLaunchController$2.run(CDKLaunchController.java:233)
> {code}
> When you actually copy&paste that url into a browser, you will get "ok".
> This happens to me on OS X with CDK 2.0 CR3 (the latest build). Marian is on Linux (Fedora 22).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months