M Kozelek

Greenhorn
+ Follow
since Feb 08, 2005
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by M Kozelek

I've tried this link and there is nothing there. Is this group still offering this study on certification?
Ok, here is my latest attempt and the output. I'm using a FileInputStream because it doesn't return null like the InputStream alone does.



The result is the following:



Is there something here that I am missing? It seems I can get to the file and write it's content out, but I can't do anything else.
13 years ago
I am running this application off the binaries in a expoleded format external the tomcat program. In a totally other location on my local hard drive. The only relationship between my files and tomcat's is the context xml that points tomcat to my classes.

The conf.xml is a physical file located on my local file system. I am manipulating it in Netbeans, running tomcat from netbeans, and debugging from the IDE as well.

I have tried to access this physical file in every way I know how so at this point I'm at a loss. The debugger is now showing that the classes are not null, but they don't have any real state either. Just the default initial values.
13 years ago
So what is the difference between storing the path in the env-context and just giving it a hard-coded path.

I've tried hard coding it just to get there, but that doesn't return a stream either. The input stream is always null.

Does putting the path in the serlvet context somehow manipulate permissions to the file as well that normally wouldn't be there by just passing a path as a string? The end result of either approach is a String value representing the path anyway, right?

I can't believe how hard I'm making this.
13 years ago
Actually, I may not have been as clear as I should have. The project is not deployed as a war. It is external to Tomcat and Tomcat is using the binaries from a context I set up in:

C:\Program Files\Apache Software Foundation\Tomcat 5.0\conf\Catalina\localhost\myapp.xml.

Don't know from a container perspective if that changes anything. The file is still stored in the WEB-INF/config/conf.xml.

The developer of the API I am using thinks the code looks right but wants me to make sure that the two inputstreams are non-null. Since I was using a reading line by line to the console, that tells me that it is not non-null, but maybe I misunderstand I/O.
13 years ago
Thanks, Balasg. A code snippet would be great. It's been a while since I've worked with the servlet context stuff and I've been pulled away to focus on something else, but will have to resolve this at some point.

In the meantime, I will try to get back up to speed on how the container lets you leverage all the environment setup.

Thanks again!!!

mk
13 years ago
No I haven't tried that. To be honest I don't event know how and would have to spend some time looking that up so I don't end up stuck there as well.

As far as why they need those two instances, here is the private implementation of the method:

13 years ago
Here is the method implementation from the source file:

13 years ago
Okay, I am still testing the inputstream, but it's still not working:

For the code:



This is the result:

13 years ago
Ahh, scratch that. It seems we are using an older library and I was totally ignoring the method description right there in the API online. I downloaded the source files and see that there is a way to create the Xml store from a stream. Testing it out now.

Jeepers...
[ May 11, 2005: Message edited by: M Kozelek ]
13 years ago
I'm actually confused on your servlet. I'm not seeing how the image is streamed to the webpage unless that href is just inserting those bites as a image right then and there since it is a mapping to the servlet and the servlet just returns that stream. I like that approach, though. I'll have to mess around with that.

Please help bridge the gap here then. So I can get the file from behind WEB-INF as long as it is in bytes. However, I the JPreferences API creates the XML file store using the following methods:


Both of these are just string represenations of the path (which is the reason I was trying to use an real/absolute path).

So even if I get the buffered stream back, I'm not sure I can leverage it.

Feeling stuck...

http://my.unidata.ucar.edu/content/staff/caron/prefs/javadoc/index.html
13 years ago
Ok, so are you saying that in using getRealPath(), I would always pass a string representing a single resource (e.g. "conf.xml instead of "config/conf.xml")? If that is the case, all of the resources would have to be stored in <<web-app>>/web, correct?

In the end, what I would like to acheive is a conf.xml file accessible only to the app and not the browser. I don't want clients hitting http://blah/conf.xml and seeing all of the preferences. So I may be setting this up wrong to begin with since I am storing it in my application under <<web-app>>/web/config.xml. Maybe it should be moved to WEB-INF somewhere.

Also, I don't want to retrieve the resource by making an external http request to get it either. I just want to point the location locally via an application relative path or absolute if there is no alternative.

If I use the getResourceAsStream() and create a new File() from the result, and then use that file to create my XmlStore(), I should be golden, right? That method will give me access from a servlet to any file in the app or server file system (assuming proper rights).

Am I getting warmer?
13 years ago
Thanks for the response. Here is the output for the real path:


When I add a BufferedReader to read and display the file contents, it is able to show me everything. When I try to access a value from the key defined in the XML for JPreferences, it acts like I can't. This may be a preferences BackingStore issue. Do you happen to know if I need to configure preferences differently for a web-context v. stand-alone. The code works in stand-alone app.
13 years ago
Hello, I am trying to use a servlet to access a file called conf.xml. This is used to initialize the JPreference classes I am testing.

The servlet is using the servlet context's getRealPath() to find the location of the file: <web-app>/web/config/conf.xml. If it makes a differences, the web-app is running from a set of binaries configured as a context within the servlet container and not deployed as a war.

For some reason, it doesn't seem like the servlet is accessing the conf.xml. However, I am not gettting a FileNotFoundException either.

I am inlcluding my code at the bottom of this post. If this question is better suited for the Apache/Tomcat, Open Source Tools, or some other forum, please accept my apologies for posting here. I feel like it is a servlet issues having to do with accessing files, but maybe it is something specific to JPreferences or Tomcat.

Thanks!



The result is always "No name was supplied".
13 years ago
Yes, the Map() solution is now feasible. I spoke with a contact from the vendor and the solution finally emerged.

The actual problem, is that I can't pass parameters in the report designer. So even if I had a Map(), I would have nothing to pass it in order to get the value back I want.

At least this is what it seemed at first. There is a way of faking it with this tool where I can force the product to read a parameter not associated with the process (what at first was interpreted as a constraint), and use that to store a value.

From the design time perspective, this is a little cumbersome still, but at run-time this will be awesome.

So thank you for your help everyone.. well except Gerald that is.

I've taken care to make sure that we can rip and replace the report engine if necessary without impacting the code too much. However, I didn't follow any formal pattern.

Is this a case of Adapter, Strategy, or something else? I'm not very experienced with patterns obviously, but I was looking into these to see if there was anything they provided that I may not be accounting for.

Thanks again!!!

mk