[Dspace-tech] Dspace 1.6.2 installation on Fedora core 11
Hi, I have tried to install Dspace 1.6.2 on fedora core 11 on several occasions but I keep on getting the same error; [r...@localhost dspace]# ant fresh_install Buildfile: build.xml does not exist! Build failed This is after installing all the requirements, Please help me on this. Thanks. -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Dspace 1.6.2 installation on Fedora core 11
On Thu, Sep 30, 2010 at 09:01, mwi...@ueab.ac.ke wrote: Hi, I have tried to install Dspace 1.6.2 on fedora core 11 on several occasions but I keep on getting the same error; [r...@localhost dspace]# ant fresh_install Buildfile: build.xml does not exist! Build failed You're supposed to either download the tarball from Sourceforge or checkout source from SVN. Then you should read documentation, especially Chapter 3 - Installation. Current links are always here: http://www.dspace.org/latest-release You're supposed to do a number of steps before running ant, mvn package is one of them. Just follow the instructions and contact us if you have any problems. Regards, ~~helix84 -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Oracle users - 64bit or 32bit? freshly built database?
On 29/09/2010 23:00, Marvin Weaver wrote: As you've all probably seen, I have been having problems getting the registry_loader part of the ant build to work on Solaris10/Oracle10 I also tried ubuntu10.04/postgres8.4 and got what appears to be the same error. Previously I had little problem building ubuntu8.04/postgres8.3. Now I am wandering if the problem might be that Solaris/Oracle and ubuntu10.04/postgres8.4 are both 64bit installations. Is anyone running on 64bit OSes? Yes we are. See: http://scholar.sun.ac.za Using Ubuntu 10.04.1 LTS 64 bit. Second part: If someone has had a successful fresh build on Oracle and has saved a dump of the schema, tables, initially loaded registry data, sequence values, etc; could you please send it to me? I commented out the load_registries part of the build.xml and have been able to bring up the xmlui interface and everything there looks OK. I can't do more because the database hasn't got the registries loaded (and anything else that might get loaded at the same time.) Unless I can get dspace properly working by Thanksgiving(Nov25), the plug is going to be pulled on it. I would rather find out why the build isn't working, but doing the missing bit by hand would allow me to see if the rest of the build worked and if batch loading will work and everything else. Desperately, Marvin mwea...@sju.edu -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech -- Hilton Gibson Systems Administrator JS Gericke Library Room 1053 Stellenbosch University Private Bag X5036 Stellenbosch 7599 South Africa Tel: +27 21 808 4100 | Cell: +27 84 646 4758 -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] how to publish the internal URL of DSpace Items
Hi all, I think I did not make my question clear. I want to get the internal URL generated by DSpace for an item to publish it on item-display page with some extra attributes. The internal URLs usually end by file extension whereas the persistent URLs won't. Any suggestions would be appreciated. I am using DSpace 1.5. Thanks in advance. Regards Vinit Kumar Senior Research Fellow Documentation Research and Training Centre Bangalore MLISc (BHU) Varanasi, India Alt email: vi...@drtc.isibang.ac.in On 28 September 2010 22:09, Vinit vinitbh...@gmail.com wrote: Dear all, Can anybody suggest a way to get the right variable to publish the internal url given by DSpace for an item? Regards Vinit Kumar Senior Research Fellow Documentation Research and Training Centre Bangalore MLISc (BHU) Varanasi, India Alt email: vi...@drtc.isibang.ac.in -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Oracle users - 64bit or 32bit? freshly built database?
Hello Marvin, did you try to load the registry after the fresh installation? You can do this by executing: [dspace]/bin/dsrun org.dspace.administer.RegistryLoader -bitstream [dspace]/config/registries/bitstream-formats.xml where [dspace] is your installation directory. Hope that helps Claudia Jürgen Am 29.09.2010 23:00, schrieb Marvin Weaver: As you've all probably seen, I have been having problems getting the registry_loader part of the ant build to work on Solaris10/Oracle10 I also tried ubuntu10.04/postgres8.4 and got what appears to be the same error. Previously I had little problem building ubuntu8.04/postgres8.3. Now I am wandering if the problem might be that Solaris/Oracle and ubuntu10.04/postgres8.4 are both 64bit installations. Is anyone running on 64bit OSes? Second part: If someone has had a successful fresh build on Oracle and has saved a dump of the schema, tables, initially loaded registry data, sequence values, etc; could you please send it to me? I commented out the load_registries part of the build.xml and have been able to bring up the xmlui interface and everything there looks OK. I can't do more because the database hasn't got the registries loaded (and anything else that might get loaded at the same time.) Unless I can get dspace properly working by Thanksgiving(Nov25), the plug is going to be pulled on it. I would rather find out why the build isn't working, but doing the missing bit by hand would allow me to see if the rest of the build worked and if batch loading will work and everything else. Desperately, Marvin mwea...@sju.edu -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech -- Claudia Juergen Universitaetsbibliothek Dortmund Eldorado 0231/755-4043 https://eldorado.tu-dortmund.de/ -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] manikin question
Tim, Thanks for your reply. I guess what I'm looking for is the xsl within the dri2xhml.xsl file that handles the rendering of the page used when the user confirms he wants to withdraw an item. I see the code that displays the header and the footer for that page, but I don't see the part that renders the stuff in the middle. -Jose From: Tim Donohue [tdono...@duraspace.org] Sent: Wednesday, September 29, 2010 5:37 PM To: Blanco, Jose Cc: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] manikin question Jose, I'm not sure I fully understand the question? Manakin works much differently than JSPUI -- so there is never really a one template to one page relationship. XSL Templates (in a theme) are usually used across many different pages in the system. Also, obviously many templates are used to generate a single page. The template you are looking for should be either in your Theme's XSL file or in the main 'dri2xhml.xsl' file (which is where most of the default templates reside -- as this file just basically transforms DRI into XHTML). If you are having trouble finding the exact template, sometimes it helps to look at the DRI structure of that page (add ?XML to the end of the Manakin URL, or XML if there's other stuff on the querystring already). You also may find it useful to use a tool like FireBug (http://getfirebug.com/) to analyze the structure of the generated XHTML, so that you can search through the templates in your Theme's XSL to find where that structure is generated. Hopefully that's helpful. Let us know if any of this doesn't make sense. - Tim On 9/29/2010 3:48 PM, Blanco, Jose wrote: I'm trying to get a better understanding of Manakin, and I've made a change in the aspect ConfirmItemForm.java And would like now to experiment with the theme that handles the display of DRIs coming from this aspect, but I can't find the template that is responsible for displaying the page that goes with this aspect. By page I mean the main body, not the header and footer display. Thank you! Jose -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] manikin question
Hi Jose, Actually, that's exactly my point. There is not a single template that renders the entire middle of the page. It's rendered by several templates working together. So, if you take a look closely, the middle part of the page is a giant table (with class=ds-table). If you dig into the dri2xhtml.xsl file, you'll see it just loads several other XSLs in the /dri2xhtml/ folder. In this case, you are looking for templates that generate the structure of the page -- so, you'd look in /dri2xhtml/structural.xsl (the *-Handler.xsl files all deal more with displaying actual metadata values from the METS files which are generated by Manakin, so you'd look there if you wanted to customize what metadata values are being displayed on a particular page). In the structural.xsl file, there is one main template that gets called for dri:table contents: xsl:template match=dri:table But, notice that template calls several other XSL templates in the file, by using the xsl:apply-templates or xsl:call-template tag. So, depending on what you are looking to change, you may need to follow the logic between the templates. Sometimes the easiest way to find a very specific template is to looking closely at the resulting XHTML that you want to change. Especially looking at specific @class attributes on HTML elements. Oftentimes you can search for those @class attribute values in the XSL templates to find where they are being generated. For example, in this case, you are looking at a big HTML table with a class=ds-table. If you search for ds-table in the structural.xsl, it will jump you right to the template that generates that content. (In some cases that @class attribute may exist in multiple templates, so you'd have to figure out which one you really need to change. But, in this example, it's only one place in the structural.xsl file) Hope that helps, - Tim On 9/30/2010 9:03 AM, Blanco, Jose wrote: Tim, Thanks for your reply. I guess what I'm looking for is the xsl within the dri2xhml.xsl file that handles the rendering of the page used when the user confirms he wants to withdraw an item. I see the code that displays the header and the footer for that page, but I don't see the part that renders the stuff in the middle. -Jose From: Tim Donohue [tdono...@duraspace.org] Sent: Wednesday, September 29, 2010 5:37 PM To: Blanco, Jose Cc: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] manikin question Jose, I'm not sure I fully understand the question? Manakin works much differently than JSPUI -- so there is never really a one template to one page relationship. XSL Templates (in a theme) are usually used across many different pages in the system. Also, obviously many templates are used to generate a single page. The template you are looking for should be either in your Theme's XSL file or in the main 'dri2xhml.xsl' file (which is where most of the default templates reside -- as this file just basically transforms DRI into XHTML). If you are having trouble finding the exact template, sometimes it helps to look at the DRI structure of that page (add ?XML to the end of the Manakin URL, orXML if there's other stuff on the querystring already). You also may find it useful to use a tool like FireBug (http://getfirebug.com/) to analyze the structure of the generated XHTML, so that you can search through the templates in your Theme's XSL to find where that structure is generated. Hopefully that's helpful. Let us know if any of this doesn't make sense. - Tim On 9/29/2010 3:48 PM, Blanco, Jose wrote: I'm trying to get a better understanding of Manakin, and I've made a change in the aspect ConfirmItemForm.java And would like now to experiment with the theme that handles the display of DRIs coming from this aspect, but I can't find the template that is responsible for displaying the page that goes with this aspect. By page I mean the main body, not the header and footer display. Thank you! Jose -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Limiting Searches
Thanks, Allen! George Kozak Digital Library Specialist Cornell University Library Information Technologies (CUL-IT) 501 Olin Library Cornell University Ithaca, NY 14853 607-255-8924 From: Allen Lam [mailto:allen.dsp...@gmail.com] Sent: Wednesday, September 29, 2010 9:23 PM To: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] Limiting Searches Hi George, Our dspace instance has a type indexing that can be searched. I did put the type-search options in a separated page - http://hub.hku.hk/browse/browse-type.jsp In the Advanced search there is no type drop down, but there is a custom made language drop down. Welcome for stealing, or borrowing of idea. Best, Allen Lam. HKU Scholars Hub Administrator, http://hub.hku.hk On 2010-09-30 2:37 AM, George Stanley Kozak wrote: I was recently asked to add type to the fields that can be searched in the Advance Search. I did do that. However, the problem is that users don't really know all of the types, so I was asked to add a drop down for all types. Along with that I was asked if I could modify the Advance Search so that people can limit their searches by Date range or by type. Before I spend a lot of time figuring this out, I was wondering if anyone has done anything similar to this that I could copy (or steal!). Thanks! George Kozak Digital Library Specialist Cornell University Library Information Technologies (CUL-IT) 501 Olin Library Cornell University Ithaca, NY 14853 607-255-8924 -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.netmailto:DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
[Dspace-tech] SWORD Easy Deposit
Hello List, We have installed SWORD easy deposit for our new website and it is accessible through http://homepage/easydeposit. I was not able to find the documentation for configuration part which will allow me to design the user interface and create steps for easy deposit. (http://easydeposit.swordapp.org/instructions/configuration/ Looks like there should be some documentation here but they are missing.) If someone could redirect me to these pages I would be really helpful for me. Thank you, Baseer. -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] Oracle users - 64bit or 32bit? freshly built database?, (Claudia J?rgen)
I commented out load_registries from the build.xml and ant builds. The logs in /dspace/log/ were owned by root, and rw only for root. I chmod to 777 on all. Then ran build, followed by your suggestion to run the registry loader via dsrun. It looks like the same error. Changes to build.xml: !-- = -- !-- Do a fresh system install -- !-- = -- !-- target name=fresh_install depends=init_installation,init_configs,test_database,setup_database,load_registries description=Do a fresh install of the system, overwriting any data -- target name=fresh_install depends=init_installation,init_configs,test_database,setup_database description=Do a fresh install of the system, overwriting any data Results and logs: -bash-3.00$ ant fresh_install Buildfile: /dspacehome/dspace-1.6.2-src-release/dspace/target/dspace-1.6.2-build.dir/build.xml init_installation: init_configs: test_database: [java] 2010-09-30 12:10:45,454 INFO org.dspace.core.ConfigurationManager @ Loading system provided config property (-Ddspace.configuration): config/dspace.cfg [java] 2010-09-30 12:10:45,522 INFO org.dspace.core.ConfigurationManager @ Using default log4j provided log configuration,if uninitended, check your dspace.cfg for (log.init.config) [java] [java] Attempting to connect to database: [java] - URL: jdbc:oracle:thin:@//dumbbell:1521/dspace [java] - Driver: oracle.jdbc.OracleDriver [java] - Username: dspace [java] - Password: dspace2009 [java] - Schema: dspace [java] [java] Testing connection... [java] Connected succesfully! [java] setup_database: [java] 2010-09-30 12:10:47,849 INFO org.dspace.core.ConfigurationManager @ Loading system provided config property (-Ddspace.configuration): config/dspace.cfg [java] 2010-09-30 12:10:47,890 INFO org.dspace.core.ConfigurationManager @ Using default log4j provided log configuration,if uninitended, check your dspace.cfg for (log.init.config) [java] 2010-09-30 12:10:47,890 INFO org.dspace.storage.rdbms.InitializeDatabase @ Initializing Database [java] 2010-09-30 12:10:49,603 WARN org.dspace.storage.rdbms.DatabaseManager @ Got SQL Exception: java.sql.SQLException: ORA-01408: such column list already indexed [java] [java] java.sql.SQLException: ORA-01408: such column list already indexed [java] [java] at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112) [java] at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331) [java] at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288) [java] at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:743) [java] at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:207) [java] at oracle.jdbc.driver.T4CStatement.executeForRows(T4CStatement.java:946) [java] at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1168) [java] at oracle.jdbc.driver.OracleStatement.executeInternal(OracleStatement.java:1687) [java] at oracle.jdbc.driver.OracleStatement.execute(OracleStatement.java:1653) [java] at org.apache.commons.dbcp.DelegatingStatement.execute(DelegatingStatement.java:264) [java] at org.apache.commons.dbcp.DelegatingStatement.execute(DelegatingStatement.java:264) [java] at org.dspace.storage.rdbms.DatabaseManager.loadSql(DatabaseManager.java:1067) [java] at org.dspace.storage.rdbms.InitializeDatabase.main(InitializeDatabase.java:100) [java] 2010-09-30 12:10:49,611 WARN org.dspace.storage.rdbms.DatabaseManager @ Got SQL Exception: java.sql.SQLException: ORA-01408: such column list already indexed [java] [java] java.sql.SQLException: ORA-01408: such column list already indexed [java] [java] at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112) [java] at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331) [java] at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288) [java] at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:743) [java] at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:207) [java] at oracle.jdbc.driver.T4CStatement.executeForRows(T4CStatement.java:946) [java] at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1168) [java] at oracle.jdbc.driver.OracleStatement.executeInternal(OracleStatement.java:1687) [java] at oracle.jdbc.driver.OracleStatement.execute(OracleStatement.java:1653) [java] at org.apache.commons.dbcp.DelegatingStatement.execute(DelegatingStatement.java:264) [java] at
Re: [Dspace-tech] SWORD Easy Deposit
Hi Baseer, We have installed SWORD easy deposit for our new website and it is accessible through http://homepage/easydeposit. I was not able to find the documentation for configuration part which will allow me to design the user interface and create steps for easy deposit. (http://easydeposit.swordapp.org/instructions/configuration/ Looks like there should be some documentation here but they are missing.) Yes - there should be more detail there, I just need to write it! Unfortunately I've been busy with another project at work for the past few months, and haven't had much time for anything else. This project is finished now, so I should be able to find some time to write them. Please feel free to contact me directly with any questions, or post them to the sword-app-tech email list: - https://lists.sourceforge.net/lists/listinfo/sword-app-tech Hopefully most of the settings are reasonably easy to configure. The main thing to know is that deposits are made up of steps, and you can reorder and configure these steps via the web interface to build the submission forms that you want. There are some further instructions and a tutorial video here: - http://swordapp.org/2010/09/the-sword-course/ (see 'Module 5 - Create your own SWORD client') Thanks, Stuart Lewis IT Innovations Analyst and Developer Te Tumu Herenga The University of Auckland Library Auckland Mail Centre, Private Bag 92019, Auckland 1142, New Zealand Ph: +64 (0)9 373 7599 x81928 -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] PowerPoint Text Extractor
I can volunteer to add this feature. On Sep 29, 2010, at 11:03 AM, Richard Rodgers wrote: Hi RIchard: I cannot speak to it's quality (and indeed we have had quality issues with other formats) but Apache POI library supports Powerpoint text extraction. I would study the doc at http://poi.apache.org/ for how to use the library, and look in: http://scm.dspace.org/svn/repo/dspace/trunk/dspace-api/src/main/java/org/dspace/app/mediafilter for examples of other extractor media filters. Then post any questions to the tech or dev list. Hope that is helpful, Richard Rodgers On Sep 29, 2010, at 10:14 AM, Jizba, Richard wrote: Hello, Are there plans to add a PPT text extractor to DSpace? In the meantime, can some provide information on how to implement one? Thanks, Richard Jizba Creighton University. ATT1..cATT2..c -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] manikin question
Unfortunately, I think this is a serious weakness of Manakin. It's realtively easy to change the header, the footer, and the display of metadata (collections, communities, items). But if you need to change anything else, you're in for a world of hurt. The way dri2xhtml renders the interface is both complex and confusing -- not at all the way other interface templating systems (including others that use XSLT) are set-up. I don't mean to be too critical here -- Manakin is a *big* improvement over JSPUI , and it cost me precisely $0, so I'm grateful to the developers, regardless. But Jose is not the first, nor likely the last, to scratch their head at how dri2xhtml is set-up. It would be great if a future version of Manakin might take a different approach. --Dave == David Walker Library Web Services Manager California State University http://xerxes.calstate.edu From: Tim Donohue [tdono...@duraspace.org] Sent: Thursday, September 30, 2010 7:25 AM To: Blanco, Jose Cc: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] manikin question Hi Jose, Actually, that's exactly my point. There is not a single template that renders the entire middle of the page. It's rendered by several templates working together. So, if you take a look closely, the middle part of the page is a giant table (with class=ds-table). If you dig into the dri2xhtml.xsl file, you'll see it just loads several other XSLs in the /dri2xhtml/ folder. In this case, you are looking for templates that generate the structure of the page -- so, you'd look in /dri2xhtml/structural.xsl (the *-Handler.xsl files all deal more with displaying actual metadata values from the METS files which are generated by Manakin, so you'd look there if you wanted to customize what metadata values are being displayed on a particular page). In the structural.xsl file, there is one main template that gets called for dri:table contents: xsl:template match=dri:table But, notice that template calls several other XSL templates in the file, by using the xsl:apply-templates or xsl:call-template tag. So, depending on what you are looking to change, you may need to follow the logic between the templates. Sometimes the easiest way to find a very specific template is to looking closely at the resulting XHTML that you want to change. Especially looking at specific @class attributes on HTML elements. Oftentimes you can search for those @class attribute values in the XSL templates to find where they are being generated. For example, in this case, you are looking at a big HTML table with a class=ds-table. If you search for ds-table in the structural.xsl, it will jump you right to the template that generates that content. (In some cases that @class attribute may exist in multiple templates, so you'd have to figure out which one you really need to change. But, in this example, it's only one place in the structural.xsl file) Hope that helps, - Tim On 9/30/2010 9:03 AM, Blanco, Jose wrote: Tim, Thanks for your reply. I guess what I'm looking for is the xsl within the dri2xhml.xsl file that handles the rendering of the page used when the user confirms he wants to withdraw an item. I see the code that displays the header and the footer for that page, but I don't see the part that renders the stuff in the middle. -Jose From: Tim Donohue [tdono...@duraspace.org] Sent: Wednesday, September 29, 2010 5:37 PM To: Blanco, Jose Cc: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] manikin question Jose, I'm not sure I fully understand the question? Manakin works much differently than JSPUI -- so there is never really a one template to one page relationship. XSL Templates (in a theme) are usually used across many different pages in the system. Also, obviously many templates are used to generate a single page. The template you are looking for should be either in your Theme's XSL file or in the main 'dri2xhml.xsl' file (which is where most of the default templates reside -- as this file just basically transforms DRI into XHTML). If you are having trouble finding the exact template, sometimes it helps to look at the DRI structure of that page (add ?XML to the end of the Manakin URL, orXML if there's other stuff on the querystring already). You also may find it useful to use a tool like FireBug (http://getfirebug.com/) to analyze the structure of the generated XHTML, so that you can search through the templates in your Theme's XSL to find where that structure is generated. Hopefully that's helpful. Let us know if any of this doesn't make sense. - Tim On 9/29/2010 3:48 PM, Blanco, Jose wrote: I'm trying to get a better understanding of Manakin, and I've made a change in the aspect ConfirmItemForm.java And would like now to experiment with the theme that handles the display of DRIs coming
Re: [Dspace-tech] manikin question
Hi Dave, Feedback (whether positive or critical) is always welcome! Though, obviously, it is even more helpful if we can better understand what is difficult and perhaps even how it could be improved upon or changed. Obviously, you mentioned the dri2xhtml being confusing and other systems doing things in a clearer way. I guess it leaves me wondering whether you (or anyone else) has suggested improvements which may make it less confusing/complex to deal with? For instance, would it be helpful if somehow the structural.xsl is split up (so it's not so large), or is it the templates themselves which are not as easy as in other systems? In general, if there are ways you or anyone else feel Manakin (or any part of DSpace for that matter) could be improved, we'd definitely be interested to hear them. Manakin, as an interface framework, really hasn't changed much since it's initial release in DSpace 1.5. Obviously, any good system/interface/etc should adapt and make improvements over time. So, I feel that all the Dspace developers would be interested to hear of suggestions for improvements or examples of easier to use interface templating systems which we could look at emulating, etc. Thanks! Feel free to send thoughts/suggestions to this mailing list. If you have specific code/template changes to suggestion you can also enter those into our issue tracker at http://jira.dspace.org/ - Tim On 9/30/2010 1:52 PM, Walker, David wrote: Unfortunately, I think this is a serious weakness of Manakin. It's realtively easy to change the header, the footer, and the display of metadata (collections, communities, items). But if you need to change anything else, you're in for a world of hurt. The way dri2xhtml renders the interface is both complex and confusing -- not at all the way other interface templating systems (including others that use XSLT) are set-up. I don't mean to be too critical here -- Manakin is a *big* improvement over JSPUI , and it cost me precisely $0, so I'm grateful to the developers, regardless. But Jose is not the first, nor likely the last, to scratch their head at how dri2xhtml is set-up. It would be great if a future version of Manakin might take a different approach. --Dave == David Walker Library Web Services Manager California State University http://xerxes.calstate.edu From: Tim Donohue [tdono...@duraspace.org] Sent: Thursday, September 30, 2010 7:25 AM To: Blanco, Jose Cc: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] manikin question Hi Jose, Actually, that's exactly my point. There is not a single template that renders the entire middle of the page. It's rendered by several templates working together. So, if you take a look closely, the middle part of the page is a giant table (with class=ds-table). If you dig into the dri2xhtml.xsl file, you'll see it just loads several other XSLs in the /dri2xhtml/ folder. In this case, you are looking for templates that generate the structure of the page -- so, you'd look in /dri2xhtml/structural.xsl (the *-Handler.xsl files all deal more with displaying actual metadata values from the METS files which are generated by Manakin, so you'd look there if you wanted to customize what metadata values are being displayed on a particular page). In the structural.xsl file, there is one main template that gets called fordri:table contents: xsl:template match=dri:table But, notice that template calls several other XSL templates in the file, by using thexsl:apply-templates orxsl:call-template tag. So, depending on what you are looking to change, you may need to follow the logic between the templates. Sometimes the easiest way to find a very specific template is to looking closely at the resulting XHTML that you want to change. Especially looking at specific @class attributes on HTML elements. Oftentimes you can search for those @class attribute values in the XSL templates to find where they are being generated. For example, in this case, you are looking at a big HTML table with a class=ds-table. If you search for ds-table in the structural.xsl, it will jump you right to the template that generates that content. (In some cases that @class attribute may exist in multiple templates, so you'd have to figure out which one you really need to change. But, in this example, it's only one place in the structural.xsl file) Hope that helps, - Tim On 9/30/2010 9:03 AM, Blanco, Jose wrote: Tim, Thanks for your reply. I guess what I'm looking for is the xsl within the dri2xhml.xsl file that handles the rendering of the page used when the user confirms he wants to withdraw an item. I see the code that displays the header and the footer for that page, but I don't see the part that renders the stuff in the middle. -Jose From: Tim Donohue
Re: [Dspace-tech] manikin question
I think one of the real challenges people run into with Manakin's templating is that there is no direct corollary between specific pages and individual templates or template files. Templates apply all over the site to an array of pages. You can't say oh, i'm in submission, i'll go edit submission.xsl. Further, you can't go looking for the template named submission_page. On top of that, there is also a lot of calling in between templates, passing parameters, etc. But I think one of the biggest difficulties is that some of the UI construction spans across the Java Cocoon generator code into the templates that depend on their output. I'll echo David's sentiment that this is a massive improvement over the JSPUI and that we owe a lot of thanks to its architects and developers. It is a challenge though, for anyone coming into it for the first time, even with a lot of experience in more standard templating architectures, to get to a point where the UI design modification process feels smooth, uninhibited and agile. The fact that there is an abstract document model in the middle of the processing that bears a resemblance to some of the markup it generates does not help matters for the uninitiated. As far as improvements, I could imagine some refactoring of global XSL templates into more feature-specific/page-specific templates, to ease the task of locating the point in the code that needs to be changed for a particular UI element. Early on in my use of Manakin, I started inserting xsl:comment tags at the start and end of the XSL templates so that in the generated source, I could have a better idea of which piece of code had generated that markup. This was only mildly helpful. I also tossed around the idea of putting some multi-purpose HTML div elements into each page so that there would be an anchor that could be used for additional page elements using CSS positioning, etc. though that always felt like a messy hack to me. -- sands fish Senior Software Engineer MIT Libraries Technology Research Development sa...@mit.edumailto:sa...@mit.edu E25-131 On Sep 30, 2010, at 3:28 PM, Tim Donohue wrote: Hi Dave, Feedback (whether positive or critical) is always welcome! Though, obviously, it is even more helpful if we can better understand what is difficult and perhaps even how it could be improved upon or changed. Obviously, you mentioned the dri2xhtml being confusing and other systems doing things in a clearer way. I guess it leaves me wondering whether you (or anyone else) has suggested improvements which may make it less confusing/complex to deal with? For instance, would it be helpful if somehow the structural.xsl is split up (so it's not so large), or is it the templates themselves which are not as easy as in other systems? In general, if there are ways you or anyone else feel Manakin (or any part of DSpace for that matter) could be improved, we'd definitely be interested to hear them. Manakin, as an interface framework, really hasn't changed much since it's initial release in DSpace 1.5. Obviously, any good system/interface/etc should adapt and make improvements over time. So, I feel that all the Dspace developers would be interested to hear of suggestions for improvements or examples of easier to use interface templating systems which we could look at emulating, etc. Thanks! Feel free to send thoughts/suggestions to this mailing list. If you have specific code/template changes to suggestion you can also enter those into our issue tracker at http://jira.dspace.org/ - Tim On 9/30/2010 1:52 PM, Walker, David wrote: Unfortunately, I think this is a serious weakness of Manakin. It's realtively easy to change the header, the footer, and the display of metadata (collections, communities, items). But if you need to change anything else, you're in for a world of hurt. The way dri2xhtml renders the interface is both complex and confusing -- not at all the way other interface templating systems (including others that use XSLT) are set-up. I don't mean to be too critical here -- Manakin is a *big* improvement over JSPUI , and it cost me precisely $0, so I'm grateful to the developers, regardless. But Jose is not the first, nor likely the last, to scratch their head at how dri2xhtml is set-up. It would be great if a future version of Manakin might take a different approach. --Dave == David Walker Library Web Services Manager California State University http://xerxes.calstate.edu From: Tim Donohue [tdono...@duraspace.org] Sent: Thursday, September 30, 2010 7:25 AM To: Blanco, Jose Cc: dspace-tech@lists.sourceforge.netmailto:dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] manikin question Hi Jose, Actually, that's exactly my point. There is not a single template that renders the entire middle of the page. It's rendered by several templates working together. So, if you take a look
Re: [Dspace-tech] tomcat reporting memory leak?
Hi, first, I want to thank Mark Wood for recommending LambdaProbe, it is proving a very useful tool. I can see already that we need to increase our PermGen, and will probably borrow Mark's JAVA_OPTS settings for our production and development Tomcat instances. In trying to further educate myself about these issues, I came across this excellent page on the Tomcat wiki, which at the end includes debugging/troubleshooting advice that is very close to the procedure Graham Triggs outlined at a recent committer's meeting. I'm forwarding this link to the list, as I think it might prove useful to others: http://wiki.apache.org/tomcat/OutOfMemory --Hardy -Original Message- From: Mark H. Wood [mailto:mw...@iupui.edu] Sent: Wednesday, September 29, 2010 12:08 PM To: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] tomcat reporting memory leak? I'd like to point out that the discussion is broadening considerably: a system can be slow for many reasons, not just memory starvation. Step 1: what resource(s) are you short of? Something like LambdaProbe can peek inside Tomcat and show you how much of each of the various memory pools is being used. OS tools can show whether you are swapping heavily or spending a lot of time in I/O wait or are really CPU-bound (and what, besides Tomcat, may be eating CPU). DBMS tools can reveal places in the schema that don't scale well, queries that could be optimized, and additional indices that would be beneficial. It would be really helpful for large, busy sites with performance problems to share any such detailed observations. Some of those problems can probably be tuned away, and some will point to specific things for coders to investigate. Scaling experience will be valuable both in documenting good ways to tune up for DSpace and in finding design hotspots for rework. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Balance your desire for bells and whistles with the reality that only a little more than 2 percent of world population has broadband. -- Ledford and Tyler, _Google Analytics 2.0_ -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] manikin question
I think Sands hits the problem on the head: The way virtually every other interface templating system works, each page in the system corresponds to an individual template or file. If I want to make a change to my DSpace home page, I should be able to easily find and edit a home page template. If Jose wants to edit the confirm item page, there should be a confirm item template. Obviously, common elements like the header, footer, sidebar, etc., should be pushed into their own templates. But, otherwise, I should be able to see and edit pages. That is what I think most people expect to see (I know I did). In so far as Manakin doesn't work that wat, it's confusing. I'll write some additional thoughts in a second email. --Dave == David Walker Library Web Services Manager California State University http://xerxes.calstate.edu From: Sands Alden Fish [sa...@mit.edu] Sent: Thursday, September 30, 2010 1:42 PM To: Tim Donohue Cc: Walker, David; dspace-tech@lists.sourceforge.net; Blanco, Jose Subject: Re: [Dspace-tech] manikin question I think one of the real challenges people run into with Manakin's templating is that there is no direct corollary between specific pages and individual templates or template files. Templates apply all over the site to an array of pages. You can't say oh, i'm in submission, i'll go edit submission.xsl. Further, you can't go looking for the template named submission_page. On top of that, there is also a lot of calling in between templates, passing parameters, etc. But I think one of the biggest difficulties is that some of the UI construction spans across the Java Cocoon generator code into the templates that depend on their output. I'll echo David's sentiment that this is a massive improvement over the JSPUI and that we owe a lot of thanks to its architects and developers. It is a challenge though, for anyone coming into it for the first time, even with a lot of experience in more standard templating architectures, to get to a point where the UI design modification process feels smooth, uninhibited and agile. The fact that there is an abstract document model in the middle of the processing that bears a resemblance to some of the markup it generates does not help matters for the uninitiated. As far as improvements, I could imagine some refactoring of global XSL templates into more feature-specific/page-specific templates, to ease the task of locating the point in the code that needs to be changed for a particular UI element. Early on in my use of Manakin, I started inserting xsl:comment tags at the start and end of the XSL templates so that in the generated source, I could have a better idea of which piece of code had generated that markup. This was only mildly helpful. I also tossed around the idea of putting some multi-purpose HTML div elements into each page so that there would be an anchor that could be used for additional page elements using CSS positioning, etc. though that always felt like a messy hack to me. -- sands fish Senior Software Engineer MIT Libraries Technology Research Development sa...@mit.edu E25-131 On Sep 30, 2010, at 3:28 PM, Tim Donohue wrote: Hi Dave, Feedback (whether positive or critical) is always welcome! Though, obviously, it is even more helpful if we can better understand what is difficult and perhaps even how it could be improved upon or changed. Obviously, you mentioned the dri2xhtml being confusing and other systems doing things in a clearer way. I guess it leaves me wondering whether you (or anyone else) has suggested improvements which may make it less confusing/complex to deal with? For instance, would it be helpful if somehow the structural.xsl is split up (so it's not so large), or is it the templates themselves which are not as easy as in other systems? In general, if there are ways you or anyone else feel Manakin (or any part of DSpace for that matter) could be improved, we'd definitely be interested to hear them. Manakin, as an interface framework, really hasn't changed much since it's initial release in DSpace 1.5. Obviously, any good system/interface/etc should adapt and make improvements over time. So, I feel that all the Dspace developers would be interested to hear of suggestions for improvements or examples of easier to use interface templating systems which we could look at emulating, etc. Thanks! Feel free to send thoughts/suggestions to this mailing list. If you have specific code/template changes to suggestion you can also enter those into our issue tracker at http://jira.dspace.org/ - Tim On 9/30/2010 1:52 PM, Walker, David wrote: Unfortunately, I think this is a serious weakness of Manakin. It's realtively easy to change the header, the footer, and the display of metadata (collections, communities, items). But if you need to change anything else, you're in for a world of hurt. The way
Re: [Dspace-tech] manikin question
So, wrapping up this long-winded criticism -- you did say this was okay right, Tim? ;-) -- I don't think it would actually take much to improve Manakin. First, just do away with the DRI schema. Have the aspects Java code simply create XML that is semantically (rather than presentationally) marked-up. Just give us the data for communities, collections, items, and the submission process. Just the data as XML. Second, push all of the presentational logic into the XSLT files. Create templates that correspond to pages in the system. If the interface needs a div or a paragraph or a submit button, that should all go into the XSLT. That is where it belongs, in the presentational layer. You'll then have a clean separation of concerns, easy to figure out templates, and happier developers. Easy for me to say, right? ;-) --Dave == David Walker Library Web Services Manager California State University http://xerxes.calstate.edu From: Walker, David Sent: Thursday, September 30, 2010 2:42 PM To: Tim Donohue Cc: Blanco, Jose; dspace-tech@lists.sourceforge.net Subject: RE: [Dspace-tech] manikin question The root of the problem, IMO, is that Manakin takes a fundamentally wrong approach to XSLT. The way Manakin works now, it generates XML that is already *presentational* in its orientation. The DRI schema includes elements that are, for all intents and purposes, layers, paragraphs, lists, and so on. The XSLT, then, applies templates recursively to that already very HTML-like XML, in order to turn each element into true HTML. This creates two fundamental issues: (1) People don't design pages recursively. Applying templates recursively to XML is great (and considered best practice) if you are going from one XML document to another XML document -- by that I mean, from one metadata schema to another, like from MODS to Dublin Core. But when you go from XML to HTML for *presentation* (which is what Manakin is doing), it's not the right approach. At all. As I mentioned earlier, the templates should more-or-less correspond to pages, so developers can see, position, and layout the HTML. That is how other systems that use XSLT for presentation work. (2) It mixes concerns. The aspects Java code (e.g., CollectionViewer.java) includes code for things like querying the database. But it also includes code for things like positioning layers, paragraphs, and buttons in the interface. You've got business logic and presentational logic in one file. But then you've also got *additional* presentational logic in the XSLT. So you've got presentational logic in two different places in the system. It just adds to the confusion. --Dave == David Walker Library Web Services Manager California State University http://xerxes.calstate.edu From: Tim Donohue [tdono...@duraspace.org] Sent: Thursday, September 30, 2010 12:28 PM To: Walker, David Cc: Blanco, Jose; dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] manikin question Hi Dave, Feedback (whether positive or critical) is always welcome! Though, obviously, it is even more helpful if we can better understand what is difficult and perhaps even how it could be improved upon or changed. Obviously, you mentioned the dri2xhtml being confusing and other systems doing things in a clearer way. I guess it leaves me wondering whether you (or anyone else) has suggested improvements which may make it less confusing/complex to deal with? For instance, would it be helpful if somehow the structural.xsl is split up (so it's not so large), or is it the templates themselves which are not as easy as in other systems? In general, if there are ways you or anyone else feel Manakin (or any part of DSpace for that matter) could be improved, we'd definitely be interested to hear them. Manakin, as an interface framework, really hasn't changed much since it's initial release in DSpace 1.5. Obviously, any good system/interface/etc should adapt and make improvements over time. So, I feel that all the Dspace developers would be interested to hear of suggestions for improvements or examples of easier to use interface templatingsystems which we could look at emulating, etc. Thanks! Feel free to send thoughts/suggestions to this mailing list. If you have specific code/template changes to suggestion you can also enter those into our issue tracker at http://jira.dspace.org/ - Tim On 9/30/2010 1:52 PM, Walker, David wrote: Unfortunately, I think this is a serious weakness of Manakin. It's realtively easy to change the header, the footer, and the display of metadata (collections, communities, items). But if you need to change anything else, you're in for a world of hurt. The way dri2xhtml renders the interface is both complex and confusing -- not at all the way other interface templating systems (including others that use XSLT) are
Re: [Dspace-tech] manikin question
The root of the problem, IMO, is that Manakin takes a fundamentally wrong approach to XSLT. The way Manakin works now, it generates XML that is already *presentational* in its orientation. The DRI schema includes elements that are, for all intents and purposes, layers, paragraphs, lists, and so on. The XSLT, then, applies templates recursively to that already very HTML-like XML, in order to turn each element into true HTML. This creates two fundamental issues: (1) People don't design pages recursively. Applying templates recursively to XML is great (and considered best practice) if you are going from one XML document to another XML document -- by that I mean, from one metadata schema to another, like from MODS to Dublin Core. But when you go from XML to HTML for *presentation* (which is what Manakin is doing), it's not the right approach. At all. As I mentioned earlier, the templates should more-or-less correspond to pages, so developers can see, position, and layout the HTML. That is how other systems that use XSLT for presentation work. (2) It mixes concerns. The aspects Java code (e.g., CollectionViewer.java) includes code for things like querying the database. But it also includes code for things like positioning layers, paragraphs, and buttons in the interface. You've got business logic and presentational logic in one file. But then you've also got *additional* presentational logic in the XSLT. So you've got presentational logic in two different places in the system. It just adds to the confusion. --Dave == David Walker Library Web Services Manager California State University http://xerxes.calstate.edu From: Tim Donohue [tdono...@duraspace.org] Sent: Thursday, September 30, 2010 12:28 PM To: Walker, David Cc: Blanco, Jose; dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] manikin question Hi Dave, Feedback (whether positive or critical) is always welcome! Though, obviously, it is even more helpful if we can better understand what is difficult and perhaps even how it could be improved upon or changed. Obviously, you mentioned the dri2xhtml being confusing and other systems doing things in a clearer way. I guess it leaves me wondering whether you (or anyone else) has suggested improvements which may make it less confusing/complex to deal with? For instance, would it be helpful if somehow the structural.xsl is split up (so it's not so large), or is it the templates themselves which are not as easy as in other systems? In general, if there are ways you or anyone else feel Manakin (or any part of DSpace for that matter) could be improved, we'd definitely be interested to hear them. Manakin, as an interface framework, really hasn't changed much since it's initial release in DSpace 1.5. Obviously, any good system/interface/etc should adapt and make improvements over time. So, I feel that all the Dspace developers would be interested to hear of suggestions for improvements or examples of easier to use interface templatingsystems which we could look at emulating, etc. Thanks! Feel free to send thoughts/suggestions to this mailing list. If you have specific code/template changes to suggestion you can also enter those into our issue tracker at http://jira.dspace.org/ - Tim On 9/30/2010 1:52 PM, Walker, David wrote: Unfortunately, I think this is a serious weakness of Manakin. It's realtively easy to change the header, the footer, and the display of metadata (collections, communities, items). But if you need to change anything else, you're in for a world of hurt. The way dri2xhtml renders the interface is both complex and confusing -- not at all the way other interface templating systems (including others that use XSLT) are set-up. I don't mean to be too critical here -- Manakin is a *big* improvement over JSPUI , and it cost me precisely $0, so I'm grateful to the developers, regardless. But Jose is not the first, nor likely the last, to scratch their head at how dri2xhtml is set-up. It would be great if a future version of Manakin might take a different approach. --Dave == David Walker Library Web Services Manager California State University http://xerxes.calstate.edu From: Tim Donohue [tdono...@duraspace.org] Sent: Thursday, September 30, 2010 7:25 AM To: Blanco, Jose Cc: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] manikin question Hi Jose, Actually, that's exactly my point. There is not a single template that renders the entire middle of the page. It's rendered by several templates working together. So, if you take a look closely, the middle part of the page is a giant table (with class=ds-table). If you dig into the dri2xhtml.xsl file, you'll see it just loads several other XSLs in the /dri2xhtml/ folder. In this case, you are looking for templates that
Re: [Dspace-tech] DSpace Setup
1. Contact Info: Hardy Pottinger, University of Missouri (MOspace) (message sent from my main e-mail address, use that). 2.a. DSpace 1.6.2 (XMLUI) with local mods for user interface, and Shibboleth special groups handling 1 assetstore at 1TB, 35GB used (big plans! really!) Number of items: 2.b. Oracle Database 10g Enterprise Edition Release 10.2.0.4.0, running on another server (unknown spec) db.maxconnections = 50 (anything less than 50 is unstable) db.maxwait = 5000 db.maxidle = 0 (idle connections are nailed by the firewall on the Oracle server, sysadmins will not change) 2.c. All RHEL-provided, Tomcat 5.5.23, running behind Apache 2.2.3 via mod_proxy 2.d. DSpace and Tomcat are on one server, Oracle db is on a shared server. Server: Dell PowerEdge 2950 Memory size: 8110 MB CPUs: 4 x Intel Xeon 5160 @ 3.00 GHz OS: Red Hat Enterprise Linux Server release 5.5 (kernel 2.6.18-194.3.1.el5PAE) 2.e. JAVA_OPTS=-Xmx512M -Xms256M (this will likely change soon, need to bump up PermGen) 3. Back when we were running on DSpace 1.5.1, after a period of about 24-36 hours of uptime, Tomcat became unavailable. Apache reported 503: service unavailable. Looking at a dump after killing all Java processes, it appeared that all database connections were unavailable. Changing the db.maxconnections and db.maxidle settings (see above) was helpful, but we are proactively rebooting tomcat and apache every night, to clean out the cobwebs. Have not disabled the nightly reboot since the upgrade to 1.6.2, so do not have current data/log files. I'm willing to try other config settings. I'm pretty sure I saw an interesting looking patch that drops database connections (mainly for streaming situations) that I can't seem to find right now, but might help this particular stability issue. 4. Volunteer to help? Of course! I am a fledgling Java developer, reasonably competent application manager, and working with XSLT only makes me want to cry a little bit, nowadays. :-) We have a development server with a snapshot of our live repository, and are willing to do load testing, run a profiler, whatever it takes to help. We're certainly not experts in any the various tech running under the hood of DSpace, but keeping our repository running smoothly is our main job, and we aim to please. You may use my address as the main contact, but we have two more developers here who are willing to pitch in. --Hardy -Original Message- From: George Stanley Kozak [mailto:g...@cornell.edu] Sent: Wednesday, September 29, 2010 11:28 AM To: dspace-tech@lists.sourceforge.net Subject: [Dspace-tech] DSpace Setup Hi... Based on Tim Donohue's suggestion to share configuration and setup information, here is Cornell University's Dspace configuration: 1.Server: Sun sun4v T5140 Memory size: 65312 Megabytes (4 CPUs) 2.Running DSpace 1.6.2 (JSPUI) with local mods for User Interface, Embargo, and Refworks. db.maxconnections = 50 db.maxwait = 5000 db.maxidle = 5 2 assetstores at 300GB each (using currently 323 GB) Number of items: 14,960 Number of Communities/Collections: 789 3.Java 1.5.0_24 4.Apache 2.29 running mod_jk to tomcat 5.Tomcat 5.5.26 JAVA_OPTS=-server -Xms1024m -Xmx2048m -Xmn64m -Dfile.encoding=UTF-8 -XX:+UseParallelGC -verbose:gc -Xloggc:/dspace/dspace/log/gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:PermSize=1024m -XX:MaxPermSize=1024m -XX:-UseGCOverheadLimit 6.PostGreSQL 8.3 max_connections = 300 shared_buffers = 32MB max_fsm_pages = 204800 Though we experienced some performance problems in the past, that seemed to disappear after we went to DSpace 1.5.2. George Kozak Digital Library Specialist Cornell University Library Information Technologies (CUL-IT) 501 Olin Library Cornell University Ithaca, NY 14853 607-255-8924 -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] DSpace Setup
On Sep 30, 2010, at 6:36 PM, Pottinger, Hardy J. wrote: 3. Back when we were running on DSpace 1.5.1, after a period of about 24-36 hours of uptime, Tomcat became unavailable. Apache reported 503: service unavailable. Looking at a dump after killing all Java processes, it appeared that all database connections were unavailable. Changing the db.maxconnections and db.maxidle settings (see above) was helpful, but we are proactively rebooting tomcat and apache every night, to clean out the cobwebs. Have not disabled the nightly reboot since the upgrade to 1.6.2, so do not have current data/log files. I'm willing to try other config settings. I'm pretty sure I saw an interesting looking patch that drops database connections (mainly for streaming situations) that I can't seem to find right now, but might help this particular stability issue. There's a patch here for xmlui: http://jira.dspace.org/jira/browse/DS-677 I'm don't know if this addresses the problem that you used to have in 1.5, though. I think I've seen something like what you're talking about with a scheduling conflict between vacuuming or other maintenance of the database and the media filter processes running. It's been a long time though and I'm very fuzzy on this. In 1.6, the solr statistics code seems to make heavy use of database connections to figure out which item, collections, and communities a bitstream belongs. I haven't spent enough time poking around though to see if the database usage might be reduced, or the connections held open less often. On a side note, I noticed that in the slides for the recent presentation from @mire about the statistics system, there are a few suggestions for optimizing solr sites with heavy usage. I missed the seminar, though, so I'm not sure of the details. --keith -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
Re: [Dspace-tech] DSpace Setup
On Sep 30, 2010, at 7:14 PM, Keith Gilbertson wrote: I think I've seen something like what you're talking about with a scheduling conflict between vacuuming or other maintenance of the database and the media filter processes running. It's been a long time though and I'm very fuzzy on this. Now that I'm thinking about it, it may have been an item import or some other long running batch process. I haven't spent enough time poking around though to see if the database usage might be reduced, or the connections held open less often. Instead of connections held open less often, I think I meant something more along the lines of reduce the amount of time it takes to return a database connection back to the database pool and/or reduce the number of concurrent connections needed. -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
