[JBoss JIRA] (AS7-5136) Source Build Failure using Maven3 and Java version 1.6
by Peer Mohamed (JIRA)
Peer Mohamed created AS7-5136:
---------------------------------
Summary: Source Build Failure using Maven3 and Java version 1.6
Key: AS7-5136
URL: https://issues.jboss.org/browse/AS7-5136
Project: Application Server 7
Issue Type: Bug
Components: Build System
Affects Versions: 7.1.2.Final (EAP), 7.1.1.Final
Reporter: Peer Mohamed
Assignee: Paul Gier
build failed. (maven3, java 1.6, gitbash)
15:14:13,654 ERROR (main) [org.jboss.as.controller.management-operation] <AbstractOperationContext.java:430> JBAS014612: Opera
tion ("evil") failed - address: ([]): java.lang.RuntimeException: this handler is evil..
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.11:test (default-test) on project jboss-as-con
troller: There are test failures
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] (AS7-5109) When starting JBoss AS -b should work no matter how I start JBoss AS to bind it to the local interface
by Jim Tyrrell (JIRA)
Jim Tyrrell created AS7-5109:
--------------------------------
Summary: When starting JBoss AS -b should work no matter how I start JBoss AS to bind it to the local interface
Key: AS7-5109
URL: https://issues.jboss.org/browse/AS7-5109
Project: Application Server 7
Issue Type: Feature Request
Components: Domain Management
Reporter: Jim Tyrrell
Assignee: Brian Stansberry
When starting JBoss as with the following command:
./domain.sh -b 192.168.193.139 -Djboss.domain.base.dir=/home/jimtyrrell/Servers/machine1/ --host-config=host-master.xml
It does not bind to the passed in IP Address. Instead it binds to localhost 127.0.0.1. It should have bound to 192.168.192.139 in this instance.
Instead I had to pass in the parameter like this:
./domain.sh -Djboss.domain.base-dir=/home/jimtyrrell/Servers/machine1/ --host-config=host-master.xml -Djboss.bind.address.management=192.168.193.139
Please expand this ticket to any and all shipped configuration starting files so that the host binding works per the help info via a -b binding.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] (JGRP-1457) TimeScheduler2 loses tasks
by David Hotham (JIRA)
David Hotham created JGRP-1457:
----------------------------------
Summary: TimeScheduler2 loses tasks
Key: JGRP-1457
URL: https://issues.jboss.org/browse/JGRP-1457
Project: JGroups
Issue Type: Bug
Affects Versions: 3.0.9
Reporter: David Hotham
Assignee: Bela Ban
The symptoms I sometime see are: broadcast messages not being delivered to a member.
I've tracked this down to being because NAKACK2 has gaps in its record of sequence numbers, and its RetransmitTask is not running. I've confirmed that the task is not running by calling stack.getTransport().dumpTimerTasks() and seeing that it is not among the scheduled tasks.
So far, so definite. I also have a theory about how this happens.
Suppose thread 1 is in TimeScheduler2._run(), and has got as far as executing some tasks but has not yet reached the line tasks.keySet().removeAll(keys).
Meanwhile, suppose thread 2 is in TimeScheduler2.schedule(), adding a task that has the same key as the just-executed task. It can reach the branch task.remove(key) ("// entry has completed; remove it"), go round the loop again, and successfully call tasks.putIfAbsent(key, task).
Now thread 1 picks up again, calls removeAll(keys), and removes the task that has just been scheduled. Oops.
I suggest that a likely fix is to delete the "else tasks.remove(key)" branch from schedule() altogether. (If we're in that branch then we're blocked by a completed entry. That entry will be removed shortly by the run() thread, and then we'll be able to progress).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] (JASSIST-172) Support for matching and replacing sequences of bytecode instructions
by susanin (JIRA)
susanin created JASSIST-172:
-------------------------------
Summary: Support for matching and replacing sequences of bytecode instructions
Key: JASSIST-172
URL: https://issues.jboss.org/browse/JASSIST-172
Project: Javassist
Issue Type: Feature Request
Affects Versions: 3.16.1-GA
Reporter: susanin
Assignee: Shigeru Chiba
Priority: Optional
I've ported BCEL's instruction matching feature (InstructionFinder class, see http://commons.apache.org/bcel/manual.html, section 3.3.7) to Javassist. The matching part works perfectly and is really nice. You can build regular expressions over bytecode instructions, i.e. it is like a usual regex for String, but your alphabet is bytecode instructions instead of letters.
For example you can say "NOP+(ILOAD|ALOAD)*" or "GETFIELD PUTFIELD". There are also short-cuts for often used or common groups of instructions.
At the moment I'm working on the replacement part. I'm trying to follow the ExprEditor approach and provide a similar API for instruction matching and replacement. It is sort of working already for simple use-cases, but still needs more work. Some of the problems that I face are:
- A match can span multiple bytecode instructions. Should each instruction be accessible via a special $... syntax? If so, which one. May be $#i, which would refer to the i-th instruction in the matched fragment.
- Should it be possible to replace all of the instructions or just some of them by e.g. using a special syntax like $#i = replacement_expression
- In ExprEditor and related classes, the replacement expression is using a Java syntax, which is very nice. But since we want to replace bytecode instructions here, we may need to be able to use bytecode instructions in the replacement expression string, because Java expressions are too high-level to express some aspects at bytecode level (e.g. pushing/poping values from stack). I can see scenarios, where one would only want to use bytecode instructions in the replecement, where one would want to use a mix of java code and bytecode instructions and where only Java code is used. Among other things, these questions are interesting here :
- which easy to use syntax should be used for bytecode expressions?
- If and how it can be mixed with Java?
Any comments and opinions regarding mentioned problems is very welcome!
And please let me know if there is any interest in this functionality. If so, I could attach my current patches.
The original discussion thread can be found here:
https://community.jboss.org/thread/201922?tstart=0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months