geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Færch (JIRA) <>
Subject [jira] Updated: (GERONIMO-1164) Java Adventure Builder Reference application deployment
Date Mon, 02 Jan 2006 10:50:02 GMT
     [ ]

Jakob Færch updated GERONIMO-1164:

    Attachment: jrf-20060102.patch

Attached jrf-20060102.patch. 
The application is now able to see an order all the way through to completion, and can send
mail to the customer.

This patch contains the following changes:

Moved the deployer-configurable properties from maven.xml to
Changed the geronimo artifact id used in unpackServer from the tomcat distribution to the
jetty distribution, as I experienced some problems with the Tomcat distro.
Added dependencies for geronimo-javamail-transport-1.0.jar, and added them 
to the list of jars being copied manually in the unpackServer goal
Moved around some of the properties in the configuration of the MailGBean and SMTPTransportGBean.
It seems that the SMTPTransportGBean isn't necessary, so I have removed it.
I didn't make my point with the ${webServicePort} clear, I think. 
The reason I introduced it (under a much more misleading name) was to 
be able to inject a logging proxy between the bean using the webservice
and the bean providing the webservice.
That is, the setup would be as follows:
Webservice-enabled bean (listening on port 8080)
Logging proxy (forwarding request on port ${webServicePort} to port 8080)
Webservice client, talking to the webservice at port ${webServicePort}

To facilitate this, only the naming:port element in the naming:service-refs
should use ${webServicePort}, the webservice-address elements for the webservice
enabled beans should still use port 8080.

I see two alternatives:
 1. discard the mechanism? After all, it's only for debugging purposes.
 2. let the mechanism stay for debugging. I've done this in the patch I'm

Unrelated, we might introduce another parameter to let deployers easily 
expose the webservices on other ports (to remove conflicts with existing 
http-servers on the machine they're deploying on). 
I agree this would be helpful.

> Java Adventure Builder Reference application deployment
> -------------------------------------------------------
>          Key: GERONIMO-1164
>          URL:
>      Project: Geronimo
>         Type: Task
>   Components: sample apps
>     Reporter: Jacek Laskowski
>     Assignee: Jacek Laskowski
>      Fix For: 1.1
>  Attachments:,,
jrf-20060102.patch, jrf-patch-partially-20051219-2.patch, jrf-patch-partially-20051219-3.patch,
jrf-patch-partially-20051219.patch, jrf-patch-partially-20051220.patch, jrf-patch-partially-20051222.patch
> It's finally the time to see Java Adventure Builder Reference application running in
Geronimo. This task is to track the progress. Instruction available at
> This is a sample application brought to you by the Java BluePrints program at Sun Microsystems,
> This sample application demonstrates how to use the capabilities of the J2EE 1.4 platform
to develop robust, scalable, portable, and maintainable e-business applications and Webservices.
It comes with full source code and documentation, so you can experiment with the J2EE technologies
and learn how to use them effectively to build your own enterprise solutions. This application
also showcases how to use the Webservices technologies in the J2EE 1.4 platform.
> This version of Adventure Builder Reference application is certified by Application Verification
Kit(AVK) for the portablity across J2EE compatible application servers.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message