March 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (HAWKULARQE-30) [QE] - Upgrade CFME from Tech Preview release to CFME 4.5 release

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-30?page=com.atlassian.jira.plu... ] Hayk Hovsepyan commented on HAWKULARQE-30: ------------------------------------------ BZ is fixed and verified. Test case was run and both metrics and inventory data are remaining after upgrade. > [QE] - Upgrade CFME from Tech Preview release to CFME 4.5 release > ----------------------------------------------------------------- > > Key: HAWKULARQE-30 > URL: https://issues.jboss.org/browse/HAWKULARQE-30 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Critical > > This task supposes to have setup Tech Preview CFME containers , including CFME, Hawkular Services, Cassandra and EAP7 containers. > The task is to upgrade all these Containers into CFME 4.5 release images. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2557) Can not parse 2 complex attributes with same XML element name in 2 different attribute groups

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2557?page=com.atlassian.jira.plugi... ] Tomaz Cerar reassigned WFCORE-2557: ----------------------------------- Assignee: Tomaz Cerar (was: Brian Stansberry) > Can not parse 2 complex attributes with same XML element name in 2 different attribute groups > --------------------------------------------------------------------------------------------- > > Key: WFCORE-2557 > URL: https://issues.jboss.org/browse/WFCORE-2557 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Beta9 > Reporter: Jeff Mesnil > Assignee: Tomaz Cerar > > This issue is a followup on WFLY-8021 where there was 2 complex attributes on the same resource: > - target-credential-reference (attribute group = target, xml element name = credential-reference) > - source-credential-reference (attribute group = source, xml element name = credential-reference) > with the corresponding XML structure: > {code} > <jms-bridge name="myBridge" ...> > <source ...> > <credential-reference clear-text="passwordOut!"/> > </source> > <target ...> > <credential-reference clear-text="passwordOut!"/> > </target> > </jms-bridge> > {code} > The parser fails to parse the source-credential-reference as the persistent XML description elementsAttribute map has a single entry for the credential-reference key that point to the target-credential-reference attribute. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2557) Can not parse 2 complex attributes with same XML element name in 2 different attribute groups

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2557?page=com.atlassian.jira.plugi... ] Tomaz Cerar commented on WFCORE-2557: ------------------------------------- Tnx [~jmesnil] Will prepare a fix asap. > Can not parse 2 complex attributes with same XML element name in 2 different attribute groups > --------------------------------------------------------------------------------------------- > > Key: WFCORE-2557 > URL: https://issues.jboss.org/browse/WFCORE-2557 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Beta9 > Reporter: Jeff Mesnil > Assignee: Tomaz Cerar > > This issue is a followup on WFLY-8021 where there was 2 complex attributes on the same resource: > - target-credential-reference (attribute group = target, xml element name = credential-reference) > - source-credential-reference (attribute group = source, xml element name = credential-reference) > with the corresponding XML structure: > {code} > <jms-bridge name="myBridge" ...> > <source ...> > <credential-reference clear-text="passwordOut!"/> > </source> > <target ...> > <credential-reference clear-text="passwordOut!"/> > </target> > </jms-bridge> > {code} > The parser fails to parse the source-credential-reference as the persistent XML description elementsAttribute map has a single entry for the credential-reference key that point to the target-credential-reference attribute. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1048) Change github url from github.com/droolsjbpm/ to github.com/kiegroup/

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1048?page=com.atlassian.jira.plugi... ] Michael Biarnes Kiefer resolved DROOLS-1048. -------------------------------------------- Resolution: Done > Change github url from github.com/droolsjbpm/ to github.com/kiegroup/ > --------------------------------------------------------------------- > > Key: DROOLS-1048 > URL: https://issues.jboss.org/browse/DROOLS-1048 > Project: Drools > Issue Type: Task > Components: build > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > Priority: Critical > > [~mark.proctor] asked me to make an inventory of what would need to happen if we ever migrate from github.com/droolsjbpm/ to github.com/kiegroup/. Technically this issue is very simply (just change it in GitHub), but organizationally this issue is difficult and dangerous: it needs to be done with care. > https://help.github.com/articles/renaming-an-organization/ > Preparation: > 1) Get some experience > - Make a dummy repository organization foo_org with a dummy repository foo_repo, add some files and a few branches, fork it to your user account, add a PR on it, clone it 2 times: > -- Once from foo_org > -- Once from your user account with foo_org added as upstream ("git remote add upstream ...github.com/ foo_org/...") > - Add some local changes on both dirs. > - On GitHub, go into the repository settings, in the danger zone and rename it from foo_org to foo_org_kiegroup. > - Try using it from your 2 local clones ("git pull --rebase" or "git fetch upstream"). Copy paste the error messages for later use. > -- Fix it locally without recloning, without losing the local changes, etc. Record these steps clearly in a recipe to share with everyone else later. > -- Once it's fixed, see if you can do git operations without having to specify origin for the direct foo_org clone. See also the git option "-u" - you'll likely have to add in the recipe as an extra step. > -- What happened to the open PR? > More stuff to try: > - What happens if you have a organization foo-org with repo foo-repo and you first rename the organization to bar-org and then renae the repo to bar-repo. Do local checkouts, forks and pull requests still work? So is there a double redirect? > 2) (Optional - not needed now that we are renaming org) Clean up our repositories in droolsjbpm. There are a few dead ones that we should not be moving. > 4) Reach out > - Talk to each type of person involved: > -- R&D developer > -- QA > -- Productization > -- Product docs > -- Community > - Make an inventory of references to "github.com/droolsjbpm" > -- Do a find in path on all our files for "github.com/droolsjbpm") > -- Which webapps reference it? > --- jenkins > --- jira > --- www.openhub.net > --- gitter > --- stackoverflow > --- google forums / mailing lists > --- ... > - Set a date when you'll be renaming the org. > -- Clearly communicate on all channels to let everyone know. This includes: > --- Public mailing lists and fora: Drools, OptaPlanner, jBPM, ... > --- Internal mailing lists: sme-brms, pm lists, bsig, etc > --- IRC channel topics > --- Social media (Twitter accounts etc) > --- ... > - Clearly communicate: > -- What you'll do > -- When you'll do it > -- How strong the freeze is: Can they make local changes meanwhile? Will they lose the open PR's? How will this affect their forks and branches? Answer all these questions proactively, based on your experience. Cropped screenshots are good! > -- A recipe: What they need to do - step by step for dummies - after the merge is done. > -- Get someone (Geoffrey, Edson and Petr) to review this mail before it goes out. > - You can't overcommunicate this, but you can undercommunicate it. And there's always going to be 1 person who complains he wasn't told about it and it messes up his work. > 5) Do it: > - Freeze starts, announce in capitals on every IRC channel > - Full checkout as backup (if things go to hell, pick up a phone and call us - don't rush things in trying to restore the situation in a bad way). > - *Rename the organization droolsjbpm to kiegroup* https://help.github.com/articles/renaming-an-organization/ > - Make sure that no one can then create the organization droolsjbpm to break our old redirects. Contact github support for this? > - Freeze stops, announce in capitals on every IRC channel > 6) Clean up the fallout > - Change the pom.xml scm tag for master (in all repo's that ref it) > - Go through your inventory and replace the references as far as humanly reasonable (stackoverflow is likely to be unreasonably, but openhub is not). This includes but is not limited to: > -- all code > -- openhub > -- jira > -- fisheye > -- .org websites (incl jboss.properties) > -- jboss.org > - have all developers and conbributors and QA atc change "git remote" etc to the new url's (prepare a very nice mail for this in advance with scripts that they can copy paste (windows/linux/mac). > Anyway, that's my 2 cents (from my experience when moving svn to Git and splitting up the monastical build 5 years ago). Do this right and this will be almost a non-event (5 years ago it went pretty well on the engineering side, but less on the product side). Mess this up and this can be a disaster that will antagonize a lot of people... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-24) HOSA --- Hawkular Agent for Openshift

by Michael Foley (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-24?page=com.atlassian.jira.plu... ] Michael Foley updated HAWKULARQE-24: ------------------------------------ an update from viet https://gist.github.com/vnugent/0b1fb80c14d4c95ddf527318a57fdb80 > HOSA --- Hawkular Agent for Openshift > ------------------------------------- > > Key: HAWKULARQE-24 > URL: https://issues.jboss.org/browse/HAWKULARQE-24 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: viet nguyen > > Top level task for HOSA. > All the work required goes here as sub-tasks. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2557) Can not parse 2 complex attributes with same XML element name in 2 different attribute groups

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2557?page=com.atlassian.jira.plugi... ] Jeff Mesnil commented on WFCORE-2557: ------------------------------------- [~ctomc] I wrote a test case to reproduce the issue in wildfly-core test suite: https://github.com/jmesnil/wildfly-core/tree/WFCORE-2557_complex_attribut... > Can not parse 2 complex attributes with same XML element name in 2 different attribute groups > --------------------------------------------------------------------------------------------- > > Key: WFCORE-2557 > URL: https://issues.jboss.org/browse/WFCORE-2557 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Beta9 > Reporter: Jeff Mesnil > Assignee: Brian Stansberry > > This issue is a followup on WFLY-8021 where there was 2 complex attributes on the same resource: > - target-credential-reference (attribute group = target, xml element name = credential-reference) > - source-credential-reference (attribute group = source, xml element name = credential-reference) > with the corresponding XML structure: > {code} > <jms-bridge name="myBridge" ...> > <source ...> > <credential-reference clear-text="passwordOut!"/> > </source> > <target ...> > <credential-reference clear-text="passwordOut!"/> > </target> > </jms-bridge> > {code} > The parser fails to parse the source-credential-reference as the persistent XML description elementsAttribute map has a single entry for the credential-reference key that point to the target-credential-reference attribute. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2557) Can not parse 2 complex attributes with same XML element name in 2 different attribute groups

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFCORE-2557: ----------------------------------- Summary: Can not parse 2 complex attributes with same XML element name in 2 different attribute groups Key: WFCORE-2557 URL: https://issues.jboss.org/browse/WFCORE-2557 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 3.0.0.Beta9 Reporter: Jeff Mesnil Assignee: Brian Stansberry This issue is a followup on WFLY-8021 where there was 2 complex attributes on the same resource: - target-credential-reference (attribute group = target, xml element name = credential-reference) - source-credential-reference (attribute group = source, xml element name = credential-reference) with the corresponding XML structure: {code} <jms-bridge name="myBridge" ...> <source ...> <credential-reference clear-text="passwordOut!"/> </source> <target ...> <credential-reference clear-text="passwordOut!"/> </target> </jms-bridge> {code} The parser fails to parse the source-credential-reference as the persistent XML description elementsAttribute map has a single entry for the credential-reference key that point to the target-credential-reference attribute. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1484) Move SessionPseudoClock to public kie-api

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-1484: ----------------------------------- Summary: Move SessionPseudoClock to public kie-api Key: DROOLS-1484 URL: https://issues.jboss.org/browse/DROOLS-1484 Project: Drools Issue Type: Enhancement Components: core engine Reporter: Mario Fusco Assignee: Mario Fusco -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1483) Support default expiration for events

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1483?page=com.atlassian.jira.plugi... ] Mario Fusco reassigned DROOLS-1483: ----------------------------------- Assignee: Mario Fusco (was: Edson Tirelli) > Support default expiration for events > ------------------------------------- > > Key: DROOLS-1483 > URL: https://issues.jboss.org/browse/DROOLS-1483 > Project: Drools > Issue Type: Feature Request > Environment: Drools >= 6.5 in STREAM mode > Reporter: Jochen Welle > Assignee: Mario Fusco > > We would like to be able to specify a "default" expiration offset for events. The default expiration offset should be used if the inferred expiration offset is infinite. > Benefits would be: > * Expiration is guaranteed: either after the specified offset or after the inferred offset. > * Rule authors are not required to include a temporal constraint in all rules. > * Event classes can be designed if the rules are not yet known. > The current behavior of @Expires (fixed expiration offset) could be the default and an optional attribute could be added to enable the new behavior. > {code:java} > @Role(Type.EVENT) > @Expires(value = "10m") // fixed expiration offset or > @Expires(value = "10m", type="fixed") // fixed expiration offset > public class MyEvent { > ... > {code} > New behavior: > {code:java} > @Role(Type.EVENT) > @Expires(value = "10m", type="default") // new feature > public class MyEvent { > ... > {code} > The goal is to have automatic event lifetime/memory management at all times. At the moment either a fixed expiration offset has to be set, which is only possible after analysing all rules and determining the expiration offset manually. Or every rule must include some temporal constraint, which is sometimes a tough burden on the rule author. > This feature is related to: > * [link DROOLS-1227|https://issues.jboss.org/browse/DROOLS-1227] I think the new behavior would touch the same code as the fix implemented there by [~mfusco] > * [link DROOLS-586|https://issues.jboss.org/browse/DROOLS-586] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBEE-176) FactoryFinder requires more privileged blocks if Security Manager is enabled

by Ivo Studensky (JIRA)

[ https://issues.jboss.org/browse/JBEE-176?page=com.atlassian.jira.plugin.s... ] Ivo Studensky updated JBEE-176: ------------------------------- Git Pull Request: https://github.com/jboss/jboss-jaxws-api_spec/pull/5 > FactoryFinder requires more privileged blocks if Security Manager is enabled > ---------------------------------------------------------------------------- > > Key: JBEE-176 > URL: https://issues.jboss.org/browse/JBEE-176 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Components: jboss-jaxws-api > Reporter: Ivo Studensky > Assignee: Ivo Studensky > > When running with Security Manager enabled, the invocation of getContextClassLoader and getClassLoader at FactoryFinder requires additional privileged blocks. > Affected version: jboss-jaxws-api_2.2_spec-2.0.3.Final -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

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 March 2017