Michael Powe

Originally posted by Bear Bibeault:
How so? Srikkanth Mohanasundaram showed you a way to do it with the EL rather than scripting.

Sorry, probably careless usage on my part. I am thinking in terms of a purely tag-based approach and to me EL looks like script. Even though, it is not classed equivalently with scriptlets.

Thanks.

mp

The param attribute of the jsp:setProperty action refers to the name of the request parameter...But you have a request attribute named user

Bingo. I knew I had to be doing something simple yet wrong. Thank you very much. You know, I posted this question over at Sun Forums twice, lots of looks and no answers. I've obviously been spending too much time with the wrong crowd!

It does not appear that I have any way of passing in attributes without resorting to scripting. That is annoying. I'll have to rethink my approach.

Thanks again.

mp

Hello,

I have a JSP with the following tags:

<jsp:useBean class="org.trollope.DbAccess" id="dba2"> <jsp:setProperty name="dba2" param="user" property="jdbcUser"> </jsp:setProperty> </jsp:useBean>

The setter doesn't work -- I just get

null

when I retrieve the property:

Bean property is: <jsp:getProperty name="dba2" property="jdbcUser"></jsp:getProperty>

However, if I insert this scriptlet immediately after the "useBean" tag, the property is set and I can retrieve it using the above getProperty tag:

<% String str = (String) request.getAttribute("user"); dba2.setJdbcUser(str); %>

So, without scriptlet, output is:

Bean property is: null

With scriptlet, output is:

Bean property is: powem

I really want to know what I am doing wrong and would appreciate any tips. One thing it has occurred to me to note is that this page is actually being called through RequestDispatcher.forward() in a servlet. I don't know if that matters or not.

I'm writing this in NetBeans 5.5, using the bundled Tomcat, 5.5.17.

Thanks.

mp
[ May 19, 2007: Message edited by: Michael Powe ]

Originally posted by vivek gaur:
how do i write this recursive method .
please advice me technically.

Hmm, this sounds suspiciously like a homework assignment.

since a recursive method works by calling itself, in a general way, you write a method that lists the objects in a directory, examines each object in the list and, if the object represents a directory, calls itself again on that object, lists the objects in that directory, examines each object in the list, and if the object represents a directory, calls itself again ... and so forth. the tricky part is always that there must be a point of return, so that the recursion returns to the top when there are no more directories to process.

how does java handle the recursive function, when it compiles the class? i believe that some 'c' compilers unroll the recursive function and turn it into standard loops because recursive functions can be extremely inefficient in use of resources when called directly. however, in terms of comprehensibility of the original source code, they are far more useful.

well, i went to google, my home-away-from-home, solver of many homework assignments, and typed in 'java list directory recursive' and got these pages in the top 7 results:

Java Practices: Recursive file listing

Java Forums - How do I list directory contents?

Java Programming, Solution to Programming Exercise

Every time this routine finds a directory, it lists not just the name of the directory but also, recursively, the names of everything that it contains. ...

Java: Example - Recursive List

Here is an example of listing files and directories recursively. ... i

Traversing the Files and Directories Under a Directory (Java ...

so, my answer is, you should start there. then, ask specific questions about the parts you don't understand and post the code that gives you problems.

thanks.

mp

background:
i have to do some processing of large text files -- 1 GB and larger, and i'll be processing as many as 12 in a row. "larger": i have one file that is 3.5 GB. something like, going through a directory of these files and processing each one.

i'm trying to work out how i can do this efficiently, and NIO seems like the good bet. i already have written an application to process these files using standard i/o. it pegs my cpu and takes a very long time. that wasn't a showstopper for an occasional single file, but now i have to do it in a production environment daily, for a dozen or more files.

my "processing" is mostly filtering (examine the contents of a field and throw out the lines that contain specific data), and occasionally swapping the contents of two fields. therefore, my feeling is that i/o is causing the performance crisis.

therefore, my thought was to memory-map the files in chunks, in read and write buffers, and do the processing between these maps. from my reading, my understanding is that changes in the write buffer are written back to the disk copy automatically.

problem:
after spending a good number of hours today, reading about NIO through online resources, i can't figure out a design for accomplishing this. there's lots of high-level overviews with code snippets, but no practical problem-solving demonstrations with NIO.

1. can anyone suggest a good design for accomplishing my task? i understand that i need to open a channel on a FileInputStream to read and on a FileOutputStream to write, but i don't understand how to set up a buffer that i can process line-by-line. i have to process the files line by line.

2. how do i read the file in chunks? it's not clear to me that i have a pointer in the disk copy that functions like a cursor in a record set. i know i have a 'position' pointer in the buffer. from the file-reading standpoint, it would seem to make most sense to simply reuse the same buffer.

2. how significant is the size of the buffer? i tried creating a 200MB buffer, but it blew up the VM:

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space

i have no notion of how much buffer is enough and i found no discussion of this topic.

3. i can't find any line-oriented functionality in NIO. how can i preserve line integrity when reading from and writing to byte or char buffers?

of course, i may be completely on the wrong track, and NIO may not be the answer, too.

thanks very much for any help. i've spent most of my saturday whipping this horse, and it's just not moving. ;-)

mp

Originally posted by JAY asasd:

There must be some way to create an in memory file though right !? One that is basically the same as a disk file but that is managed in memory rather than disk ?

you can use java.nio.*, the "new" i/o classes, to memory-map files.

public abstract MappedByteBuffer map(FileChannel.MapMode mode, long position, long size) throws IOException Maps a region of this channel's file directly into memory.

Is there a unix way to create a temporary file that I could access using runtime.exec() ?

there are all kinds of ways to make "temporary" files. getting rid of them when you're done with them is usually more of an issue, judging by the way my /tmp directories fill up. ;-)

see

public static File createTempFile(String prefix, String suffix) throws IOException Creates an empty file in the default temporary-file directory, using the given prefix and suffix to generate its name.

thanks.

mp

Originally posted by Shailesh Deshpande:

Is there any way we can access the image file from the java class, while bundling it in the EAR file?

ServletContext context = session.getServletContext(); String realContextPath = context.getRealPath(newPage);

in some circumstances, this will give you the actual path to the image. i do not know anything about EJBs. however, in JSP, my experience has been that the file has to be somewhere where the "real path" makes sense -- you have to have access to in within the web server context. (e.g., you probably won't be able to access the file if it's on the root directory of the server.) you may be able to determine the real path to the file without actually being able to access it.

thanks.

mp

Look at the File API for createTempFile. I don't think there's any reason that the file has to be "temporary." I'd say you can put it in any directory and keep it as long as you like.

In fact, it's not temporary unless you explicitly call deleteOnExit(). The only drawback I see to this method is you can't control the filenames. You control the first 3 chars and the extension, but the rest of the filename will be gibberish.

I might suggest writing a temp file and then renaming it using some convention that makes sense in the context in which the files will be used.

thanks.

mp

you need the "new" i/o (java.nio.*), which includes memory mapping of files for faster reads/writes.

i'm on the same search myself, actually. there are plenty of "high-level" overviews of this topic but precious little detail. i need to be able to parse and process 1+ GB files in real time. ;-)

Here's a tidbit:

File Management Made Easier

thanks.

mp

"it" is not ignoring spaces -- spaces are characters just like another element of text. if you read a line into a String and the length method returns 654, it means there are 654 characters, including spaces. the likelihood is that the tool creating the file truncates trailing spaces -- most decent text editors do this automatically.

there are two approaches to making the String a standard 850 chars. one is to read the string into a StringBuffer and then simply append chars to the required length. this would be quite easy to do, i think.

the other is to insert some boilerplate text like 'n/a' into the empty fields. to do that, you'll have to parse the lines and find the empty fields. the regex package may be a good tool to accomplish this.

make a template out of the required fields, parse the existing line and determine which fields are empty and fill them. of course, that implies that you have a means of distinguishing the contents of the fields, in some way being able to identify which fields have been left blank.

thanks.

mp

Caution: Happy Fun Ball may suddenly accelerate to dangerous speeds.