vif-devel Mailing List for VIF (Page 7)
Brought to you by:
aktion-hip
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(6) |
Sep
(25) |
Oct
|
Nov
|
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
(4) |
May
(9) |
Jun
(2) |
Jul
(3) |
Aug
|
Sep
(2) |
Oct
|
Nov
(1) |
Dec
|
| 2004 |
Jan
(1) |
Feb
|
Mar
(4) |
Apr
(9) |
May
(4) |
Jun
(2) |
Jul
(1) |
Aug
(5) |
Sep
(3) |
Oct
(2) |
Nov
(4) |
Dec
(3) |
| 2005 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(9) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2006 |
Jan
(18) |
Feb
(40) |
Mar
(5) |
Apr
|
May
|
Jun
(4) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(6) |
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(9) |
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Farzad K. <to...@sa...> - 2002-09-01 18:37:53
|
Hi Benno Well, It seems that we are going through some discussion to come to a solution for the cvs stuffs and build process. As you said, you're preserving two major goals, first the usability and second the easy deployable project file. Okay, I will discuss the first issue first and point my ideas in this respect. As you said about the Eclipse and the tomcat support, the development is seemed somehow tighten to these two tools as you're structuring the files as the Eclipse is okay with but in general we would be different developers with different IDEs running on our systems and, therefore the project should be somehow well structured so that anyone can find where to go and make changes. At this point we should declare the "well structured" word. You know, when we are talking about source files, we really mean them to be the same project, if they are not in the same project they should be really in different ones, no doubt. So the file structure should talk by itself. Right now, we have two or more source directories. One is the framework and the other is the project files and so far. If the frame work is totally another project, then we put it in another project ( I don't mean another registered project in sf.net ) and the program uses the jar file. Well, you also talked about the licenses. It is so easy, putting the whole sources together doesn't mean that we would put them in the same jar file. We can cope the situation using Ant easily. Ant is capable of handling any strange building process. I will come to this very soon. The other point to mention is this tomcat, I think the way we are organizing the project files is a speciall tomcat-oriented one. I just wanted to deploy the project on JRun4 and I encountered couple of problems. The very first thing was I had to put the deployed file's directory in the classpath, letting the program finding the property files and another point was to set the application context root to vif by hand. I think the problems all stem from current dependency of the project built files to tomcat server which is not the a real production server in most cases. We in the company are using the WAS on iSeries but I think we are crazy to do so. Even the simple OC4J is better than WAS but tomcat by itself is simple servlet container. The build process. To be honest with you, I don't know how a developer is supposed to know how to compile a project source files and get the result jar, war or ear file. I am still confused how to compile the whole project as I am just using IntelliJ IDEA, but with some ant script we keep all developers away from changes in the build process. It is just needed to have the latest build.xml file from the cvs and then you can find everything fine. You see, we have the same problem in the company. The current project we are using in the company is using the Ant for the compiling and stuff like those. The whole process takes about 10 minutes and it does lots of things just as generating soap helper classes, ejb files using XDoclet and running xrpcc on the generated files to have the configuration files and lots of stubs and blob blob files and then everything is compiled and eventually in the dist folder we have three folders, client, server and javadoc. Each one has the needed files to be used and I don't know how the xrpcc is working but I can build the project. In our case, without using Ant, we have to know what exactly to do, (and I mean) not to forget any step to have the correct out files. As far as I know, Eclipse also has some plug-ins for Ant so you can use it as well. Well, I think I have talked too much so I cut it for now and tell me if you are not still convinced :)) I am going to describe more. Thanks, Farzad. ---------------- Farzad Kohantorabi [mailto:to...@sa...] <ICQ#:91712022> |
|
From: Luthiger S. B. <ben...@id...> - 2002-08-31 21:16:21
|
Dear Marc
According to the information in the root cause the application can't =
find the properties file XMLImplementation.properties. This file and the =
other files (vif.properties, GROUPSTATES.xml, ROLES.xml) must reside in =
Tomcat's working directory. The working directory is the directory you =
are in when submitting the command for startup Tomcat. For example if =
you are in /opt/jakarta-tomcat-4.0.4/bin (in this example the directory =
the file startup.sh resides) and you enter the command ./startup.sh, =
this makes /opt/jakarta-tomcat-4.0.4/bin as working directory. But if =
you are in /opt/jakarta-tomcat-4.0.4 and submit the command =
./bin/startup.sh, in this case /opt/jakarta-tomcat-4.0.4 is your working =
directory.
Therefore, the place to copy the files vif.properties, =
XMLImplementation.properties etc. depends on the way you start Tomcat.
Hope this explanation solves the problem.
Regards
Benno
-----Original Message-----
From: Mac...@ao... [mailto:Mac...@ao...]
Sent: Freitag, 30. August 2002 20:14
To: vif...@li....
Subject: [Vif-devel] (no subject)
Hey there;
I set war file in webapps and setup xml and property files in root =
directory and when I run=20
http://localhost:8080/vifapp/admin/servlet?requestType=3DcreateSU&userId=3D=
suId&passwd=3DsuPasswd I get the error;
...
root cause java.lang.Error: XSLTToStreamProcessor not set in =
org.hip.xml.utilities.XSLImplementationSelector and xslt.processor not =
specified in properties file at =
org.hip.xml.utilities.XSLImplementationSelector.getXSLTToStreamProcessor
...
|
|
From: <Mac...@ao...> - 2002-08-30 18:14:05
|
Hey there;
I set war file in webapps and setup xml and property files in root
directory and when I run
<A HREF="http://localhost:8080/vifapp/admin/servlet?requestType=createSU&userId=suId&passwd=suPasswd">http://localhost:8080/vifapp/admin/servlet?requestType=createSU&userId=suId&
passwd=suPasswd</A> I get the error;
Apache Tomcat/4.0.1 - HTTP Status 500 - Internal Server Error
type Exception report
message Internal Server Error
description The server encountered an internal error (Internal Server Error)
that prevented it from fulfilling this request.
exception javax.servlet.ServletException: Servlet execution threw an
exception at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFi
lterChain.java:269) at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChai
n.java:193) at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java
:243) at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566
) at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java
:201) at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566
) at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2344) at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566
) at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.ja
va:170) at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564
) at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564
) at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:462) at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564
) at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:1
63) at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566
) at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:10
11) at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1106)
at java.lang.Thread.run(Thread.java:484)
root cause java.lang.Error: XSLTToStreamProcessor not set in
org.hip.xml.utilities.XSLImplementationSelector and xslt.processor not
specified in properties file at
org.hip.xml.utilities.XSLImplementationSelector.getXSLTToStreamProcessor(XSLIm
plementationSelector.java:96) at
org.hip.kernel.servlet.impl.AbstractXSLView.prepareTransformation(AbstractXSLV
iew.java:118) at
org.hip.vif.servlets.HtmlErrorViewImpl.(HtmlErrorViewImpl.java:52) at
org.hip.vif.servlets.HtmlErrorPageImpl.(HtmlErrorPageImpl.java:49) at
org.hip.vif.exc.VIFExceptionHandlerImpl.handleOther(VIFExceptionHandlerImpl.ja
va:131) at
org.hip.vif.exc.VIFExceptionHandlerImpl.protectedHandle(VIFExceptionHandlerImp
l.java:196) at
org.hip.kernel.exc.AbstractExceptionHandler.handle(AbstractExceptionHandler.ja
va:61) at
org.hip.kernel.exc.AbstractExceptionHandler.handle(AbstractExceptionHandler.ja
va:48) at
org.hip.vif.admin.servlets.impl.VIFAdminRequestHandler.callExceptionHandler(VI
FAdminRequestHandler.java:67) at
org.hip.vif.admin.servlets.impl.VIFAdminRequestHandler.handle(VIFAdminRequestH
andler.java:139) at
org.hip.vif.admin.servlets.impl.VIFAdminRequestHandler.doGet(VIFAdminRequestHa
ndler.java:83) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFi
lterChain.java:247) at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChai
n.java:193) at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java
:243) at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.j
ava:566) at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java
:201) at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566
) at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2344) at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566
) at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.ja
va:170) at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564
) at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564
) at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:462) at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564
) at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:1
63) at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566
) at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:10
11) at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1106)
at java.lang.Thread.run(Thread.java:484)
Thanx Mac
|
|
From: Luthiger S. B. <ben...@id...> - 2002-08-28 09:29:25
|
Dear Farzad I appreciate your intention to clarify the CVS directory structure. However I'm not (yet) convinced of your suggestions. I think before we realize a new directory structure we have to agree on the goal that has to be achieved. The intention behind the actual directory structure is (1) easy usability and (2) ease of deployment. However, usability and deployment is contingent to the IDE and the form of the deliverable. I use Eclipse with Tomcat Plugin as IDE and I want to deliver the application as Tomcat WAR file. Separation of the Java code in various distinct projects makes sense in this context. It allows me easy navigation within the IDE. A further reason to separate framework and application code is that the framework code can be used for other applications too whereas the application code stands for itself. Consistently I've put the application code under GPL whereas the framework code is LGPL. All further resources (e.g. web pages) are organized as Tomcat application in a separate project. Deployment then consists of three steps: (1) I export the compiled framework code to the framework JAR in the Tomcat application project's lib directory. (2) I export the compiled application code to the application JAR in the Tomcat application project's lib directory. (3) I export the Tomcat application project to a WAR file in the deployment directory. The Eclipse features make it possible to export the whole application essentially with three mouse clicks. Therefore I didn't use Ant because I hardly see a use for it (beside of the fact that I don't know Ant very well ;-) ). The Eclipse IDE with Tomcat Plugin has two great features (beside others). The first is debugging. Via Tomcat Plugin I can start Tomcat. I then set some breakpoints in the code and start a browser. I'm then able to follow how the application works at the breakpoints within my IDE. This simplifies testing considerably. Of course this only works on condition that the application is organized like a Tomcat project. The second feature of interest is the seamless integration of CVS into the Eclipse IDE. Within my IDE and with few mouse clicks I can import, checkout and synchronize packages, classes and other files. These two features make it obvious to organize the CVS like my IDE. And that's exactly what it is: a one to one picture of my IDE. If you can convince me that your suggestions increase usability and/or facilitate deployment (for example with the use of Ant), I will agree to your suggested changes. Regards Benno -----Original Message----- From: vif...@li... [mailto:vif...@li...]On Behalf Of Farzad Kohantorabi Sent: Dienstag, 27. August 2002 04:43 To: vif...@li... Subject: [Vif-devel] cvs Hi there Last night I checked out the files from the cvs and I think we can improve the way we store the files. I think the project files are too separated and the necessary ones can not be distinguished. I highly recommend to reorganize the file. I think we don't have to separate the project files from the framework and even the static web pages.=20 My suggestion to do so it: the root of the cvs can contain the following folders: src ( the source file ) resources ( the recourse files, just like property files ) config ( configuration files, just like manifest and deployment descriptors ) script ( contains all necessary script files, just like build files ) lib ( all necessary library files to compile and run the project ) Well, all the related project sources should go under the src folder, the framework can be put in the framework package. The web pages can be also under some web packages. Just, a question might arise here and that how we can get all this together to make a built project file. Well, it is so simple. Ant. I realized the there is not Ant script in the project. To tell it the truth I have not been involved in a project without Ant automated compilation for many years. So I think we can develop an Ant script as well to improve the development. If we do so, then it is not important which IDE we are using, we are compiling the project in the same way. Anyways, I have talked too much. Please let me know how you feel about. Thanks, Farzad. ---------------- Farzad Kohantorabi [mailto:to...@sa...] <ICQ#:91712022> |
|
From: Farzad K. <to...@sa...> - 2002-08-27 02:42:53
|
Hi there Last night I checked out the files from the cvs and I think we can improve the way we store the files. I think the project files are too separated and the necessary ones can not be distinguished. I highly recommend to reorganize the file. I think we don't have to separate the project files from the framework and even the static web pages. My suggestion to do so it: the root of the cvs can contain the following folders: src ( the source file ) resources ( the recourse files, just like property files ) config ( configuration files, just like manifest and deployment descriptors ) script ( contains all necessary script files, just like build files ) lib ( all necessary library files to compile and run the project ) Well, all the related project sources should go under the src folder, the framework can be put in the framework package. The web pages can be also under some web packages. Just, a question might arise here and that how we can get all this together to make a built project file. Well, it is so simple. Ant. I realized the there is not Ant script in the project. To tell it the truth I have not been involved in a project without Ant automated compilation for many years. So I think we can develop an Ant script as well to improve the development. If we do so, then it is not important which IDE we are using, we are compiling the project in the same way. Anyways, I have talked too much. Please let me know how you feel about. Thanks, Farzad. ---------------- Farzad Kohantorabi [mailto:to...@sa...] <ICQ#:91712022> |
|
From: Luthiger S. B. <ben...@id...> - 2002-08-25 20:19:59
|
Hello I just uploaded a new release vif-V0.11 which fixes some problems the = application had on Linux. The changes of the new release are: - Fixed bug which prevented application to run on Linux because of case = sensitive SQL calls to database. - Added password parameter to db scripts thus allowing to run these = scripts for password protected database. - Added source code jars to release. Regards Benno=20 _________________________________________________________________________= ___ Benno Luthiger Informatikdienste - Technologie und Informationsmanagement Weinbergstr.109 ETH-Zentrum, WEP J 11 8092 Z=FCrich Tel: 01 / 632 57 65 Mail: ben...@id... _________________________________________________________________________= ___ |
|
From: Benno L. <ben...@id...> - 2002-08-15 12:49:44
|
Hi The project's CVS root is a little messy and jammed, sorry for that. The directories with relevant content are: VIF/ (java source code for the application VIF) VIF Test/ (java unit tests for the application VIF) VIF Framework/ (java source code for the framework VIF) VIF Framework Test/ (java unit tests for the framework VIF) VIF XML Implementations/ (java source code for the xml implementation layer) VIF XML Implementations Test/ (java unit tests for the xml implementation layer) vifapp/ (Tomcat project) I've organized the java source code into three projects. Each of them has a project assigned containing junit tests. The vifapp directory is a Tomcat project. It contains the html and xslt files. I'm using Eclipse as IDE and I've installed the Tomcat plugin. Organizing the project's ressources this way makes it easy for me to deploy a new project release. I create new java jar files in the directory vifapp/WEB-INF/lib and, after refreshing the vifapp project, I create the vif.war file. Regards Benno |