July 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4864) JSP in web application doesn't get VFS-based security permissions

by Bartosz Spyrko-Śmietanko (JIRA)

Bartosz Spyrko-Śmietanko created WFLY-4864: ---------------------------------------------- Summary: JSP in web application doesn't get VFS-based security permissions Key: WFLY-4864 URL: https://issues.jboss.org/browse/WFLY-4864 Project: WildFly Issue Type: Bug Components: Web (Undertow) Affects Versions: 10.0.0.Alpha4 Reporter: Bartosz Spyrko-Śmietanko Assignee: Stuart Douglas Permissions granted to web applications (using vfs:/... codebase) are not available in JSPs. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4656) Export dependency for "javax.jms.api" in org.jboss.genericjms module

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-4656?page=com.atlassian.jira.plugin.... ] Jeff Mesnil updated WFLY-4656: ------------------------------ Fix Version/s: 10.0.0.Alpha5 > Export dependency for "javax.jms.api" in org.jboss.genericjms module > -------------------------------------------------------------------- > > Key: WFLY-4656 > URL: https://issues.jboss.org/browse/WFLY-4656 > Project: WildFly > Issue Type: Feature Request > Components: JCA, JMS > Affects Versions: 9.0.0.CR1, 10.0.0.Alpha1 > Reporter: Miroslav Novak > Assignee: Jeff Mesnil > Fix For: 10.0.0.Alpha5 > > > More info in WFLY-4642. > If deployment with MDB has dependency to module "org.jboss.genericjms" then module "javax.jms.api" is not loaded for the deployment and deploy fails. > This is a change in module loading behaviour against previous versions of Wildfly/EAP and complicates migration/usability. > We can avoid this by exporting "javax.jms.api" dependency in "org.jboss.genericjms" module. It should look like: > {code} > <module xmlns="urn:jboss:module:1.3" name="org.jboss.genericjms"> > ... > <dependencies> > ... > <module name="javax.jms.api" slot="main" export="true"/> > ... > </dependencies> > </module> > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4863) Journal file size configuration attribute changed

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-4863?page=com.atlassian.jira.plugin.... ] Jeff Mesnil updated WFLY-4863: ------------------------------ Security: (was: Red Hat Internal) > Journal file size configuration attribute changed > ------------------------------------------------- > > Key: WFLY-4863 > URL: https://issues.jboss.org/browse/WFLY-4863 > Project: WildFly > Issue Type: Feature Request > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 10.0.0.Alpha5 > > > Attribute journal file-size is set to 102400 bytes in messaging subsystem (in Wildfly 9 with ActiveMQ). This attribute was not set in EAP 6.x and its default value was 10Mb. Current value 102400 bytes causes warnings if message of specific size is sent to server as it is the same value of the connection-factory's min-large-message-size -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4862) Provide as automated EAP 6.2 --> EAP6.Latest transformers testing

by Tomaz Cerar (JIRA)

Tomaz Cerar created WFLY-4862: --------------------------------- Summary: Provide as automated EAP 6.2 --> EAP6.Latest transformers testing Key: WFLY-4862 URL: https://issues.jboss.org/browse/WFLY-4862 Project: WildFly Issue Type: Enhancement Components: Domain Management, Test Suite Reporter: Tomaz Cerar Assignee: Tomaz Cerar We should be able to automate testing to all EAP6.2+ as much as possible. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4861) Unable to establish HTTP/2 connection via plain http (non https)

by Radim Hatlapatka (JIRA)

[ https://issues.jboss.org/browse/WFLY-4861?page=com.atlassian.jira.plugin.... ] Radim Hatlapatka updated WFLY-4861: ----------------------------------- Affects Version/s: 10.0.0.Alpha4 > Unable to establish HTTP/2 connection via plain http (non https) > ---------------------------------------------------------------- > > Key: WFLY-4861 > URL: https://issues.jboss.org/browse/WFLY-4861 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Alpha4 > Reporter: Radim Hatlapatka > Assignee: Stuart Douglas > Priority: Blocker > > HTTP/2 doesn't work over plain http (non-https) even when {{http-listener}}'s {{enable-http2}} option is set to {{true}}, see [1]. > I am using Http2 client from netty for trying whether it is possible to establish HHTP/2 connection via upgrade. > [1] > {code:xml} > <server name="default-server"> > <http-listener name="default" socket-binding="http" enable-http2="true" redirect-socket="https"/> > <https-listener name="https" socket-binding="https" security-realm="https" enable-http2="true"/> > <host name="default-host" alias="localhost"> > <location name="/" handler="welcome-content"/> > <filter-ref name="server-header"/> > <filter-ref name="x-powered-by-header"/> > </host> > </server> > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4861) Unable to establish HTTP/2 connection via plain http (non https)

by Radim Hatlapatka (JIRA)

Radim Hatlapatka created WFLY-4861: -------------------------------------- Summary: Unable to establish HTTP/2 connection via plain http (non https) Key: WFLY-4861 URL: https://issues.jboss.org/browse/WFLY-4861 Project: WildFly Issue Type: Bug Components: Web (Undertow) Reporter: Radim Hatlapatka Assignee: Stuart Douglas Priority: Blocker HTTP/2 doesn't work over plain http (non-https) even when {{http-listener}}'s {{enable-http2}} option is set to {{true}}, see [1]. I am using Http2 client from netty for trying whether it is possible to establish HHTP/2 connection via upgrade. [1] {code:xml} <server name="default-server"> <http-listener name="default" socket-binding="http" enable-http2="true" redirect-socket="https"/> <https-listener name="https" socket-binding="https" security-realm="https" enable-http2="true"/> <host name="default-host" alias="localhost"> <location name="/" handler="welcome-content"/> <filter-ref name="server-header"/> <filter-ref name="x-powered-by-header"/> </host> </server> {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4584) Use Apache ActiveMQ Artemis as the messaging broker

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-4584?page=com.atlassian.jira.plugin.... ] Jeff Mesnil commented on WFLY-4584: ----------------------------------- [~gytis] thanks, I've opened a PR to fix the examples (tracked by WFLY-4860). > Use Apache ActiveMQ Artemis as the messaging broker > --------------------------------------------------- > > Key: WFLY-4584 > URL: https://issues.jboss.org/browse/WFLY-4584 > Project: WildFly > Issue Type: Task > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 10.0.0.Alpha4 > > > replace the current messaging subsystem (with HornetQ) with a new messaging-activemq subsystem (with ActiveMQ Artemis) -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4860) Update examples to use the messaging-activemq subsystem

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-4860?page=com.atlassian.jira.plugin.... ] Jeff Mesnil updated WFLY-4860: ------------------------------ Summary: Update examples to use the messaging-activemq subsystem (was: Update examples) > Update examples to use the messaging-activemq subsystem > ------------------------------------------------------- > > Key: WFLY-4860 > URL: https://issues.jboss.org/browse/WFLY-4860 > Project: WildFly > Issue Type: Sub-task > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 10.0.0.Alpha4 > > > Update all examples shipped with WildFly to use the messaging-activemq subsystem instead of the legacy messaging subsystem. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-789) Investigate possibilty of having EAP transformers tests run by default

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-789?page=com.atlassian.jira.plugin... ] Tomaz Cerar updated WFCORE-789: ------------------------------- Fix Version/s: 2.0.0.Alpha6 > Investigate possibilty of having EAP transformers tests run by default > ---------------------------------------------------------------------- > > Key: WFCORE-789 > URL: https://issues.jboss.org/browse/WFCORE-789 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management, Test Suite > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 2.0.0.Alpha6 > > > We now need access to RH internal network to access maven artifacts needed for testing with legacy modules given that now publish most of EAP artifacts in enterprise repo, it should be possible to use that. > repo details: https://access.redhat.com/maven-repository -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4853) Provide two cluster test case for EJBClient

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/WFLY-4853?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz updated WFLY-4853: -------------------------------------- Description: The Wildfly test suite is missing a test case for testing EJBClient interactions over two clusters, which does exist in the EAP test cycle. This test case aims to duplicate that multi-node SmartFrog test in the Wildfly testsuite so that errors are identified early. The test setup: - two clusters {noformat} ejb-forwarder = {node0, node1} ejb={node3, node4} {noformat} where each node of cluster ejb-forwarder has a remote outbound connection to node3 - a forwarding SFSB deployment on cluster ejb-forwarder, which forwards invocations to cluster ejb - a non-forwarding deployment on cluster ejb - a client which makes invocations on the clustered deployment on ejb-forwarder every 10 ms The test execution: - once the servers and deployments have been deployed, each server is shut down and then restarted in turn, at which time the test ends. The expected behaviour: - at least 90% of client invocations will complete without exception - test client invocations on ejb-forwarder will fail over from node0 to node1 (or vice versa, depending on which node of cluster ejb-forwarder is down) - server-client invocations on ejb will fail-over from node3 to node 4 (or vice versa depending on which node of cluster ejb is down) The invocation transaction attribute set up: - invocations from the client to ejb-forwarder are not in transaction scope - invocations from ejb-forwarder to ejb are in transaction scope with attribute REQUIRED This allows exercising invocations from a managed transaction context, which uncovered a number of issues... was: The Wildfly test suite is missing a test case for testing EJBClient interactions over two clusters, which does exist in the EAP test cycle. The test setup: - two clusters {noformat} ejb-forwarder = {node0, node1} ejb={node3, node4} {noformat} where each node of cluster ejb-forwarder has a remote outbound connection to node3 - a forwarding SFSB deployment on cluster ejb-forwarder, which forwards invocations to cluster ejb - a non-forwarding deployment on cluster ejb - a client which makes invocations on the clustered deployment on ejb-forwarder every 10 ms The test execution: - once the servers and deployments have been deployed, each server is shut down and then restarted in turn, at which time the test ends. The expected behaviour: - at least 90% of client invocations will complete without exception - test client invocations on ejb-forwarder will fail over from node0 to node1 (or vice versa, depending on which node of cluster ejb-forwarder is down) - server-client invocations on ejb will fail-over from node3 to node 4 (or vice versa depending on which node of cluster ejb is down) The invocation transaction attribute set up: - invocations from the client to ejb-forwarder are not in transaction scope - invocations from ejb-forwarder to ejb are in transaction scope with attribute REQUIRED This allows exercising invocations from a managed transaction context, which uncovered a number of issues... > Provide two cluster test case for EJBClient > ------------------------------------------- > > Key: WFLY-4853 > URL: https://issues.jboss.org/browse/WFLY-4853 > Project: WildFly > Issue Type: Feature Request > Components: Test Suite > Affects Versions: 10.0.0.Alpha4 > Reporter: Richard Achmatowicz > Assignee: Richard Achmatowicz > > The Wildfly test suite is missing a test case for testing EJBClient interactions over two clusters, which does exist in the EAP test cycle. This test case aims to duplicate that multi-node SmartFrog test in the Wildfly testsuite so that errors are identified early. > The test setup: > - two clusters > {noformat} > ejb-forwarder = {node0, node1} > ejb={node3, node4} > {noformat} > where each node of cluster ejb-forwarder has a remote outbound connection to node3 > - a forwarding SFSB deployment on cluster ejb-forwarder, which forwards invocations to cluster ejb > - a non-forwarding deployment on cluster ejb > - a client which makes invocations on the clustered deployment on ejb-forwarder every 10 ms > The test execution: > - once the servers and deployments have been deployed, each server is shut down and then restarted in turn, at which time the test ends. > The expected behaviour: > - at least 90% of client invocations will complete without exception > - test client invocations on ejb-forwarder will fail over from node0 to node1 (or vice versa, depending on which node of cluster ejb-forwarder is down) > - server-client invocations on ejb will fail-over from node3 to node 4 (or vice versa depending on which node of cluster ejb is down) > The invocation transaction attribute set up: > - invocations from the client to ejb-forwarder are not in transaction scope > - invocations from ejb-forwarder to ejb are in transaction scope with attribute REQUIRED > This allows exercising invocations from a managed transaction context, which uncovered a number of issues... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

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 2015