Hi all,
I have seen alot of questions on this list about how to get Orion to run. I
have also seen these on other lists (jsp, struts). So I am going to "paste"
my config files that I have on my local box that runs Orion. These are
strictly my settings..there are probably other ways to get Orion to run.
Ok..so, the first step is to setup some sort of "start" script. I created a
.bat file (assuming your in MS Windows) that looks like so:
c:\java\jdk13\jre\java -jar orion.jar -console2
This is saved in the c:\orion dir, (that is where i have orion installed).
Create a short-cut on the desktop to this and your ready to start orion (as
an application..not a service). If your using linux, unix, etc..you may have
some different way of doing this. Sorry..I haven't tried doing so on a
different platform yet.
Now, there are a few config files you need to "modify". Like I said..my way
of doing it works, but it may not be the same way some other people have
done it.
Here is the paste of server.xml which resides in /config of orion root.
***********************************
<?xml version="1.0"?>
<!DOCTYPE application-server PUBLIC "-//Evermind//DTD Orion
Application-server//EN"
"http://www.orionserver.com/dtds/application-server.dtd">
<application-server>
<library path="../lib" />
<rmi-config path="./rmi.xml" />
<data-sources path="./data-sources.xml" />
<principals path="./principals.xml" />
<log>
<file path="../log/server.log" />
</log>
<transaction-config timeout="30000" />
<global-application name="bm" path="c:\\bm\\" />
<global-web-app-config path="global-web-application.xml" />
<web-site name="bm" path="./bm_web.xml" />
<cluster id="124" />
</application-server>
************************************
You'll notice that I deleted some things, and I am also not using the
default-web-site.xml file. I chose to do this myself. So, the
global-application MUST be there. I changed it from default to bm, which is
the initials of the company I work for. I also set the path to a local dir,
instead of inside the orion dir. I prefer this because we are still
evaluating app servers and I don't want to be dependent on a specific dir
under an app server. It also allows me to sort of organize a standard dir
for all of our developers so that its in sync if we copy it from one place
to another. Ofcourse we could do this if it was under the Orion folder as
well..but people may install orion in different drives, paths, etc. This
way, the root is always c:\ and its easily changeable. The rest of the tags,
except the <web-site..> tag are part of the original server.xml file. I did
add the <cluseter id="124" /> to cluster my orion app server with another
box for fail-over. I'll write up on that some other time..I have a few more
things to learn about how Orion does this before I can write up on it.
Lastly, web-site name="bm" path="./bm_web.xml" />..I decided to leave the
web-site config file in the /config path..it is an Orion specific config
file, so it won't move to other app servers if we go to another app server.
You can add more of these <web-site..> tags if you like if you have other
web sites to deploy under one instance of Orion.
Now, in c:\bm\ I have a few dirs. I run our internal admin site as well as
our www production site with a single instance of Orion, and to
"standardize" and organize our dirs (as well as preparing it for a .ear
format), I have structured the dir like so:
c:\bm\live-www
c:\bm\admin-www
c:\bm\properties
c:\bm\logs
c:\bm\META-INF
The application name is BM, as depicted in the server.xml
<global-application> tag. Its path is c:\bm, and thus a META-INF dir must be
present. In META-INF I have one file, application.xml. This is a J2EE
standard application deployment descriptor. Orion creates 3 other files when
an application is deployed that are specific to Orion. These I'll leave for
you to look at. My application.xml config file looks like so:
*****************************************************
<?xml version="1.0"?>
<!DOCTYPE application PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE
Application 1.2//EN" "http://java.sun.com/j2ee/dtds/application_1_2.dtd">
<application>
<display-name>bm</display-name>
<module>
<web>
<web-uri>live-www</web-uri>
<context-root>/</context-root>
</web>
</module>
<module>
<web>
<web-uri>admin-www</web-uri>
<context-root>admin/</context-root>
</web>
</module>
<security-role>
<role-name>administrators</role-name>
</security-role>
<security-role>
<role-name>users</role-name>
</security-role>
</application>
*********************************************************
The only thing I modified was the <display-name> tag to put the name of my
application BM in there. I also added two <module> tags. Please read about
application.xml in the /docs dir of Orion. In my situation, I deployed our
internal admin site as well as our production site (although..we are not
using Orion at this time..this is just locally on my box). Because of the
nature of servlet contexts, I am able to do this with a single instance of
Orion, with our admin site in one context while our production site has its
own context. Infact, I have the admin site using 3 contexts, one for /radio,
/tv and /cable, as you'll see in the bm-web.xml file momentarily. Now, the
module <web-uri> names are specific to the bm-web.xml config file (I'll list
that next). The names are the actual dir names where the www files (jsp,
html, images, etc) are located. The <context-root> tag identifies the
relative path to that dir from the application root dir. In my case, this is
c:\bm. So, there will be a dir called c:\bm\live-www and c:\bm\admin-www.
This file is also a J2EE standard so it should work across application
servers. The rest of the tags are part of the orion recomendation of
application.xml, or should I say..I got it from their default-web-app if I
recall correctly. Don't hold me to it though.
Next up is the bm-web.xml config file, also located in the /config file. As
I explained above, this is specific to Orion, so I keep it with the orion
config files. Here is that listing:
*************************************************
<?xml version="1.0"?>
<!DOCTYPE web-site PUBLIC "Orion Web-site"
"http://www.orionserver.com/dtds/web-site.dtd">
<web-site host="[ALL]" port="80" display-name="BuyMedia.com Admin Cable
Site">
<default-web-app application="bm" name="live-www" />
<web-app application="bm" name="admin-www" root="/admin/radio/" />
<web-app application="bm" name="admin-www" root="/admin/tv/" />
<web-app application="bm" name="admin-www" root="/admin/cable/" />
<access-log path="c:\bm\logs\bm-web.log" />
</web-site>
****************************************************
This file basically sets up the location of web-apps (servlet 2.2 contexts)
as well as the port and ip address and some other settings. The host="[ALL]"
can be changed to direct a specific IP address (and you would use two or
more of these files, one for each IP address, if you want to setup multiple
IPs for individual web-apps..yet another topic to discuss one day). So, the
"default-web-app" tag has to be part of this .xml file, and it represents
the root web site to display. That is, www.mycompany.com goes to this site.
As I said above, notice the name of the application is BM, like it was in
application.xml and server.xml, and notice the name is "live-www". This is
also the same name as that in application.xml in the <module> tag. These
need to match. The next three tags are to set up separate web-apps. Each of
these represent a different servlet context. Keep in mind that each context
can not be shared or accessed with other contexts, so if you do this, make
sure if a user needs access to two or more of these contexts in one
session..it wont work. So do not make the mistake of assuming different
web-apps share the same session for an individual client. It would be nice
if there was an easy to to share "global" information amongst all web
contexts, and I was told there is a way using some specific classes in the
JDK, but it wasn't as easy as ServletContext.setAttribute() and
getAttribute(). Before Servlet 2.2, you couldn't run more than one web-app,
but all servlets (and jsp pages) had access to the "global" servlet context
to share data. The last thing in this config file is the root="/admin/radio"
setting (and /tv and /cable). This is the access root to get to that web
app. Thus, by typing in www.mycompany.com/admin/radio, you get to the
admin-www index.jsp page. Notice in my case, I have all 3 paths going to the
same one dir. This is because all three contexts use the exact same pages.
The only difference is, in my jsp pages I include a header on every page,
that has some special scriplet code that keeps track of the specific media
they are in. Thus, I store a String MediaType object in the context of each
of the 3 web-apps, that allows me to identify in every JSP page in
admin-www, what app the client is in. This is mostly for conditional display
of media specific forms. For example, even though all three use the same
index.jsp page, I may choose to display a DATE field, for example, if the
user is using the /admin/radio context, but not the other two. I do this in
my jsp scriplet code by grabbing the context URI path, and if the path of
/admin/radio is in the URI string returned, I would display something
specific to that web-app. This allows me to use one www structure
(admin-www) with 3 web-apps. An important reminder (if I have repated it
once..I have repeated it 1000 times), each web-app has its own context, thus
even though they all 3 share the same one www dir on the hard drive, they
don't have access to the same session information. I suppose its possible to
share data by storing info through some sort of file in the admin-www dir,
but that isn't thread safe. Before I end this..notice the very last
tag..its just the location of where the orion web log is stored. You can
look at this for statistics on hits and stuff I believe. I don't know it
well however.
The orion-web.xml file is automatically created for you when you first start
orion and it deploys your app. There are some changes that I am not sure if
they can be set elsewhere, but you may need to manually set them. First, you
might like to know the feature I hope I inspired in getting put in for Orion
(although I know others had say in this too). That is, a feature Resin had a
while back that I thought would be great for Orion...auto-reloading of
classes when they are modified. This means you don't have to restart Orion
every time you make a change in code. However, the downside is that you do
have to make sure all your classes implement the Serializable interface so
that Orion can persist them across restarts. Unfortanately if you already
have alot of code, this will entail some work on your end to get your
classes to do this. On the other hand, I think all classes should implement
Serializable..its a good thing. RMI uses it, as well as you can use it to
send your classes via http to applets (for special use, such as sending
clients messages, keeping track of their position on the site, etc).
Anyways, to get this feature working, you need to set up a setting in
orion-web.xml (somebody correct me if this can be set elsewhere that gets
Orion to automatically set this when it creates orion-web.xml). First, you
need to set the development attribute to true. Next you need to set the
source-directory attribute to the specific location on your hd where the
source code resides that when compiled becomes the code for the particular
web-app you are setting this for. In my case, I put my source in
c:\bm\source\code. I set the compiler output to either
c:\bm\live-www\WEB-INF\classes, or c:\bm\admin-www\WEB-INF\classes and
compile the code. In orion-web-app I set the attribute
source-directory="c:\bm\source\code" for both apps. Now, if the code
changes, Orion automatically compiles the .java source and deploys it to
Orion (but only if its Serializable objects). The nice thing about this is
that it checks all source, not just servlets and javabeans. If you modify
some "core" code, Orion picks up on this and recompiles that code for you.
My only complaint is that I am unaware of exactly how the process goes. I
often modify some code, save it and compile it. I then restart the server. I
then have to log in again (if the code is accessed by jsp pages that require
me to be logged in to get to), and see the change. This doesn't take long,
but it is FAR nicer to just modify the code, save it and have Orion compile
it and deploy it for me. Then I don't have to log in..its immediately
available to see. If anyone knows this particular process and can explain
it..that would be great. Below is my orion-web.xml that exists in both
admin-www and live-www web-apps for me.
*******************************
<?xml version="1.0"?>
<!DOCTYPE orion-web-app PUBLIC "-//Evermind//DTD Orion Web Application
2.2//EN" "http://www.orionserver.com/dtds/orion-web.dtd">
<orion-web-app deployment-version="1.1.32" development="true"
jsp-cache-directory="./persistence" temporary-directory="./temp"
servlet-webdir="/servlet/" source-directory="c:\bm\source\code">
<session-tracking autoencode-absolute-urls="true" />
</orion-web-app>
***********************************
One thing to note..since I can't get my code to reload because not all of my
classes implement Serializable, I don't use this setting right now. Because
of this..I don't know if you can use drive:\path, drive:\\path, or
drive:\path\ or drive:\\path\\. You'll have to play with it. If anyone knows
this..please share it.
I won't explain web.xml. For me, it looks like this for each app:
**************************
<?xml version="1.0"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application
2.2//EN" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">
<web-app>
<servlet>
<servlet-name>action</servlet-name>
<display-name>action</display-name>
<servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
<init-param>
<param-name>debug</param-name>
<param-value>0</param-value>
</init-param>
<init-param>
<param-name>forward</param-name>
<param-value>org.apache.struts.action.ActionForward</param-value>
</init-param>
<init-param>
<param-name>config</param-name>
<param-value>/WEB-INF/action.xml</param-value>
</init-param>
<init-param>
<param-name>application</param-name>
<param-value>org.apache.struts.action.ActionResources</param-value>
</init-param>
<init-param>
<param-name>mapping</param-name>
<param-value>org.apache.struts.action.ActionMappingBase</param-value>
</init-param>
<init-param>
<param-name>nocache</param-name>
<param-value>false</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>action</servlet-name>
<url-pattern>*.do</url-pattern>
</servlet-mapping>
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
<taglib>
<taglib-uri>/WEB-INF/bm.tld</taglib-uri>
<taglib-location>/WEB-INF/bm.tld</taglib-location>
</taglib>
<login-config>
<auth-method>BASIC</auth-method>
</login-config>
</web-app>
******************************************************8
I am using the jakarta Struts framework, and this is how I have it mapped.
Incase anyone reading this wants to use Struts, just make sure struts.jar is
in the WEB-INF/lib dir of your web-app, and struts.tld is in the WEB-INF dir
of your web-app. Also, Orion had a slight problem with the use of Struts in
the pre 1.0.3 version, so you may want to get one of the latest versions of
orion.jar (www.orionserver.com/orion/orion.jar..copy it over the
/orion/orion.jar..possibly backing up the old one before doing so) for it to
work.
Here I am just mapping a servlet to the apache struts controller servlet,
and I map an extension to that servlet name in the web.xml config file
(*.do). This way any of my links that have a *.do extension are directly
sent to the controller servlet for processing. Read up on struts if you are
interested in how this works.
Anyways..I am open to any questions, as well as any corrections in what I
have said if anyone needs help. I hope this helps at least one other person
out there. Orion is a kick ass product and its progressing very nicely, but
the one area lacking, which the Orion team has often acknowledged, is
documentation. If anyone else is decent at writing technically, maybe they
can help the team out as I hope to do if I can. Maybe this doc (with
modifications) can be a more detailed doc on how to get Orion to run. Lets
help out Joseph and others that are all helping the Orion team out as much
as possible by providing more detailed docus on how to get specific things
to work with Orion.
