July 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (EJBTHREE-1002) EJB3-based version of the RetryInterceptor

by Brian Stansberry (JIRA)

EJB3-based version of the RetryInterceptor ------------------------------------------ Key: EJBTHREE-1002 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1002 Project: EJB 3.0 Issue Type: Feature Request Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Looking for a conceptual equivalent to the EJB2 RetryInterceptor -- ability to reestablish a valid remoting client when the current FamilyClusterInfo does not contain any valid targets. If the approach is analogous to the RetryInterceptor case, what would be registered in JNDI is the FamilyClusterInfo itself (rather than the EJB2 Invoker). Looking this up in JNDI would provide the current list of targets. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-4022) EJB security-domain tag in jboss.xml for a domain defined in login-config.xml only works if java:/jaas/ prefix is absent, contrary to the documentation.

by Erica Kane (JIRA)

EJB security-domain tag in jboss.xml for a domain defined in login-config.xml only works if java:/jaas/ prefix is absent, contrary to the documentation. -------------------------------------------------------------------------------------------------------------------------------------------------------- Key: JBAS-4022 URL: http://jira.jboss.com/jira/browse/JBAS-4022 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.0.4.GA Environment: Clustered Reporter: Erica Kane I created a security domain in the the JBoss server login-config.xml: <application-policy name = "webappDomain"> <authentication> <login-module code = "org.jboss.security.auth.spi.DatabaseServerLoginModule" flag = "required"> <module-option name = "dsJndiName">java:jdbc/web</module-option> <module-option name = "principalsQuery">select password from Users where username=?</module-option> <module-option name = "rolesQuery">select Role, 'Roles' from Roles where username=?</module-option> <module-option name = "unauthenticatedIdentity">guest</module-option> </login-module> </authentication> </application-policy> In jboss-web.xml, I have <?xml version="1.0" encoding="UTF-8"?> <jboss-web> <security-domain flushOnSessionInvalidation="true">java:/jaas/webappDomain</security-domain> <context-root>/web</context-root> </jboss-web> and this works perfectly for securing web pages. However, if I put the following tag in jboss.xml: <security-domain>java:/jaas/webappDomain</security-domain> I find that protected EJBs default to using the "other" security domain, as shown by error messages complaining about the missing user.properties file and so on (I have left "other" on the default setting of UsersRolesLoginModule). What DOES work is to put: <security-domain>webappDomain</security-domain> in jboss.xml without the java:/jaas/ prefix. However, this does not match the documentation. See http://docs.jboss.org/jbossas/jboss4guide/r4/html/ch8.chapter.html example 8.8. Of course there the tag is set to java:/jaas/other, which for this bug would default to "other" anyway. I think it is terribly confusing to have jboss.xml and jboss-web.xml using different forms for the security-domain, but even if this is necessary for some reason it should be corrected in the documentation. Other people appear to have run into this as well: http://forum.java.sun.com/thread.jspa?threadID=773530 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-3942) twiddle.sh should read run.conf - and other small ehancements

by Paul Jenner (JIRA)

twiddle.sh should read run.conf - and other small ehancements ------------------------------------------------------------- Key: JBAS-3942 URL: http://jira.jboss.com/jira/browse/JBAS-3942 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Other Affects Versions: JBossAS-4.0.5.GA Reporter: Paul Jenner The twiddle.sh script should read environment variables from run.conf in the same way as the startup and shutdown scripts do - e.g. JAVA_HOME and JAVA. Additionally twiddle.sh should honous the JAVA environment variable instead of overwriting it with $JAVA_HOME/bin/java or "java". This makes it consistent with startup and shutdown which do honour JAVA. Finally the header should be changed from JBoss Shutdown script to JBoss twiddle script :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

4
6
0 / 0

[JBoss JIRA] Created: (JGRP-501) JGroups demo hosted by jboss.org

by Bela Ban (JIRA)

JGroups demo hosted by jboss.org -------------------------------- Key: JGRP-501 URL: http://jira.jboss.com/jira/browse/JGRP-501 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assigned To: Vladimir Blagojevic Priority: Minor Fix For: 2.5 Goal: users can download a minimal JGroups installation (either via WebStart or as an applet) and explore JGroups. The configuration would probably include TUNNEL and there would be a GossipRouter instance running, e.g. on labs.jboss.org. We could provide access to chat & whiteboard (org.jgroups.demos.wb.Whiteboard) This would also be a good test case for the new revamped GossipRouter. Plus, once we have redundant GossipRouters, we can test client failover. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

2
6
0 / 0

[JBoss JIRA] Created: (JGRP-409) Channel bundling

by Bela Ban (JIRA)

Channel bundling ---------------- Key: JGRP-409 URL: http://jira.jboss.com/jira/browse/JGRP-409 Project: JGroups Issue Type: Feature Request Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.6 We can distributed traffic across multiple sockets in the transport. E.g. if we have eth0 and eth1, and both are 100Mbps *full duplex*, then we should be able to send 100Mbps on eth0 and 100Mbps on eth1 *simultaneously*. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 9 months

3
8
0 / 0

[JBoss JIRA] Created: (JBAS-4460) Jboss Password Encryption Security Flaw

by Scott Kesecki (JIRA)

Jboss Password Encryption Security Flaw --------------------------------------- Key: JBAS-4460 URL: http://jira.jboss.com/jira/browse/JBAS-4460 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Security Affects Versions: JBossAS-4.0.3 SP1 Reporter: Scott Kesecki Assigned To: Scott M Stark The Jboss salt to encrypt and decrypt passwords are stored in clear text in the jboss source that can be downloaded by everyone. Anyone that has a basic understanding of how java works can take the source tree get the class definition that has the password encryption and turn it into a a password decryption class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

2
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-941) merge issue when removing from OneToMany in detached state (layered architecture)

by Rico Apfelbeck (JIRA)

merge issue when removing from OneToMany in detached state (layered architecture) --------------------------------------------------------------------------------- Key: EJBTHREE-941 URL: http://jira.jboss.com/jira/browse/EJBTHREE-941 Project: EJB 3.0 Issue Type: Bug Affects Versions: AS 4.2.0 CR1 Environment: 13:37:59,625 INFO [ServerInfo] Java version: 1.5.0_09,Sun Microsystems Inc. 13:37:59,625 INFO [ServerInfo] Java VM: Java HotSpot(TM) Server VM 1.5.0_09-b01,Sun Microsystems Inc. 13:37:59,625 INFO [ServerInfo] OS-System: Windows XP 5.1,x86 Reporter: Rico Apfelbeck We work on a client-server environment with a webstart-client with an own JVM. Only the server has access to the JPA. POJOs are transfered from client to server and back. Our Issue occurs in the following workflow: - We get an Object A on the server from the Entitymanager and transfer it to the client. - This Object has a OneToMany-relation to some Objects B (fetchtype: EAGER, cascade: ALL). In B we have a reference to A. - On the client we remove in A some B from the Set, for example with clean() and transfer A back to the server. - We merge A on the server. - There is no exception thrown. The returned A from the merge-call does not contain any B, reloading A by Id results in a restored list containing the removed Bs. While added new Bs to A are stored correctly, removing them doesn't result in the deletion of the removed Bs from the database. Updating B in the List in A results in updated Bs when merging A. Only the removal causes problems. We assume that the problem comes from checking the now empty list against the database. Reloading A before merging in the server and manually compare the List of Bs, using EntityManager.remove() when neccesary. helps our case, but that's not the way it shoud be. :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

4
4
0 / 0

[JBoss JIRA] Created: (JBMICROCONT-122) Use the ScopedClassPool from javassist

by Adrian Brock (JIRA)

Use the ScopedClassPool from javassist -------------------------------------- Key: JBMICROCONT-122 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-122 Project: JBoss MicroContainer Issue Type: Task Components: BeanInfo Affects Versions: JBossMC_2_0_0 Beta Reporter: Adrian Brock The javassist reflection utilities use the original shared classpool. This does not understand classloaders. This should be updated to use the newer ScopedClassPool from javassist. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

5
8
0 / 0

[JBoss JIRA] Created: (JBXB-100) Add support for unmarshal(Source)

by Thomas Diesler (JIRA)

Add support for unmarshal(Source) --------------------------------- Key: JBXB-100 URL: http://jira.jboss.com/jira/browse/JBXB-100 Project: JBoss XML Binding (JBossXB) Issue Type: Feature Request Affects Versions: JBossXB-1.0.0.CR9 Reporter: Thomas Diesler JBossWS fragments the incomming SOAP message into Source elements. Currently its using DOMSource. The interface to JBossXB is inefficient since the DOMSource needs to be serialized into a String and then into an InputStream. It would be much better if JBossXB could unmarshall the Source directly. Later we could transparently switch from DOMSource to some more efficient implementation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

4
7
0 / 0

[JBoss JIRA] Created: (JBAS-3773) Empty baseCtxDN and rolesCtxDN adds a comma to the userDn and user roles

by Eric van Lydegraf (JIRA)

Empty baseCtxDN and rolesCtxDN adds a comma to the userDn and user roles ------------------------------------------------------------------------ Key: JBAS-3773 URL: http://jira.jboss.com/jira/browse/JBAS-3773 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Security Affects Versions: JBossAS-4.0.5.CR1 Reporter: Eric van Lydegraf Assigned To: Scott M Stark The LDAP server (Lotus Domino) has users organized along different CtxDN contexts, so for JNDI empty contexts are used and the filter sorts out the users and groups. When Using LoginExtLoginModule, a sucessful retrieval of a User, has a full userDN but the code will append a comma expecting BaseCtxDN used in the search. The same is true for group membership. The solution I came up with is if the context is empty, no Ctx is appended and only the search result is preserved. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

2
4
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2007