• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Junilu Lacar
  • Martin Vashko
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Scott Selikoff
  • salvin francis
  • Piet Souris

Just trying to get a file picker dialog running in SpringBoot 2, but it will not load or display

 
Bartender
Posts: 1700
17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

Using another REST (sparkjava.com) framework, I have no problem displaying a file dialog using JFrame or JFileChooser that displays when the user calls the service from an HTTP-enabled application.

Yet, in SpringBoot 2, nothing I've tried has worked.

The advice seems to be to set the System property to "headless", like this:

   System.setProperty("java.awt.headless", "false)

That doesn't work. I still am getting the Headless Exception when I try to open the dialog.

Just to be clear, I understand SpringBoot is a server application, but I'm calling this method from a client. And, again, this technique works fine with other REST frameworks.

---

I also tried to set Headless this way:



Nope, does not work in SpringBoot 2.

Below is the code:



All is fine until the "showOpenDialog(...)", then the Headless Exception.

Perhaps SpringBoot just isn't going to let me do this no matter what I try?

Has anyone overcome this issue and gotten a file picker dialog to display from a client calling SpringBoot?

Thanks in advance,

-- mike
 
Saloon Keeper
Posts: 10863
234
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can you print out the value of the java.awt.headless system property before you show the dialog? Same with the result of the GraphicsEnvironment.isHeadless() method?
 
Mike London
Bartender
Posts: 1700
17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:Can you print out the value of the java.awt.headless system property before you show the dialog? Same with the result of the GraphicsEnvironment.isHeadless() method?



Hey Stephan,

Yep, I had a breakpoint before the dialog opening and "System.getProperty("java.awt.headless")" returned false.

I'm not sure about the GraphicsEnvironment, but I'll look into that as well.

So, in your view, being able to call the service from a HTTP fat client and see the file dialog "should" work, right?

Thanks,

- mike
 
Stephan van Hulst
Saloon Keeper
Posts: 10863
234
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think that method just returns the value of the java.awt.headless system property.

Yes, I think you should be able to run the application in headful mode. I don't know why you would want to though.
 
Mike London
Bartender
Posts: 1700
17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:I think that method just returns the value of the java.awt.headless system property.

Yes, I think you should be able to run the application in headful mode. I don't know why you would want to though.



The use-case is a third party application that does not give the user a way to select a file from the file system.

That third party application calls the service, should get the dialog, let the user select a file, and return that file to the web service client (aka, the application).

Works fine with sparkjava, but not with SB so far.

Thanks,

-- mike
 
Mike London
Bartender
Posts: 1700
17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
UPDATE: The graphics environment reports that headless is STILL TRUE regardless of how I try to set it to false..

Neither Method 1 or Method 2 below works so I can open a File Chooser from a third-party application calling the service.

Method 1: In Java code within the method:



Method 2: Change the Spring Build Configuration:


Neither works.

So, in this code:



The "ge.isheadless()" is always true regardless of method 1 or method 2 at the top.

The code crashes on the showOpenDialog() method call with a HeadlessException.

---

There was one other suggestion to use a command line argument to set headless. However, this service is a WAR file deployed in Tomcat.

Can anyone try to get this working?

Something this simple should not take hours and hours and hours....

Thanks,

-- mike
 
Stephan van Hulst
Saloon Keeper
Posts: 10863
234
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You would set it as a JVM option when you start up Tomcat. You can probably do this in the Catalina config.

I'm still confused, but I find the use case of a client triggering a dialog on the server very odd.
 
Mike London
Bartender
Posts: 1700
17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:You would set it as a JVM option when you start up Tomcat. You can probably do this in the Catalina config.

I'm still confused, but I find the use case of a client triggering a dialog on the server very odd.



Think about a third party application like a fat database client that unfortunately does not give the user a way to find a file on the system.

By calling the service, you would get a file picker dialog. Pick a file and it returns to the field in the database application.

This approach works fine using "sparkjava" REST framework that isn't so picky.

--

I'll look into the start up config for Tomcat.

Thanks!

- mike
 
Stephan van Hulst
Saloon Keeper
Posts: 10863
234
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Try to set the system property in a static initializer at the top of your Application class. It might be possible that simply referring to any of the Spring types from your code might trigger the toolkit to be initialized before the system property is set.

I understand that you want to select a file on the server and enter it into a database field on the server, through a client application you can't modify. What I don't understand is why you are doing it by running UI code on the server. That would only work if the client is running on the same host as the server, in the same user session.

Personally I'd route the client's request through a tiny Swing application that initializes a JFileChooser with a FileSystemView that acts as a proxy to your actual server. That way you can run your database application on any host, not just on the same host as your web server. Unless of course that never going to be a use case for you.
 
Mike London
Bartender
Posts: 1700
17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:Try to set the system property in a static initializer at the top of your Application class. It might be possible that simply referring to any of the Spring types from your code might trigger the toolkit to be initialized before the system property is set.

I understand that you want to select a file on the server and enter it into a database field on the server, through a client application you can't modify. What I don't understand is why you are doing it by running UI code on the server. That would only work if the client is running on the same host as the server, in the same user session.

Personally I'd route the client's request through a tiny Swing application that initializes a JFileChooser with a FileSystemView that acts as a proxy to your actual server. That way you can run your database application on any host, not just on the same host as your web server. Unless of course that never going to be a use case for you.



Yep, the static initializer worked. but now I see that my idea won't work since, as you said, the file open dialog appears on the server, not on the client application that WOULD be remote to the server. Plus, this method leaves a Java application running. Using JFileChooser, this method works the first time only (getting the dialog). Using JFrame and AWT works every time, but again only on the server console.

----

So how, from a client program that needs to get a file path from some file on the server, from the Spring app, like you briefly mentioned above could I call a Swing program that would return that selected file back to Spring and ultimately back to the client program? Not sure how to do this.

By your comments above with an alternate approach, did you mean something like:

         

Perhaps what I'm trying to do really isn't achievable and I'm trying to use a REST service incorrectly?
 
Stephan van Hulst
Saloon Keeper
Posts: 10863
234
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Make a tiny application that uses a REST client to communicate with your server, and also has an interface that allows the client application to talk to it. It will run on the same host as the client application, and acts as a bridge between the client and the server.

When the client applications needs a file path from the server, the file chooser application spawns a JFileChooser with a custom FileSystemView. You would implement just enough of its methods so that the JFileChooser can browse through files on the server. A method is implemented by making REST calls to the server. It might look something like this:

The dependencies I used:

I didn't test any of this. It's likely there need to be some performance tweaks to prevent unnecessary round-trips, but it's just to give you an idea.
 
Mike London
Bartender
Posts: 1700
17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Totally awesome!

Thanks very much.

-- mike
 
I AM MIGHTY! Especially when I hold this tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!