September 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (HAWKULARQE-175) Error/exceptions naming unification on hawkular ruby gem - MIQSprint-67

by Prachi Yadav (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-175?page=com.atlassian.jira.pl... ] Prachi Yadav closed HAWKULARQE-175. ----------------------------------- Resolution: Done This will be covered by CF-UI automation for regressions > Error/exceptions naming unification on hawkular ruby gem - MIQSprint-67 > ----------------------------------------------------------------------- > > Key: HAWKULARQE-175 > URL: https://issues.jboss.org/browse/HAWKULARQE-175 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Michael Foley > > Error/exceptions naming unification on hawkular ruby gem and upgrade to miq side following this. This allows the client code to rescue only one exception. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3210) Wildfly module isolation not working consistently

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi... ] David Lloyd commented on WFCORE-3210: ------------------------------------- An important question is this: why must your custom log4j do all the work? Did you know that WildFly can support log4j appenders natively? > Wildfly module isolation not working consistently > ------------------------------------------------- > > Key: WFCORE-3210 > URL: https://issues.jboss.org/browse/WFCORE-3210 > Project: WildFly Core > Issue Type: Bug > Components: Logging, Modules > Affects Versions: 2.2.0.Final > Reporter: Nuno Godinho de Matos > > There is an underministic bug on the module layer of wildfly, whereby the boot logic of the application server is not ensured to give the appropriate module isolation - which can lead to unexpected boot classpath problems. > An example of this phenomena is given on the wildfly forum thread: > https://developer.jboss.org/thread/275839 > In this example, we have the logging subsystem setup to use a custome handler. > The custom handler wishes to have acces to the JUL extension classes on the org.jboss.logmanger module, but wishes to do have no relationship with the org.apache.log4j packages associated to the wildfly org.jboss.log4j module. > What we see in this example is that an application gets from wildfly mixed behavior. > Most of the time, during boot, the processes works without problem, where the custom handler runs isolated from the undersired log4j libraries within wildfly. > But other times the application boot procedure will not go smoothly with the custom handler having processes routing JUL LogRecords events into the bundled log4j because the application server has loaded some of the classes that exist the org.jboss.log4j module. > And as we know when the same class is loaded by different class loaders, then that class that orinates from class loader A cannot be assigned to the corresponding class of class loader B, even if the classes are exactly the same. > This is not an isolated issue. > There are also open issues on the wildfly forum reporting on startup problems on the logging subsystme where sometimes the LogManager class had not yet been loaded, and sometimes this issue goes away. > This is an indication of some deep issue engrained into the module loading, where the module isolation behavior is not ensured to work all the time and that the boot procedure is not deterministically reliable. > It should not be that the application server some time starts successfully and others not. > Booting wildfly should always result in the same outcode. > Problems of this nature with class loading problems should either always happen if the configuration is not done properly or never happen if the configuration is proper. > In the case of thread: > https://developer.jboss.org/thread/275839 > Our belief is that the configuration is doing all it possible can to request the necessary module isolation from base packages and the outcome where log4j class load problems take place should never be allowed to happen. > Many thanks. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-173) UX Improvement - When adding a datasource - MIQ Sprint-67

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-173?page=com.atlassian.jira.pl... ] Guilherme Baufaker Rêgo commented on HAWKULARQE-173: ---------------------------------------------------- Negative Test Case checked and !Error Screen.png|thumbnail! ManageIQ is working as it should be. > UX Improvement - When adding a datasource - MIQ Sprint-67 > --------------------------------------------------------- > > Key: HAWKULARQE-173 > URL: https://issues.jboss.org/browse/HAWKULARQE-173 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Sunil kondkar > Attachments: Error Screen.png > > > From MIQ Sprint-67 Demo: > UX Improvement - When adding a datasource, there is a need to fetch available jdbc drivers from middleware server. If a provider is not running, do not display an exception when fetching jdbc drivers, but show a descriptive warning message and allow the user to close the wizard. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-173) UX Improvement - When adding a datasource - MIQ Sprint-67

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-173?page=com.atlassian.jira.pl... ] Guilherme Baufaker Rêgo updated HAWKULARQE-173: ----------------------------------------------- Attachment: Error Screen.png > UX Improvement - When adding a datasource - MIQ Sprint-67 > --------------------------------------------------------- > > Key: HAWKULARQE-173 > URL: https://issues.jboss.org/browse/HAWKULARQE-173 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Sunil kondkar > Attachments: Error Screen.png > > > From MIQ Sprint-67 Demo: > UX Improvement - When adding a datasource, there is a need to fetch available jdbc drivers from middleware server. If a provider is not running, do not display an exception when fetching jdbc drivers, but show a descriptive warning message and allow the user to close the wizard. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-175) Error/exceptions naming unification on hawkular ruby gem - MIQSprint-67

by Prachi Yadav (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-175?page=com.atlassian.jira.pl... ] Prachi Yadav commented on HAWKULARQE-175: ----------------------------------------- <Prachi> ping <josejulio> pong <Prachi> Need your help on https://github.com/ManageIQ/manageiq-providers-hawkular/pull/26 <josejulio> What can I do for you? Although I didn't do anything there :) <Prachi> I just want to understand what exactky it is saying <Prachi> what is the feature <Prachi> and what exactly i need to test for this feature <josejulio> Oh, as far i understand, they renamed some exceptions on the client <josejulio> there is no feature there, just renaming <josejulio> it should behave the same after that PR <josejulio> just want to verify if you gave me the right link, the content is: Client error name format unification #26 <Prachi> So do we have anything which needs to test? <Prachi> yes <Prachi> and this as well <Prachi> https://github.com/hawkular/hawkular-client-ruby/pull/222 <Prachi> Actually the card on which we are working is <Prachi> https://issues.jboss.org/browse/HAWKULARQE-175 <Prachi> which is related to this PR <josejulio> Well, let me see if there is anything that can be tested wrt that <Prachi> okay <Prachi> Thank you <josejulio> Ummh, I don't see anything that can be tested externally, these are internal changes as far i can see <josejulio> name changes, grouping exceptions <Prachi> ok <Prachi> Can i update the same thing in https://issues.jboss.org/browse/HAWKULARQE-175 <josejulio> Sorry, what do you mean? <Prachi> I mean their is not need to test anything in this <Prachi> only internal changes <josejulio> oh ok, yes. <Prachi> okay <Prachi> Thanks a lot :) <josejulio> You're welcome > Error/exceptions naming unification on hawkular ruby gem - MIQSprint-67 > ----------------------------------------------------------------------- > > Key: HAWKULARQE-175 > URL: https://issues.jboss.org/browse/HAWKULARQE-175 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Michael Foley > > Error/exceptions naming unification on hawkular ruby gem and upgrade to miq side following this. This allows the client code to rescue only one exception. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3210) Wildfly module isolation not working consistently

by Nuno Godinho de Matos (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi... ] Nuno Godinho de Matos commented on WFCORE-3210: ----------------------------------------------- Hi James, You are right that I have tried to explain what the issue that is taking place is. - I have tried to convey multiple times that: There must be an issue with module system or with my module configuration. Because if modules can conceptually be isolated from one another; and since the custom appenders are searched within "custom" modules; then these custom modules, like my own module, should be able to 100% isolated from the jboss log4j, 100% of the time. - which seems not to be the case whenever i start widlfly for the first time, or switch around my way of starting wildfly. This i have tried to explain many many times as you point out. But then, I have also tried to convey the business use case for this. - We have our own log4j 1 appenders - that we normally use at application server level not at deployment level. - We do not want to be configuring logging per deployment. - In fact, we want more than the logging of an invididual application, we want all logging events. Such as Warnings loged by background monitoring threads of ActiveMq, or any such stuff we do not demploy but that logs important relevant information . - But because our appenders are not JDK appenders (obviously) -- To note be politically correct here: -- Java util logging API is simply the worst logging API on the planet. And if it is not it is close to it. It is broken from the day it was created. Everything that could go wrong there went wrong. The lack of thread name, the thread id as an integer, no MDC concept, everything is missing there, and what is in is bad. So we would never have chosen JUL as the base for our appenders at the point when they were written. - We want to use these appenders. NOTE: - Conceptually, I could rewrite every single one of my appenders as Java Util appender because on Wildfly offers a LogRecord extension class that has all the good proper information in there that you do not have on pure JUL. But agaub that is not JDK standard that is wildfly specific goodies. To rewrite all of these appenders would be quite a bit of effort. And if conceptually I do not need to this because the module subsystem allows me to escape this effort, why would I do it? What I am trying to do, I believe, is conceptually trivial. - It is just trying to make JUL appender that routes to Log4j work 100% of the time. And if module isolation is working 100% stable - this should be possible. As always. Many thanks. > Wildfly module isolation not working consistently > ------------------------------------------------- > > Key: WFCORE-3210 > URL: https://issues.jboss.org/browse/WFCORE-3210 > Project: WildFly Core > Issue Type: Bug > Components: Logging, Modules > Affects Versions: 2.2.0.Final > Reporter: Nuno Godinho de Matos > > There is an underministic bug on the module layer of wildfly, whereby the boot logic of the application server is not ensured to give the appropriate module isolation - which can lead to unexpected boot classpath problems. > An example of this phenomena is given on the wildfly forum thread: > https://developer.jboss.org/thread/275839 > In this example, we have the logging subsystem setup to use a custome handler. > The custom handler wishes to have acces to the JUL extension classes on the org.jboss.logmanger module, but wishes to do have no relationship with the org.apache.log4j packages associated to the wildfly org.jboss.log4j module. > What we see in this example is that an application gets from wildfly mixed behavior. > Most of the time, during boot, the processes works without problem, where the custom handler runs isolated from the undersired log4j libraries within wildfly. > But other times the application boot procedure will not go smoothly with the custom handler having processes routing JUL LogRecords events into the bundled log4j because the application server has loaded some of the classes that exist the org.jboss.log4j module. > And as we know when the same class is loaded by different class loaders, then that class that orinates from class loader A cannot be assigned to the corresponding class of class loader B, even if the classes are exactly the same. > This is not an isolated issue. > There are also open issues on the wildfly forum reporting on startup problems on the logging subsystme where sometimes the LogManager class had not yet been loaded, and sometimes this issue goes away. > This is an indication of some deep issue engrained into the module loading, where the module isolation behavior is not ensured to work all the time and that the boot procedure is not deterministically reliable. > It should not be that the application server some time starts successfully and others not. > Booting wildfly should always result in the same outcode. > Problems of this nature with class loading problems should either always happen if the configuration is not done properly or never happen if the configuration is proper. > In the case of thread: > https://developer.jboss.org/thread/275839 > Our belief is that the configuration is doing all it possible can to request the necessary module isolation from base packages and the outcome where log4j class load problems take place should never be allowed to happen. > Many thanks. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-175) Error/exceptions naming unification on hawkular ruby gem - MIQSprint-67

by Prachi Yadav (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-175?page=com.atlassian.jira.pl... ] Prachi Yadav commented on HAWKULARQE-175: ----------------------------------------- Contacted Developer <josejulio> , "He don't see anything that can be tested externally, these are internal changes as far he can see, these PRs has only name changes, grouping exceptions" . So no QE is required. > Error/exceptions naming unification on hawkular ruby gem - MIQSprint-67 > ----------------------------------------------------------------------- > > Key: HAWKULARQE-175 > URL: https://issues.jboss.org/browse/HAWKULARQE-175 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Michael Foley > > Error/exceptions naming unification on hawkular ruby gem and upgrade to miq side following this. This allows the client code to rescue only one exception. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-175) Error/exceptions naming unification on hawkular ruby gem - MIQSprint-67

by Prachi Yadav (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-175?page=com.atlassian.jira.pl... ] Prachi Yadav commented on HAWKULARQE-175: ----------------------------------------- This is related to PR https://github.com/hawkular/hawkular-client-ruby/pull/222 and https://github.com/ManageIQ/manageiq-providers-hawkular/pull/26 > Error/exceptions naming unification on hawkular ruby gem - MIQSprint-67 > ----------------------------------------------------------------------- > > Key: HAWKULARQE-175 > URL: https://issues.jboss.org/browse/HAWKULARQE-175 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Michael Foley > > Error/exceptions naming unification on hawkular ruby gem and upgrade to miq side following this. This allows the client code to rescue only one exception. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1354) Increment WildFly Elytron schema version

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1354?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1354: ---------------------------------- Fix Version/s: 1.2.0.Beta3 (was: 1.2.0.Beta2) > Increment WildFly Elytron schema version > ---------------------------------------- > > Key: ELY-1354 > URL: https://issues.jboss.org/browse/ELY-1354 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.2.0.Beta3 > > > At the same time we need to review how we handle supporting multiple versions. > On one hand we can look at making our parser fairly permissive so if we are just adding it can support both old and new, the biggest advantage here is we can minimise code duplication. > The down side however is in the future it becomes very difficult to reverse and remove support for older schema. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1346) HTTP Basic auth does not use a IdentityCredentialCallback which prevents the identity from being propagated

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1346?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1346: ---------------------------------- Fix Version/s: 1.2.0.Beta2 > HTTP Basic auth does not use a IdentityCredentialCallback which prevents the identity from being propagated > ----------------------------------------------------------------------------------------------------------- > > Key: ELY-1346 > URL: https://issues.jboss.org/browse/ELY-1346 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Stuart Douglas > Assignee: Darran Lofthouse > Fix For: 1.1.1.Final, 1.2.0.Beta2 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 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

jboss-jira September 2017