[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
[JBoss JIRA] Created: (JBCOMMON-38) Use URI instead of URL in FileProtocolArchiveBrowserFactory
by Davide Baroncelli (JIRA)
Use URI instead of URL in FileProtocolArchiveBrowserFactory
-----------------------------------------------------------
Key: JBCOMMON-38
URL: http://jira.jboss.com/jira/browse/JBCOMMON-38
Project: JBoss Common
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Davide Baroncelli
Assigned To: Dimitris Andreadis
Priority: Critical
Fix For: 2.2.2.GA
Current code in FileProtocolArchiveBrowserFactory has problems when the URL coming from above contains escaped characters. E.g.: In an app. I'm writing, the class receives an URL coming from a ClassLoader.getResources method: resources in directories containing square brackets arrive to the class in escaped URLs such as the following:
file:/C:/Stratosfera/pos_back/%5BCARCON%5Dstratosfera-verifica-cartoline-concorso/war/WEB-INF/classes/
this form fails in the current implementation because of line 40:
File f = new File(url.getPath());
this results in a non existing file. Replacing the line with the following solves the problem:
File f;
try {
f = new File(url.toURI());
}
catch ( URISyntaxException e ) {
throw new RuntimeException( e );
}
this problems creates various compatibility problems in depending libraries (hibernate entitymanager for one).
--
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
[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
[JBoss JIRA] Created: (JBAS-4504) Container does not report invalid named query exception
by Radim Marek (JIRA)
Container does not report invalid named query exception
--------------------------------------------------------
Key: JBAS-4504
URL: http://jira.jboss.com/jira/browse/JBAS-4504
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB3
Affects Versions: JBossAS-4.0.5.GA
Environment: java 5 update 11; jboss 4.0.5 GA
Reporter: Radim Marek
Assigned To: Carlo de Wolf
Priority: Minor
When entity manager is called to create non-existing named query (for example because of mistyping), container doesn't throw a persistence exception.
Code
Query query = entityManager.createNamedQuery("MarketingBatch.getBatches");
had been called from remote client and exception had appeared only on client as ClassNotFound: org.hibernate.MappingException. Other problems with named query are reported as expected.
I thought all exception not handled by session bean should be reported. It would be at least convenient.
--
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