[ http://issues.apache.org/jira/browse/GERONIMO-1164?page=all ]
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 project.properties
----------------
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
submitting
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: http://issues.apache.org/jira/browse/GERONIMO-1164
> Project: Geronimo
> Type: Task
> Components: sample apps
> Reporter: Jacek Laskowski
> Assignee: Jacek Laskowski
> Fix For: 1.1
> Attachments: adventure1.0.3-built-with-jdk-1.4.2.zip,
> adventurebuilder1.0.3-geronimo-deployment-plans.zip, 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 http://wiki.apache.org/geronimo/AdventureBuilder
> This is a sample application brought to you by the Java BluePrints program at
> Sun Microsystems, Inc.
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
