June 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-1366) @DataSourceDefinition incorrectly requires other properties than name and class-name

by Eduardo Martins (JIRA)

[ https://issues.jboss.org/browse/WFLY-1366?page=com.atlassian.jira.plugin.... ] Eduardo Martins commented on WFLY-1366: --------------------------------------- The linked PR has the test I used to check the issue. > @DataSourceDefinition incorrectly requires other properties than name and class-name > ------------------------------------------------------------------------------------ > > Key: WFLY-1366 > URL: https://issues.jboss.org/browse/WFLY-1366 > Project: WildFly > Issue Type: Feature Request > Components: EE > Affects Versions: 8.0.0.Alpha1 > Reporter: arjan tijms > Assignee: Eduardo Martins > Labels: spec, validation > > When using the <data-source> element in e.g. web.xml or application.xml JBoss EAP 6.0.1/JBoss AS 7.1.3 does not accept a configuration without properties other than {{name}} and {{class-name}}. For instance: > {code:xml} > <data-source> > <name>java:app/myDS</name> > <class-name>com.example.MyDS</class-name> > </data-source> > {code} > With such configuration, the following exception is thrown: > {noformat} > Caused by: org.jboss.jca.common.api.validator.ValidateException: IJ010069: Missing required element xa-datasource-property in org.jboss.jca.common.metadata.ds.v11.XADataSourceImpl > at org.jboss.jca.common.metadata.ds.v10.XADataSourceImpl.validate(XADataSourceImpl.java:385) > at org.jboss.jca.common.metadata.ds.v10.XADataSourceImpl.<init>(XADataSourceImpl.java:116) > at org.jboss.jca.common.metadata.ds.v11.XADataSourceImpl.<init>(XADataSourceImpl.java:76) > at org.jboss.as.connector.subsystems.datasources.ModifiableXaDataSource.getUnModifiableInstance(ModifiableXaDataSource.java:373) > at org.jboss.as.connector.subsystems.datasources.XaDataSourceService.getDeployer(XaDataSourceService.java:70) > at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:116) > {noformat} > At the point where the exception is thrown, the code checks if there are any properties at all: > {code} > if (this.xaDataSourceProperty.isEmpty()) > throw new ValidateException( > bundle.requiredElementMissing( > Tag.XA_DATASOURCE_PROPERTY.getLocalName(), > this.getClass().getCanonicalName())); > {code} > I don't understand why this check is there. If I'm not mistaken the spec (e.g. JSR 250 section 2.13 and JSR 316 section EE.5.17) does not seem to mandate properties to be present and the corresponding annotation only requires {{name}} and {{className}} to be specified. > A workaround is to subclass the data source class and provide a dummy property, e.g. > {code:xml} > <data-source> > <name>java:app/myDS</name> > <class-name>com.example.MySubDS</class-name> > <property> > <name>dummy</name> > <value>dummy</value> > </property> > </data-source> > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1366) @DataSourceDefinition incorrectly requires other properties than name and class-name

by Eduardo Martins (JIRA)

[ https://issues.jboss.org/browse/WFLY-1366?page=com.atlassian.jira.plugin.... ] Eduardo Martins updated WFLY-1366: ---------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/7676 > @DataSourceDefinition incorrectly requires other properties than name and class-name > ------------------------------------------------------------------------------------ > > Key: WFLY-1366 > URL: https://issues.jboss.org/browse/WFLY-1366 > Project: WildFly > Issue Type: Feature Request > Components: EE > Affects Versions: 8.0.0.Alpha1 > Reporter: arjan tijms > Assignee: Eduardo Martins > Labels: spec, validation > > When using the <data-source> element in e.g. web.xml or application.xml JBoss EAP 6.0.1/JBoss AS 7.1.3 does not accept a configuration without properties other than {{name}} and {{class-name}}. For instance: > {code:xml} > <data-source> > <name>java:app/myDS</name> > <class-name>com.example.MyDS</class-name> > </data-source> > {code} > With such configuration, the following exception is thrown: > {noformat} > Caused by: org.jboss.jca.common.api.validator.ValidateException: IJ010069: Missing required element xa-datasource-property in org.jboss.jca.common.metadata.ds.v11.XADataSourceImpl > at org.jboss.jca.common.metadata.ds.v10.XADataSourceImpl.validate(XADataSourceImpl.java:385) > at org.jboss.jca.common.metadata.ds.v10.XADataSourceImpl.<init>(XADataSourceImpl.java:116) > at org.jboss.jca.common.metadata.ds.v11.XADataSourceImpl.<init>(XADataSourceImpl.java:76) > at org.jboss.as.connector.subsystems.datasources.ModifiableXaDataSource.getUnModifiableInstance(ModifiableXaDataSource.java:373) > at org.jboss.as.connector.subsystems.datasources.XaDataSourceService.getDeployer(XaDataSourceService.java:70) > at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:116) > {noformat} > At the point where the exception is thrown, the code checks if there are any properties at all: > {code} > if (this.xaDataSourceProperty.isEmpty()) > throw new ValidateException( > bundle.requiredElementMissing( > Tag.XA_DATASOURCE_PROPERTY.getLocalName(), > this.getClass().getCanonicalName())); > {code} > I don't understand why this check is there. If I'm not mistaken the spec (e.g. JSR 250 section 2.13 and JSR 316 section EE.5.17) does not seem to mandate properties to be present and the corresponding annotation only requires {{name}} and {{className}} to be specified. > A workaround is to subclass the data source class and provide a dummy property, e.g. > {code:xml} > <data-source> > <name>java:app/myDS</name> > <class-name>com.example.MySubDS</class-name> > <property> > <name>dummy</name> > <value>dummy</value> > </property> > </data-source> > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1366) @DataSourceDefinition incorrectly requires other properties than name and class-name

by Eduardo Martins (JIRA)

[ https://issues.jboss.org/browse/WFLY-1366?page=com.atlassian.jira.plugin.... ] Eduardo Martins resolved WFLY-1366. ----------------------------------- Resolution: Out of Date The issue is out of date, checked master and 8.2.0.Final, it probably was fixed when I reworked resource definitions. > @DataSourceDefinition incorrectly requires other properties than name and class-name > ------------------------------------------------------------------------------------ > > Key: WFLY-1366 > URL: https://issues.jboss.org/browse/WFLY-1366 > Project: WildFly > Issue Type: Feature Request > Components: EE > Affects Versions: 8.0.0.Alpha1 > Reporter: arjan tijms > Assignee: Eduardo Martins > Labels: spec, validation > > When using the <data-source> element in e.g. web.xml or application.xml JBoss EAP 6.0.1/JBoss AS 7.1.3 does not accept a configuration without properties other than {{name}} and {{class-name}}. For instance: > {code:xml} > <data-source> > <name>java:app/myDS</name> > <class-name>com.example.MyDS</class-name> > </data-source> > {code} > With such configuration, the following exception is thrown: > {noformat} > Caused by: org.jboss.jca.common.api.validator.ValidateException: IJ010069: Missing required element xa-datasource-property in org.jboss.jca.common.metadata.ds.v11.XADataSourceImpl > at org.jboss.jca.common.metadata.ds.v10.XADataSourceImpl.validate(XADataSourceImpl.java:385) > at org.jboss.jca.common.metadata.ds.v10.XADataSourceImpl.<init>(XADataSourceImpl.java:116) > at org.jboss.jca.common.metadata.ds.v11.XADataSourceImpl.<init>(XADataSourceImpl.java:76) > at org.jboss.as.connector.subsystems.datasources.ModifiableXaDataSource.getUnModifiableInstance(ModifiableXaDataSource.java:373) > at org.jboss.as.connector.subsystems.datasources.XaDataSourceService.getDeployer(XaDataSourceService.java:70) > at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:116) > {noformat} > At the point where the exception is thrown, the code checks if there are any properties at all: > {code} > if (this.xaDataSourceProperty.isEmpty()) > throw new ValidateException( > bundle.requiredElementMissing( > Tag.XA_DATASOURCE_PROPERTY.getLocalName(), > this.getClass().getCanonicalName())); > {code} > I don't understand why this check is there. If I'm not mistaken the spec (e.g. JSR 250 section 2.13 and JSR 316 section EE.5.17) does not seem to mandate properties to be present and the corresponding annotation only requires {{name}} and {{className}} to be specified. > A workaround is to subclass the data source class and provide a dummy property, e.g. > {code:xml} > <data-source> > <name>java:app/myDS</name> > <class-name>com.example.MySubDS</class-name> > <property> > <name>dummy</name> > <value>dummy</value> > </property> > </data-source> > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBEE-160) jboss-transaction-api OSGi bundle requiring optional packages

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/JBEE-160?page=com.atlassian.jira.plugin.s... ] Tomaz Cerar reassigned JBEE-160: -------------------------------- Assignee: Scott Marlow (was: Tomaz Cerar) > jboss-transaction-api OSGi bundle requiring optional packages > ------------------------------------------------------------- > > Key: JBEE-160 > URL: https://issues.jboss.org/browse/JBEE-160 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Reporter: Brett Meyer > Assignee: Scott Marlow > > The jboss-transaction-api_1.2_spec OSGi bundle requires the 'javax.enterprise.context'. Instead, that should be optional, right? cdi-api shouldn't be required to simply use jta. Thanks! -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-133) Complete i18n of exceptions and log messages

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-133?page=com.atlassian.jira.plugin.sy... ] Jan Kalina reassigned ELY-133: ------------------------------ Assignee: Jan Kalina > Complete i18n of exceptions and log messages > -------------------------------------------- > > Key: ELY-133 > URL: https://issues.jboss.org/browse/ELY-133 > Project: WildFly Elytron > Issue Type: Task > Reporter: David Lloyd > Assignee: Jan Kalina > Priority: Blocker > Fix For: 1.0.0.Final > > > All exceptions and relevant log messages must be i18nized. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4790) Getting DirectBuffer OOM when sending fragmented binary message to websocket endpoint

by Rostislav Svoboda (JIRA)

[ https://issues.jboss.org/browse/WFLY-4790?page=com.atlassian.jira.plugin.... ] Rostislav Svoboda commented on WFLY-4790: ----------------------------------------- [~swd847], could you please link Undertow JIRA or commit which fixes this ? > Getting DirectBuffer OOM when sending fragmented binary message to websocket endpoint > ------------------------------------------------------------------------------------- > > Key: WFLY-4790 > URL: https://issues.jboss.org/browse/WFLY-4790 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Alpha3 > Reporter: Radim Hatlapatka > Assignee: Stuart Douglas > Priority: Critical > Fix For: 10.0.0.Alpha5 > > > When sending fragmented binary message (message with message payload of length 4 * 2**20 (4M). Sent out in fragments of 64). The server throws {{java.lang.OutOfMemoryError: Direct buffer memory}} [1] > The memory for direct buffer by default depends on the size set by -Xmx, which is in EAP 7.0.0.DR4 by default set to -Xmx512m. Increasing it just increases the time before the limit is hit (it is enough to send those messages multiple times to hit the limit again). > I believe the issue is similar to the one for EAP 6.4: [https://bugzilla.redhat.com/show_bug.cgi?id=1223708] > [1] > {noformat} > 15:10:55,463 ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError: Direct buffer memory > at java.nio.Bits.reserveMemory(Bits.java:658) > at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:123) > at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311) > at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57) > at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55) > at org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:143) > at io.undertow.websockets.core.BufferedBinaryMessage$1.handleEvent(BufferedBinaryMessage.java:106) > at io.undertow.websockets.core.BufferedBinaryMessage$1.handleEvent(BufferedBinaryMessage.java:97) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at io.undertow.server.protocol.framed.AbstractFramedStreamSourceChannel$1.run(AbstractFramedStreamSourceChannel.java:264) > at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:560) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:462) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-783) Intermittent Disconnection from CLI After Reload

by Joe Wertz (JIRA)

[ https://issues.jboss.org/browse/WFCORE-783?page=com.atlassian.jira.plugin... ] Joe Wertz updated WFCORE-783: ----------------------------- Description: Race condition in server reload. The CLI only waits for a connection to be established and does not check the server status before continuing to execute commands. If the next command is executed before the server had completed the reload, failures occur. > Intermittent Disconnection from CLI After Reload > ------------------------------------------------- > > Key: WFCORE-783 > URL: https://issues.jboss.org/browse/WFCORE-783 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 2.0.0.Alpha5 > Reporter: Joe Wertz > Assignee: Joe Wertz > > Race condition in server reload. The CLI only waits for a connection to be established and does not check the server status before continuing to execute commands. If the next command is executed before the server had completed the reload, failures occur. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-783) Intermittent Disconnection from CLI After Reload

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-783?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated WFCORE-783: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1232933 > Intermittent Disconnection from CLI After Reload > ------------------------------------------------- > > Key: WFCORE-783 > URL: https://issues.jboss.org/browse/WFCORE-783 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 2.0.0.Alpha5 > Reporter: Joe Wertz > Assignee: Joe Wertz > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-783) Intermittent Disconnection from CLI After Reload

by Joe Wertz (JIRA)

Joe Wertz created WFCORE-783: -------------------------------- Summary: Intermittent Disconnection from CLI After Reload Key: WFCORE-783 URL: https://issues.jboss.org/browse/WFCORE-783 Project: WildFly Core Issue Type: Bug Components: CLI Affects Versions: 2.0.0.Alpha5 Reporter: Joe Wertz Assignee: Joe Wertz -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4724) Port SingletonTunnelTestCase from EAP6 to WildFly

by Tomas Hofman (JIRA)

[ https://issues.jboss.org/browse/WFLY-4724?page=com.atlassian.jira.plugin.... ] Tomas Hofman updated WFLY-4724: ------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/7673 (was: https://github.com/wildfly/wildfly/pull/7582) > Port SingletonTunnelTestCase from EAP6 to WildFly > ------------------------------------------------- > > Key: WFLY-4724 > URL: https://issues.jboss.org/browse/WFLY-4724 > Project: WildFly > Issue Type: Feature Request > Components: Clustering, Test Suite > Reporter: Tomas Hofman > Assignee: Tomas Hofman > > The test case is simulating cluster split & merge and checking that only one provider of a singleton service is elected after merge. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 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 June 2015