Hi Martin, Thank you for the suggestion. It's been some time since I looked at this but we will try this again in our environment.
- Doron _________________________ Doron Shalvi NLM Digital Collections http://collections.nlm.nih.gov shal...@mail.nih.gov ------------------------------ Date: Wed, 9 Feb 2011 14:33:20 +1100 From: <martin.pien...@csiro.au> Subject: Re: [fcrepo-user] Fedora 3.3.1 and Muradora To: <fedora-commons-users@lists.sourceforge.net> Cc: antony.tomaso...@csiro.au Message-ID: <0a6c5e0faf257a47bfc5303e9bca4f3a8c40b00...@exnsw-mbx03.nexus.csiro.au> Content-Type: text/plain; charset="us-ascii" Hi Doron Thanks for the info. I managed to get around this problem by deleting the berkeley jar files from the WEB-INF/lib directory, and then placing the correct ones (for Muradora's XACML - db.jar and dbxml.jar) into the tomcat/lib directory. That way - it will share them, instead of trying to load up multiple copies. My next problem is that any user that does not have the "public" or "administrator" roles gets a "403 Forbidden" when Muradora tries to access http://MY_SERVER:8080/fedora/describe?xml=true So my LDAP users, who are able to login to muradora (using FilterLdap.java), cannot access any records, because of the above 403 error. It's got me stumped at the moment - and with log4j debug turned on, I get no hints as to what is wrong unfortunately. The only reason that we're upgrading to Fedora 3.3.1 is to fix the security issue that it addresses. Kind regards Martin -----Original Message----- From: Shalvi, Doron (NIH/NLM) [C] [mailto:shal...@mail.nlm.nih.gov] Sent: Tuesday, 8 February 2011 9:05 AM To: 'fedora-commons-users@lists.sourceforge.net' Subject: Re: [fcrepo-user] Fedora 3.3.1 and Muradora Hi Martin, We received the same error you did when attempting to deploy Muradora 1.4.0B1 with Fedora 3.3. Fedora 3.3 introduced FESL, which contains the XACML components that came from Muradora. Muradora/FESL loads a native library from the JVM in order to interface with the Berkeley DB; however, this causes a runtime error when the same code tries to load the native library twice - once for Muradora, and once for FESL within Fedora 3.3. The resulting error has to do with a native library already being loaded by another classloader in the same JVM. For this reason, we dropped back down to Fedora 3.2.1 (which does not include FESL), although I suppose you would also be OK running Fedora 3.3+ and Muradora in separate containers. As we currently don't have a great need for XACML, we have slowly been excising these components from Muradora, with the goal of rewiring it to work with FESL in the latest Fedora, such that they can be deployed on the same container without problems. Peri - please share your strategy for customizing Muradora and Fedora 3.3+ to work on the same container! Thanks, Doron _________________________ Doron Shalvi NLM Digital Collections http://collections.nlm.nih.gov shal...@mail.nih.gov ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Fedora-commons-users mailing list Fedora-commons-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
