[JBoss JIRA] (WFCORE-1776) CLI gui returns null for specific command with access-control parameter while console CLI returns valid result
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1776?page=com.atlassian.jira.plugi... ]
Alexey Loubyansky moved JBEAP-5946 to WFCORE-1776:
--------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1776 (was: JBEAP-5946)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: CLI
(was: CLI)
Affects Version/s: (was: 7.0.1.CR1)
(was: 7.1.0.DR4)
> CLI gui returns null for specific command with access-control parameter while console CLI returns valid result
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1776
> URL: https://issues.jboss.org/browse/WFCORE-1776
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Alexey Loubyansky
> Assignee: Alexey Loubyansky
>
> I tried to click through CLI GUI, particullary interested in webservices subsystem.
> I navigated through the tree into {{/subsystem=webservices/endpoint-config=*}}, right-click and chose {{ead-resource-description}}.
> It generated this command, but after executing through GUI, it returns null:
> {code}
> /subsystem=webservices/endpoint-config=*/:read-resource-description(recursive=false,access-control=none)
> null
> {code}
> The same command in console CLI return valid resut:
> {code:java}
> [standalone@localhost:9990 /] /subsystem=webservices/endpoint-config=*/:read-resource-description(recursive=false,access-control=none)
> {
> "outcome" => "success",
> "result" => [{
> "address" => [
> ("subsystem" => "webservices"),
> ("endpoint-config" => "*")
> ],
> "outcome" => "success",
> "result" => {
> "description" => "Webservice endpoint configuration",
> "attributes" => {},
> "operations" => undefined,
> "notifications" => undefined,
> "children" => {
> "pre-handler-chain" => {
> "description" => "Pre handler chain",
> "model-description" => undefined
> },
> "post-handler-chain" => {
> "description" => "Post handler chain",
> "model-description" => undefined
> },
> "property" => {
> "description" => "Configuration property",
> "model-description" => undefined
> }
> }
> }
> }]
> }
> {code}
> The problem seems to be related to the {{access-control=none}} parameter, because without it both GUI and console return the same valid result
> {code:java}
> /subsystem=webservices/endpoint-config=*/:read-resource-description(recursive=false)
> {
> "outcome" => "success",
> "result" => [{
> "address" => [
> ("subsystem" => "webservices"),
> ("endpoint-config" => "*")
> ],
> "outcome" => "success",
> "result" => {
> "description" => "Webservice endpoint configuration",
> "attributes" => {},
> "operations" => undefined,
> "notifications" => undefined,
> "children" => {
> "pre-handler-chain" => {
> "description" => "Pre handler chain",
> "model-description" => undefined
> },
> "post-handler-chain" => {
> "description" => "Post handler chain",
> "model-description" => undefined
> },
> "property" => {
> "description" => "Configuration property",
> "model-description" => undefined
> }
> }
> }
> }]
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JASSIST-263) ClassPool cannot read generated classes
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-263?page=com.atlassian.jira.plugi... ]
Shigeru Chiba commented on JASSIST-263:
---------------------------------------
ClassPool needs bytecode since a loaded class does not expose its bytecode although Java 9 seems to include a method to obtain the bytecode. Here the bytecode means a class file (= generated byte[] array).
> 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, 10 months
[JBoss JIRA] (WFLY-6127) Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-6127?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-6127:
------------------------------------
Thanks [~veselroger] for reporting the WFLY-7075 jira to add the suggested extension.
For applying the patch that you mention, for the org.jboss.as.jpa.container.ExtendedEntityManager.getSynchronizationType() to return the proper application specified SynchronizationType, could you please also create a tracking jira for that bug fix, which your comment correctly identifies as still unfixed after WFLY-6127 changes were applied. We need a separate jira for that bug fix because the changes for WFLY-6127 were already released in WildFly 10.1.0, so it would be confusing to reopen it. Thank you! -Scott
> Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6127
> URL: https://issues.jboss.org/browse/WFLY-6127
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 9.0.2.Final, 10.0.0.Final
> Reporter: Mazen Mahmoud
> Assignee: Scott Marlow
> Priority: Blocker
> Fix For: 10.1.0.CR1, 10.1.0.Final
>
> Attachments: server-log.txt
>
>
> SPEC: If a component is called and the JTA transaction is propagated into that component:
> If there is a persistence context of type SynchronizationType.UNSYNCHRONIZED
> associated with the JTA transaction and the target component specifies a persistence context of type SynchronizationType.SYNCHRONIZED, the IllegalStateException is thrown by the container
> We have a stateful session bean (SFB1) / PC: TRANSACTION/UNSYNCHRONIZED)
> stateful session bean (SFB2) / PC: TRANSACTION/SYNCHRONIZED)
> SFB1 method M1 (REQUIRED) calls SFB2 Method 2 (REQUIRED):
> PC is propagated from SFB1 to SFB2 without any exception.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-7083) Resource adapter subsystem configuration descriptions: wm-security
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7083?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev updated WFLY-7083:
--------------------------------
Affects Version/s: 10.1.0.Final
> Resource adapter subsystem configuration descriptions: wm-security
> ------------------------------------------------------------------
>
> Key: WFLY-7083
> URL: https://issues.jboss.org/browse/WFLY-7083
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 10.1.0.Final
> Reporter: Ilia Vassilev
> Assignee: Ilia Vassilev
> Priority: Trivial
>
> These descriptions of wm-security may want to be reviewed.
> * There is a typo in the resource description of {{wm-security}}:
> bq. Toggle on/off wm.security for this resource-adapter. In case of false all wm-security-* parameters are ignored, even thei defaults.
> * For {{wm-security-mapping-required}}, the description seems to refer to documentation sections:
> bq. Defines if a mapping is required for security credentials. A value of false means Case 1 as defined in section 16.4.3, and a value of true means Case 2 as defined in section 16.4.4.
> However these sections can me moved or removed, and the numbers will often change. I'm not even sure what content this refers to. We shouldn't hard-code documentation references.
> * Ending the description with a full stop is also missing on many descriptions.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-7083) Resource adapter subsystem configuration descriptions: wm-security
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7083?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev moved JBEAP-5945 to WFLY-7083:
--------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7083 (was: JBEAP-5945)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JCA
(was: JCA)
(was: User Experience)
Affects Version/s: (was: 7.0.0.GA)
> Resource adapter subsystem configuration descriptions: wm-security
> ------------------------------------------------------------------
>
> Key: WFLY-7083
> URL: https://issues.jboss.org/browse/WFLY-7083
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Reporter: Ilia Vassilev
> Assignee: Ilia Vassilev
> Priority: Trivial
>
> These descriptions of wm-security may want to be reviewed.
> * There is a typo in the resource description of {{wm-security}}:
> bq. Toggle on/off wm.security for this resource-adapter. In case of false all wm-security-* parameters are ignored, even thei defaults.
> * For {{wm-security-mapping-required}}, the description seems to refer to documentation sections:
> bq. Defines if a mapping is required for security credentials. A value of false means Case 1 as defined in section 16.4.3, and a value of true means Case 2 as defined in section 16.4.4.
> However these sections can me moved or removed, and the numbers will often change. I'm not even sure what content this refers to. We shouldn't hard-code documentation references.
> * Ending the description with a full stop is also missing on many descriptions.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (DROOLS-1276) KieContainer.newKieSession((String) null) should return the default ksession to be consistent with getKieSessionModel(null)
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1276?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet commented on DROOLS-1276:
------------------------------------------
Raisd priority of this one, because without a fix for this one, the kie optaplanner-execution-server can't handle kjar that use the default ksession (which is a common use case).
> KieContainer.newKieSession((String) null) should return the default ksession to be consistent with getKieSessionModel(null)
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1276
> URL: https://issues.jboss.org/browse/DROOLS-1276
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 6.5.0.CR1
> Reporter: Geoffrey De Smet
> Assignee: Mario Fusco
> Priority: Critical
>
> This works to get the default kieSession:
> {code}
> String ksessionName = null;
> // if ksessionName is null, then the default kieSession is used
> KieSessionModel kieSessionModel = kieContainer.getKieSessionModel(ksessionName);
> {code}
> But this doesn't work to get the default ksession:
> {code}
> String ksessionName = null;
> // Fails if ksessionName is null. Should return the default ksession instead.
> return kieContainer.newKieSession(ksessionName);
> {code}
> The above fails if ksessioName is null with this stacktrace:
> {code}
> java.lang.NullPointerException
> at java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1011)
> at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1006)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:692)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:652)
> at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirectorFactory.newKieSession(DroolsScoreDirectorFactory.java:129)
> {code}
> If no default ksession exists with argument null, a nice error message should be thrown.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (DROOLS-1276) KieContainer.newKieSession((String) null) should return the default ksession to be consistent with getKieSessionModel(null)
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1276?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet updated DROOLS-1276:
-------------------------------------
Priority: Critical (was: Major)
> KieContainer.newKieSession((String) null) should return the default ksession to be consistent with getKieSessionModel(null)
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1276
> URL: https://issues.jboss.org/browse/DROOLS-1276
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 6.5.0.CR1
> Reporter: Geoffrey De Smet
> Assignee: Mario Fusco
> Priority: Critical
>
> This works to get the default kieSession:
> {code}
> String ksessionName = null;
> // if ksessionName is null, then the default kieSession is used
> KieSessionModel kieSessionModel = kieContainer.getKieSessionModel(ksessionName);
> {code}
> But this doesn't work to get the default ksession:
> {code}
> String ksessionName = null;
> // Fails if ksessionName is null. Should return the default ksession instead.
> return kieContainer.newKieSession(ksessionName);
> {code}
> The above fails if ksessioName is null with this stacktrace:
> {code}
> java.lang.NullPointerException
> at java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1011)
> at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1006)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:692)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:652)
> at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirectorFactory.newKieSession(DroolsScoreDirectorFactory.java:129)
> {code}
> If no default ksession exists with argument null, a nice error message should be thrown.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1127) SocketBindingManagerImpl$UnnamedRegistryImpl is overly picky about unbound sockets
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1127?page=com.atlassian.jira.plugi... ]
Paul Ferraro commented on WFCORE-1127:
--------------------------------------
[~dan.berindei]
"JGroups prior to version 4.0 "fixes" this by always replacing the ManagedSocketFactory set by JChannelFactory.init() with its own DefaultSocketFactory in JChannel.startStack()."
That not the case in WF 10. This was corrected almost a year ago:
https://github.com/wildfly/wildfly/commit/ab5b4358aef108dfa8296b1f5df7888...
This exposed a number of issues with unbound sockets and the SocketBindingManager - all of which were fixed, such that WildFly 10.x uses the the provided ManagedSocketFactory w/JGroups 3.6.x without issue. Granted, I haven't tried this with JGroups 4 yet, but it seems to me that the infinispan-server fork of WildFly's jgroups subsystem is quite out of date.
> SocketBindingManagerImpl$UnnamedRegistryImpl is overly picky about unbound sockets
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-1127
> URL: https://issues.jboss.org/browse/WFCORE-1127
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.1.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 2.0.2.Final
>
>
> A failure like this isn't necessary:
> {code}
> 08:02:23,475 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.jgroups.channel.ee.connector: org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee.connector: java.lang.IllegalStateException
> at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:96)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> 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)
> Caused by: java.lang.IllegalStateException
> at org.jboss.as.network.SocketBindingManagerImpl$UnnamedRegistryImpl.unregisterBinding(SocketBindingManagerImpl.java:501)
> at org.jboss.as.network.ManagedDatagramSocketBinding.close(ManagedDatagramSocketBinding.java:73)
> at org.jboss.as.clustering.jgroups.ManagedSocketFactory.close(ManagedSocketFactory.java:148)
> at org.jgroups.protocols.UDP.closeUnicastSocket(UDP.java:577)
> at org.jgroups.protocols.UDP.destroySockets(UDP.java:429)
> at org.jgroups.protocols.UDP.start(UDP.java:274)
> at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:965)
> at org.jgroups.JChannel.startStack(JChannel.java:890)
> at org.jgroups.JChannel._preConnect(JChannel.java:553)
> at org.jgroups.JChannel.connect(JChannel.java:288)
> at org.jgroups.JChannel.connect(JChannel.java:279)
> at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:94)
> ... 5 more
> {code}
> If there's no socket address, it should just move on.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-7075) proposal (Extension): Adding ability of check testForMixedSynchronizationTypes by isJoinToTransaction (as current state of synchronization)
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-7075:
------------------------------------
Sounds good, I pasted my last comment mostly for me, so I wouldn't have to open the spec and find it, to review it again, while thinking about this issue. :)
> proposal (Extension): Adding ability of check testForMixedSynchronizationTypes by isJoinToTransaction (as current state of synchronization)
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7075
> URL: https://issues.jboss.org/browse/WFLY-7075
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Affects Versions: 10.1.0.Final
> Environment: *AppServer:* WildFly 10.1.0.Final
> *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar
> Reporter: Viacheslav Astapkovich
> Assignee: Scott Marlow
> Attachments: kitchensink-ear.rar
>
>
> As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution.
>
> *The obtained defect:*
> A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final.
> The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar)
> *FIX:*
> We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127
> Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e...
> _Changes_: The method getSynchronizationType returns declared synchronization type.
> *Consequences:*
> We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction.
> Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call.
> It requires a declaration of synchronize persistence context.
> We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans.
> However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check.
> *Our actions:*
> We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization).
> This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false.
> _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d...
> *Example for reproduction:*
> I modified quickstart example: [^kitchensink-ear.rar]
> MemberRepository begin Extended UNSYNCHRONIZED Persistence Context.
> MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED.
> MemberRepository also perform join Transaction.
> Questions from [~smarlow]:
> - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it.
> We decided to use Container-managed EntityManager, because
> - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components
> - The container makes our job
> We want to use the existing mechanism
> *In Addition:*
> Formally, this is out of JPA SPEC, but we have the following reasons:
> - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?".
> But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given.
> ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... )
> - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months