There are many ways to learn to code these days. From coding bootcamps like Flatiron School to online courses to totally free beginner resources. The best way to learn to code depends on many factors, but the most important one is you. See what course is best for you.
Solved
Detaching my java application from openoffice leaving it open
Posted on 2009-05-18
Hello guys!
I'm facing the following problem: in my java application I need to open an openoffice calc spreadsheet, populate it with my data and then detach from OOo leaving the spreadsheet open on screen (this is mandatory, since the user expect to get an OOo calc open with certain data exported from my application, and then work with this data on calc).
I managed to get everything working (calc opens filled with data) but I don't understand how can I detach this calc window from my java app.
It seems that the communication bridge between java and OOo creates a new thread. When the user closes the java application, the JVM won't stop until all OOo instances are closed. I suspect that the java-OOo "bridge" live thread prevents the JVM to fully stop. Googling around the only way I found to detach is to stop OOo, but this is not what I want. OOo must stay open and fully detached from Java.
Any ideas? Thanks in advance.
I'm facing the following problem: in my java application I need to open an openoffice calc spreadsheet, populate it with my data and then detach from OOo leaving the spreadsheet open on screen (this is mandatory, since the user expect to get an OOo calc open with certain data exported from my application, and then work with this data on calc).
I managed to get everything working (calc opens filled with data) but I don't understand how can I detach this calc window from my java app.
It seems that the communication bridge between java and OOo creates a new thread. When the user closes the java application, the JVM won't stop until all OOo instances are closed. I suspect that the java-OOo "bridge" live thread prevents the JVM to fully stop. Googling around the only way I found to detach is to stop OOo, but this is not what I want. OOo must stay open and fully detached from Java.
Any ideas? Thanks in advance.
-
5
4
9 Comments
Active today
>>It seems that the communication bridge between java and OOo creates a new thread
If your theory's correct, then try 'finding' that thread and interrupting it. Yes, that's an unfortunately low-level way of approaching it, but if the 'bridge' won't allow that via the api, then i can't think of another way
If your theory's correct, then try 'finding' that thread and interrupting it. Yes, that's an unfortunately low-level way of approaching it, but if the 'bridge' won't allow that via the api, then i can't think of another way
To give you more infos, my java app shouldn't close just after the export operation. The java app is a huge rich client J2EE application lauched via Java Web Start that usually keeps open all the day on user client machine (somethimes the application is closed and re-opened many times).
What I need is to communicate with OOo only for the time needed for the export operation, then detach. Both Java app and OOo keep open. My concern is because so many customers use it and I fear to receive many and many phone calls asking me why processes does not go down. I know that this is a difficult situation to obtain, since people probabily won't be aware of the existence of many unterminated JVMs... but usually users don't kill the OOo quickstart process (that keeps the bridge thread alive) and when you deal with such big apps every aspect can be a trouble.
I fear i'll not be able to find the right thread to stop. I must investigate further on this possibility.
Anyway, I'm looking for a UNO based solution (Universal Network Objects).
What I need is to communicate with OOo only for the time needed for the export operation, then detach. Both Java app and OOo keep open. My concern is because so many customers use it and I fear to receive many and many phone calls asking me why processes does not go down. I know that this is a difficult situation to obtain, since people probabily won't be aware of the existence of many unterminated JVMs... but usually users don't kill the OOo quickstart process (that keeps the bridge thread alive) and when you deal with such big apps every aspect can be a trouble.
I fear i'll not be able to find the right thread to stop. I must investigate further on this possibility.
Anyway, I'm looking for a UNO based solution (Universal Network Objects).
Tried to stop the tread. Nothing. Even System.exit(0) won't shut down the JVM.
This UNO bridge thread is really tough to know off.
This UNO bridge thread is really tough to know off.
I don't see the point in doing that. If the main or a secondary JVM doesn't shut down, the problem is the same for me.
Anyway, all my tests were performed on a simplified app lauched through a main method from the development environment. When I close the test frame, the dev environment shows me that the process is still on and closes only when I shutdown OOo.
Today I tried with the real application launched through JWS and it seems that the process goes down even if OOo is up. I don't know the reason of this different behavior, but this could lead to a non-problem. If the production environment works, I'm happy.
I'm still testing other cases, then bring back here for a conclusion.
Anyway, all my tests were performed on a simplified app lauched through a main method from the development environment. When I close the test frame, the dev environment shows me that the process is still on and closes only when I shutdown OOo.
Today I tried with the real application launched through JWS and it seems that the process goes down even if OOo is up. I don't know the reason of this different behavior, but this could lead to a non-problem. If the production environment works, I'm happy.
I'm still testing other cases, then bring back here for a conclusion.
Mmmmh... not so simple. Keeping the connection bridge opened after my export operation causes malfunctioning of other parts of the java application (developed by others) that deal with OOo in other way. Sounds like I must find a way to break the connection between java and OOo just after terminating my export.
Active today
>>I don't see the point in doing that. If the main or a secondary JVM doesn't shut down, the problem is the same for me.
Well i was thinking at least you could close down the gui - but i take your point ;-)
afaicr there's a way of using TCP/IP to bridge is there not? That could obviate the coupling of processes
Well i was thinking at least you could close down the gui - but i take your point ;-)
afaicr there's a way of using TCP/IP to bridge is there not? That could obviate the coupling of processes
Your hint was really helpful.
Instead of working at XDesktop level I found a solution (http://www.oooforum.org/forum/viewtopic.phtml?t=35602) that works at XConnection level. That worked for me, other code now works still well also after my export operation.
Thank you for your support!
Instead of working at XDesktop level I found a solution (http://www.oooforum.org/forum/viewtopic.phtml?t=35602) that works at XConnection level. That worked for me, other code now works still well also after my export operation.
Thank you for your support!
Featured Post
There are many ways to learn to code these days. From coding bootcamps like Flatiron School to online courses to totally free beginner resources. The best way to learn to code depends on many factors, but the most important one is you. See what course is best for you.
Question has a verified solution.
Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.
Have a better answer? Share it in a comment.
Join & Write a Comment Already a member? Login.
In real business world data are crucial and sometimes data are shared among different information systems. Hence, an agreeable file transfer protocol need to be established.
Tiling windows is a great way to see multiple applications at once. Windows Tiler is a tool that automatically tiles open application windows as the open and close.
This video teaches viewers about errors in exception handling.
In this seventh video of the Xpdf series, we discuss and demonstrate the PDFfonts utility, which lists all the fonts used in a PDF file. It does this via a command line interface, making it suitable for use in programs, scripts, batch files — any pl…
- Document Management
- Document Imaging
- Programming
- Adobe Acrobat
- Scripting Languages
- Printers and Scanners, *PDF
Suggested Courses
Course of the Month4 days, 14 hours left to enroll
579 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.