[JBoss JIRA] Created: (JBDS-983) Console not showing up when staritng a EAP/SOA-P Instance
by Jim Tyrrell (JIRA)
Console not showing up when staritng a EAP/SOA-P Instance
---------------------------------------------------------
Key: JBDS-983
URL: https://jira.jboss.org/jira/browse/JBDS-983
Project: JBoss Developer Studio
Issue Type: Feature Request
Affects Versions: 3.0.0.M4
Reporter: Jim Tyrrell
For some reason starting a SOA-P instance by right clicking in the server view does not start/open the console for the output of the server as it is starting. For EAP and Seam projects this does not seem to be the case as often, but I think I have seen it. The current JBDS 3.0 M4 release does seem to not show the console unless I open the console via the Window -> Show View -> General -> Console and then I have to click an icon to enable the "Java Stack Trace Console". Once I have setup the console once as just noted even if I close it it will open as I expect. If I close JBDS and make sure that the console was not left open, I get the same behaviour when I try to right click on the SOA-P instance.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 hours, 6 minutes
[JBoss JIRA] (JBDS-2817) Add link to Early Access & Update page templates for new scripted install page
by Michelle Murray (JIRA)
Michelle Murray created JBDS-2817:
-------------------------------------
Summary: Add link to Early Access & Update page templates for new scripted install page
Key: JBDS-2817
URL: https://issues.jboss.org/browse/JBDS-2817
Project: Developer Studio (JBoss Developer Studio)
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: installer
Affects Versions: 7.1.0.Beta1
Reporter: Michelle Murray
Assignee: Nick Boldt
JBDS-2768 created a useful web page about scripted installations: https://devstudio.jboss.com/usage/scripted-install/
A link to this page should be added to both the Early Access and Update page templates. I think the best place to add the info is in the right-hand info box "Installation :: Core Tooling". I think the text should come after the 3 steps for installing and read:
"Installing can also be completed using scripts. For more information see <link>."
--
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
12 years, 1 month
[JBoss JIRA] (JBIDE-15830) openshift-java-client: incompatibility with OpenShift Enterprise and Origin when using the remote-user authentication plugin
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15830?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-15830 at 10/31/13 6:00 PM:
--------------------------------------------------------------------
[~bleanhar] the above tests are unit tests, they're not run against any env. They just pass a client-id in and assert the useragent that the client's using.
The code that's creating the useragent that's being used is the following:
{code:title=UrlConnectionHttpClient}
...
private static final String USERAGENT_FOR_KEYAUTH = "OpenShift";
...
private String setupUserAgent(String authKey, String authIV, String userAgent) {
if (!StringUtils.isEmpty(authKey)) {
if (userAgent == null) {
userAgent = USERAGENT_FOR_KEYAUTH;
} else if (!userAgent.startsWith(USERAGENT_FOR_KEYAUTH)) {
userAgent = USERAGENT_FOR_KEYAUTH + '-' + userAgent;
}
}
return userAgent;
}
{code}
To my understanding this would always prepend "OpenShift" if it's not there already, given that the client's using an authkey.
[~bleanhar] do you have any idea of what the jenkins-plugin's using as authkey?
was (Author: adietish):
[~bleanhar] the above tests are unit tests, they're not run against any env. They just pass a client-id in and assert the useragent that the client's using.
The code that's creating the useragent that's being used is the following:
{code:title=UrlConnectionHttpClient}
...
private static final String USERAGENT_FOR_KEYAUTH = "OpenShift";
...
private String setupUserAgent(String authKey, String authIV, String userAgent) {
if (!StringUtils.isEmpty(authKey)) {
if (userAgent == null) {
userAgent = USERAGENT_FOR_KEYAUTH;
} else if (!userAgent.startsWith(USERAGENT_FOR_KEYAUTH)) {
userAgent = USERAGENT_FOR_KEYAUTH + '-' + userAgent;
}
}
return userAgent;
}
{code}
To my understand this would always prepend "OpenShift" if it's not there already.
> openshift-java-client: incompatibility with OpenShift Enterprise and Origin when using the remote-user authentication plugin
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-15830
> URL: https://issues.jboss.org/browse/JBIDE-15830
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Reporter: Brenton Leanhardt
> Assignee: Andre Dietisheim
> Labels: openshift-java-client
> Fix For: 4.1.1.Beta1, 4.2.0.Alpha1
>
>
> OpenShift Enterprise and Origin both ship an authentication plugin that allows parts of authentication to be handled by Apache and other parts to be delegated to the openshift-origin-controller codebase. I've found that all versions of openshift-java-client after 2.3.0.Final change a (poorly documented) requirement for the OpenShift remote-user plugin.
> In order for a request to bypass the Apache authentication and passthrough to the OpenShift Broker the user-agent header is inspected. If the user-agent is 'OpenShift' then the Broker will require an encrypted authentication token. Today this is used by the jenkins cartridge but I believe it's also still used for scaling.
> You can see this for details:
> https://github.com/openshift/origin-server/blob/master/documentation/arch...
> In 2.3.0.Final of the openshift-java-client the user-agent was 'OpenShift' however all versions after this set the user-agent to the java version (eg, User-Agent: Java/1.7.0_45).
--
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
12 years, 1 month
[JBoss JIRA] (JBIDE-15830) openshift-java-client: incompatibility with OpenShift Enterprise and Origin when using the remote-user authentication plugin
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15830?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-15830:
------------------------------------------
[~bleanhar] the above tests are unit tests, they're not run against any env. They just pass a client-id in and assert the useragent that the client's using.
The code that's creating the useragent that's being used is the following:
{code:title=UrlConnectionHttpClient}
...
private static final String USERAGENT_FOR_KEYAUTH = "OpenShift";
...
private String setupUserAgent(String authKey, String authIV, String userAgent) {
if (!StringUtils.isEmpty(authKey)) {
if (userAgent == null) {
userAgent = USERAGENT_FOR_KEYAUTH;
} else if (!userAgent.startsWith(USERAGENT_FOR_KEYAUTH)) {
userAgent = USERAGENT_FOR_KEYAUTH + '-' + userAgent;
}
}
return userAgent;
}
{code}
To my understand this would always prepend "OpenShift" if it's not there already.
> openshift-java-client: incompatibility with OpenShift Enterprise and Origin when using the remote-user authentication plugin
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-15830
> URL: https://issues.jboss.org/browse/JBIDE-15830
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Reporter: Brenton Leanhardt
> Assignee: Andre Dietisheim
> Labels: openshift-java-client
> Fix For: 4.1.1.Beta1, 4.2.0.Alpha1
>
>
> OpenShift Enterprise and Origin both ship an authentication plugin that allows parts of authentication to be handled by Apache and other parts to be delegated to the openshift-origin-controller codebase. I've found that all versions of openshift-java-client after 2.3.0.Final change a (poorly documented) requirement for the OpenShift remote-user plugin.
> In order for a request to bypass the Apache authentication and passthrough to the OpenShift Broker the user-agent header is inspected. If the user-agent is 'OpenShift' then the Broker will require an encrypted authentication token. Today this is used by the jenkins cartridge but I believe it's also still used for scaling.
> You can see this for details:
> https://github.com/openshift/origin-server/blob/master/documentation/arch...
> In 2.3.0.Final of the openshift-java-client the user-agent was 'OpenShift' however all versions after this set the user-agent to the java version (eg, User-Agent: Java/1.7.0_45).
--
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
12 years, 1 month
[JBoss JIRA] (JBIDE-11602) Provide first class support for client side development
by Victor Rubezhny (JIRA)
[ https://issues.jboss.org/browse/JBIDE-11602?page=com.atlassian.jira.plugi... ]
Victor Rubezhny commented on JBIDE-11602:
-----------------------------------------
The patch proposed for the issue [Bug 411955 - Warning about missing NLS shown|https://bugs.eclipse.org/bugs/show_bug.cgi?id=411955].
Patch removes the 'Missing NLS...' message.
> Provide first class support for client side development
> -------------------------------------------------------
>
> Key: JBIDE-11602
> URL: https://issues.jboss.org/browse/JBIDE-11602
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: jsp/jsf/xml/html source editing
> Reporter: Sebastien Deleuze
> Assignee: Victor Rubezhny
> Priority: Critical
> Labels: jsdt, vjet
> Fix For: 4.2.x
>
> Attachments: jbosstools-add-vjet-dependencies-patch.patch, jquery-1.5.1.min.js.jpg, jquery.tagcanvas.min.js.jpg, nexj-JS-Content-Assist-On-a-JS-in-ticket-monster-project-After-Insertion.jpg, nexj-JS-Content-Assist-On-a-JS-in-ticket-monster-project.jpg, nexj-JS-Content-Assist-On-an-HTML-1-in-ticket-monster-project-After-Insertion.jpg, nexj-JS-Content-Assist-On-an-HTML-1-in-ticket-monster-project.jpg, nexj-JS-Content-Assist-On-an-HTML-2-1-in-ticket-monster-project-After-Insertion.jpg, nexj-JS-Content-Assist-On-an-HTML-2-1-in-ticket-monster-project.jpg, nexj-JS-Content-Assist-On-an-HTML-2-2-in-ticket-monster-project-After-Insertion.jpg, nexj-JS-Content-Assist-On-an-HTML-2-2-in-ticket-monster-project.jpg, nexj-JS-Content-Assist-On-Any-JS-in-ticket-monster-project-After-Insertion.jpg, nexj-JS-Content-Assist-On-Any-JS-in-ticket-monster-project.jpg, nexj-JS-Content-Assist-On-Any-JS-in-ticket-monster-project.jpg, vjet-JS-Content-Assist-On-a-JS-in-ticket-monster-project-After-Insertion.jpg, vjet-JS-Content-Assist-On-a-JS-in-ticket-monster-project.jpg, vjet-JS-Content-Assist-On-Any-JS-in-ticket-monster-project-After-Insertion.jpg, vjet-JS-Content-Assist-On-Any-JS-in-ticket-monster-project.jpg, vjet-JS-Content-Assist-On-HTML-1-in-ticket-monster-project-After-Insertion.jpg, vjet-JS-Content-Assist-On-HTML-1-in-ticket-monster-project.jpg, vjet-JS-Content-Assist-On-HTML-2-1-in-ticket-monster-project-After-Insertion.jpg, vjet-JS-Content-Assist-On-HTML-2-1-in-ticket-monster-project.jpg, vjet-JS-Content-Assist-On-HTML-2-2-in-ticket-monster-project-After-Insertion.jpg, vjet-JS-Content-Assist-On-HTML-2-2-in-ticket-monster-project.jpg
>
>
> Web application development is currently moving in many projects from end to end server side technologies to HTML5 RIA developed with REST Webservices/ Webscoket on serverside + pure client side technologies GUI (Backbone.js for example).
> Eclipse has been always been quite bad in the field of advanced Javascript development. JSDT was a good start, but its development has been stopped for a few years, and in its current status, it is not really a good tool for real HTML5/JS dev. From what I know, there is no roadmap for strong move on this field in the WTP team. The only real Eclipse initiative for client side development is Orion (http://www.eclipse.org/orion/) outside of the IDE.
> The only other alternative is Aptana Studio 3, acquired last year by AppAccelerator.
> My question is : is there any plan to consider client side development as a first class citizen in JBoss Studio, even if this question apply to the whole Eclipse Ecosystem ? Other IDE like Netbeans or IntelliJ Idea have a strong support for these technologies, and my guess is this lack may be a significant blocking point in the following years.
> Thanks in advance for your feedback.
--
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
12 years, 1 month
[JBoss JIRA] (JBIDE-15499) Support drag'n'drop of links to "connectors" similar to marketplace to central for auto install
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15499?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-15499 at 10/31/13 4:06 PM:
--------------------------------------------------------------
Since this is about documentation of correct usage (and an upstream issue) I think we can resolve this (again, for Beta1 - no respin was needed).
[~mmurray] I've set RN doc status to Not Yet as this clearly needs to be documented carefully so users know to drag into Central, not into other views or editors.
[~snjeza] If you think more can be done here - either fixes to upstream or a better way of handling when users drag into the wrong place - feel free to open a new enhancement JIRA, linked to this one.
was (Author: nickboldt):
Since this is about documentation of correct usage (and an upstream issue) I think we can resolve this (again, for Beta1 - no respin was needed).
[~mmurray] I've set RN doc status to Not Yet as this clearly needs to be documented carefully so users know to drag into Central, not into other views or editors.
> Support drag'n'drop of links to "connectors" similar to marketplace to central for auto install
> -----------------------------------------------------------------------------------------------
>
> Key: JBIDE-15499
> URL: https://issues.jboss.org/browse/JBIDE-15499
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: central
> Reporter: Max Rydahl Andersen
> Assignee: Snjezana Peco
> Priority: Blocker
> Fix For: 4.1.1.Beta1
>
>
> usecase is that you can have a link to a connector, such as JBDS-IS could be installed by drag'n'drop to jboss tools or jbds.
> Similar to eclipse marketplace for marketplace urls something like:
> * https://devstudio.jboss.com/central/install?connector=com.jbds.integratio... or
> * http://download.jboss.org/jbosstools/central/install?CID=com.jbds.integra...
> would install the two connectors named "com.jbds.integration-stack.bpel" and "org.eclipse.m2e"
> This would allow drag'n'drop install from html docs.
> Consider also supporting this from any clipboard object (eg., dragged from an Acrobat Reader PDF or Microsoft Office doc). Would need to ensure we do lots of platform testing.
--
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
12 years, 1 month
[JBoss JIRA] (JBIDE-15499) Support drag'n'drop of links to "connectors" similar to marketplace to central for auto install
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15499?page=com.atlassian.jira.plugi... ]
Nick Boldt resolved JBIDE-15499.
--------------------------------
Release Notes Docs Status: Not Yet Documented
Release Notes Text: Now you can drag a link into the JBoss Central view to cause Central connector(s) to be installed into Eclipse or JBDS.
Resolution: Done
Since this is about documentation of correct usage (and an upstream issue) I think we can resolve this (again, for Beta1 - no respin was needed).
[~mmurray] I've set RN doc status to Not Yet as this clearly needs to be documented carefully so users know to drag into Central, not into other views or editors.
> Support drag'n'drop of links to "connectors" similar to marketplace to central for auto install
> -----------------------------------------------------------------------------------------------
>
> Key: JBIDE-15499
> URL: https://issues.jboss.org/browse/JBIDE-15499
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: central
> Reporter: Max Rydahl Andersen
> Assignee: Snjezana Peco
> Priority: Blocker
> Fix For: 4.1.1.Beta1
>
>
> usecase is that you can have a link to a connector, such as JBDS-IS could be installed by drag'n'drop to jboss tools or jbds.
> Similar to eclipse marketplace for marketplace urls something like:
> * https://devstudio.jboss.com/central/install?connector=com.jbds.integratio... or
> * http://download.jboss.org/jbosstools/central/install?CID=com.jbds.integra...
> would install the two connectors named "com.jbds.integration-stack.bpel" and "org.eclipse.m2e"
> This would allow drag'n'drop install from html docs.
> Consider also supporting this from any clipboard object (eg., dragged from an Acrobat Reader PDF or Microsoft Office doc). Would need to ensure we do lots of platform testing.
--
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
12 years, 1 month