2006/1/3, Jakob Roesgaard Færch <[EMAIL PROTECTED]>: > =============================================== > Secure Webservices > =============================================== > The web service enabled session beans BrokerServiceBean, > LodgingPOEndpointBean, ActivityPOEndpointBean, AirlinePOEndpointBean and > CreditCardEndpointBean need to be secured. > > The process is described (as implemented in the Sun Appserver) here: > <http://developers.sun.com/prodtech/appserver/reference/techart/mutual_auth.html> > > I think securing the services should be considered a hard requirement in > order to support the Adventure Builder 1.0.3. > If we don't want to go through the hassle of securing the web services, > a work around would be to instead support Adventure Builder 1.0.1, which > doesn't use secure web services.
Hi Jakob, I'm sure you'll forgive me, but I don't think it's that much important. I think not many end users will go up to this point and see how it works in a secured environment. It'd be very nice to have, but it should not hold us from announcing that Adventure Builder can finally be deployed and run in Apache Geronimo. I created a JIRA improvement for it to keep it in mind - http://issues.apache.org/jira/browse/GERONIMO-1415. > =============================================== > Supported JRE's? > =============================================== > The Adventure Builder application available at > <https://blueprints.dev.java.net/adventurebuilder> is a Java 1.5 binary > and is not built with 1.4 compability. > This means that to run the application as-downloaded, you have to start > the server in a 1.5 VM. This does seem to work, but I have come > across the following problems: > - The included daytrader application can't start due to a > deserialization problem > This might be remedied by somehow using a Geronimo distribution > without the Daytrader application > - The deployer.jar receives SecurityExceptions when talking to a > running server, e.g. to list running modules > > I guess the alternatives are > 1) Straighten out the above issues. I guess other issues might arise > - my impression is that Geronimo does not officially support > 1.5 VM's You're right. Although most (if not all) components work on Java 5, but it's not required by J2EE 1.4, which Geronimo's versions up to 1.0 support. > 2) Offer a 1.4-build of the Adventure Builder application. This would > definitely work, but also to some extent lower the credibility; > how should we prove that the application hasn't been tampered with? Absolutely true and no longer necessary. The committed revision 365750 (Exclude geronimo/daytrader-derby-jetty/1.0-SNAPSHOT/car from being run) fixes it. Only these configurations, which provide required services are started. It's a workaround for an issue in Geronimo itself, which we shouldn't have bothered with while working on the sample app. > ======================================================= > Adventure Builder as part of the Geronimo distribution? > ======================================================= > It should be possible to download a binary Geronimo distribution > including the Adventure Builder and deploy the application to the > Geronimo server automatically That would indeed be great if we could provide a car with AB. I don't think it's possible because of AB license constraints (I'm not a lawyer so I might possibly be wrong). > - or the user should be able to > indicate to the installer that the Adventure Builder sample application > should be installed. > > Right now, I am only able to deploy the application when either building > the server from source or manually installing artifacts into my local > maven repository. I think the committed revision 365764 (Deploy Adventure Builder without having to download the whole source tree (only /etc and /sandbox/adventurebuilder directories are required)) removed the need to download the whole source tree, which should meet the requirements of not-very-willing-to-download users. Cheers, Jacek
