svn commit: r1039585 - in /incubator/river/jtsk/skunk/surrogate: nbproject/project.properties schemas/config-sample.xml

[gt...@apache.org]

Author: gtrasuk
Date: Fri Nov 26 22:49:50 2010
New Revision: 1039585

URL: http://svn.apache.org/viewvc?rev=1039585&view=rev
Log:
Daily.

Modified:
    incubator/river/jtsk/skunk/surrogate/nbproject/project.properties
    incubator/river/jtsk/skunk/surrogate/schemas/config-sample.xml

Modified: incubator/river/jtsk/skunk/surrogate/nbproject/project.properties
URL: http://svn.apache.org/viewvc/incubator/river/jtsk/skunk/surrogate/nbproject/project.properties?rev=1039585&r1=1039584&r2=1039585&view=diff
==============================================================================
--- incubator/river/jtsk/skunk/surrogate/nbproject/project.properties (original)
+++ incubator/river/jtsk/skunk/surrogate/nbproject/project.properties Fri Nov 26 22:49:50 2010
@@ -24,8 +24,8 @@ debug.test.classpath=\
 dist.dir=dist
 dist.jar=${dist.dir}/RiverSurrogate.jar
 dist.javadoc.dir=${dist.dir}/javadoc
-endorsed.classpath=\
-    ${libs.JAXB-ENDORSED.classpath}
+#endorsed.classpath=\
+#    ${libs.JAXB-ENDORSED.classpath}
 excludes=
 includes=**
 jar.archive.disabled=${jnlp.enabled}

Modified: incubator/river/jtsk/skunk/surrogate/schemas/config-sample.xml
URL: http://svn.apache.org/viewvc/incubator/river/jtsk/skunk/surrogate/schemas/config-sample.xml?rev=1039585&r1=1039584&r2=1039585&view=diff
==============================================================================
--- incubator/river/jtsk/skunk/surrogate/schemas/config-sample.xml (original)
+++ incubator/river/jtsk/skunk/surrogate/schemas/config-sample.xml Fri Nov 26 22:49:50 2010
@@ -17,4 +17,29 @@
         <cfg:group>TestGroup</cfg:group>
     </cfg:discovery-context>
 
+    <!-- List components here:
+    Likely components would be:
+    - Surrogate installer
+        - Or would that just be an application that runs under the
+        container?  Interesting question...
+    - Codebase server
+    - Application installer
+
+    Actually for all of these, we should ask the question, "Is this just an
+    application?"  The prime difference would be accessibility to the
+    container objects.
+
+    So then we have to design the interface between the container and these
+    container components, given that we might have different application
+    types that have different startup modalities (e.g. surrogates start
+    differently from applications, which start differently from jini Starter
+    applications, etc.  We need to have a container component protocol,
+    which does not actually need to be public or particularly stable in the
+    long term.  The application-level protocol of course has to be stable.
+
+    Do these container components have to be pluggable at the user level?
+    In other words, do we have to allow for finding them anywhere but in the
+    jar files shipped with the container?
+
+    -->
 </cfg:container-config>