X-Application Version: 4.1.1
Tamino Version : 4.1.1
Platform : Win2k
WebContainer : Tamocat 4.1.17
JDK Version : 1.4.1
When you generate a suite of jsps for a doctype, a complete directory structure is created under the webapps directory in order for these to be fully functional pages.
In an application situation you are likely to have lots (probably 20+) different doctypes and you surely do not want all the .gif, .jar, configuration files etc etc to be duplicated in the directory structure of each doctype.
I have read the documentation on deployment etc but I do not find any information on how to structure an application with multiple doctypes. What I would like is one directory (maybe with sub-directories) containing all the ‘common’ stuff like images, jar files, etc. and then a directory per doctype containing only the things specific to that doctypes i.e. jsp pages, structure document etc.
Can anyone assist in indicating what the implications are to configuring Tomcat when splitting the modules like this?
Regards
Elsabe Jacobs
Hi,
in principal you are able to deal with multiple schemas within one X-Application, but you are not able to generate Applications with multiple schemas.
Please, read the one post I have written before: http://tamino.forums.softwareag.com/viewtopic.php?p=14198
If I understood you right, you want to build an application with several “sub applications”. Am I right?
In this special case, you could put all common files like gifs, jpgs etc into one folder called “images”. Then you’ll create further directories for each “sub application” containing the specific JSP files.
You’ll need to modify the pathes within the JSP files.
On the main level you’ll need to adapt/create a common xapplication.xml file for the whole application.
Within the xapplication.xml file you’ll need to define all collections and schemas you need.
e.g.: /webapps/anApplication/
|–WEB-INF/…
|–images
|–sub_app_01/
| |–file1.jsp
| |–…
| |–fileN.jsp
|–sub_app_02/
| |–file1.jsp
| |–…
| |–fileN.jsp
…
|–sub_app_M/
| |–file1.jsp
| |–…
| |–fileN.jsp
|–xapplication.xml.
Within the xapplication.xml file
<collection name="collection01" variable="xappCollection01">
<schema name="customer" />
<schema name="invoice" />
</collection>
...
<collection name="collectionN" variable="xappCollectionN">
<schema name="schemaN" />
</collection>
If you want to keep every “sub application” as an individual application then you should able to
put common jar files into the /shared/lib directory to make them aware for all of your applications.
Your common files like gifs, jpgs etc. could be placed within a normal application and you need to
reference them in your applications by appsolute pathes.
By the way, whe are a little bit inquisitive 
Is it able to you to tell us, what kind of application you are building?
Hope this message will help you.
Bye
Thorsten
Thank you for the reply. I will try it and give feedback on which architecture worked the best for us.
In South Africa, companies have to pay over a Skills Development Levy to the government. By submitting reports on planned and actual ‘skills development’ (training) activities the companies are able to claim some of the money back from government.
We are developing a system to manage the data required to produce the reports as required by government.
Thanks
Elsabe
Hi Elsabe,
thanks for the information.
Bye
Thorsten
Hi Thorsten
I have tried the architecture as suggested with the one Application directory under webapps with sub-directories containing the generated pages for each schema and then adding all the schemas to the xapplication.xml file. In principle it works well.
My problem:
At this stage it seems as though the schemas as specified in the xapplication.xml file in the element must all contain unique element names. When this is the case all works well. When two of the schemas share element names one of them gives the following error when trying to list the available instances or to create a new one: ambiguous element: Title
Error!
An error occurred in the application program. Please report the following problem to your webmaster.
Error message: internal error
Help message:
Exception id: 999
Exception Type: ApplicationException
Stacktrace:
XException: id = 999
com.softwareag.xtools.xapplication.common.AssertionFailed
ambiguous element: Title
at com.softwareag.xtools.xapplication.businessdocument.SchemaSet.lookup(SchemaSet.java:85)
at com.softwareag.xtools.xapplication.businessdocument.BusinessDocumentWorkspace.getSchema(BusinessDocumentWorkspace.java:589)
at com.softwareag.xtools.xapplication.businessdocument.BusinessDocumentWorkspace.create(BusinessDocumentWorkspace.java:222)
at com.softwareag.xtools.xapplication.businessdocument.BusinessDocumentWorkspace.create(BusinessDocumentWorkspace.java:251)
at com.softwareag.xtools.xapplication.plugin.StandardWorkspacePlugin.createDocument(StandardWorkspacePlugin.java:271)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.softwareag.xtools.xapplication.plugin.Action.invoke(Action.java:147)
at com.softwareag.xtools.xapplication.plugin.Dispatcher.execute(Dispatcher.java:153)
at com.softwareag.xtools.xapplication.jsp.SessionContext.processWorkspaceAction(SessionContext.java:376)
at com.softwareag.xtools.xapplication.jsp.taglib.ModuleTag.processDocumentAction(ModuleTag.java:291)
at com.softwareag.xtools.xapplication.jsp.taglib.ModuleTag.doStartTagCore(ModuleTag.java:95)
at com.softwareag.xtools.xapplication.jsp.JspTag.doStartTag(JspTag.java:132)
at org.apache.jsp.create_jsp._jspx_meth_xapp_module_0(create_jsp.java:104)
at org.apache.jsp.create_jsp._jspService(create_jsp.java:82)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:137)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:204)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:260)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:432)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:386)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:534)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:530)
at java.lang.Thread.run(Thread.java:536)
Is this how it works or am I doing something wrong? Is there a way to overcome this error.
Thanks
Elsabe
Hello,
you gave the right description: If two schemas share element names, X-Application returns this error of ambigous elements.
The only way currently to solve this problem is working without schemas. This may be possible for your application if you can avoid functionality that requires schema support (e.g. creating empty documents, using loop tags).
Bye,
Christian.
Hi
I wonder if my problem was not something else.
We have ‘entity’ schemas and ‘code’ schemas. An ‘entity’ schema is something like Employee, Organisation etc. and code schemas are things like Title, Account Type etc. We have these code schemas in order to create dynamic selection lists (drop down) in the capture of the entities.
Initially we had the code schemas as only a root element for example
<title>Mr</title> </pre>.<BR><BR>We then have an element in the Employee also called <pre class="ip-ubbcode-code-pre"> <title> </pre>.<BR><BR>Seperately each work fine but together in the same xapplication.xml the title document gave the ambiguous error.<BR><BR>If I change the schema of the title document to be <BR><pre class="ip-ubbcode-code-pre"><TitleCode>
<Title>Mr</Title>
</TitleCode>
then even though both TitleCode and Employee have an element named there are no errors.
Anyway, it seems I have overcome the problem.
Regards
Elsabe