April 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-10200) WARN on presence of -jms.xml file if embedded broker is not present, instead of doing invalid wiring

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-10200?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-10200: ------------------------------------ Summary: WARN on presence of -jms.xml file if embedded broker is not present, instead of doing invalid wiring (was: WARN on presence of -jmx.xml file if embedded broker is not present, instead of doing invalid wiring) > WARN on presence of -jms.xml file if embedded broker is not present, instead of doing invalid wiring > ---------------------------------------------------------------------------------------------------- > > Key: WFLY-10200 > URL: https://issues.jboss.org/browse/WFLY-10200 > Project: WildFly > Issue Type: Enhancement > Components: JMS > Reporter: Brian Stansberry > Assignee: Jeff Mesnil > Priority: Minor > > This is largely a topic for discussion. > If the messaging subsystem is present but no 'server' child resource is installed, there's a DUP that will try and create services for destinations in any discovered xxx-jmx.xml. These will fail due to missing dependencies on broker services. > Perhaps the DUP could just log a WARN in this case. Of course if the app depends on the destinations configured in the -jmx.xml and they are not provided otherwise (i.e. separately configured on an external broker) then the app will fail anyway, and the WARN would just help explain why. But if the destinations are available, then the -jms.xml could be regarded as just ignorable cruft left in the deployment. > For example, the app at https://github.com/jboss-openshift/openshift-quickstarts/tree/master/jta-... could benefit from this, by being able to work when deployed 1) with an embedded broker or 2) with an external broker and just an empty subsystem-messaging-activemq. > An assumption I'm making here is a subsystem=messaging-activemq is or will be useful even without a child 'server' resource. That's what our current openshift images configure when we configure for an external broker. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3733) Picketbox should be loaded lazily by the vault reader

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3733?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-3733: ---------------------------------------- Component/s: Domain Management Assignee: Stuart Douglas [~swd847] I've assigned this to you just because I thought you'd solved it and I don't want someone else to do duplicate work. > Picketbox should be loaded lazily by the vault reader > ----------------------------------------------------- > > Key: WFCORE-3733 > URL: https://issues.jboss.org/browse/WFCORE-3733 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Stuart Douglas > Assignee: Stuart Douglas > > This will allow the ee8.preview.mode property to work correctly, otherwise EE8 API's get loaded too early. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2952) Add an XML formatter resources to the logging subsystem

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2952?page=com.atlassian.jira.plugi... ] James Perkins edited comment on WFCORE-2952 at 4/11/18 3:00 PM: ---------------------------------------------------------------- Analysis Document: https://github.com/wildfly/wildfly-proposals/pull/47 was (Author: jamezp): Analysis Document: https://developer.jboss.org/docs/DOC-56153 > Add an XML formatter resources to the logging subsystem > ------------------------------------------------------- > > Key: WFCORE-2952 > URL: https://issues.jboss.org/browse/WFCORE-2952 > Project: WildFly Core > Issue Type: Feature Request > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > > The logging subsystem should include a resource for a {{xml-formatter}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2952) Add an XML formatter resources to the logging subsystem

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2952?page=com.atlassian.jira.plugi... ] James Perkins updated WFCORE-2952: ---------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/3206 > Add an XML formatter resources to the logging subsystem > ------------------------------------------------------- > > Key: WFCORE-2952 > URL: https://issues.jboss.org/browse/WFCORE-2952 > Project: WildFly Core > Issue Type: Feature Request > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > > The logging subsystem should include a resource for a {{xml-formatter}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10221) Hot deployment causes cascading redeployment of dependent artfacts when using jboss-all.xml configuration files

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-10221?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFLY-10221: ----------------------------------------- In general across WildFly if Y depends on X and you bounce X, then Y is going to bounce too. This applies to deployments with dependency links via jboss-all.xml as well. Otherwise there is no way to know if Y will still work correctly and the server has no understanding of its internal state. Plus the mere fact of bouncing X means there is a period of time where a stated dependency of Y is not present. The app.ear.deployed marker does not get updated because the deployment scanner updates the markers to reflect the results of its own activity, i.e. seeing changed content and telling the server to deploy it. It would be a minor Enhancement request to get that changed. If you'd like I can convert this to an Enhancement and move it to the WFCORE project. I can't promise when we'd get to it though. > Hot deployment causes cascading redeployment of dependent artfacts when using jboss-all.xml configuration files > --------------------------------------------------------------------------------------------------------------- > > Key: WFLY-10221 > URL: https://issues.jboss.org/browse/WFLY-10221 > Project: WildFly > Issue Type: Bug > Affects Versions: 11.0.0.Final > Reporter: John Doe > Assignee: Jason Greene > Priority: Minor > > Let's assume I have 2 files _app.ear_ and _framework.ear_ deployed in WildFly 11. > _framework.ear_ needs to be deployed before _app.ear_ which is expressed by the _jboss-all.xml_ file contained in the app.ear/META-INF folder: > {code:java} > <jboss umlns="urn:jboss:1.0"> > <jboss-deployment-dependencies xmlns="urn:jboss:deployment-dependencies:1.0"> > <dependency name="framework.ear" /> > </jboss-deployment-dependencies> > </jboss> > {code} > Now something changes in _framework.ear_ and a redeployment of _framework.ear_ becomes necessary. > _app.ear_ does get redeployed, too, immediately after a hot deployment of _framework.ear_ has been carried out. > *Observations:* After the redeployment of _framework.ear_ a new _framework.ear.deployed_ marker gets created, but same does not hold for _app.ear.deployed_. > In fact no new _app.ear.deployed_ gets created at all (same timestamp for this file as before) despite a redeployment takes place. > Nevertheless, in the console I see a redeployment for the dependent _app.ear_ occurs. > Extending the example above, this is time consuming when you have a couple of additional dependencies cascading through. > I don't understand why this happens because _app.ear_ did not change. > My expectation is that only a redeployment of _framework.ear_ will take place. In my opinion there is no reason to redeploy _app.ear_, too. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1532) Deprecate AuthConf setHost, setProtocol, setPort properties

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1532?page=com.atlassian.jira.plugin.s... ] Jan Kalina reassigned ELY-1532: ------------------------------- Assignee: (was: Jan Kalina) > Deprecate AuthConf setHost, setProtocol, setPort properties > ----------------------------------------------------------- > > Key: ELY-1532 > URL: https://issues.jboss.org/browse/ELY-1532 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Reporter: David Lloyd > Priority: Critical > > We should deprecate (with a view towards removal) the setHost, setPort, and setProtocol properties of AuthenticationConfiguration. These properties are only sporadically utilized by backing systems, and often cause complex problems when they are used. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10225) Possible problem inflowing transactions from IIOP

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-10225?page=com.atlassian.jira.plugin... ] David Lloyd commented on WFLY-10225: ------------------------------------ /cc [~swd847] [~tomekadamski] > Possible problem inflowing transactions from IIOP > ------------------------------------------------- > > Key: WFLY-10225 > URL: https://issues.jboss.org/browse/WFLY-10225 > Project: WildFly > Issue Type: Bug > Components: EJB, IIOP, Transactions > Reporter: David Lloyd > > WFLY-7680 introduced the concept of lazy transaction inflow. The transaction is not associated with the thread unless the EJB invocation mode causes the caller transaction to be used (if present). > This may have caused a problem where transaction association does not function correctly when transactional operations are invoked via IIOP, though I do not have a good explanation as to why this would happen yet. > The significant participants in this process appear to be: > * {{org.jboss.as.ejb3.iiop.EjbCorbaServant}} > * {{org.jboss.as.ejb3.iiop.EjbIIOPTransactionInterceptor}} > * {{org.jboss.as.ejb3.tx.CMTTxInterceptor}} > It's possible that there is some situation where the behavior of the invocation has changed due to the remote TX inflow interceptor being gone, which prevents the transaction from being associated with the thread until later than before. Or, this may all be a coincidence and the problem may be caused elsewhere. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10225) Possible problem inflowing transactions from IIOP

by David Lloyd (JIRA)

David Lloyd created WFLY-10225: ---------------------------------- Summary: Possible problem inflowing transactions from IIOP Key: WFLY-10225 URL: https://issues.jboss.org/browse/WFLY-10225 Project: WildFly Issue Type: Bug Components: EJB, IIOP, Transactions Reporter: David Lloyd WFLY-7680 introduced the concept of lazy transaction inflow. The transaction is not associated with the thread unless the EJB invocation mode causes the caller transaction to be used (if present). This may have caused a problem where transaction association does not function correctly when transactional operations are invoked via IIOP, though I do not have a good explanation as to why this would happen yet. The significant participants in this process appear to be: * {{org.jboss.as.ejb3.iiop.EjbCorbaServant}} * {{org.jboss.as.ejb3.iiop.EjbIIOPTransactionInterceptor}} * {{org.jboss.as.ejb3.tx.CMTTxInterceptor}} It's possible that there is some situation where the behavior of the invocation has changed due to the remote TX inflow interceptor being gone, which prevents the transaction from being associated with the thread until later than before. Or, this may all be a coincidence and the problem may be caused elsewhere. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2469) Please implement multiselect dropdown under dataobject sections

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2469?page=com.atlassian.jira.plugi... ] Edson Tirelli updated DROOLS-2469: ---------------------------------- Component/s: Guided Rule Editor > Please implement multiselect dropdown under dataobject sections > ---------------------------------------------------------------- > > Key: DROOLS-2469 > URL: https://issues.jboss.org/browse/DROOLS-2469 > Project: Drools > Issue Type: Feature Request > Components: Guided Rule Editor > Reporter: chandra vudumula > Assignee: Guilherme Carreiro > Priority: Minor > Attachments: screenshot-1.png > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2469) Please implement multiselect dropdown under dataobject sections

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2469?page=com.atlassian.jira.plugi... ] Edson Tirelli reassigned DROOLS-2469: ------------------------------------- Assignee: Guilherme Carreiro (was: Edson Tirelli) > Please implement multiselect dropdown under dataobject sections > ---------------------------------------------------------------- > > Key: DROOLS-2469 > URL: https://issues.jboss.org/browse/DROOLS-2469 > Project: Drools > Issue Type: Feature Request > Reporter: chandra vudumula > Assignee: Guilherme Carreiro > Priority: Minor > Attachments: screenshot-1.png > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 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 April 2018