July 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (HAWKULARQE-150) Redeploy archive on EAP - Should fail

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-150?page=com.atlassian.jira.pl... ] Hayk Hovsepyan commented on HAWKULARQE-150: ------------------------------------------- [~mfoley] I did a research in this area, this works as designed. Steps to redeploy are: 1. Deploy war file. 2. Wait until it appears in list of deployments. Here we have improvements that it takes much shorter to recognize deployment in CFME UI, ~10 sec. 3. Try to deploy it once more. It fails to submit with gently warning that deployment already exists. What customer did, is, he skipped 2. step, did not wait until deployment is recognized by CFME and immediately tried to redeploy it. In this case no gently warning is shown that deployment exits, it shows that deployment has been initiated to server. But in fact it failed and failure is shown in Events. And deployment is not broken and is on the server/ > Redeploy archive on EAP - Should fail > ------------------------------------- > > Key: HAWKULARQE-150 > URL: https://issues.jboss.org/browse/HAWKULARQE-150 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Critical > > <mfoley> both apps are deployed in the same eap? > <bhirsch> yep > <mfoley> so you deployed 1 ... shows in the display > <bhirsch> And actions work. I can use cf to start, stop, and deploy > <mfoley> deploy a 2nd ... not showing the display > <bhirsch> correct > <mfoley> odd > <bhirsch> agreed > <mfoley> i suppose a 3rd would not display either > <bhirsch> haven't tried yet. I'm not really an MW guy, so all I had was ticket-monster and helloworld :-) Need a third .war > <mfoley> it's okay > <mfoley> seems like a bug to me ... > <mfoley> i appreciate the feedback > <bhirsch> np > <mfoley> you are a solutions architect? > <bhirsch> correct, SA in the Northeast > <mfoley> cool ... > <mfoley> general question ... what is your impression of the MW Provider? > <bhirsch> I have a customer that wanted a CF demo, with a focus on the MW provider area (they are a JBoss customer) So, here we are. > <mfoley> you can be direct .... it's okay > <bhirsch> So far so good > <mfoley> :) > <mfoley> excellent > <bhirsch> No complaints really. The deployment is a little involved, but very well documented > <mfoley> well ... only demo 1 deployment :) > <bhirsch> haha... yeah. I'm not very worried about that part. Just figured it was something you all would want to know > <mfoley> oh we do > <bhirsch> they'll probably be thrilled to see MW in CF at all > <mfoley> i hope so ... it would be validation of the new direction and strategy > <bhirsch> They use a lot of EAP, so this plus OpenShift (also an OSE customer) could help us beat VMware VRA out the door > <mfoley> :) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-150) Redeploy archive on EAP - Should fail

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-150?page=com.atlassian.jira.pl... ] Hayk Hovsepyan resolved HAWKULARQE-150. --------------------------------------- Resolution: Done > Redeploy archive on EAP - Should fail > ------------------------------------- > > Key: HAWKULARQE-150 > URL: https://issues.jboss.org/browse/HAWKULARQE-150 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Critical > > <mfoley> both apps are deployed in the same eap? > <bhirsch> yep > <mfoley> so you deployed 1 ... shows in the display > <bhirsch> And actions work. I can use cf to start, stop, and deploy > <mfoley> deploy a 2nd ... not showing the display > <bhirsch> correct > <mfoley> odd > <bhirsch> agreed > <mfoley> i suppose a 3rd would not display either > <bhirsch> haven't tried yet. I'm not really an MW guy, so all I had was ticket-monster and helloworld :-) Need a third .war > <mfoley> it's okay > <mfoley> seems like a bug to me ... > <mfoley> i appreciate the feedback > <bhirsch> np > <mfoley> you are a solutions architect? > <bhirsch> correct, SA in the Northeast > <mfoley> cool ... > <mfoley> general question ... what is your impression of the MW Provider? > <bhirsch> I have a customer that wanted a CF demo, with a focus on the MW provider area (they are a JBoss customer) So, here we are. > <mfoley> you can be direct .... it's okay > <bhirsch> So far so good > <mfoley> :) > <mfoley> excellent > <bhirsch> No complaints really. The deployment is a little involved, but very well documented > <mfoley> well ... only demo 1 deployment :) > <bhirsch> haha... yeah. I'm not very worried about that part. Just figured it was something you all would want to know > <mfoley> oh we do > <bhirsch> they'll probably be thrilled to see MW in CF at all > <mfoley> i hope so ... it would be validation of the new direction and strategy > <bhirsch> They use a lot of EAP, so this plus OpenShift (also an OSE customer) could help us beat VMware VRA out the door > <mfoley> :) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3097) Subsystem xml writers should be lazy created when needed

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3097?page=com.atlassian.jira.plugi... ] Kabir Khan resolved WFCORE-3097. -------------------------------- Fix Version/s: 3.0.0.Beta29 Resolution: Done > Subsystem xml writers should be lazy created when needed > -------------------------------------------------------- > > Key: WFCORE-3097 > URL: https://issues.jboss.org/browse/WFCORE-3097 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 3.0.0.Beta29 > > > Currently subsystemWriter is registered up-front with instance of writer. > But in most scenarios that uses use server in production, writers are never even used as they only marshal configuration when it is changed via mgmt api, otherwise there is no need for them to be even initiated. > We should be able to do similar as we did with parsers when they are only created when needed and after their usage they are GC-able. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-139) Targetted refresh - MIQ Sprint-64

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-139?page=com.atlassian.jira.pl... ] Hayk Hovsepyan resolved HAWKULARQE-139. --------------------------------------- Resolution: Done Verified on both manual and automation > Targetted refresh - MIQ Sprint-64 > --------------------------------- > > Key: HAWKULARQE-139 > URL: https://issues.jboss.org/browse/HAWKULARQE-139 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Hayk Hovsepyan > > Summary: Enhancement for updating the status of deployments and servers frequently without the need in manual refresh > Slide Deck: Slide-Deck: https://www.slideshare.net/ManageIQ/sprint-64 > PR: https://github.com/ManageIQ/manageiq-providers-hawkular/pull/27 > Decrease the waiting times for deployments appearance in CFME Tests. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3105) Upgrade WildFly Elytron to 1.1.0.CR4

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3105?page=com.atlassian.jira.plugi... ] Kabir Khan resolved WFCORE-3105. -------------------------------- Fix Version/s: 3.0.0.Beta29 Resolution: Done > Upgrade WildFly Elytron to 1.1.0.CR4 > ------------------------------------ > > Key: WFCORE-3105 > URL: https://issues.jboss.org/browse/WFCORE-3105 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta29 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-864) NameNotFoundException due to policyRegistration -- service jboss.naming.context.java.policyRegistration

by Philippe Marschall (JIRA)

[ https://issues.jboss.org/browse/SECURITY-864?page=com.atlassian.jira.plug... ] Philippe Marschall commented on SECURITY-864: --------------------------------------------- [~benze] {quote}I looked at your code in GitHub. Won't the exceptions thrown by the EmptyPolicy still cause the same slowdowns? Or is the exception thrown by WF simply limited to the fact that no policyRegistration is found (even though it is never actually used)?{quote} Yes that's what we observed, the policyRegistration is never actually used. We profiled the application afterwards and found no more exceptions raised during normal EJB processing. It was to be noted though that we use EJB remoting and not servlets so JACC can never really be called. However we now also provide a {{JBossPolicyRegistrationObjectFactory}} that registers a {{JBossPolicyRegistration}}. > NameNotFoundException due to policyRegistration -- service jboss.naming.context.java.policyRegistration > ------------------------------------------------------------------------------------------------------- > > Key: SECURITY-864 > URL: https://issues.jboss.org/browse/SECURITY-864 > Project: PicketBox > Issue Type: Bug > Components: PicketBox > Reporter: Chao Wang > Assignee: Stefan Guilhen > > "NameNotFoundException due to policyRegistration -- service jboss.naming.context.java.policyRegistration" is recorded in server.log during quickstart example run by changing log level: > {noformat} > <logger category="org.jboss.as.security"> > <level name="TRACE"/> > </logger> > <logger category="org.jboss.security"> > <level name="TRACE"/> > </logger> > {noformat} > See detailed description in community discussion [#907134|https://developer.jboss.org/message/907134] > I choose Jira component picketbox since the exception is titled as "PBOX000293: Exception caught: javax.naming.NameNotFoundException" -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1682) DMN Marshaller prefix preservation and minor improvements

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1682?page=com.atlassian.jira.plugi... ] Tibor Zimányi updated DROOLS-1682: ---------------------------------- Tester: Tibor Zimányi > DMN Marshaller prefix preservation and minor improvements > --------------------------------------------------------- > > Key: DROOLS-1682 > URL: https://issues.jboss.org/browse/DROOLS-1682 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > > Required: > * when a DMN xml file uses a prefix for the DMN namespace, such prefix is to be maintained while marshalling back to xml > Nice to have: > * additional attributes in the non-DMN namespace shall be preserved > * even if no extension elements converters are registered, it would be nice for the DMN-extension element itself to be preserved while marshalling back; especially for the case when it's an empty DMN-extension element element -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1682) DMN Marshaller prefix preservation and minor improvements

by Matteo Mortari (JIRA)

Matteo Mortari created DROOLS-1682: -------------------------------------- Summary: DMN Marshaller prefix preservation and minor improvements Key: DROOLS-1682 URL: https://issues.jboss.org/browse/DROOLS-1682 Project: Drools Issue Type: Bug Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari Required: * when a DMN xml file uses a prefix for the DMN namespace, such prefix is to be maintained while marshalling back to xml Nice to have: * additional attributes in the non-DMN namespace shall be preserved * even if no extension elements converters are registered, it would be nice for the DMN-extension element itself to be preserved while marshalling back; especially for the case when it's an empty DMN-extension element element -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1682) DMN Marshaller prefix preservation and minor improvements

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1682?page=com.atlassian.jira.plugi... ] Matteo Mortari updated DROOLS-1682: ----------------------------------- Sprint: 2017 Week 30-31 > DMN Marshaller prefix preservation and minor improvements > --------------------------------------------------------- > > Key: DROOLS-1682 > URL: https://issues.jboss.org/browse/DROOLS-1682 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > > Required: > * when a DMN xml file uses a prefix for the DMN namespace, such prefix is to be maintained while marshalling back to xml > Nice to have: > * additional attributes in the non-DMN namespace shall be preserved > * even if no extension elements converters are registered, it would be nice for the DMN-extension element itself to be preserved while marshalling back; especially for the case when it's an empty DMN-extension element element -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1681) Publish XSDs automatically for new Drools versions

by Petr Široký (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1681?page=com.atlassian.jira.plugi... ] Petr Široký commented on DROOLS-1681: ------------------------------------- [~mbiarnes] is this something you could possibly take a look at? > Publish XSDs automatically for new Drools versions > -------------------------------------------------- > > Key: DROOLS-1681 > URL: https://issues.jboss.org/browse/DROOLS-1681 > Project: Drools > Issue Type: Feature Request > Components: build > Affects Versions: 6.4.0.Final, 6.5.0.Final, 7.0.0.Final, 7.1.0.Final > Reporter: Russell Morrisey > Assignee: Petr Široký > > When a new Drools final version is released, the XSD should be published and uploaded automatically to the site. > Drools website is missing XSDs for 6.4, 6.5 and 7.x. The URL given in the kmodule.xml example files returns a 404 error. > Automation of the XSDs was previously discussed here: > https://github.com/kiegroup/droolsjbpm-build-bootstrap/pull/122/files -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 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 July 2017