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

[JBoss Transactions Development] - proposal for Xid format change

by jhalliday

Xid creation is somewhat slow at present and misses the opportunity to encode some useful information. I propose some changes. Old version: gtrid = nodename.getBytes()+"#"+tx_uid.stringForm().getBytes(); bqual = new Uid().stringForm().getBytes(); Converting Uids to string form is expensive and should be avoided as we are just going to convert it straight back to binary anyhow. The only advantage of the string form is it makes Xid.toString easy. However, it's better to avoid the overhead on Xid creation and move it to Xid.toString instead i.e. decode the data back in to a Uid in toString. I was mulling over moving nodename from String to int for similar reasons, but I'm scrapping that idea in favor of just cleaning up the code so it uses a fixed charset - right now bad things happen if the encoding and decoding take place on systems with different default charset. The branch qualifier should be extended to encode the EIS ID of the XAResource the branch is being created for, if it's available. This will help in new versions of the server, where the JCA should supply a meaningful EIS ID (e.g. the JNDI name of the Datasource) so that Xids/XAResourceRecords can then be matched to data sources. This is useful for diagnosing failures. It's also handy in recovery situations - if you have a record with a specific EIS ID and also a current XAResource with the same, then if the recovery pass on that resource does not include the Xid as in-doubt, you can conclude the tx completed but the tx manager crashed before removing its log file. Currently there is insufficient information to draw that conclusion, making cleaning up the log file a more risky proposition. Thus we arrive at the new version: gtrid = nodename.getBytes("UTF-8")+"#"+UidHelper.getBytes(tx_uid); bqual = eisId.getBytes("UTF-8")+#"+UidHelper.getBytes(new Uid()); Comments? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262722#4262722 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262722

14 years, 6 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Testing Deployers with new Reflect + ClassPool

by flavia.rainone＠jboss.com

"alesj" wrote : "flavia.rainone(a)jboss.com" wrote : | | I'll start adding a test to reproduce the failure I caught yesterday. | | | Which failure is that? | The bug that was causing the test failure you found: https://jira.jboss.org/jira/browse/JBREFLECT-65 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262711#4262711 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262711

14 years, 6 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Testing Deployers with new Reflect + ClassPool

by alesj

"flavia.rainone(a)jboss.com" wrote : | I'll start adding a test to reproduce the failure I caught yesterday. | Which failure is that? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262705#4262705 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262705

14 years, 6 months

1
0
0 / 0

[JBoss Portal Development] - Jboss - Windows Active Directory Integration - Urgent

by arunicbe

I am integrating Jboss Portal server 2.7.2 with Microsoft Windows server 2003 active directory ldap. I followed the steps provided in the wiki configportalforMicrosoftactivedirectory. When I open the portal, it throws the error "User Search Failed". I am unable to proceed. I have provided the contents of ldap_identity-config.xml at the bottom. I have two questions: 1. Is this config correct? 2. I created two organisational units in my active directory namely People and Roles. Do I need to create admin user in any of these OUs. Do we need to create any groups under Roles OU. Any help is highly appreciated. Thanks. Contents of my ldap_identity-config.xml: <?xml version="1.0" encoding="UTF-8"?>    <identity-configuration> LDAP host myip port 389 adminDN myadmin adminPassword myadminpassword   User LDAP  org.jboss.portal.identity.ldap.LDAPExtUserModuleImpl Role LDAP  org.jboss.portal.identity.ldap.LDAPExtRoleModuleImpl Membership LDAP org.jboss.portal.identity.ldap.LDAPStaticGroupMembershipModuleImpl UserProfile DELEGATING ldapModuleJNDIName java:/portal/LDAPUserProfileModule DBDelegateUserProfile DB randomSynchronizePassword true LDAPDelegateUserProfile LDAP <option-group> <group-name>common</group-name> userCtxDN ou=People,ou=Roles,dc=caro,dc=com uidAttributeID sAMAccountName userSearchFilter <![CDATA[(&(sAMAccountName={0})(objectClass=User))]]> roleCtxDN <![CDATA[ou=People,ou=Roles,dc=caro,dc=com]]> roleSearchFilter <![CDATA[(&((CN={0})(objectClass=group)))]]> searchScope SUBTREE_SCOPE </option-group> </identity-configuration> View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262700#4262700 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262700

14 years, 6 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Testing Deployers with new Reflect + ClassPool

by flavia.rainone＠jboss.com

"alesj" wrote : With so many ifs in Classpool project, we definitely need more CL hierarchy CP/TypeInfo tests in Deployers. | | * CL isolation check | * Domain hierarchy usage | * Import from another bundle, although class exists in our jar | * Do things still properly work after re-deploy; e.g. no stale stuff left over | * ... | | This is all crucial before we even try to make Javassist as default Reflect impl. | I think that we should look into the class pool tests and see what they are missing before we proceed to deployers tests. I'll start adding a test to reproduce the failure I caught yesterday. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262687#4262687 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262687

14 years, 6 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Testing Deployers with new Reflect + ClassPool

by flavia.rainone＠jboss.com

"alesj" wrote : I've now at least removed the super horrible hack, | but this code definitely needs a proper cleanup, | as I've still found a bunch of weird things; catching NPE to do some logic, ... Those things were also part of the super horrible hack and defintely will be removed. "alesj" wrote : I've currently used reflection to get to the underlying classloader. | This might not be so hackish, but we could still make some effort to see if there is a better way of doing this. | TBH, I don't like using reflection because of performance. Any other ideas? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262684#4262684 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262684

14 years, 6 months

1
0
0 / 0

[JBoss XML Binding Development] - Re: JBossEntityResolver cannot resolve...

by alex.loubyansky＠jboss.com

Looks like it's an issue of the calling code, not in JBossEntityResolver itself. I think if the namespace/publicId for the not resolved schemas was mapped to the schemaLocation/systemId of the resovled schemas it would be able to resolve it. If that's true then it's a configuration issue and should be fixed in the calling code (JBossWSEntityResolver, JBossWS code or something on top). I'd suggest posting this on the WS user forums as well to get the WS team look into this. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262661#4262661 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262661

14 years, 6 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Extender Patter vs. LifecycleInterceptors

by thomas.diesler＠jboss.com

anonymous wrote : | Re-use of code. ;-) | What code would actually be reused by adding these adaptors? Perhaps you think an interceptor *is* a deployer and the invocation and ordering should be done by the deployer framework. This is something I'm not so sure about. considering how the deployers are being invoked on the various bundle state changes. Also, how would that work in Felix and other frameworks when it becomes standard. I'd still like to see a use case or actual code that could be reused by the adaptors that yo have in mind. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262623#4262623 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262623

14 years, 6 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Testing Deployers with new Reflect + ClassPool

by alesj

With so many ifs in Classpool project, we definitely need more CL hierarchy CP/TypeInfo tests in Deployers. * CL isolation check * Domain hierarchy usage * Import from another bundle, although class exists in our jar * Do things still properly work after re-deploy; e.g. no stale stuff left over * ... This is all crucial before we even try to make Javassist as default Reflect impl. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262616#4262616 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262616

14 years, 6 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Extender Patter vs. LifecycleInterceptors

by alesj

"thomas.diesler(a)jboss.com" wrote : Could you pls elaborate on the use case for the adaptors? Deployer deployer = ...; LifecycleInterceptor interceptor = new DeployerToLifecycleInterceptorAdaptor(deployer); LifecycleInterceptor interceptor = ...; Deployer deployer = new LifecycleInterceptorToDeployerAdaptor(interceptor); "thomas.diesler(a)jboss.com" wrote : (i.e. what benefit would these adaptors bring) Re-use of code. ;-) I already have a feeling you're re-inventing things a bit too much with this LI farmework, where you should actually just have this and other adaptors in the first place. But I trust your judgment, nevertheless adaptors should exist, in order to prove both concepts, LI and VDF, right. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262610#4262610 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262610

14 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2009