Hi Frank, On Fri, Aug 12, 2011 at 4:24 AM, Asseg, Frank <frank.as...@fiz-karlsruhe.de> wrote: > Hola Chris > > On 08/11/11 18:34, Chris Wilper wrote: >>> xalan.jar is in the dependency list of fedora-webapp via >>> org.apache.xmlgraphics:fop:jar:0.95-1:compile >>> and after compiling the webapp i can locate the jar in >>> target/WEB-INF/lib but it's not in the fedora.war generated by the >>> installer. >>> Is this intentional or should we file a bug? >> >> What do you mean by fedora-webapp? Are you talking about the parent >> maven module called fcrepo-webapp, or the child of that, called >> fcrepo-webapp-fedora (the one that's reponsible for putting together >> the war). > when I do "mvn:dependency:tree" in fedora-webapp-fop i find the xalan > dependency which gets imported via xmlgraphics. But there's no other > xalan dependency in any of the fedora-webapp modules. > So when the escidoc guys start up their JBoss they get the following > exception when the xalan.jar is not in the classpath: > > Caused by: java.lang.RuntimeException: XPathFactory#newInstance() failed > to create an XPathFactory for the default object model: > http://java.sun.com/jaxp/xpath/dom with the > XPathFactoryConfigurationException: > javax.xml.xpath.XPathFactoryConfigurationException: No XPathFctory > implementation found for the object model: > http://java.sun.com/jaxp/xpath/dom > at javax.xml.xpath.XPathFactory.newInstance(Unknown Source) > [xml-apis-1.3.04.jar/:1.3.04] > at > org.fcrepo.server.validation.ecm.EcmValidator.<clinit>(EcmValidator.java:26) > [fcrepo-server-3.4.2.jar/:na]
Aha...so EcmValidator, which is part of the main Fedora webapp, does need an XPathFactory implementation to be in the classpath. Xalan has one, but it's only included as a library for the fcrepo-fop webapp. But I'm pretty sure Sun Java also comes with a default implementation, which I believe is what Asger depended on when integrating ECM with Fedora. I'm not sure why this would be failing, then. What version (and vendor) of Java are you using in this environment? >>> An ActiveMQ and JAX-RS implementation is included in the fedora war. >>> This is of course fine when fedora gets installed in a Servlet Container >>> like tomcat or jetty but when deploying on an Application Server like >>> JBoss or Glassfish who pack their own implementations of JMS and JAX-RS >>> the different versions clash. >>> Is there some option in the installer we can tweak to have the fedora >>> war exclude those implementations? >> >> Yuck. Would excluding them from the war file really be enough? > From what i can tell this would help the escidoc guys a lot, since they > repeatedly run into conflicts with JBoss. >> I know >> we've gone through a few efforts in the past to try to get Fedora >> working properly in app servers, but it seems like a very difficult >> proposition to get *any* sufficiently sophisticated webapp to deploy >> in multiple kinds of app server successfully, because they seem to >> want to force you to use their stack of libraries. > Hmm would it be possible to have the installer look for a property > in the install.properties files that holds a list of jars to exclude > from the final war? > Like: > exclude.libraries=activeMQ.jar,jersey.jar Having the installer change the war file runs counter to the current goal of distributing exactly one WAR file per release, without the need for an installer: https://jira.duraspace.org/browse/FCREPO-534 If we were to go down the path of supporting customizing the war file for different application server platforms, we would clearly need to reconsider that goal. So this provokes some higher-level questions: How do we feel about supporting alternative deployments of Fedora? Is it something we should do? And should we go so far as to add JBoss or other specific app server testing to our release cycle? I think we'd need some serious help with testing specific app servers if we were to go that far. As for myself, I don't have experience with JBoss or other app servers in production deployments. I know their stated value propositions, but I don't really appreciate first-hand the value they provide over simpler Tomcat or Jetty-based deployments. There's a complexity cost to supporting multiple kinds of deployments for any product. I want to be sure that if we go that way, we have a good understanding of the value we're getting for the extra effort and time. It's telling that in 2010, Atlassian discontinued support for JBoss and other app servers[1] for customers of their flagship products (JIRA and Confluence). Here's how they explained their decision: "We are reducing our application server platform support to reduce the amount of testing time and help us speed up our ability to deliver market-driven features. We are committed to helping our customers understand this decision and assist them in migrating to Tomcat, our supported application server." So supporting these app servers was too much of a money and time sink for them to justify the value. Granted, this is just one example of one company's decision. But it's a smart company with a large full-time technical staff. So for us to go in a different direction, I think we ought to have a good, shared understanding of the tradeoffs. - Chris [1] http://confluence.atlassian.com/display/JIRA/End+of+Support+Announcements+for+JIRA#EndofSupportAnnouncementsforJIRA-DeprecatedApplicationServersforJIRA%2827January2010%29 http://confluence.atlassian.com/display/DOC/End+of+Support+Announcements+for+Confluence#EndofSupportAnnouncementsforConfluence-DeprecatedApplicationServersforConfluence%2827January2010%29 ------------------------------------------------------------------------------ Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev _______________________________________________ Fedora-commons-developers mailing list Fedora-commons-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
