[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
3 months, 2 weeks
[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, 5 months
[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, 5 months
[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, 5 months
[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, 5 months