The Tasklet/Weblet Bundles tool lists all the packaged Tasklet and App Bundles available for the user to choose from when creating jobs and applications. A Bundle is nothing more than a packaged modular component with all software and resources files stored in a JAR file (with an extension of .sfb). This tool allows the user to view and manage the available Bundles and view various details about them, including demonstrate any optional GUI interfaces associated with each Bundle, if the Bundle has a GUI associated with it. Tasklet and App Bundles are based on the open source soafaces specification. You can read more about soafaces here.
When listing the available Bundles, you can filter by type. The two types are Application Bundles (contain GUI Weblets only) and Tasklet Bundles which contain server-side Tasklets and optional Weblet/RuntimeViewer GUIs for customizing the Tasklet's input and for viewing the runtime status of the Tasklet.
Tasklet type Bundles, are Bundles that implement the Tasklet interface and
can be used to build and run workflow type backend jobs. The Tasklet is a required interface that
must be implemented and is defined in the MANIFEST.MF file contained in the
Bundle jar archive file. Other
Bundle interfaces (such as a Weblet and RuntimeViewer) are optional and can
be used to customize the Tasklet's input JavaBeans and view the status of a Tasklet.
Tasklet Bundles can be used
to build jobs using the Job Designer tool.
App only type Bundles, are Bundles that implement the Weblet interface and
do NOT implement the Tasklet interface. The Weblet is a required interface that
must be implemented and defined in the MANIFEST.MF file contained in the
Bundle jar archive file. This type
of Bundle can be used to build only GUI type applications using the Application Builder tool.
It can NOT be used to build jobs and workflows since it does not contain a Tasklet.
The Bundle Description button will display basic details about the selected Bundle.
This will show the meta information describing the Bundle that is found in the MANIFEST.MF file.
An example is shown here:
Manifest-Version: 1.0 Ant-Version: Apache Ant 1.7.0 Created-By: 10.0-b19 (Sun Microsystems Inc.) SOAFaces-Name: Hello World 3 SOAFaces-SymbolicName: surda-beansoup-helloworld3 SOAFaces-Version: 1.0.0 SOAFaces-Description: Simple SOAFaces example SOAFaces-Vendor: Grand Logic, Inc SOAFaces-Category: example SOAFaces-Tasklet: org.beansoup.helloworld3.workflow.HelloWorld SOAFaces-InputBean: org.beansoup.helloworld3.client.HelloWorldInput SOAFaces-OutputBean: SOAFaces-Weblet: org.beansoup.helloworld3.HelloWorldGWTModule SOAFaces-RuntimeViewer:
The App/Weblet GUI button will display the GWT Weblet associated with the Bundle (if one exists). A Weblet can be used to build a GUI application. When you click the button, the App is displayed in demo mode with limited capabilities. This action provides the user with an example of how the Weblet would functions in an application.
The Tasklet Design Time GUI button will display the GWT customizer associated with the Bundle (if one exists). This is a Weblet that can be used to build a GUI customizer for a Tasklet to edit the input properties of that Tasklet. When you click the button, the Weblet is displayed in demo mode with limited capabilities. This action provides the user with an example of how the Weblet customizer would functions in a job and Tasklet.
The Tasklet Runtime GUI button will display the GWT RuntimeViewer associated with a Tasklet (the RuntimeViewer API is optional for Tasklets to use). The RuntimeViewer is displayed in a demo mode with limited capabilities. The RuntimeViewer is used to display the output/input JavaBeans and current runtime status associated with a Tasklet's execution as part of a job. The RuntimeViewer can show the status of the Tasklet as the Tasklet is running or the results of the Tasklet after it finishes running. This can provide a historical snapshot of the output/input JavaBeans associated with a Tasklet at the time the Tasklet was run. This is a great auditing tool to see exactly the output generated by the Tasklet (and thus the corresponding job) when it ran or as it is running.
Weblets and RuntimeViewer that can be associated with a Bundle
are implemented using the GWT framework. When building and deploying
a Bundle that includes a Weblet/RuntimeViewer, JobServer will automatically compile the GWT
java code into ajax/javascript on the fly. You only need to include the java
source code for the Weblet/RuntimeViewer.
JobServer handles compiling and deploying the GWT javascript code for you. You can also
GWT compile the Weblet/RuntimeViewer yourself and include the javascript in the Bundle (place it in the directory
www. If you do not included the compiled GWT code,
the first time you access a Weblet (or RuntimeViewer) it might take a moment to display
the GUI, because JobServer is busy running the GWT compiler on it. The next time
you access that specific Weblet (or RuntimeViewer) it will appear quickly since it is already
compiled. If a developer ever deploys a new version of the Bundle,
GWT will know to recompile it for you - it is all automatic. There
are special override options described below, that give you extra manual control
over the GWT compiler but these are typically used in special cases by administrators or someone
performing trouble shooting on a Bundle.
When you develop and build a Bundle that has a Weblet or RuntimeViewer,
you can choose to include the compiled GWT code in your Bundle archive file or you can let JobServer
compile the GWT GUI on the fly into html/javascript.
If you do not include the compiled GWT code, JobServer can
automiatically compile the GWT code for the
Weblet and RuntimeViewer associated with a Bundle for you the first time the Weblet, RuntimeViewer
are accessed. The GWT java code
is compiled on the fly into javascript/ajax code so be patient while the compiler runs.
Note, that for the on-the-fly compiling to work,
you must include the GWT java binary and source for the client code in the Bundle. If you do not
want JobServer to dynamically (on-the-fly) compile your Weblet/RuntimeViewer, then you can compile it
yourself and include the generated GWT html/javascript output and place it in the www
directory within the Bundle jar (".sfb" file).
This action allows the user to force all the Bundles to have their GWT javascript generated code to be cleared, so that the next time the GWT GUIs are accessed (Weblet or RuntimeViewer) they will be compiled again by the GWT compiler. This feature is only to be used in situations where there might be need to force the GWT compiler to recreate the javascript/ajax code and should only be used in rare circumstances. Note that this action only marks the Bundles for recompile and does not actually force an immediate recompile. The actual GWT recompile process will only happen when each individual Weblet/RuntimeViewer is accessed again. Note that this function does not apply to Bundles who have been statically GWT compiled.
This action allows the user to force the selected Bundle to have its GWT javascript generated code to be cleared, so that the next time the GWT GUIs are accessed (Weblet or RuntimeViewer) they will be compiled again by the GWT compiler. This feature is only to be used in situations where there might be need to force the GWT compiler to recreate the javascript/ajax code and should only be used in rare circumstances. Note that this action only marks the selected Bundle for recompile and does not actually force an immediate recompile. The actual GWT recompile process will only happen when the individual Bundle is accessed again. Note this function does not apply to Bundles who have been statically GWT compiled.
Deletes the selected Bundle.
Upload a new Bundle. The Bundle must have an extension of .sfb and
be in a JAR file format.
You can manually add Bundles to JobServer by dropping the Bundle file into JobServer's
soafaces directory. Do NOT expand the Bundle (.sfb file) yourself,
JobServer will do this for you.