Hi, Glen
Thanks for your comment, see my comments inline.
Thanks
Jeff
Glen Mazza wrote:
Hello Jeff,
Here's my comments on each patch.
Patch #901:
1.)
+ <target name="copy-war-libs" unless="without.libs">
+ <copy todir="${war-lib}">
+ <fileset dir="${cxf.home}/modules">
+ <include name="cxf-*.jar" />
+ </fileset>
+ <fileset dir="${cxf.home}/lib">
+ <exclude name="servlet-api-*.jar" />
+ <exclude name="geronimo-servlet_*.jar" />
+ <exclude name="cxf-*.jar" />
+ </fileset>
+ </copy>
</target>
I think the listing of jar files needed should be explicitly listed via
<includes/> (even if there are 40 of them--remember this is only done
once in the common_build.xml), not *all* included but just having a few
left out via <excludes/>. This also will provide us a crisp,
authoritative list of precisely what is needed to run CXF. Using
excludes over time might result in unneeded jars getting into the WAR
files (i.e., we add a JAR file to the /lib directory but forget to
exclude it here.)
Well, I don't think we need to list them, because in fact we include *all* the
jars. Allowing me explain a little bit on this.
Currently, we have two flavors CXF jar, one is all-in-one jar, called
cxf-2.1-incubator.jar; the other is module-based jar, which is listed in the
"${cxf.home}/modules",
for the WARs, we used the module-based jars, so we need to exclude the
all-in-one jar.
The reason why I excluded those two servlet jars, because we deploy it into a servlet-container, there is no need to have these two servlet jars.
2.)
Deploy the application into APACHE TOMCAT with the commond:
+ ant deploy-tomcat
Undeploy the application from the APACHE TOMCAT with the command:
+ ant undeploy-tomcat
Can the instructions on tomcat-deploy and tomcat-undeploy be moved to
the common samples README without too much loss in user understanding,
instead of being copied in every sample application's instructions?
That would greatly simplify maintenance. (BTW, it's nice that you got
rid of that redundant -Dtomcat = true option)
I think it is better for us to keep it in those specific samples, first of all, not all
samples have this "running demo in a servlet container", only 7 or 8 samples,
and for these samples, since it has this specific section, it would be better
for us to keep it in this section.
Patch #902:
3.) Is the idea of supporting Java-first web services *without* adding
annotations[1] supported by the JAX-WS standard? I believe this is what
this sample is about, correct? I'm not certain why we should be
encouraging this style of coding--it doesn't seem very rigorous to
program web services this way.
This is mainly a philosophical concern, not a comment on the code as a
whole.
[1] http://cwiki.apache.org/CXF20DOC/simple-frontend.html
Yes, you are right, it doesn't have the annotation (JSR-181), it is another front-end (POJO based) other than JAX-WS front-end.
we are not encouraging it, but we need to have a sample for the completeness, we will leave the decision to users.
4.) I would take a look at this patch (#902) again--are their any
classes or interfaces being used which are *identical* to ones in other
samples? I don't know how others feel, but I would just reference them
in the ant.build file when compiling and creating the WAR file, instead
of constantly recreating identical classes. This will also help us in
the future when we starting factoring out common classes that are used
by multiple samples.
I don't like reusing too much, but I would like to hear others comments on this...
Regards,
Glen
Am Freitag, den 10.08.2007, 17:39 +0800 schrieb Jeff.Yu:
Hi,
Just added the "FULL WAR" build patch, can someone help me review it.
below are those two JIRAs and patches.
https://issues.apache.org/jira/browse/CXF-901
https://issues.apache.org/jira/browse/CXF-902
Thanks
Jeff
Jeff.Yu wrote:
Hi,
I've just provided a "java_first_pojo" sample patch, could someone
please help me review it and apply it if it is okay.
Thanks
Jeff
Daniel Kulp wrote:
Jeff,
I think this is all great and I don't want to discourage you.
However, this is something that won't be "EASY" for a non-committer
to completely pick up. svn patches don't record the renames/moves
very well so that part is going to be very tricky to do.
What I'd suggest is to create a couple subtasks of CXF-763. Examples:
1) Update "war" building for full war
2) Add javafirst_pojo demo
3) etc....
And go ahead and use normal patches for those. Then add a
"re-organize" demos subtask and probably attach a script or something
that would do the series of "svn mv" operations. Definitely not
ideal.
Other notes:
javafirst_jaxws (will add one) - there is one already.
hello_world_code_first
As far as the hello_world_RPCLit demo goes, I'm doing a training
thing this friday and one of the things I'm doing it taking the
hello_world_code_first and demonstrating some of the differences that
occur just by adding/modifying some of the annotations. It might be
interesting to try and turn that demo into more of a step-by-step
tutorial. Maybe have the "RPC" annotation there but commented out
and have a step in the tutorial be to uncomment it, start the server
and look at the wsdl. Turn on logging
(@Features(...LoggingFeature)) and look at the messages, etc....
Dan
On Tuesday 07 August 2007 23:40, Jeff.Yu wrote:
Hi, All
I would like to pick up the CXF-763, and below is my proposal on it,
let me know what you think.
1. Directory Structure:
-----------------------------
wsdlfirst (was: hello_world)
wsdlfirst_soap12 (was: soap12)
wsdlfirst_pure_xml (was: hello_world_xml_bare)
jaxws_async (was: hello_world_async)
jaxws_handlers (was: handlers)
jaxws_dispatch_provider (was: dispatch_provider)
javafirst_pojo (will add one, would like to use the aegis data
binding) javafirst_jaxws (will add one)
javafirst_spring_support (was: spring_http)
secure_https (was: hello_world_https)
in_jvm_transport (was: collocated)
configuration_interceptor (was: streaminterceptor)
hello_world_RPCLit (Will remove, or what name will it be given?)
hello_world_xml_wrapped (Will remove, or what name will it be given?)
---keep below folders unchanged------
restful_dispatch
restful_http_binding
ws_addressing
ws_policy
ws_rm
integration
js_provider
js_client
soap_header
mtom
mtosi_1.1
jms_pubsub
jms_queue
callback
2. Deploy to Container
--------------------------------
It will be different from what we have now, I would like to pack all
the required jars to $WAR/WEB-INF/lib folder, and then generate a WAR,
so if you want to deploy it to containers, what you need to do is to
copy the WAR to the container's deploy folder. you can see details in
this thread:
http://www.nabble.com/How-to-deploy-to-JBoss--tf4210975.html#a11978522
For tomcat container, if you set the CATALINA_HOME, and then you run:
"ant deploy-tomcat" , it will copy the generated war to the
$CATALINA_HOME/webapps/
3. secure_https sample (was: hello_world_https)
-----------------------------------------
Will change those three configuration file (****.cxf) to the ***.xml
file.
Thanks
Jeff
