java thinks that fop is a GUI application, so it creates a dock icon for it and gives it focus when it is launched. This is highly annoying as it can happen in rapid succession during an automated build process using fop. org.apache.fop.cli.Main is the name of the class that is used as the application name in the OS X Menu Bar.
0.95 and 1.0 have this problem.
The fix is trivial... just edit the fop script to have: fop_exec_args="-Djava.awt.headless=true"
Actually, that won't work... this will: --- fop.orig 2010-11-24 23:25:55.000000000 -0500 +++ fop 2010-11-24 23:26:29.000000000 -0500 @@ -19,6 +19,7 @@ rpm_mode=true fop_exec_args= +java_exec_args="-Djava.awt.headless=true" no_config=false fop_exec_debug=false show_help=false @@ -247,7 +248,7 @@ fi # Execute FOP using eval/exec to preserve spaces in paths, # java options, and FOP args -fop_exec_command="exec \"$JAVACMD\" $LOGCHOICE $LOGLEVEL -classpath \"$LOCALCLASSPATH\" $FOP_OPTS org.apache.fop.cli.Main $fop_exec_args" +fop_exec_command="exec \"$JAVACMD\" $java_exec_args $LOGCHOICE $LOGLEVEL -classpath \"$LOCALCLASSPATH\" $FOP_OPTS org.apache.fop.cli.Main $fop_exec_args" if $fop_exec_debug ; then echo $fop_exec_command fi
resetting P2 open bugs to P3 pending further review
not a bug; certain functions of FOP require resolving relative dimensions, such as pixel, which can only be determined by accessing headed features
If that is true, then fop is misdesigned, and that IS a bug. There's no reason that you should need to access a physical head in order to do anything since you don't actually USE the head. Take a look at the patch that I provided you with back in 2010. We've been using it in Macports for almost 2 years now. I suggest you take the fix.
The suggested change only affects the script to call Java not any internal code. Folks you want to run FOP on a headless environment can easily add -Djava.awt.headless=true to their Java startup script; Just as you have done. Therefore we don't need to do anything to FOP's code or distribution.
(In reply to comment #6) > If that is true, then fop is misdesigned, and that IS a bug. There's no reason > that you should need to access a physical head in order to do anything since > you don't actually USE the head. > > Take a look at the patch that I provided you with back in 2010. We've been > using it in Macports for almost 2 years now. I suggest you take the fix. It is a reasonable question as to whether there are in fact any dependencies on running headed. If not, then we could add the headless param to the command line start-ups. If there is, then we could consider removing those dependencies (if feasible). I do note there is a FAQ item on headless at [1], which answer refers to [2]. [1] http://xmlgraphics.apache.org/fop/faq.html#svg-headless [2] http://xmlgraphics.apache.org/fop/1.0/graphics.html#batik
I agree that any dependencies on being attached to a head should be removed, but the fact that fop works just fine with -Djava.awt.headless=true seems to indicate that there are no such real dependencies. Furthermore, this is not about wanting to run without a head. This bug is about fop making my head totally useless while it is running. If I don't add -Djava.awt.headless=true, then fop steals focus from real applications every time it runs. This means that if I kick off a build of X11 in the background and switch to do email or whatnot, fop will steal focus away from my email application when the build starts to produce its documentation. Since fop is exec'd about once every 5 seconds during that time, it can make life quite annoying. This is a real issue and needs to be addressed. If you don't like the -Djava.awt.headless=true patch that we've been shipping for the past ~2 years, then by all means, find a better solution and remove whatever dependencies exist inside fop.
(In reply to comment #9) > I agree that any dependencies on being attached to a head should be removed, > but the fact that fop works just fine with -Djava.awt.headless=true seems to > indicate that there are no such real dependencies. I recall running into a dependency last year when running junit tests. Some of them failed if headless was set for all of them. But I need to re-check to see if that dependency still exists. If it doesn't, I'll apply the suggested change.
http://svn.apache.org/viewvc?view=revision&revision=1325624 checking on junit shows that all tests are invoked in headless mode; so i've applied the suggested fix to {fop, fop.bat, and fop.js}; however, since I do not personally make use of these shells/scripts, i would appreciate it if anyone who does use them report any new problems that arise due to this change; if it turns out that some special usages do require non-headless mode, then i'll further tweak the shells/scripts to provide a command option to remove the headless define
As discussed, this commit has been reverted as the user can set the headless or any other JVM argument if they wish to do so. These arguments, however, should not be set by default. Glenn, should I set the status of this to invalid since it's not actually a bug? Or wontfix? Or should I just leave it be?
(In reply to comment #12) > As discussed, this commit has been reverted as the user can set the headless > or any other JVM argument if they wish to do so. These arguments, however, > should not be set by default. > > Glenn, should I set the status of this to invalid since it's not actually a > bug? Or wontfix? Or should I just leave it be? I would like to have a better understanding if most usage of FOP requires headed than headless. Since the FOP tests apparently work with headless mode, I have to wonder if headless is the more typical usage. A better fix would be to keep this original fix, and then change to headed if AWT output is used if the user did not explicitly set headed or headless. In other words, I think that switching to headed by default in order to fix AWT usage is the wrong approach. I think we should use headless by default.
(In reply to comment #13) > (In reply to comment #12) > > As discussed, this commit has been reverted as the user can set the headless > > or any other JVM argument if they wish to do so. These arguments, however, > > should not be set by default. > > > > Glenn, should I set the status of this to invalid since it's not actually a > > bug? Or wontfix? Or should I just leave it be? > > I would like to have a better understanding if most usage of FOP requires > headed than headless. Since the FOP tests apparently work with headless > mode, I have to wonder if headless is the more typical usage. The junit tests don't run in a headless environment, a HeadlessException. So I'm not sure what is meant by "typical usage". > > A better fix would be to keep this original fix, and then change to headed > if AWT output is used if the user did not explicitly set headed or headless. > > In other words, I think that switching to headed by default in order to fix > AWT usage is the wrong approach. I think we should use headless by default. The problem with that patch is that it forces a headless environment, where as previously the user had the option of a headless environment (with the -Djava.awt.headless=true). No code change is needed in for a headless environment. However with this patch applied a code change is needed, and in several places. Aside from that, a graphical head is needed for use of the AWT renderer but also for SVG as Batik's reliance on the AWT system hasn't been addressed. The use of SVG in the user base is vast, so I'm not sure it's fair to say "typical usage" doesn't require a headless environment. Fixing Batik is not a small task and not one that it seems anyone is in any rush to fix.
Sorry, turns out I can't type. I didn't mean to suggest that the unit tests represent typical use-cases, though they do, they should test a lot more. My point was merely we have to be careful since FOP is used in so many different ways by so many different people; a typical use-case isn't easy to define.