[JBoss JIRA] (JBIDE-19029) Error: "Attribute name is not allowed to appear in element sub-deployment" in two Seam examples
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19029?page=com.atlassian.jira.plugi... ]
Viacheslav Kabanovich commented on JBIDE-19029:
-----------------------------------------------
There is a difference in jboss-deployment-structure-1_0.xsd compared to later versions. All versions define subDeploymentType which declares 'name' attribute, but while versions 1.1 and 1.2 use this new type for element 'sub-deployment', version 1.0 does not. I do not know if it is a bug of the copy of jboss-deployment-structure-1_0.xsd or it is a supposed difference of version 1.0.
[~rob.stryker], could you clarify this please?
> Error: "Attribute name is not allowed to appear in element sub-deployment" in two Seam examples
> -----------------------------------------------------------------------------------------------
>
> Key: JBIDE-19029
> URL: https://issues.jboss.org/browse/JBIDE-19029
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server, upstream
> Environment: JBDS 8.0.1.GA
> Reporter: Matous Jobanek
> Assignee: Viacheslav Kabanovich
> Fix For: 4.2.3.Final, 4.3.0.Alpha1
>
>
> When the projects
> * mail-ear from the Seam example mail \[1\]
> * tasks-ear from the Seam example tasks \[2\]
> are imported into JBDS the error
> {panel}
> Attribute 'name' is not allowed to appear in element 'sub-deployment'
> {panel}
> will be shown for the file jboss-deployment-structure.xml.
> It is caused by the bug in _jboss-deployment-structure-1_0.xsd_; see AS7-1345
> This bug should be IMHO ignored and the error shouldn't be shown.
> \[1\] https://github.com/seam2/jboss-seam/tree/Seam_2_3/examples/mail
> \[2\] https://github.com/seam2/jboss-seam/tree/Seam_2_3/examples/tasks
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBIDE-12351) Remote JMX connection to servers cannot be established with IPv6
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-12351?page=com.atlassian.jira.plugi... ]
Alexey Kazakov reassigned JBIDE-12351:
--------------------------------------
Assignee: Rob Stryker
> Remote JMX connection to servers cannot be established with IPv6
> ----------------------------------------------------------------
>
> Key: JBIDE-12351
> URL: https://issues.jboss.org/browse/JBIDE-12351
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: jmx
> Affects Versions: 3.3.0.Final
> Environment: Fedora 17 32bit
> EAP 6.0.0.GA
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Labels: f2f2014
> Fix For: 4.2.3.Final, 4.3.0.Alpha1
>
>
> When I set up a remote server accessible over IPv6, start the server and then try to open the server in MBean Explorer, it's stuck on "Loading" and keeps printing this error in the log:
> {code}
> ERROR: JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> Jul 20, 2012 2:41:24 PM org.xnio.Xnio <clinit>
> INFO: XNIO Version 3.0.4.GA-redhat-1
> Jul 20, 2012 2:41:25 PM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.0.4.GA-redhat-1
> Jul 20, 2012 2:41:25 PM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 3.2.8.GA-redhat-1
> Jul 20, 2012 2:41:25 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 2:41:25 PM org.xnio.Xnio <clinit>
> INFO: XNIO Version 3.0.4.GA-redhat-1
> Jul 20, 2012 2:41:25 PM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.0.4.GA-redhat-1
> Jul 20, 2012 2:41:25 PM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 3.2.8.GA-redhat-1
> Jul 20, 2012 2:41:26 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, 3 months
[JBoss JIRA] (JBIDE-19030) Creation of new RichFaces project results in outdated archetype
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19030?page=com.atlassian.jira.plugi... ]
Fred Bricon resolved JBIDE-19030.
---------------------------------
Release Notes Text: Richfaces Archetype 4.5.1.Final is now live for all JBT/JBDS versions
Resolution: Done
> Creation of new RichFaces project results in outdated archetype
> ---------------------------------------------------------------
>
> Key: JBIDE-19030
> URL: https://issues.jboss.org/browse/JBIDE-19030
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: project-examples
> Affects Versions: 4.2.1.Final
> Reporter: Matej Novotny
> Assignee: Fred Bricon
> Priority: Minor
> Fix For: 4.2.2.Final
>
>
> In JBDS one can create RichFaces project via:
> * File -> New -> Other -> RichFaces Project
> This results in choosing kitchensink archetype for version 4.2.3 which is outdated.
> There were some major changes to RichFaces beggining with version 4.5 so it would be nice if JBDS could make use of any 4.5.x.Final version artifact instead.
> Note: Latest archetype version is 4.5.1.Final and 4.5.2.Final is being staged at the moment, so one of these two should be used I guess.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBIDE-19030) Creation of new RichFaces project results in outdated archetype
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19030?page=com.atlassian.jira.plugi... ]
Fred Bricon commented on JBIDE-19030:
-------------------------------------
Richfaces Archetype 4.5.1.Final is now live for all JBT/JBDS versions
> Creation of new RichFaces project results in outdated archetype
> ---------------------------------------------------------------
>
> Key: JBIDE-19030
> URL: https://issues.jboss.org/browse/JBIDE-19030
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: project-examples
> Affects Versions: 4.2.1.Final
> Reporter: Matej Novotny
> Assignee: Fred Bricon
> Priority: Minor
> Fix For: 4.2.2.Final
>
>
> In JBDS one can create RichFaces project via:
> * File -> New -> Other -> RichFaces Project
> This results in choosing kitchensink archetype for version 4.2.3 which is outdated.
> There were some major changes to RichFaces beggining with version 4.5 so it would be nice if JBDS could make use of any 4.5.x.Final version artifact instead.
> Note: Latest archetype version is 4.5.1.Final and 4.5.2.Final is being staged at the moment, so one of these two should be used I guess.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBIDE-19030) Creation of new RichFaces project results in outdated archetype
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19030?page=com.atlassian.jira.plugi... ]
Fred Bricon updated JBIDE-19030:
--------------------------------
Fix Version/s: 4.2.2.Final
(was: 4.3.x)
> Creation of new RichFaces project results in outdated archetype
> ---------------------------------------------------------------
>
> Key: JBIDE-19030
> URL: https://issues.jboss.org/browse/JBIDE-19030
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: project-examples
> Affects Versions: 4.2.1.Final
> Reporter: Matej Novotny
> Assignee: Fred Bricon
> Priority: Minor
> Fix For: 4.2.2.Final
>
>
> In JBDS one can create RichFaces project via:
> * File -> New -> Other -> RichFaces Project
> This results in choosing kitchensink archetype for version 4.2.3 which is outdated.
> There were some major changes to RichFaces beggining with version 4.5 so it would be nice if JBDS could make use of any 4.5.x.Final version artifact instead.
> Note: Latest archetype version is 4.5.1.Final and 4.5.2.Final is being staged at the moment, so one of these two should be used I guess.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBIDE-18900) CordovaSim: Can't run default FeedHenry app locally
by Ilya Buziuk (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18900?page=com.atlassian.jira.plugi... ]
Ilya Buziuk commented on JBIDE-18900:
-------------------------------------
[~maxandersen], I get the point with parameters - that's fair, I haven't thought about it from that angle ;-). I have created a separate issue for that - JBIDE-19032
#1/2 Ok I got it. Please correct me if I'm wrong. The proposal is the following: having 2 *different launch configurations* of the *same launch config type*. This approach would work and it's easy to do. But it seems to have 2 drawbacks:
- no obvious UI for changing default server url
- it's not clear how to switch between FH's remote and local server
#3 well, IMO the original problem is *it's not clear from the user perspective how to force CordovaSim use local FH server*. And separate launch configuration seems to solve it. Now it's clear how to trigger between local and remote server. Also it's clear how to change server url (for instance to http://127.0.0.1:5543) cause we have a separate UI for that. Basically, I personally think that this approach is *not* ideal due to the fact that in order to use local server one needs to open launch config and do it manually. But at the same time it seems to be more straightforward.
On balance, we have 2 alternatives now with the following +/-:
*(1) leave old launch type:*
+) simple
+) do not require API breakage (if we not implementing JBIDE-19032 for 8.1.0)
-) not obvious from the user perspective
*(2) new launch type*
+/-) not simple compared with (1), but not intricate either
+) separate FH UI / more straightforward
-) will probably require API breakage (ideally I want to refactor some stuff in CordovaSim)
Third option is to implement (1) for 8.1.0 and (2) for master.
WDYT?
> CordovaSim: Can't run default FeedHenry app locally
> ---------------------------------------------------
>
> Key: JBIDE-18900
> URL: https://issues.jboss.org/browse/JBIDE-18900
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cordovasim
> Affects Versions: 4.2.1.Final
> Reporter: Ilya Buziuk
> Assignee: Ilya Buziuk
> Fix For: 4.3.0.Alpha1
>
> Attachments: configuration.png, cordovasimFH.png, hello_tom.png, newLaunch.png, preferences.png, ToolsProject-Cloud-App.zip, ToolsProject-Cordova-App.zip
>
>
> Basically, the situation is the following:
> 1. *ToolsProject-Cordova-App.zip* - is a basic FH hybrid app (all the app does is saying Hello + 'username' from the input field )
> 2. To run this app one simply needs to unpack the archive and import it as a cordova project to the studio
> 3. The application will work with a *remote* server like a charm !hello_tom.png|thumbnail!
> 4. However, there is an option to use *local* server instead of *remote* one
> 5. *ToolsProject-Cloud-App.zip* - is a app for running local server via grunt task runner
> 6. In order to run local server one needs:
> - unpack the app
> - run *npm install .*
> - run *grunt serve*
> Need to find the way to made CordovaSim use this *local* server
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBIDE-18724) HTML Validation: Ability to ignore custom htm tags (e.g. <ion-*>)
by Victor Rubezhny (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18724?page=com.atlassian.jira.plugi... ]
Victor Rubezhny commented on JBIDE-18724:
-----------------------------------------
PR is replaced with the new one: https://github.com/jbosstools/jbosstools-jst/pull/433
> HTML Validation: Ability to ignore custom htm tags (e.g. <ion-*>)
> -----------------------------------------------------------------
>
> Key: JBIDE-18724
> URL: https://issues.jboss.org/browse/JBIDE-18724
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: jsp/jsf/xml/html source editing, upstream
> Reporter: Victor Rubezhny
> Assignee: Victor Rubezhny
> Labels: new_and_noteworthy
> Fix For: 4.2.3.Final
>
>
> WTP HTML validator marks any custom html tags as unknown. It's possible to disable this validation at all: Window->Preferences->Web->HTML Files->Validation ==> Set Elements -> Unknown tag name severity to "Ignore":
> !00001262.png!
> But it would be useful to have ability to make HTML validator ignore some particular tags only.
> I suggest to contribute a patch to WTP to fix it.
> We have already did it for attributes, so lets do it for tags too:
> - New preferences with a list of ignored tags (a mask can be used)
> - A new preference page to set these preferences
> - QuickFix for validation problem which will add the tag name/mask to this list/preferences
> - Extension in our angular/ionic plugin which will disable validation for <ion-*> tags.
> I've filed it to bugzilla - https://bugs.eclipse.org/bugs/show_bug.cgi?id=444545 but we have to provide a patch for it if we want to have it done ;)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months