In Btrace UserGuide(https://kenai.com/projects/btrace/pages/UserGuide ) it refers 'BTrace Restrictions' , and also refers in unsafe mode no ‘BTrace Restrictions’
BTrace Restrictions
can not create new objects.
can not create new arrays.
can not throw exceptions.
... ...
Supported Arguments
unsafe - do not check for btrace restrictions violations (true/false)
in my btrace shell, I already set -Dcom.sun.btrace.unsafe=true，but even can't create new object, why?
You need to mark the script itself for unsafe execution by using #BTrace(unsafe=true)
Related
I've read a few forum posts that some people prefer to use raise event over rpc,
but I can't find the reason why they prefer it. Is raise event interchangeable with rpc?
I mean I get it raise event is easier to use than RPC , because RPC requires the gameobject holding it to have photon view. But is there a situation where I should be using rpc instead of raise event? Any input is greatly appreciated !
RPCs and Events are very similar, but have some key similarities/differences:
Both:
Have options for buffering: (RpcTarget.*Buffered and RaiseEventOptions.CachingOptions)
Have options for encryption: (RpcSecure and SendOptions.Encrypt)
Have options for targeting specific users: (RpcTarget and RaiseEventOptions.Receivers)
Only RPC(s):
Require the [PunRPC] method attribute
Require (and run) on a particular object with a PhotonView
if the object no longer exists on the remote, the RPC never runs and is dropped
Have parameters defined by the method declaration only
Does support method overloading, but not optional parameters
Can have PhotonMessageInfo parameter
Only RaiseEvent(s):
Are always sent "ViaServer"
Your local client will be sent a copy of the event through the server, rather than executing locally immediately (assuming you're a receiver)
Can be circumvented by calling your OnEvent method directly, and using ReceiverGroup.Others
Uses a callback target defining the OnEvent method
Can be called without the need for a target PhotonView
Parameters arbitrary defined, they must be manually parsed/casted by the client
Have a limit of user-definable IDs: 1-200 (can be circumvented with parameters as sub-IDs)
Can be sent both reliably and unreliably via SendOptions
TL;DR: Generally, you'll want to use an RPC if something is related to a PhotonView, and a RaiseEvent call if not. They have basically the same capabilities otherwise
Source: Photon PUN Documentation: "RPCs and RaiseEvent"
In the following RISC-V assembly code:
...
#Using some temporary (t) registers
...
addi a7,zero,1 #Printint system call code
addi a0,zero,100
ecall
...
Should any temporary (t) registers be saved to the stack before using ecall? When ecall is used, an exception occurs, kernel mode is on and code is executed from an exception handler. Some information is saved when exceptions occur, such as EPC and CAUSE , but what about the temporary registers? Environment calls are considered not to be like procedures for safety reasons, but they look like it. Do the procedure calling conventions still apply in this case?
You are correct that the hardware captures some information, such as the epc (if it didn't the interrupted pc would be lost during transfer of control to the exception handler).
However that's all the hardware does — the rest is up to software. Here, RARS is providing the exception handler for ecall.
RARS documentation states (from the help section on syscalls, which is what these are called on MIPS (and RARS came from MARS)):
Register contents are not affected by a system call, except for result registers as specified in the table below.
And below this quote in the help is ecall function code table labeled "Table of Available Services", in which 1 is PrintInt.
Should any temporary (t) registers be saved to the stack before using ecall?
No, it is not necessary, the $t registers will be unaffected by an ecall.
This also means that we can add ecalls to do printf-style debugging without concern for preserving the $t registers, which is nice. However, keeping that in mind, we might generally avoid $a0 and $a7 for our own variables, since putting in an ecall for debugging will need those registers.
In addition, you can write your own exception handler, and it would not have to follow any particular conventions for parameter passing or even register preservation.
I have an Eclipse 3.x-based application which uses commands and handlers.
I'm in the process of upping the code coverage and want to test as much as I can. The simple cases (POJOs) I've learned how to test. However, there are cases where I can't find a good starting point, especially when creating a fixture.
For example: Eclipse Command Handlers. I have a handler class MyHandler extending org.eclipse.core.commands.AbstractHandler. It has a single method public Object execute(ExecutionEvent event) throws ExecutionException. Usually, event is passed in from a user action in the GUI, e.g., clicking a menu item.
How can I unit test this? Would I need to mock the ExecutionEvent with the help of a mocking framework?
Unless inevitable, I prefer to mock only types I do own. See here for a discussion of Should you only mock types you own?
Since ExecutionEvents can be created without too much hassle I wouldn't mock them. The snippet below creates an event that you can pass to your handlers' execute method.
IEvaluationContext context = new EvaluationContext( null, new Object() );
Map<String, String> parameters = new HashMap<>();
ExecutionEvent event = new ExecutionEvent( null, parameters, null, context );
The first argument of the ExecutionEvent constructor references the command - I have never had any use for it. If your code requires an actual command, you can use the ICommandService to obtain a reference to your command:
ICommandService commandService = ...
Command command = commandService.getCommand( "id.of.my.command" );
The second argument is a map of command parameters. The third argument is the trigger. If case of the Eclipse workbench this is the SWT Event if available. Leave it null if your production code does not evaluate it.
Before calling execute, you would probably want to prepare the variables of the context:
context.addVariable( ISources.ACTIVE_PART_NAME, myPart );
context.addVariable( ISources.ACTIVE_CURRENT_SELECTION_NAME, new StructuredSelection() );
Note that null is not allowed as a variable value. Either omit the call or - if already added, use removeVariable().
If you don't need a command (see above) - and of course your production code doesn't require a workbench - you can even run the tests as plain JUnit tests (as opposed to PDE JUnit test).
I'm working with Java RMI. The problem is that, by closing a thread, or call System.exit(0), I need the object registered with the RMI registry to execute an unbind() to remove all associations with the object. When we perform System.exit(0), the object is already registered with the RMI registry.
How I can do so by calling System.exit(0) the unbind() is made of the object in particular? I had thought about making a System.exit() override , but apparently that's not the solution.
The problem is that, by closing a thread, or call System.exit(0), I need the object registered with the RMI registry to execute an unbind() to remove all associations with the object.
So do that. But there is no such thing as 'closing a thread', and even exiting a thread doesn't require you to unbind anything.
When we perform System.exit(0), the object is already registered with the RMI registry.
Good, so the unbind() will succeed. Not sure what point is being made her. Did you mean 'still registered'?
How I can do so by calling System.exit(0) the unbind() is made of the object in particular?
You can't. You have to precede the System.exit() call with an unbind() call.
I had thought about making a System.exit() override , but apparently that's not the solution.
You can't override static methods, and System is final.
It seems you may have System.exit() spattered all over the place, which is already poor practice.
The simple answer is not to call System.exit() at all, but to unbind and unexport the object instead. Then the RMI threads will exit and your JVM will exit of its own accord, as long as you don't have any non-daemon threads of your own.
The short version: How do I get JBPM5 Rule Nodes to use a DRL file which reads and updates process variables?
The long version:
I have a process definition, being run under JBPM5. The start of this process looks something like this:
[Start] ---> [Rule Node] ---> [Gateway (Diverge)] ... etc
The gateway uses constraints on a variable named 'isValid'.
My Rule Node is pointing to the RuleFlowGroup 'validate', which contains only one rule:
rule "Example validation rule"
ruleflow-group "validate"
when
processInstance : WorkflowProcessInstance()
then
processInstance.setVariable("isValid", new Boolean(false));
end
So, by my logic, if this is getting correctly processed then the gateway should always follow the "false" path.
In my Java code, I have something like the following:
KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
kbuilder.add(ResourceFactory.newClassPathResource("myProcess.bpmn"), ResourceType.BPMN2);
kbuilder.add(ResourceFactory.newClassPathResource("myRules.drl"), ResourceType.DRL);
KnowledgeBase kbase = kbuilder.newKnowledgeBase();
StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();
new Thread(new Runnable()
{
public void run()
{
ksession.fireUntilHalt();
}
}).start();
// start a new process instance
Map<String, Object> params = new HashMap<String, Object>();
params.put("isValid", true);
ksession.startProcess("test.processesdefinition.myProcess", params);
I can confirm the following:
The drl file is getting loaded into working memory, because when I put syntax errors in the file then I get errors.
If I include a value for "isValid" in the Java params map, the process only ever follows the path specified by Java, apparently ignoring the drools rule.
If I take the "isValid" parameter out of the params map, I get a runtime error.
From this I assume that the final "setVariable" line in the rule is either not executing, or is updating the wrong thing.
I think my issue is related to this statement in the official documentation:
Rule constraints do not have direct access to variables defined inside the process. It is
however possible to refer to the current process instance inside a rule constraint, by adding
the process instance to the Working Memory and matching for the process instance in your
rule constraint. We have added special logic to make sure that a variable processInstance of
type WorkflowProcessInstance will only match to the current process instance and not to other
process instances in the Working Memory. Note that you are however responsible yourself to
insert the process instance into the session and, possibly, to update it, for example, using Java
code or an on-entry or on-exit or explicit action in your process.
However I cannot figure out how to do what is described here. How do I add the process instance into working memory in a way that would make it accessible to this first Rule Node? Rule Nodes do not seem to support on-entry behaviors, and I can't add it to the Java code because the process could very easily complete execution of the rules node before the working memory has been updated to include the process.
As you mentioned, there are several options to inserting the process instance into the working memory:
- inserting it after calling startProcess()
- using an action script to insert it (using "insert(kcontext.getProcessInstance()")
If calling startProcess() might already have gone over the rule task (which is probably the case in your example), and you don't have another node in front of your rule task where you could just use an on-entry/exit script to do this (so that's is hidden), I would recommend using an explicit script task before your rule task to do this.
Kris