January 2009 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: MultiThreadFailoverTest removed on build.xml

by clebert.suconic＠jboss.com

"clebert.suconic(a)jboss.com" wrote : Can't we make use getNumIterations()=1 on those MultiThreadFailoverTest when as part of the testsuite, and use a bigger value under stress or timing? I have already done it. Feel free to increase the NumIterations if you don't like it... but I think we should let the tests run faster before our checkouts, and let Hudson run the stress tests. also... we want to execute stress on hudson? As part of the hourly build or should we create another build running less frequently? It used to be part of hudson-tests, but I guess Tim removed them. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203836#4203836 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4203836

17 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Security services deployer for the MC

by david.lloyd＠jboss.com

I've made another deployer. The purpose of this deployer is to support the injection of security-related entities (Ciphers, SecureRandoms, MessageDigests etc). It lives in the sandbox here: http://anonsvn.jboss.org/repos/sandbox/david.lloyd/jboss-securityservice/... To use it in a deployment, you'd do something like this (example taken from the XNIO SSH implementation in development): | <security-service xmlns="urn:jboss:security-service:1.0"> | |  | | <secure-random name="SshSecureRandom" algorithm="SHA1PRNG"/> | | <diffie-hellman-parameter-spec name="OakleyGroup2"> | <generator value="2"/> | <prime radix="16"> | FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 | 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD | EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 | E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED | EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 | FFFFFFFF FFFFFFFF | </prime> | </diffie-hellman-parameter-spec> | | <diffie-hellman-parameter-spec name="OakleyGroup14"> | <generator value="2"/> | <prime radix="16"> | FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 | 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD | EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 | E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED | EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D | C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F | 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D | 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B | E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 | DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510 | 15728E5A 8AACAA68 FFFFFFFF FFFFFFFF | </prime> | </diffie-hellman-parameter-spec> | | <key-factory kind="factory" name="DHKeyFactory" algorithm="DiffieHellman"/> | | <key-agreement kind="factory" name="DHKeyAgreement" algorithm="DiffieHellman"/> | | <key-pair-generator kind="factory" name="DHKeyPairGenerator" algorithm="DiffieHellman"/> | | <message-digest kind="factory" name="DHSHA1Digest" algorithm="SHA-1"/> | |  | | <mac kind="factory" name="SshMac-hmac-sha1" algorithm="HmacSHA1"/> | | <mac kind="factory" name="SshMac-hmac-sha1-96" algorithm="HmacSHA1" truncate-length="96"/> | | <mac kind="factory" name="SshMac-hmac-md5" algorithm="HmacMD5"/> | | <mac kind="factory" name="SshMac-hmac-md5-96" algorithm="HmacMD5" truncate-length="96"/> | |  | | <cipher kind="factory" name="SshCipher-DESede" algorithm="DESede/CBC/NoPadding"/> | <cipher kind="factory" name="SshCipber-Blowfish" algorithm="Blowfish/CBC/NoPadding"/> | <cipher kind="factory" name="SshCipher-AES" algorithm="AES/CBC/NoPadding"/> | <cipher kind="factory" name="SshCipher-ARC4" algorithm="ARCFOUR/ECB/NoPadding"/> |  | | <cipher kind="factory" name="SshCipher-rsa" algorithm="RSA"/> | | </security-service> | Then these things are available for injection as standard POJOs, which decouples the data (like the large primes) and the configuration (the ciphers etc.) from the application. I can't really think of any way to justify sticking this in to the MC proper, but if anyone has any interest in any of this functionality, I'll be putting out a real release sometime before the XNIO SSH implementation is released... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203834#4203834 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4203834

17 years, 2 months

1
0
0 / 0

[Other JBoss Development Design] - Re: JBAS-6390, JBNAME-25, IPv6 support

by scott.stark＠jboss.org

All the tests passed, so I committed the change to the Branch_4_2. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203827#4203827 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4203827

17 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: MultiThreadFailoverTest removed on build.xml

by clebert.suconic＠jboss.com

Can't we make use getNumIterations()=1 on those MultiThreadFailoverTest when as part of the testsuite, and use a bigger value under stress or timing? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203822#4203822 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4203822

17 years, 2 months

1
0
0 / 0

[Design of JBoss ESB] - Soap-ui Template overwritten

by akfs

Simplified the Soap UI Template to identify the XML content Vs Element Content Allowed the XML injection of xml elements in Bare format e.g ABC Vs ABC We had made changes cause of Sqlserver 2005 hosted webservices which are bare format. https://jira.jboss.org/jira/browse/JBESB-2288 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203810#4203810 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4203810

17 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - MultiThreadFailoverTest removed on build.xml

by clebert.suconic＠jboss.com

Andy removed it from tests on commit r5590 (which was about a wildcard fix). so, I'm assuming it was an accident, and I'm removing the exclude clause. However I agree those tests are taking a long time to run. Maybe we should move them to timing? I'm adding two other tests that are doing the exact same thing with Paging and LargeMessage that will take even longer. LargeMessage and Paging are using real files, so they are supposed to take longer. I'm using less iterations.. but still a slow test. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203805#4203805 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4203805

17 years, 2 months

1
0
0 / 0

[Other JBoss Development Design] - Re: JBAS-6390, JBNAME-25, IPv6 support

by scott.stark＠jboss.org

I'm running the Branch_4_2 testsuite with the change. If it looks good I'll commit it, otherwise I'll hold it to the next release. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203765#4203765 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4203765

17 years, 2 months

1
0
0 / 0

[Design of JBoss Transaction Services] - JTA/JTS thread disassociation semantics

by jhalliday

With the local JTA impl, Transaction.[commit()|rollback()] don't do Thread disassociation, whilst TransactionManager.commit()|rollback()] do. Thus transactionmanager.begin(); transactionmanager.getTransaction().rollback(); transactionmanager.getStatus(); results in STATUS_ROLLEDBACK. Which is all well and good. Now substitute the JTS implementation and run the same code again. Any guesses? yup, that right: STATUS_NO_TRANSACTION. This is compliant with the JTA spec, which mandates thread disassociation for the TransactionManager but says nothing about Transaction. On the other hand its got the potential to break things. Indeed it does break the JCA, which has transaction context checking on the connections which is insufficiently robust to cope with this. So, do we change the JTS or just document it and move on? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203731#4203731 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4203731

17 years, 2 months

1
0
0 / 0

[Design of OSGi Integration] - Re: Current roadmap

by alesj

"alesj" wrote : | All I care about is OSGiMetaData class. | How you get there, is up to you. | This is what I had in when we discussed interface as metadata: - http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201192#4201192 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203713#4203713 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4203713

17 years, 2 months

1
0
0 / 0

[Design of OSGi Integration] - Re: Current roadmap

by alesj

All I care about is OSGiMetaData class. How you get there, is up to you. e.g. I "heard" you're gonna provide me a regexp based impl :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203712#4203712 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4203712

17 years, 2 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-dev-forums January 2009