× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi all,

Trying to help a friend out but I'm not a WAS/Java person so any help would
be appreciated. They're running WAS ND 6.0 on a 520 using WDSC for
development.


Here is a summary of the issues we are trying to resolve.


1. Java Security Policy: We use a file upload utility to allow
intranet users to upload/maintain certain content, typically in the form of
MS Word, MS Excel, Adobe PDF documents, etc... We can make this work in the
context of the EAR deployment, but when we go to redeploy/modify the EAR
file, it *removes these files* as they do not exist in the EAR. I
learned how to separate the static content from the dynamic content, but the
java servlet, which exists in the deployed application, cannot read/write
the directories at or below the document root of a given HTTP server
instance. On a Tomcat server, there is a file called "catalina.policy"
where I can *grant applications permission to objects outside of the
application context* such as:

grant codeBase "file:/home/virtual/site6/fst/var/www/html/-" {

permission java.net.SocketPermission "*", "connect";

permission java.io.FilePermission"/usr/java/j2sdk1.4.2_05/jre/lib/ext/mail.jar",
"read";

permission java.io.FilePermission"/usr/java/j2sdk1.4.2_05/jre/lib/ext/activation.jar",
"read";

permission java.net.SocketPermission "SMTPHOST:25", "connect,resolve";

permission java.util.PropertyPermission "*", "read,write";

};

I assume there is a similar mechanism within WAS. I have in fact located
three policy files within
/QIBM/UserData/WebSphere/AppServer/V6/ND/profiles/TEST/properties called: "
client.policy", "server.policy", and "was.policy". The contents are
similar. There are also "was.policy" files in the IBM default applications
such as
/QIBM/UserData/WebSphere/AppServer/V6/ND/profiles/TEST/config/cells/ALUMDIV5_TEST/applications/DefaultApplication.ear/deployments/DefaultApplication/META-INF,
although they do not exist for applications we created. I Googled "
was.policy" and located the following
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/tsec_waspolicyfile.html.
We will be studying this, but if you know someone who can tell us
specifically what to do and how to do it, that would be helpful.

1. When we deploy an application, WAS inserts the application name
into our URL: i.e. http://www.<domain>.com/index.jsp becomes
http://www.<domain>/<appname>/index.jsp where "<appname>" is the name
of our application EAR file. This "feature" is of concern because of
existing bookmarks and the fact that our current search engines rankings are
based on the existing structure. IBM tech support pointed me to Apache
mod_rewrite, but this doesn't seem to be working (I suspect because the HTTP
Server Powered By Apache hands off the request to WAS and is no longer
involved). We must be able to remove the application name from the path,
but we haven't been able to figure out how. Any guidance would be greatly
appreciated.

2. Deploying/re-deploying the EAR file takes approximately 2 hours
(the EAR file is right at 500MB). This is an unacceptable length of time
for the application to be "down". I suppose we could force files into the
directory structure (including web.xml if we create a new servlet)...
are there prescribed methods for partial deployments? Splitting the
application into static and dynamic content (see #1) should also reduce the
size of the EAR file, and we could eventually try to break the existing
application into multiple smaller applications, but this creates other
issues within the Studio product. I can't imagine that our site would be
considered "large" in the grand scheme of things. What can be done to
reduce the time required to deploy?

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.