I'm following the IzPack documentation use case Executing a Java Class with ProcessPanel and am running into some difficulty achieving the desired behavior from the onSuccess and onFail elements and could use some clarification from someone more familar with IzPack 4.3.5.
I've defined a java condition, process.panel.condition, that I want to use to control the availability of the next and previous buttons on the process panel after the run method in my Java class has been invoked. This run method assigns true or false to the static field, ConditionBoolean, underlying the process.panel.condition condition.
My expectation is that when process.panel.condition is true, I'd like the previous button to become disabled and the next button enabled. When process.panel.condition is false, I'd like the complement to occur- previous becomes enabled and next becomes disabled.
Instead what appears to be happening is that the previous button assignment is working but the next button is always made enabled.
Can anyone point out why I'm seeing this behavior and how I should go about changing my approach to achieve my desired behavior?
Below are the xml definitions and associated Java class referenced in the executeclass element.
<conditions>
<condition type="java" id="process.panel.condition">
<java>
<class>MyClass</class>
<field>ConditionBoolean</field>
</java>
<returnvalue type="boolean">True</returnvalue>
</condition>
</conditions>
Process spec xml as follows:
<processing>
<job name="Step 1">
<executeclass name="MyClass">
<arg>...</arg>
</executeclass>
</job>
<onFail previous="false" next="false" />
<onSuccess condition="!process.panel.condition" previous="true" next="false" />
<onSuccess condition="process.panel.condition" previous="false" next="true" />
</processing>
And the MyClass implementation:
import com.izforge.izpack.util.AbstractUIProcessHandler;
public class MyClasss {
public static boolean ConditionBoolean;
public void run(AbstractUIProcessHandler handler, String[] args) {
ConditionBoolean = false;
try {
...
ConditionBoolean = true;
} catch (Throwable e) {
handler.logOutput(e.getMessage(), false);
}
}
}
I've never seen a non-built-in condition id to have dots. So it might be a bug with izpack, considering it still has various weird bugs. Consider changing the id to something like "processPanelCondition".
After digging through the IzPack issues, I found IzPack-238, Installation will be treated as successfull [sic] even if a process in the ProcessPanel returns a boolean value of false, which pointed out that IzPack would report success after invoking a run method with a void return type.
This issue was then patched in version 4.2.1 to allow the run method to have a boolean return value that indicates whether or not the run method completed successfully. Despite the issue being resolved back in 2009-02, the documentation refered to in the question was not updated.
After switching the return value of the run method from void to boolean, and returning the outcome, I was able to resolve my problem.
Related
The code from two years back had to be upgraded to E4, and now a bunch of stuff does not work anymore. One of these is the IEvaluationService if used like this:
<handler class="org.acme.PrintHandler" commandId="org.eclipse.ui.file.print">
<activeWhen>
<with variable="activePart">
<test property="org.acme.printable" />
</with>
</activeWhen>
</handler>
IEvaluationService service = (IEvaluationService) PlatformUI.getWorkbench().getService(IEvaluationService.class);
service.requestEvaluation("org.acme.printable");
How do I (re)trigger the evaluation of a PropertyTester? Since E4 is really not even close to being production ready, I need a workaround for E3 (compatibility layer).
Related question - but this user was searching for the equivalent in E4, while I need one that works in E3.
Funnily enough, if I replace the <activeWhen> tags with <enabledWhen> it works. In that case IEventBroker#post and IEventBroker#send work, too.
This is a similar question. That user used Eclipse 4.2 - I tested the problem with 4.5, 4.6 and 4.7.
The EvaluationService is API compatible in the E3 Compatibility Layer. But the implementation in E4 is completely different, causing the behaviour of requestEvaluation to be fundamentally different.
The best solution to this problem I could find is to manually deactivate and activate all contexts of currently active parts. This causes internally to re-evaluate and, when required, re-render all UI elements of the respective parts.
One could argue this is less efficient than requesting the evaluation of a very specific property, as the EvaluationService is supposed to do. But since the evaluation is limited to active parts only, it should not create too much overhead. And it does work globally, as no specific property string is required anymore.
The only usecase not covered by this yet may be the main toolbar of your RCP application.
/**
* Triggers evaluation of all UI elements (buttons, etc.) of the active part.
* Also causes test of all property testers of all opened parts implicitly.
* Workaround of the broken <code>IEvaluationService.requestEvaluation</code>.
*/
public static void triggerUIElementsEvaluation() {
try {
final EPartService partService = PlatformUI.getWorkbench().getService(EPartService.class);
final MPart activePart = partService.getActivePart();
/* Toggle context of active part to trigger re-evaluation of its UI elements. */
if (activePart != null) {
activePart.getContext().deactivate();
activePart.getContext().activateBranch();
}
} catch (IllegalStateException e) {
/* Ignore "Application does not have an active window" exception to allow program to continue. */
}
}
eventBroker.post(UIEvents.REQUEST_ENABLEMENT_UPDATE_TOPIC, UIEvents.ALL_ELEMENT_ID);
See also Eclipse bug 436755 and Eclipse Wiki: Eclipse 4 - RCP - Event Model
I'm going to share my workaround, which is not good, and does not work in alles cases. And only really works because in my use case I have a IWorkbenchPart with an ISelectionProvider... but maybe it will help the next person:
IWorkbenchPart activePart = // get active view or editor
ISelectionProvider selectionProvider = activePart.getSite().getSelectionProvider();
ISelection selection = selectionProvider.getSelection();
selectionProvider.setSelection(new StructuredSelection());
selectionProvider.setSelection(selection);
This code just resets the selection, which normally triggers the PropertyTester. I don't think it'll work if nothing was selected.
I'm using latest IntelliJ IDEA Ultimate 16 EAP. I have some code in a library that initializes an object with some setters:
X createSomething() {
X x = new X();
x.setY(z);
return x; // breakpoint on this line
}
I'm looking to modify this returned value's state from the debugger: calling x.setY(y). I tried with conditions, because I want it to happen on every hit of the breakpointstopping at the breakpoint and using the "Evaluate Expression" window is unfeasible.
It's not possible to do this in any of the normal object oriented ways (e.g. overriding that method), nor it is possible to capture the result outside the method and modify it there because it's deep within many calls.
Here are my tries that all failed due to no support for those language features in the debugger. They failed with a dialog asking "Would you like to stop at the breakpoint?". The language level is fixed at Java 6-7 because I'm developing for Android.
Try 1: Call the method
Problem processing VM event:
Breakpoint: 'Line 9 in ClassName.createSomething() (package)'
Error: Failed to evaluate breakpoint condition 'x.setY(y)'
Reason: Boolean value expected
Also tried variants like: x.setY(y); false;, but it needs to be an expression.
Try 2: Call the method using lambda
Problem processing VM event:
Breakpoint: 'Line 9 in ClassName.createSomething() (package)'
Error: Failed to evaluate breakpoint condition '() -> { x.setY(y); return false; }'
Reason: Lambdas evaluation is not supported
Try 3: Call the method to have a boolean expression
Problem processing VM event:
Breakpoint: 'Line 9 in ClassName.createSomething() (package)'
Error: Failed to evaluate breakpoint condition 'new java.util.concurrent.Callable<Boolean>() { #Override public Boolean call() { x.setY(y); return false; } }.call()'
Reason: Anonymous class evaluation is not supported
Try 4: Call a static method (working workaround)
I found a workaround that I want to share, but I'm still looking for a better solution if anyone knows one: that doesn't require recompiling and restarting.
Create a method in a class:
public class SomeClass {
public static boolean fixX(X x) {
x.setY(y);
return false; // don't actually stop on the breakpoint
}
}
In the breakpoint condition add
full.pkg.SomeClass.fixX(x)
This works, but any time you want to modify the condition you'll have to restart the app. Parametrized fixX(x, changeAbleY) is a solution to that.
Make sure to disable or remove the breakpoint to prevent headaches by modified behavior when debugging unrelated issues.
Steps:
Right click on the breakpoint
A tool popup will open, in that popup click on "More" link at the bottom then a window will open.
Now check "Log evaluated expression" checkbox in that window and enter your method call in the given text box e.g methodName().
Click OK and start debugging.
When the breakpoint will hit your method will get called before that line's execution.
Reference: https://www.jetbrains.com/idea/help/configuring-breakpoints.html
Screenshot: Screenshot of breakpoint configuration window.
IntelliJ has a feature to add "Watches" where you can execute your void method but that's manual, not automatic.
This has got me stumped.
I've written an ant task which sets a logging level via an attribute (logLevel="INFO"). The setter is implemented like this
public void setLogLevel(String logLevel) {
System.out.println("Log level passed to ant task: " + logLevel);
this.level = Level.toLevel(logLevel);
System.out.println("Log level set to " + level.toString());
}
When I tested the task this setter never executed, even though the attribute was correctly spelled and set. After a lot of hair pulling I decided to try something that shouldn't matter; I moved the logLevel attribute ahead of my other attributes (it was next to last). Guess what - that change caused to setter to execute.
I changed the attribute back and forth several times to make sure this made a difference, it does. If the attribute is one of the first ones encountered, the setter executes and the attribute is set. If it's one of the last encountered, the setter does not execute.
I've seen this behavior in both Ant 1.7.1 and 1.9.0. Can anyone tell me why this strange behavior is happening and what I might be doing wrong? My task has 15 attributes and the logLevel attribute is not set when it is the 11th attribute or lower.
Per Martin Clayton here is the xml fragment from the build.xml file. The logLevel attribute is set here but if I move it down a few lines it will not be set.
<testReport report="${report}/report.xml"
logLevel="${logLevel}"
highestSeverityCountProperty="highestCount"
highSeverityCountProperty="highCount"
mediumSeverityCountProperty="mediumCount"
lowSeverityCountProperty="lowCount"
lowestSeverityCountProperty="lowestCount"
totalViolationsCountProperty="totalCount"
failOnHighestSeverityCount="${lvl1ViolationsFailValue}"
failOnHighSeverityCount="${lvl2ViolationsFailValue}"
failOnMeidumSeverityCount="${lvl3ViolationsFailValue}"
failOnLowSeverityCount="${lvl4ViolationsFailValue}"
failOnLowestSeverityCount="${lvl5ViolationsFailValue}"
failOnTotalViolationsCount="${totalViolationsFailValue}"
failureReason="failMessage"/>
The problem I'm having is that not all attributes get set. This problem does not happen in an ant build from a command line or eclipse. It happens during ant builds using the IBM Rational Team Concert Jazz Build Engine.
I don't know what the problem is but I have found a workaround using dynamic ant tasks without setters. See here for a simple description. This worked for me.
I have a problem with the OpenFaces SuggestionField.
I have created a site with a SuggestionField in it and set the suggestionMode to "custom". Then I added a dropDownItems child-tag, which is supposed to get all items to show, right?
Well, and that is my problem, the dropdown-items are empty at start (because in the database there are 20k+ items) and should get filled with already pre-filtered items when the user starts to type something in the field. However, the method never triggers...
Here is the code for the field and the affected method in the backing bean:
<o:suggestionField id="adr" value="#{addressBean.selectedAddressString}" suggestionMode="custom" valueChangeListener="#{addressBean.valueChanged}">
<f:ajax event="change" execute="adr" render="region x y"></f:ajax>
<o:dropDownItems value="#{addressBean.addressStrings}"/>
</o:suggestionField>
public List<String> getAddressStrings() {
String filter = Faces.var("searchString", String.class);
logger.debug(filter);
return filter(filter);
}
The method-header for the filter - method is:
private List<String> filter(String filter);
According to this site, the "custom" mode should send an ajax-request to the server.
I added the valueChangeListener attribute as I hoped that at least this gets triggered, but either I have a problem there too, or something is going very wrong...
Anyway, here is the code of this method (yea, it does just log ;-) )
public void valueChanged(ValueChangeEvent vce){
logger.debug("something changed "+vce.getNewValue());
}
As I know that there are tons of different versions of all components and probably the solutions look different for each, here are the versions I use:
OS: Windows 7
Server: Tomcat 7.0.42
Java: 1.7.0_51
JSF: 2.2 (Mojarra 2.2)
OpenFaces: 3.1.EA1.1287
Every answer is appreciated, thanks in advance. :-)
Well, i found my problem.
Openfaces 3.x (including current nightly builds) is not fully compatible with JSF 2.2 (or at least 2.2.6+). As the nightly-doc says, it is currently compatible with 2.1.11.
One of the non-compatibility symptoms is that the suggestionfield does not trigger the server-side event.
I have a very weird problem, the classic of works on localhost and not in server.
I've tried to find a bigger problem and discovered that this code :
<div class="pageHeader"><h1>Products2 #{products.debug} </h1></div>
When :
#ManagedBean(name="products")
#SessionScoped
public class ProductsBean {
private String debug = "Debug : ";
public ProductsBean() {
debug = "Debug : ";
}
public String getDebug() {
return debug;
}
public void setDebug(String debug) {
this.debug = debug;
}
And the debug string has getters/setters,
Works perfectly in localhost but not on remote. In the remote server it doesn't echo the string at all, and no exception gets thrown and I have no idea how to start looking for the problem. The thing is that this problem gets repeated in other ways, for instance this page has a dataTable which appears empty, though it's not in localhost. when I tried file uploading in an whole different page I got exception of Target Unreachable, identifier resolved to null, which is not the problem in this case, but it seems to be related somehow I guess
Any help? I'm running on Oracle Linux Server with Oracle GlassFish
The problem is here.
Target Unreachable, identifier 'loadSimCards' resolved to null
I believe #loadSimCards resolved to null during processing.
The object is not getting created/prepopulated in your bean.
Check the code and verify if it is indeed getting populated.
You can post your Java code if you are still facing issues.
Also check beans.xml file and declaration in faces-config.xml
Reference - JEE CDI tip: Target Unreachable, identifier resolved to null
The first step in my mind would be to do a Right Click -> View Source in the browser and let us know what it shows. In the view source if the string "#{products.debug} is not getting printed, it means that the server is indeed evaluating the EL Expression, but at the time of rendering it is coming as an empty string.
Can you please provide the actual getters/setters.
Can you put loggers/SOPs in them and let us know whether they are being called and in what sequence.
Replace the pure EL Expression with a data-binding control like h:inputText and see what happens.
< h:inputText value="#{products.debug}" />
Probably unrelated, but do you have a < base /> tag declared in your page in the head section? Base tag href provides the location from which child resources are loaded. I have seen some abnormal behavior in the past while shifting servers, when the main page is loaded from from the remote while the child resources are loaded from the localhost itself on your developer box, because one forgets to change the base tag reference.