[JBoss JIRA] (WFLY-7059) elytron module.xml, unnecessary exclude
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7059?page=com.atlassian.jira.plugin.... ]
Martin Choma edited comment on WFLY-7059 at 9/6/16 7:58 AM:
------------------------------------------------------------
I didn't find package org/wildfly/wildfly/security/manager/_private , sorry for not mentioning that in description.
was (Author: mchoma):
I didn't find package org/wildfly/wildfly/security/manager/_private .
> elytron module.xml, unnecessary exclude
> ---------------------------------------
>
> Key: WFLY-7059
> URL: https://issues.jboss.org/browse/WFLY-7059
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
>
> in {noformat}./jboss-eap-7.1/modules/system/layers/base/org/wildfly/security/elytron/main/module.xml {noformat}
> there is {noformat} <exclude path="org/wildfly/wildfly/security/manager/_private"/>{noformat}, which is probably unnecessary.
> {noformat}
> <module xmlns="urn:jboss:module:1.3" name="org.wildfly.security.elytron">
> <exports>
> <exclude path="org/wildfly/security/_private"/>
> <exclude path="org/wildfly/wildfly/security/manager/_private"/>
> </exports>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-7059) elytron module.xml, unnecessary exclude
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7059?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-7059:
----------------------------------------
Looks like a typo - I will double check we exclude the correct ones.
> elytron module.xml, unnecessary exclude
> ---------------------------------------
>
> Key: WFLY-7059
> URL: https://issues.jboss.org/browse/WFLY-7059
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
>
> in {noformat}./jboss-eap-7.1/modules/system/layers/base/org/wildfly/security/elytron/main/module.xml {noformat}
> there is {noformat} <exclude path="org/wildfly/wildfly/security/manager/_private"/>{noformat}, which is probably unnecessary.
> {noformat}
> <module xmlns="urn:jboss:module:1.3" name="org.wildfly.security.elytron">
> <exports>
> <exclude path="org/wildfly/security/_private"/>
> <exclude path="org/wildfly/wildfly/security/manager/_private"/>
> </exports>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-7059) elytron module.xml, unnecessary exclude
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7059?page=com.atlassian.jira.plugin.... ]
Martin Choma commented on WFLY-7059:
------------------------------------
I didn't find package org/wildfly/wildfly/security/manager/_private .
> elytron module.xml, unnecessary exclude
> ---------------------------------------
>
> Key: WFLY-7059
> URL: https://issues.jboss.org/browse/WFLY-7059
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
>
> in {noformat}./jboss-eap-7.1/modules/system/layers/base/org/wildfly/security/elytron/main/module.xml {noformat}
> there is {noformat} <exclude path="org/wildfly/wildfly/security/manager/_private"/>{noformat}, which is probably unnecessary.
> {noformat}
> <module xmlns="urn:jboss:module:1.3" name="org.wildfly.security.elytron">
> <exports>
> <exclude path="org/wildfly/security/_private"/>
> <exclude path="org/wildfly/wildfly/security/manager/_private"/>
> </exports>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-7059) elytron module.xml, unnecessary exclude
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-7059?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-7059:
-----------------------------------
Why unnecessary? We don't want to expose those packages as API.
> elytron module.xml, unnecessary exclude
> ---------------------------------------
>
> Key: WFLY-7059
> URL: https://issues.jboss.org/browse/WFLY-7059
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
>
> in {noformat}./jboss-eap-7.1/modules/system/layers/base/org/wildfly/security/elytron/main/module.xml {noformat}
> there is {noformat} <exclude path="org/wildfly/wildfly/security/manager/_private"/>{noformat}, which is probably unnecessary.
> {noformat}
> <module xmlns="urn:jboss:module:1.3" name="org.wildfly.security.elytron">
> <exports>
> <exclude path="org/wildfly/security/_private"/>
> <exclude path="org/wildfly/wildfly/security/manager/_private"/>
> </exports>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-7018) Valid Wildfly 10.0.0.Final DataSource fails in Wildfly 10.1.0.Final
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/WFLY-7018?page=com.atlassian.jira.plugin.... ]
Stefano Maestri reassigned WFLY-7018:
-------------------------------------
Assignee: Lin Gao (was: Stefano Maestri)
This configuration is not valid because a connection property should be always needed w/ data source class.
It's related to JBJCA-1312 and, in fact, it duplicates JBJCA-1320.
Assigning to Lin (who was the assignee of both issues above) for a complete explanation of the new behaviour and, eventually, analysis of corner cases.
> Valid Wildfly 10.0.0.Final DataSource fails in Wildfly 10.1.0.Final
> -------------------------------------------------------------------
>
> Key: WFLY-7018
> URL: https://issues.jboss.org/browse/WFLY-7018
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 10.1.0.Final
> Reporter: Mark S
> Assignee: Lin Gao
>
> My current Wildfly 10.0.0.Final (Non-XA) Datasource configuration will not work for Wildfly 10.1.0.Final. See the "Steps to Reproduce" section.
> The stacktrace points to here:
> * https://source.jboss.org/browse/IronJacamar/adapters/src/main/java/org/jb...
> * https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.3.4.Final/a...
> h3. The work-around
> h3. Wildfly 10.1.0.Final Datasource configuration via CLI
> {code}
> # No parameter to set a connection property value.
> {code}
> h3. Wildfly 10.1.0.Final Datasource configuration via XML (standalone-full.xml)
> Note the addition of {{<connection-property name="databaseName">myapp</connection-property>}}
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:datasources:4.0">
> <datasources>
> <datasource jndi-name="java:/MY_APP_DS" pool-name="Postgres_MY_APP_DS">
> <connection-url>jdbc:postgresql://localhost:5432/myapp</connection-url>
> <connection-property name="databaseName">myapp</connection-property>
> <driver>postgres</driver>
> <security>
> <user-name>myapp</user-name>
> <password>myapp</password>
> </security>
> <validation>
> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/>
> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/>
> </validation>
> </datasource>
> <drivers>
> <driver name="postgres" module="org.postgres">
> <driver-class>org.postgresql.Driver</driver-class>
> <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
> <datasource-class>org.postgresql.ds.PGSimpleDataSource</datasource-class>
> </driver>
> </drivers>
> </datasources>
> </subsystem>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JASSIST-263) ClassPool cannot read generated classes
by Paul Pogonyshev (JIRA)
Paul Pogonyshev created JASSIST-263:
---------------------------------------
Summary: ClassPool cannot read generated classes
Key: JASSIST-263
URL: https://issues.jboss.org/browse/JASSIST-263
Project: Javassist
Issue Type: Bug
Affects Versions: 3.20.0-GA
Reporter: Paul Pogonyshev
Assignee: Shigeru Chiba
Attachments: JavassistBug.java
ClassPool.get() cannot retrieve classes that are in turn generated at runtime. For example, if I try to define at runtime two classes, one of which extends another, the base will not be found, even though it can be retrieved just fine from my class loader. See the attached example.
As far as I could trace it, the issue comes from ClassPoolTail.find() returning a null URL for the class. This is understandable, since class definition doesn't exist as a file --- it is generated at runtime. However, ClassPool.get() should still succeed for classes that have no URL, yet can be found through its ClassLoader.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBJCA-1329) No error message on concurrent processing of the same inflow transaction
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1329?page=com.atlassian.jira.plugin... ]
Stefano Maestri commented on JBJCA-1329:
----------------------------------------
I'll run TCK and I'll add a test case too updating PR
> No error message on concurrent processing of the same inflow transaction
> ------------------------------------------------------------------------
>
> Key: JBJCA-1329
> URL: https://issues.jboss.org/browse/JBJCA-1329
> Project: IronJacamar
> Issue Type: Bug
> Components: Core
> Affects Versions: WildFly/IronJacamar 1.3.4.Final
> Reporter: Ondra Chaloupka
> Assignee: Stefano Maestri
> Attachments: JcaInflowTransactionTestCase_multipleWorkSharedXidInBunch_jta_server.log
>
>
> I experience losing messages when they are received with the same xid when messages are received in parallel. This means case that prior message is not yet fully processed when meanwhile new message is promoted for being processed.
> This is the scenario which behaves wrong by my view
> * EIS passes a message with xid1 to RAR to be processed
> * first message is passed as work to be process (stays in progress)
> * EIS passes a second message with xid1 to RAR to be processed
> * the second message is forgotten. It will never reach a {{MessageListner}}
> ** no error is returned or shown in log
> Compared following scenario passes without a problem.
> * EIS passes a message with xid1 to RAR to be processed
> * first message is fully processed with {{MessageListner}} (it reaches the end of the _onMessage_ method)
> * EIS passes a second message with xid1 to RAR to be processed
> * second message is processed by {{MessageListener}}
> From logging I can see that work was cancelled [2] by call of WorkWrapper [1]. But any information is forgotten. There is no error message in the log and there is wrong type and listnener methods called ({{javax.resource.spi.work.WorkListener}} by {{workCompleted}} with work type defined with status 4) for such messages.
> If I do understand right the jca specification says that {{WorkCompletedException}} needs to be shown[3].
> [1] https://github.com/ironjacamar/ironjacamar/blob/1.3/core/src/main/java/or...
> [2]
> {code}
> 2016-08-25 09:28:32,688 TRACE [org.jboss.jca.core.workmanager.WorkWrapper] (default-threads - 4) Cancel work: WorkWrapper@1755d562[workManger=org.jboss.as.connector.services.workmanager.NamedWorkManager(a)dcb0b17[id=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceAdapter-default name=default specCompliant=true shortRunningExecutor=org.jboss.jca.core.workmanager.StatisticsExecutorImpl@5c446e25 longRunningExecutor=org.jboss.jca.core.workmanager.StatisticsExecutorImpl@170ccc4f xaTerminator=org.jboss.jca.core.tx.jbossts.XATerminatorImpl@57da418e validatedWork=[org.jboss.as.test.jbossts.crashrec.jca.rar.TxnWork, org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit] callbackSecurity=null securityIntegration=org.jboss.jca.core.security.picketbox.PicketBoxSecurityIntegration@78ad9dc3 resourceAdapter=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceAdapter@fc1a5071 shutdown=false activeWorkWrappers=[WorkWrapper@5715513d] statistics=WorkManagerStatistics@71bdb84[active=1 successful=6 failed=0 doWorkAccepted=0 doWorkRejected=0 scheduleWorkAccepted=6 scheduleWorkRejected=0 startWorkAccepted=0 startWorkRejected=0]] work=org.jboss.as.test.jbossts.crashrec.jca.rar.TxnWork@241d1e13 xid=formatId=4660 gtrid(64)={0x7f00000100000000010000002a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000} bqual(64)={0x7f00000100000000010000002a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000} txTimeout=-1 workListener=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceWorkListner@40b572b1 workContexts=null exception=javax.resource.spi.work.WorkCompletedException: ARJUNA016068: Work already active!, error code: 2]
> {code}
> [3]
> {quote}
> The application server must reject Work submissions for a transaction whosecompletion is in-progress, with a WorkCompletedException set to the errorcode WorkException.TX_CONCURRENT_WORK_DISALLOWED.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1767) Exception on tab completion when adding new JGroups stack
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1767?page=com.atlassian.jira.plugi... ]
Alexey Loubyansky updated WFCORE-1767:
--------------------------------------
Description:
I just happened to catch the following exception:
{noformat}
[standalone@localhost:9990 /] /subsystem=jgroups/stack=anothertcp:add(transport={type=TCP,socket-binding=jgroups-tcp},protocols=[{Exception in thread "Aesh Process Loop 1561063579" java.lang.IllegalArgumentException
at org.jboss.dmr.ModelValue.asType(ModelValue.java:147)
at org.jboss.dmr.ModelNode.asType(ModelNode.java:321)
at org.jboss.as.cli.impl.ValueTypeCompleter$ComplexInstance.isCompliantType(ValueTypeCompleter.java:239)
at org.jboss.as.cli.impl.ValueTypeCompleter$Instance.getType(ValueTypeCompleter.java:103)
at org.jboss.as.cli.impl.ValueTypeCompleter$ValueTypeCallbackHandler.getCandidates(ValueTypeCompleter.java:445)
at org.jboss.as.cli.impl.ValueTypeCompleter.complete(ValueTypeCompleter.java:332)
at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:254)
at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:74)
at org.jboss.as.cli.CommandCompleter.doComplete(CommandCompleter.java:134)
at org.jboss.as.cli.CommandCompleter.complete(CommandCompleter.java:63)
at org.jboss.as.cli.impl.Console$Factory$1$1.complete(Console.java:143)
at org.jboss.aesh.console.AeshCompletionHandler.complete(AeshCompletionHandler.java:155)
at org.jboss.aesh.console.AeshInputProcessor.complete(AeshInputProcessor.java:423)
at org.jboss.aesh.console.AeshInputProcessor.parseOperation(AeshInputProcessor.java:165)
at org.jboss.aesh.console.Console.processInternalOperation(Console.java:773)
at org.jboss.aesh.console.Console.execute(Console.java:733)
at org.jboss.aesh.console.Console.access$900(Console.java:73)
at org.jboss.aesh.console.Console$6.run(Console.java:642)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}
when double tapping tab on the following:
{noformat}
[standalone@localhost:9990 /] /subsystem=jgroups/stack=anothertcp:add(transport={type=TCP,socket-binding=jgroups-tcp},protocols=[{
{noformat}
When trying a second time, it popped up again, so it is likely reproducible. Note that the server was started with:
{code}
./standalone -c standalone-ha.xml
{code}
The exception killed the CLI.
was:
I just happened to catch the following exception:
{noformat}
Exception in thread "Aesh Process Loop 1360657223" java.lang.IllegalArgumentException
at org.jboss.dmr.ModelValue.asType(ModelValue.java:147)
at org.jboss.dmr.ModelNode.asType(ModelNode.java:321)
at org.jboss.as.cli.impl.ValueTypeCompleter$ComplexInstance.isCompliantType(ValueTypeCompleter.java:236)
at org.jboss.as.cli.impl.ValueTypeCompleter$Instance.getType(ValueTypeCompleter.java:100)
at org.jboss.as.cli.impl.ValueTypeCompleter$ValueTypeCallbackHandler.getCandidates(ValueTypeCompleter.java:414)
at org.jboss.as.cli.impl.ValueTypeCompleter.complete(ValueTypeCompleter.java:323)
at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:254)
at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:74)
at org.jboss.as.cli.CommandCompleter.doComplete(CommandCompleter.java:134)
at org.jboss.as.cli.CommandCompleter.complete(CommandCompleter.java:63)
at org.jboss.as.cli.impl.Console$Factory$1$1.complete(Console.java:143)
at org.jboss.aesh.console.AeshCompletionHandler.complete(AeshCompletionHandler.java:150)
at org.jboss.aesh.console.AeshInputProcessor.complete(AeshInputProcessor.java:420)
at org.jboss.aesh.console.AeshInputProcessor.parseOperation(AeshInputProcessor.java:165)
at org.jboss.aesh.console.Console.processInternalOperation(Console.java:767)
at org.jboss.aesh.console.Console.execute(Console.java:727)
at org.jboss.aesh.console.Console.access$900(Console.java:73)
at org.jboss.aesh.console.Console$6.run(Console.java:636)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}
when double tapping tab on the following:
{noformat}
[standalone@localhost:9990 /] /subsystem=jgroups/stack=anothertcp:add(transport={type=TCP,socket-binding=jgroups-tcp},protocols=[{
{noformat}
When trying a second time, it popped up again, so it is likely reproducible. Note that EAP was started with:
{code}
./standalone -c standalone-ha.xml
{code}
and the EAP was in a different directory than the {{jboss-cli.sh}}, though I don't think that should matter.
* EAP: $MYDIR/jboss-eap-7.1.0.DR3-playground/bin/standalone.sh
* jboss-cli: $MYDIR/jboss-eap-7.1.0.DR3-clean/bin/jboss-cli.sh
The exception killed the CLI.
> Exception on tab completion when adding new JGroups stack
> ---------------------------------------------------------
>
> Key: WFCORE-1767
> URL: https://issues.jboss.org/browse/WFCORE-1767
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Alexey Loubyansky
> Assignee: Alexey Loubyansky
>
> I just happened to catch the following exception:
> {noformat}
> [standalone@localhost:9990 /] /subsystem=jgroups/stack=anothertcp:add(transport={type=TCP,socket-binding=jgroups-tcp},protocols=[{Exception in thread "Aesh Process Loop 1561063579" java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.asType(ModelValue.java:147)
> at org.jboss.dmr.ModelNode.asType(ModelNode.java:321)
> at org.jboss.as.cli.impl.ValueTypeCompleter$ComplexInstance.isCompliantType(ValueTypeCompleter.java:239)
> at org.jboss.as.cli.impl.ValueTypeCompleter$Instance.getType(ValueTypeCompleter.java:103)
> at org.jboss.as.cli.impl.ValueTypeCompleter$ValueTypeCallbackHandler.getCandidates(ValueTypeCompleter.java:445)
> at org.jboss.as.cli.impl.ValueTypeCompleter.complete(ValueTypeCompleter.java:332)
> at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:254)
> at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:74)
> at org.jboss.as.cli.CommandCompleter.doComplete(CommandCompleter.java:134)
> at org.jboss.as.cli.CommandCompleter.complete(CommandCompleter.java:63)
> at org.jboss.as.cli.impl.Console$Factory$1$1.complete(Console.java:143)
> at org.jboss.aesh.console.AeshCompletionHandler.complete(AeshCompletionHandler.java:155)
> at org.jboss.aesh.console.AeshInputProcessor.complete(AeshInputProcessor.java:423)
> at org.jboss.aesh.console.AeshInputProcessor.parseOperation(AeshInputProcessor.java:165)
> at org.jboss.aesh.console.Console.processInternalOperation(Console.java:773)
> at org.jboss.aesh.console.Console.execute(Console.java:733)
> at org.jboss.aesh.console.Console.access$900(Console.java:73)
> at org.jboss.aesh.console.Console$6.run(Console.java:642)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> when double tapping tab on the following:
> {noformat}
> [standalone@localhost:9990 /] /subsystem=jgroups/stack=anothertcp:add(transport={type=TCP,socket-binding=jgroups-tcp},protocols=[{
> {noformat}
> When trying a second time, it popped up again, so it is likely reproducible. Note that the server was started with:
> {code}
> ./standalone -c standalone-ha.xml
> {code}
> The exception killed the CLI.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months