[JBoss JIRA] (SASL-78) Invalid manifest section in jboss-sasl JAR
by Björn Kautler (JIRA)
Björn Kautler created SASL-78:
---------------------------------
Summary: Invalid manifest section in jboss-sasl JAR
Key: SASL-78
URL: https://issues.jboss.org/browse/SASL-78
Project: SASL Provider
Issue Type: Bug
Components: Build
Affects Versions: 1.0.5.Final, 1.0.4.Final
Reporter: Björn Kautler
Assignee: Darran Lofthouse
In the {{MANIFEST.MF}} of your {{jboss-sasl}} JAR you have a section {{Build-Information}}.
This violates that JAR specification.
A section in the manifest always refers to an entry in the JAR.
If you have sections in the manifest that do not refer to an entry in the JAR, it is assumed that the JAR was tampered with as there are entries missing that are referenced in the manifest.
Please either remove this section and include the entries in that secion in the main section which is according to the specification or include a file called {{Build-Information}} at the root of your JAR file. (You are still using jboss-parent 7, if you upgrade to 8 or newer, the problem will be gone)
----
In my concrete use-case this happened with other JARs with invalid manifest entries:
- I have signed those JARs and included them in a WebStart application
- I started the application with 8u102 32-bit {{javaws}}
- The JARs were downloaded and their entries signatures verified
- As there were entries in the manifest that are not present in the JAR, the file was not seen as completely signed with one signature, but Java remembered for each entry with which signature it was signed
This already is not too nice as it slows down the application as now for each class that gets loaded the signature has to be retrieved from a map and a list instead of having just one signature for all entries. But it gets much worse:
- The acutal application was to be executed with 8u102 64-bit, so the 32-bit one wrote its session information out into files, including the information about verified JARs and also their entries if needed, and starts the 64-bit JVM
- The 64-bit JVM loads this session information and thus does not have to do the time-consuming verification of the JARs all over again
- Unfortunately since 8u91 or so there is a bug in this session reading and writing algorithm, so that some of the entry names get crippled with additional characters in-between
- If now a class should be loaded that has such a crippled entry in the JAR-entry-to-signature map, the entry is not found and the class is considered as not signed which will block the application from further execution
Of course this second part is a bug in Java, but it would work flawlessly if the JARs would not have invalid sections.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFLY-5522) split artemis journal in its own module
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-5522?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated WFLY-5522:
--------------------------------
Component/s: (was: Transactions)
> split artemis journal in its own module
> ---------------------------------------
>
> Key: WFLY-5522
> URL: https://issues.jboss.org/browse/WFLY-5522
> Project: WildFly
> Issue Type: Enhancement
> Components: JMS
> Affects Versions: 10.0.0.CR2
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Minor
> Fix For: 11.0.0.Alpha1
>
>
> The org.jboss.jts is depending on the org.apache.activemq.artemis only for its journal functionality but get all the module dependencies (including messaging stuff) that is not used at all.
> The org.apache.activemq.artemis should be split with a separate module for its journal containing the journal jar + commons jar + native lib required for libAIO.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFLY-5574) org.wildfly.test.extension.rts InboundBridgeTestCase failing when transaction uses JTS
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-5574?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated WFLY-5574:
--------------------------------
Priority: Minor (was: Major)
> org.wildfly.test.extension.rts InboundBridgeTestCase failing when transaction uses JTS
> --------------------------------------------------------------------------------------
>
> Key: WFLY-5574
> URL: https://issues.jboss.org/browse/WFLY-5574
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite, Transactions
> Affects Versions: 10.0.0.CR3
> Reporter: Ondra Chaloupka
> Assignee: Gytis Trikleris
> Priority: Minor
> Fix For: 11.0.0.CR1
>
> Attachments: server.log
>
>
> There is failures in testcase org.wildfly.test.extension.rts.InboundBridgeTestCase when transaction uses JTS.
> Example of the failure
> {code}
> testCommit(org.wildfly.test.extension.rts.InboundBridgeTestCase) Time elapsed: 2.54 sec <<< FAILURE!
> java.lang.AssertionError: expected:<4> but was:<5>
> {code}
> The JBOSS_HOME distribution is change to transaction to be run with JTS: changing the {{docs/example/standalone-rts.xml}} to switch transactions parameter in iiop orb subsystem to {{full}} and adding {{jts}} element to transactions subsystem.
> When JBOSS_HOME is set then I've run the test in this way
> {{./integration-tests.sh clean install -Dts.noSmoke -Dts.rts -Djboss.dist=$JBOSS_HOME -Dtest=InboundBridgeTestCase}}
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (SECURITY-864) NameNotFoundException due to policyRegistration -- service jboss.naming.context.java.policyRegistration
by Martin Letenay (JIRA)
[ https://issues.jboss.org/browse/SECURITY-864?page=com.atlassian.jira.plug... ]
Martin Letenay commented on SECURITY-864:
-----------------------------------------
We have faced this problem after upgrade from JBoss 7.1 to Wildfly 9.
However, it is not only cosmetic but has severe negative performance implications.
Our application is EJB invocation intensive (invokes various EJB calls tens or hundreds times) and the performance after switch from 7.1 to 9.0 was 10 times slower !
>From the picketbox code inspection it seems the {{EJBAuthorizationHelper}} is trying to pass the {{PolicyRegistration}} instance into the underlying {{AuthorizationModuleDelegate}} during every EJB method invocation authorization phase.
However, the {{PolicyRegistration}} seems to be relevant only for XACML security configurations.
For plain Delegate or JACC authorization modules the {{PolicyRegistration}} is never used (and never created).
When e.g. JACC authorization is used, the (unsuccessful) JNDI lookup is performed for each and every (secured) EJB invocation and it results in unnecessary performance degradation.
We couldn't find anywhere in the documentation or the code where the PolicyRegistration si being put into the JNDI tree.
Since we're using custom LoginModule implementation, we have developed a temporary workaround that during initialization of JAAS LoginModule we check the existence of the {{java:/policyRegistration}} JNDI resource and if it is missing (actually always), we instantiate the {{org.jboss.security.plugins.JBossPolicyRegistration}} and bind it into JNDI tree.
After this workaround, the performance of our application went back to normal times as of JBoss 7.1, i.e. nearly 10 times faster.
It would be really nice to have this issue resolved properly (e.g. by storing negative JNDI lookup or registering the policy also for Delegate/JACC modules).
> NameNotFoundException due to policyRegistration -- service jboss.naming.context.java.policyRegistration
> -------------------------------------------------------------------------------------------------------
>
> Key: SECURITY-864
> URL: https://issues.jboss.org/browse/SECURITY-864
> Project: PicketBox
> Issue Type: Bug
> Components: PicketBox
> Reporter: Chao Wang
> Assignee: Stefan Guilhen
>
> "NameNotFoundException due to policyRegistration -- service jboss.naming.context.java.policyRegistration" is recorded in server.log during quickstart example run by changing log level:
> {noformat}
> <logger category="org.jboss.as.security">
> <level name="TRACE"/>
> </logger>
> <logger category="org.jboss.security">
> <level name="TRACE"/>
> </logger>
> {noformat}
> See detailed description in community discussion [#907134|https://developer.jboss.org/message/907134]
> I choose Jira component picketbox since the exception is titled as "PBOX000293: Exception caught: javax.naming.NameNotFoundException"
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFLY-6966) FatalError on Transaction Expired Entry Monitor during server shutdown
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-6966?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson closed WFLY-6966.
-------------------------------
Resolution: Rejected
I don't believe it is specified in WFLY that there will be no errors so I propose to close this unless it is reopened as a system wide policy
> FatalError on Transaction Expired Entry Monitor during server shutdown
> ----------------------------------------------------------------------
>
> Key: WFLY-6966
> URL: https://issues.jboss.org/browse/WFLY-6966
> Project: WildFly
> Issue Type: Enhancement
> Components: IIOP, Transactions
> Affects Versions: 10.1.0.CR1
> Reporter: Ondra Chaloupka
> Assignee: Tomasz Adamski
> Priority: Minor
>
> I do experience intermittent errors being shown in server log during server shutdown. It happens time to time for server configured to use {{JTS}} transaction that {{Transaction Expired Entry Monitor}} shows {{FatalError}} during container shutdown.
> I do experience this failure when jdbc object store is used.
> The shutdown log looks
> {code}
> 2016-08-16 07:07:46,900 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0028: Stopped deployment wmq.jmsra.rar (runtime-name: wmq.jmsra.rar) in 132ms
> 2016-08-16 07:07:46,914 INFO [org.wildfly.extension.messaging-activemq] (MSC service thread 1-2) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory
> 2016-08-16 07:07:46,914 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS]
> 2016-08-16 07:07:46,915 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA]
> 2016-08-16 07:07:46,921 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0019: Stopped Driver service with driver-name = h2
> 2016-08-16 07:07:46,924 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0028: Stopped deployment crashrecovery-jms-stateless-cmt.jar (runtime-name: crashrecovery-jms-stateless-cmt.jar) in 156ms
> 2016-08-16 07:07:46,947 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 16) WFLYCLINF0003: Stopped client-mappings cache from ejb container
> 2016-08-16 07:07:46,952 TRACE [com.arjuna.ats.arjuna] (Transaction Expired Entry Monitor) InputObjectState::InputObjectState(0:ffff7f000001:55f44a88:57b2ec0b:8, Recovery/FactoryContact)
> 2016-08-16 07:07:46,959 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 32) AMQ151003: resource adaptor stopped
> 2016-08-16 07:07:46,962 TRACE [com.arjuna.orbportability] (MSC service thread 1-4) ORB::shutdown ()
> 2016-08-16 07:07:46,962 TRACE [com.arjuna.orbportability] (MSC service thread 1-4) OA::destroyRootPOA ()
> 2016-08-16 07:07:46,962 TRACE [com.arjuna.orbportability] (MSC service thread 1-4) RootOA::shutdownObject (Servant)
> 2016-08-16 07:07:46,962 INFO [com.arjuna.ats.jbossatx] (MSC service thread 1-4) ARJUNA032018: Destroying TransactionManagerService
> 2016-08-16 07:07:46,963 INFO [com.arjuna.ats.jbossatx] (MSC service thread 1-4) ARJUNA032014: Stopping transaction recovery manager
> 2016-08-16 07:07:47,000 FATAL [com.arjuna.ats.jts] (Transaction Expired Entry Monitor) ARJUNA022006: The ORB has not been initialized yet
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) Exception in thread "Transaction Expired Entry Monitor" com.arjuna.ats.arjuna.exceptions.FatalError
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) at com.arjuna.ats.internal.jts.ORBManager.getORB(ORBManager.java:56)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) at com.arjuna.ats.internal.jts.recovery.contact.FactoryContactItem.restore_state(FactoryContactItem.java:264)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) at com.arjuna.ats.internal.jts.recovery.contact.FactoryContactItem.restoreMe(FactoryContactItem.java:320)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) at com.arjuna.ats.internal.jts.recovery.contact.FactoryContactItem.recreate(FactoryContactItem.java:100)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) at com.arjuna.ats.internal.jts.recovery.contact.ExpiredContactScanner.scan(ExpiredContactScanner.java:99)
> 2016-08-16 07:07:47,001 ERROR [stderr] (Transaction Expired Entry Monitor) at com.arjuna.ats.internal.arjuna.recovery.ExpiredEntryMonitor.run(ExpiredEntryMonitor.java:171)
> 2016-08-16 07:07:47,001 DEBUG [com.arjuna.ats.arjuna] (Listener:4712) Recovery listener existing com.arjuna.ats.internal.arjuna.recovery.WorkerService
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (MSC service thread 1-4) PeriodicRecovery: Mode <== TERMINATED
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (MSC service thread 1-4) PeriodicRecovery: shutdown waiting for scan to end
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: scan TERMINATED at phase 1
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: background thread Status <== INACTIVE
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: background thread exiting
> 2016-08-16 07:07:47,002 DEBUG [com.arjuna.ats.arjuna] (MSC service thread 1-4) PeriodicRecovery: shutdown scan wait complete
> 2016-08-16 07:07:47,003 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-4) WFLYJCA0010: Unbound data source [java:jboss/datasources/jdbc-store]
> 2016-08-16 07:07:47,006 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-4) WFLYJCA0019: Stopped Driver service with driver-name = module_postgresql-9.4.1207.jar
> 2016-08-16 07:07:47,012 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 32) AMQ221002: Apache ActiveMQ Artemis Message Broker version 1.1.0.SP16-redhat-1 [023d1e88-638c-11e6-927a-a180c25082cf] stopped
> 2016-08-16 07:07:47,012 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0008: Undertow HTTP listener default suspending
> 2016-08-16 07:07:47,013 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0007: Undertow HTTP listener default stopped, was bound to 127.0.0.1:8080
> 2016-08-16 07:07:47,013 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0004: Undertow 1.3.21.Final-redhat-1 stopping
> 2016-08-16 07:07:47,018 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: JBoss EAP 7.0.0.GA (WildFly Core 2.1.2.Final-redhat-1) stopped in 250ms
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFLY-1033) Enhance XTS AS7 configuration
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-1033?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson closed WFLY-1033.
-------------------------------
Resolution: Deferred
Although this would be possible we do not have customer/user requests for it
> Enhance XTS AS7 configuration
> -----------------------------
>
> Key: WFLY-1033
> URL: https://issues.jboss.org/browse/WFLY-1033
> Project: WildFly
> Issue Type: Enhancement
> Components: XTS
> Reporter: Andrew Dinn
> Assignee: Gytis Trikleris
> Priority: Minor
> Fix For: 11.0.0.Alpha1
>
>
> The current integration of XTS into AS7 as an AS7 extension allows optional configuration of the coordinator URL from the <xts/> element in the AS7 standalone configuration file. No other configuration options are currently supported.
> XTS ought to support more precise configuration. IN particular, it ought to be possible to enable or disable deployment of coordinator, participant or client services independently and also to choose whether to deploy WS-AT or WS-BA services or both. This requires selectively deploying only the required web service endpoints, selectively executing the required initialization routines and selectively loading the required high level service implementations and context factory implementations.
> The XTS implementation has already been factored so as to to support such discriminated bootstrapping. So this task only requires modifying the AS7 extension code to manage the relevant configuration information and install the relevant values into the XTS environment configuration beans before starting the XTS service.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFLY-1119) Assign an unique NodeID automatically
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-1119?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson closed WFLY-1119.
-------------------------------
Resolution: Rejected
> Assign an unique NodeID automatically
> -------------------------------------
>
> Key: WFLY-1119
> URL: https://issues.jboss.org/browse/WFLY-1119
> Project: WildFly
> Issue Type: Feature Request
> Components: Transactions
> Reporter: Clebert Suconic
> Priority: Optional
>
> It shouldn't be needed to assign the node-id manually IMO.
> You could store the node-id on a file and recover it for subsequent starts.
> On hornetQ for instance, we look for the nodeID on a file, if the file doesn't exist we assign a UUID and write to the file.
> In our previous experience UUID would be a best fit to assign the nodes since that was the only way we could guarantee unique IDs between the nodes.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months