Reading/accessing a file in Java web service

[Fingolfin]

Hello,
I'm having trouble accessing a file in a Web Service that I'm making:

String dat = "config.xml";
@WebMethod(operationName = "operation")
public String[] operation(@WebParam(name = "parameter")
String parameter, @WebParam(name = "parameter1")
String parameter1) {

try {
fis = new FileInputStream(dat);
print = "File found";
} catch (FileNotFoundException ex) {
print = ex.toString();
}

After executing at the client there is a following error:
Result1 = java.io.FileNotFoundException: config.xml (The system cannot
find the path specified)

The config.xml file is currently both in root and in WEB-INF folder and
still the file can't be found.

The same code works _perfectly_ in ordinary Java Main Class in Java
(non-web) Application.

Am I writing the path wrong or something else?

 

[Arne Vajhøj]

I'm having trouble accessing a file in a Web Service that I'm making:

String dat = "config.xml";
@WebMethod(operationName = "operation")
public String[] operation(@WebParam(name = "parameter")
String parameter, @WebParam(name = "parameter1")
String parameter1) {

try {
fis = new FileInputStream(dat);
print = "File found";
} catch (FileNotFoundException ex) {
print = ex.toString();
}

After executing at the client there is a following error:
Result1 = java.io.FileNotFoundException: config.xml (The system cannot
find the path specified)

The config.xml file is currently both in root and in WEB-INF folder and
still the file can't be found.

The same code works _perfectly_ in ordinary Java Main Class in Java
(non-web) Application.

Am I writing the path wrong or something else?

Yes.

No path in file name => default directory for server process => not
root or WEB-INF of your web app.

I suggest putting it in WEB-INF/classes and open it as
resource instead of using FileInputStream.

Arne

 

[Fingolfin]

Yes.

No path in file name => default directory for server process => not
root or WEB-INF of your web app.

I suggest putting it in WEB-INF/classes and open it as
resource instead of using FileInputStream.

Arne

Thanks for the suggestion,but I was focused on using FileInputStream
because I had an interface and a class that was using it.

I realized that i could perhaps access the path through servlet context,
and I stumbled apon (After hours of searching):

@Resource private WebServiceContext wsc;

and in the operation:
MessageContext ctxt = wsc.getMessageContext();
ServletContext req = (ServletContext) ctxt.get(ctxt.SERVLET_CONTEXT);
String realthapth = req.getRealPath("WEB-INF");

 

[Arne Vajhøj]

>
Thanks for the suggestion,but I was focused on using FileInputStream
because I had an interface and a class that was using it.

You interface and class would be more general if they took an
InputStream so you could use both a FileInputStream and a
classloader resource stream.

I realized that i could perhaps access the path through servlet context,
and I stumbled apon (After hours of searching):

@Resource private WebServiceContext wsc;

and in the operation:
MessageContext ctxt = wsc.getMessageContext();
ServletContext req = (ServletContext) ctxt.get(ctxt.SERVLET_CONTEXT);
String realthapth = req.getRealPath("WEB-INF");

You could do that. But unless you are really hard tied
to FileInputStream, then it is not the best solution.

Arne

 

[Fingolfin]

Fingolfin wrote:

You interface and class would be more general if they took an
InputStream so you could use both a FileInputStream and a
classloader resource stream.

You could do that. But unless you are really hard tied
to FileInputStream, then it is not the best solution.

Arne

Ok, to be completely honest, I didn't make the interface myself and
would like to keep it as it is because of that reason to save time. But
for the future reference thanks for the advice!

 

[Lew]

Ok, to be completely honest, I didn't make the interface myself and
would like to keep it as it is because of that reason to save time.

That could very well be a false economy. Remember, suboptimal choices also
cost time. The time lost due to keeping a more concrete type in the interface
could readily overwhelm the time saved.

Google "technical debt".

 

[Fingolfin]

That could very well be a false economy. Remember, suboptimal choices
also cost time. The time lost due to keeping a more concrete type in
the interface could readily overwhelm the time saved.

Google "technical debt".

Indeed. However, to my luck this project is rather very small and
won't be expanding any further in that direction so that a need for
something else appears.

Thanks for the note though!

 

[Arne Vajhøj]

Indeed. However, to my luck this project is rather very small and
won't be expanding any further in that direction so that a need for
something else appears.

Look out. It has happened many times that some code has been
quickly slapped together because it should only be used for
6 months and it would never need new functionality. And
10 or 20 years later the maintenance programmer are
struggling to squeeze tons of new features into it.

Arne

 

[Fingolfin]

Look out. It has happened many times that some code has been
quickly slapped together because it should only be used for
6 months and it would never need new functionality. And
10 or 20 years later the maintenance programmer are
struggling to squeeze tons of new features into it.

Arne

I can't argue with you guys because you are correct and I know it, so I
will adjourn and take your advices into account.