A digital transformation requires faster time to market, shorter software development lifecycles, and the ability to adapt rapidly to changing customer demands. DevOps provides the solution.
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.
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
-
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
We value your feedback.
Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
Today, the web development industry is booming, and many people consider it to be their vocation. The question you may be asking yourself is – how do I become a web developer?
What do responsible coders do? They don't take detrimental shortcuts. They do take reasonable security precautions, create important automation, implement sufficient logging, fix things they break, and care about users.
Simple Linear Regression
Suggested Courses
Course of the Month7 days, 10 hours left to enroll
715 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.