[Bill]

Hi,

I’m writing an app in WebSphere that dynamically creates reports saving the necessary files in a special directory in the context root of the app (i.e., context-root/reports/…). This directory has no other content but subdirectories for each user and each report requested. This is working with no problem.

However, there is a serious problem when using the Blue IDE to redeploy the app. When I do this, my dynamic directories (below context-root/reports/) are left unaccessible. The subdirectories remain on disk but all type of access is denied.

I’m deploying exploded. I have three principal questions.
1) Is this normal behavior?
2) How do I redo the security parameters for the orphaned directories so I can work with them?
3) Could this happen in production? If so, how do I get around this? I don’t see how it’s possible to make these report files accessible from a directory above the context-root.

I’m developing on Windows Server 2003 and I’m logged on as the only administrator account.

Please advise.

Thanks, Bill

[Brian Fernandes]

Bill,

Could you please clarify – you say your dynamic directories are inaccessible. Are you talking about the directories in your project, the ones that reside in your workspace? Or are you saying that your application can no longer write to those locations in the running (i.e. deployed) location?

What happens if you stop the Websphere server – are they accessible then?

What version of WebSphere are you deploying to. and what version of Blue are you using? Is Blue being started with admin rights? I’m not familiar with Windows 2003 – but in an OS like vista, you need to explicitly start with admin rights even when running with an admin account.

[Bill]

Hi Brian and thanks for responding.

Here’s what it looks like:

app.ear
 - app.war
  - img (dir)
  - META-INF (dir)
  - WEB-INF (dir)
  - reports (dir created by app, the problem is below this level)
   - user1 (dir)
    - report1 (dir)
     - report content files...
    - report2 (dir)
     - report content files...
  - user2, ... userx (same as user1)
 - app.jar
  - ejbs, etc..
- META-INF (dir) 

The problem drectories are NOT part of the deployed project; they are created dynamically at run time within the reports directory.

Neither the application nor a standard Windows explorer can access what is under the reports directory. Doesn’t matter if WebSpere is running or not.

WebSphere version is 7.0
Blue is 7.5 Build id: 7.5-Blue-20090609

I’m launching blue after logging on as the only administrator account on the system (it must have all rights).

Thanks again for the reply and hope to hear something more from you soon.
Bill

[Brian Fernandes]

Bill,

There appears to be something wrong with the way folders/resources are being created by your app. If they still cannot be accessed even when WebSphere is not running, that is very odd indeed – are you sure that websphere is not running when you checked this?

I’m afraid I can only give you a few suggestions that may help shed some more light on the issue:

1) Try creating reports under another folder instead of “reports”
2) Create a simple folder under context root and put some regular file in it at runtime, use simple java.io methods, are those resources accessible?
3) Create a reports directory inside your webapplication (before deployment) – does that help?

[Bill]

Brian,

Here’s a bit more information. I’ve had the need recently to reboot my development server (I don’t like to do it unless absolutely necessary). But anyway, when rebooted, the problem directories (those below reports) were no longer there. I’ve heard of these “shadow” directories that really don’t exist but the OS thinks they do.. until rebooted.

So my development problem is more or less solved (albeit for a forced reboot) but my potential production problem is not. So here’s de $64,000 question…

When WebSphere deploys an EAR or WAR, does it respect the underlying directory structure that may have been created in the web context root?

If not, how can I make these files accesible outside the web context root?

I really do not want to have to give special instructions to the systems operators to move the directories before deploying and restore them after. They’ll go into brain freeze and half the time it won’t get done correctly.

The production system is on SLES 9.0. Novell Suse Linux server.

Any suggestions?

Thanks,
Bill

[Author]

Posts