[JBoss JIRA] (WFLY-1113) JBoss AS 7 doesn't appear to support container-managed security via web.xml and jboss-web.xml
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-1113?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse resolved WFLY-1113.
------------------------------------
Fix Version/s: 8.0.0.Alpha1
Resolution: Out of Date
> JBoss AS 7 doesn't appear to support container-managed security via web.xml and jboss-web.xml
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-1113
> URL: https://issues.jboss.org/browse/WFLY-1113
> Project: WildFly
> Issue Type: Feature Request
> Components: Documentation
> Environment: n/a
> Reporter: Craig Ringer
> Assignee: Darran Lofthouse
> Fix For: 8.0.0.Alpha1
>
>
> There's no documentation for container-managed security in JBoss AS 7, and the schema for the main jboss config files and jboss-web.xml don't suggest any configuration mechanisms for JAAS realms, principal-to-user/group mappings, etc.
> This is a significant limitation for apps porting from Glassfish 3, which expect to be able to access the current security principal from JNDI or inject it, and expect to be able to declare container-controlled access to particular URLs and different HTTP methods in web.xml.
> Documenting this limitation in AS 7.0.0 would be a big improvement and would save porting time and hassle. Implementing support in a future version would, of course, be ideal.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (WFLY-1272) Infinite loop when starting my ear in JBoss 7.2.0 with autodeploy
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-1272?page=com.atlassian.jira.plugin.... ]
Thomas Diesler updated WFLY-1272:
---------------------------------
Assignee: (was: Thomas Diesler)
Component/s: Server
(was: ConfigAdmin)
> Infinite loop when starting my ear in JBoss 7.2.0 with autodeploy
> -----------------------------------------------------------------
>
> Key: WFLY-1272
> URL: https://issues.jboss.org/browse/WFLY-1272
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Reporter: Emmanuel Hugonnet
>
> Hi,
> I have a quite complexe application which I'm trying to port form JBoss 6.1.0 to JBoss 7.2.0.
> The ear is exploded as well as the war it contains. I have activated the auto-deploy-exploded on the deployment scanner.
> I have no error messages only warnings but the startup goes into an infinite loop trying to deploy my application again and again.
> If I set the auto-deploy-exploded to false then I can deploy correctly.
> Maybe it is because my application takes some time to launch (having to load a bunch of data into cache on startup).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (WFLY-1272) Infinite loop when starting my ear in JBoss 7.2.0 with autodeploy
by Emmanuel Hugonnet (JIRA)
Emmanuel Hugonnet created WFLY-1272:
---------------------------------------
Summary: Infinite loop when starting my ear in JBoss 7.2.0 with autodeploy
Key: WFLY-1272
URL: https://issues.jboss.org/browse/WFLY-1272
Project: WildFly
Issue Type: Bug
Components: ConfigAdmin
Reporter: Emmanuel Hugonnet
Assignee: Thomas Diesler
Hi,
I have a quite complexe application which I'm trying to port form JBoss 6.1.0 to JBoss 7.2.0.
The ear is exploded as well as the war it contains. I have activated the auto-deploy-exploded on the deployment scanner.
I have no error messages only warnings but the startup goes into an infinite loop trying to deploy my application again and again.
If I set the auto-deploy-exploded to false then I can deploy correctly.
Maybe it is because my application takes some time to launch (having to load a bunch of data into cache on startup).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (WFLY-1271) Infinispan remote-store requires remote-servers but not marked as required in mgmt model
by Takayoshi Kimura (JIRA)
Takayoshi Kimura created WFLY-1271:
--------------------------------------
Summary: Infinispan remote-store requires remote-servers but not marked as required in mgmt model
Key: WFLY-1271
URL: https://issues.jboss.org/browse/WFLY-1271
Project: WildFly
Issue Type: Bug
Components: Clustering
Reporter: Takayoshi Kimura
Assignee: Paul Ferraro
Affect version is actually 8.0.0.Alpha1-SNAPSHOT (before 8.0.0.Alpha1, we don't have such selection).
Command remote-store=REMOTE_STORE:add fails with this exception:
{quote}
15:58:05,112 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014607: Failed to persist configuration change: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014675: Failed to marshal configuration
at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.<init>(AbstractFilePersistenceResource.java:50) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.<init>(ConfigurationFilePersistenceResource.java:45) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.persistence.BackupXmlConfigurationPersister.store(BackupXmlConfigurationPersister.java:80) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:522) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:178) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:359) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:228) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:513) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:499) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:321) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:228) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:223) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:235) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:124) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:148) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:97) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:114) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [jboss-as-protocol-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [jboss-as-protocol-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
Caused by: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014680: Failed to write configuration
at org.jboss.as.controller.persistence.AbstractConfigurationPersister.marshallAsXml(AbstractConfigurationPersister.java:123) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.<init>(AbstractFilePersistenceResource.java:43) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
... 22 more
Caused by: java.lang.IllegalArgumentException
at org.jboss.dmr.ModelValue.asList(ModelValue.java:128) [jboss-dmr-1.1.6.Final.jar:1.1.6.Final]
at org.jboss.dmr.ModelNode.asList(ModelNode.java:1205) [jboss-dmr-1.1.6.Final.jar:1.1.6.Final]
at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLWriter.processCommonCacheAttributesElements(InfinispanSubsystemXMLWriter.java:282)
at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLWriter.writeContent(InfinispanSubsystemXMLWriter.java:124)
at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLWriter.writeContent(InfinispanSubsystemXMLWriter.java:42)
at org.jboss.as.server.parsing.StandaloneXml.writeServerProfile(StandaloneXml.java:1191) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.server.parsing.StandaloneXml.writeContent(StandaloneXml.java:1108) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.server.parsing.StandaloneXml.writeContent(StandaloneXml.java:103) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.staxmapper.XMLMapperImpl.doDeparse(XMLMapperImpl.java:88) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
at org.jboss.staxmapper.XMLMapperImpl.deparseDocument(XMLMapperImpl.java:83) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
at org.jboss.as.controller.persistence.AbstractConfigurationPersister.marshallAsXml(AbstractConfigurationPersister.java:117) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
... 23 more
{quote}
Reproduce steps:
{quote}
[standalone@localhost:9999 /] /subsystem=infinispan/cache-container=web/replicated-cache=repl/file-store=FILE_STORE:remove
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
[standalone@localhost:9999 /] /subsystem=infinispan/cache-container=web/replicated-cache=repl/remote-store=REMOTE_STORE:add
{
"outcome" => "failed",
"failure-description" => "JBAS014677: Failed to persist configuration change: JBAS014675: Failed to marshal configuration",
"rolled-back" => true,
"response-headers" => {"process-state" => "reload-required"}
}
[standalone@localhost:9999 /] /subsystem=infinispan/cache-container=web/replicated-cache=repl/remote-store=REMOTE_STORE:add(remote-servers=[])
{
"outcome" => "success",
"response-headers" => {"process-state" => "reload-required"}
}
{quote}
In $JBOSS_HOME/docs/schema/jboss-as-infinispan_1_3.xsd, it looks like the remote-server is required as it's defined as minOccurs="1":
{quote}
<xs:element name="remote-server" type="tns:remote-server" minOccurs="1" maxOccurs="unbounded"/>
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (WFLY-786) NicInterfaceCriteriaUnitTestCase testBasic fails on a host configured with a dual IP stack
by Pavel Janousek (JIRA)
[ https://issues.jboss.org/browse/WFLY-786?page=com.atlassian.jira.plugin.s... ]
Pavel Janousek reassigned WFLY-786:
-----------------------------------
Assignee: Brian Stansberry (was: Ondrej Zizka)
Fix assignation of this issue to the author of TestCase.
> NicInterfaceCriteriaUnitTestCase testBasic fails on a host configured with a dual IP stack
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-786
> URL: https://issues.jboss.org/browse/WFLY-786
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 8.0.0.Alpha1
> Reporter: Michael Musgrove
> Assignee: Brian Stansberry
>
> This test fails when we run the test suite with the following IPv6 options:
> {noformat}
> -Djava.net.preferIPv4Stack=false -Djava.net.preferIPv6Addresses=true -Djboss.bind.address=[::1] -Djboss.bind.address.management=[::1] -Djboss.bind.address.unsecure=[::1]
> {noformat}
>
> It appears that the test is expecting an array containing one nic address but instead gets two (IPv4 and IPv6) addresses. The linked JBTM jira is where we initially reported the issue. Test output is:
> {noformat}
> Failed tests:
> testBasic(org.jboss.as.controller.interfaces.NicInterfaceCriteriaUnitTestCase): expected:<[/0:0:0:0:0:0:0:1%1]> but was:<[/0:0:0:0:0:0:0:1%1, /127.0.0.1]>
> testMultipleCriteria(org.jboss.as.controller.interfaces.NotInterfaceCriteriaUnitTestCase): expected:<{name:eth0 (eth0)=[/fe80:0:0:0:216:3eff:fe0e:a61c%2]}> but was:<{name:eth0 (eth0)=[/fe80:0:0:0:216:3eff:fe0e:a61c%2, /172.17.131.3]}>
> testMultipleCriteria(org.jboss.as.controller.interfaces.AnyInterfaceCriteriaUnitTestCase): expected:<{name:lo (lo)=[/0:0:0:0:0:0:0:1%1], name:eth0 (eth0)=[/fe80:0:0:0:216:3eff:fe0e:a61c%2]}> but was:<{name:lo (lo)=[/127.0.0.1, /0:0:0:0:0:0:0:1%1], name:eth0 (eth0)=[/fe80:0:0:0:216:3eff:fe0e:a61c%2, /172.17.131.3]}>
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (SECURITY-738) XACML DatabaseResourceAttributeLocator fails when used with Oracle 11g Driver
by Hisanobu Okuda (JIRA)
Hisanobu Okuda created SECURITY-738:
---------------------------------------
Summary: XACML DatabaseResourceAttributeLocator fails when used with Oracle 11g Driver
Key: SECURITY-738
URL: https://issues.jboss.org/browse/SECURITY-738
Project: PicketBox
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JBossXACML
Affects Versions: picketbox_xacml_2.0.8.Final
Environment: EAP 6.0.1
Reporter: Hisanobu Okuda
Assignee: Anil Saldhana
We are using the DatabaseResourceAttributeLocator in jboss-xacml 2.0.8.Final for fetching a policy attribute from an Oracle 11g database. The Oracle JDBC driver is ojdbc6 11.2.0.x. However, the locator fails with an SQLException. The complete stacktrace is attached, but the interesting part is the following:
{code}
Caused by: java.sql.SQLException: error occurred during batching: batch must be either executed or cleared
at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3435)
at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3493)
at oracle.jdbc.driver.OraclePreparedStatementWrapper.executeQuery(OraclePreparedStatementWrapper.java:1491)
at org.jboss.security.xacml.locators.attrib.DatabaseAttributeLocator.getColumnValue(DatabaseAttributeLocator.java:215)
... 48 more
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (WFLY-1235) Fix french translation of org.jboss.as.connector.logging.ConnectorLogger
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1235?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1235:
-----------------------------------------------
Brian Stansberry <brian.stansberry(a)redhat.com> made a comment on [bug 955859|https://bugzilla.redhat.com/show_bug.cgi?id=955859]
Fix the french translation of org.jboss.as.connector.logging.ConnectorLogger :
deployingCompliantJdbcDriver=D\u00E9ploiement du pilote compatible JDCB %s (version %d.%d)
deployingNonCompliantJdbcDriver=D\u00E9ploiement du pilote non compatible JDCB %s (version %d.%d)
Should say "JDBC" instead of "JDCB"
> Fix french translation of org.jboss.as.connector.logging.ConnectorLogger
> ------------------------------------------------------------------------
>
> Key: WFLY-1235
> URL: https://issues.jboss.org/browse/WFLY-1235
> Project: WildFly
> Issue Type: Task
> Components: Documentation
> Reporter: Dominique Jean-Prost
>
> Fix french translation of org.jboss.as.connector.logging.ConnectorLogger :
> deployingCompliantJdbcDriver=D\u00E9ploiement du pilote compatible JDCB %s (version %d.%d)
> deployingNonCompliantJdbcDriver=D\u00E9ploiement du pilote non compatible JDCB %s (version %d.%d)
> used JCDB instead of *JDBC*
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (WFLY-88) Recovery not fully triggered when distributed transaction falls down at prepare phase of 2PC
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-88?page=com.atlassian.jira.plugin.sy... ]
RH Bugzilla Integration commented on WFLY-88:
---------------------------------------------
Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 952746|https://bugzilla.redhat.com/show_bug.cgi?id=952746] from NEW to POST
> Recovery not fully triggered when distributed transaction falls down at prepare phase of 2PC
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-88
> URL: https://issues.jboss.org/browse/WFLY-88
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Remoting
> Reporter: Ivo Studensky
> Assignee: jaikiran pai
> Fix For: 8.0.0.Alpha1
>
> Attachments: logs_prepareHaltClient.tgz
>
>
> It looks like recovery process is not fully triggered on a distributed transaction when the transaction falls down at prepare phase of 2PC. In the new crash recovery tests over propagated transactions only one of two servers recovers from the crash, but the other keeps an unfinished tx in its tx log.
> It corresponds to prepareHaltClient and prepareHaltServer test methods of org.jboss.as.test.jbossts.crashrec.txpropagation.TxPropagationCrashRecoveryTestCase, see JBQA-2604 for general description of the new tests. The prepareHaltClient test crashes the server which initiated the transaction, while as the prepareHaltServer test crashes the second server.
> The tests are written against EAP6.x branch, so for reproducing this it is needed a built server from the 7.1 branch of AS7.
> Steps to reproduce.
> 1. git clone -b as7 git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-transactions.git
> 2. cd eap-tests-transactions
> 3. git checkout tx_propag_crashrec_tests
> 4a. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#prepareHaltClient -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT>
> or
> 4b. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#prepareHaltServer -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT>
> The logs of prepareHaltClient run attached to this jira.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months