jPOS 2.0.8 has been released, new development version is now 2.0.9-SNAPSHOT
see ChangeLog for details.
This release includes the former jPOS-EE SSH module that can be enabled by calling Q2 with the --ssh switch.
This requires a file cfg/authorized_keys and defaults to port 2222. After starting the SSH service, one can:
ssh -p 2222 admin@localhost
and get a Q2 CLI prompt.
See q2 --help for details.
jPOS 2.0.6 has been released, new development version is now 2.0.7-SNAPSHOT
see ChangeLog for details.
jPOS 2.0.4 has been released, new development version is now 2.0.5-SNAPSHOT
see ChangeLog for details.
In 2.0.4 we've added a SpaceLogListener that can be used to write log output in an asynchronous way.
It works with a companion LoggerService that pull entries from the Space and actually log them.
The configuration is very simple, here is an example:
(this is basically your old 00_logger.xml, synchronously writing to disk)
The logger service pulls entries from logger.q2 space queue and uses the second logger as its output (we arbitrarily called it DAEMON).
The SpaceLogListener can send to the Space the original "Live" (so to speak) LogEvent, or create a Frozen one (see the frozen property). When set to true, log filters (i.e. the ProtectedLogFilter) has to be applied before the SpaceLogListener, otherwise, it won't work on the frozen LogEvent.
A FrozenLogEvent is Serializable, so we are not limited to TSpace, one can use the ReplicatedSpace in order to implement a very simple central logging.
jPOS 2.0.2 has been released, new development version is now 2.0.3-SNAPSHOT - see ChangeLog
MavenCentral has been updated (2.0.2) and jPOS Maven Repository already has 2.0.3-SNAPSHOT available.
/by apr/
10 years ago I add an experimental ReplicatedSpace implementation to the jPOS-EE project. While it was fun to develop and test, it didn't get too much traction (or so I thought).
It turned out that I've started to hear about several high-end production systems using it, so I migrated it from the old GoogleCode repo to the new Github one.
Want to give it a quick try? Here are the very simple instructions:
git clone https://github.com/jpos/jPOS-template.git rspace && cd rspace
build.gradleAdd the dependency compile "org.jpos.ee:jposee-rspace:2.0.9-SNAPSHOT", your dependencies will look like this:
dependencies {
compile ('org.jpos:jpos:2.0.+') {
exclude(module: 'junit')
exclude(module: 'hamcrest-core')
}
testCompile 'junit:junit:4.8.2'
compile "org.jpos.ee:jposee-rspace:2.0.9-SNAPSHOT"
}
Call gradle installResources
This will extract the ReplicatedSpace configuration from its jar and will place it in your src/dist directory
Remove the file src/dist/deploy/01_multi_instance_prevention.xml so that you can run multiple instances on the same machine
gradle dist
This will create a build/distributions/rspace-2.0.0.tar.gz that you can extract in several boxes. For a quick local run, you can gradle installApp and cd build/install/rspace to have the same effect.
Call bin/q2 and you'll see something like this:
<log realm="org.jpos.space.ReplicatedSpaceAdaptor" at="Thu Jun 04 15:18:17.406 UYT 2015" lifespan="1ms">
<info>
view-accepted
[apr-19136|0] (1) [apr-19136]
</info>
</log>
If you run it again, or in a different box in the same LAN, you'll see several view-accepted messages.
At this point, you can create a little script to perform some space operations, i.e:
import org.jpos.space.*;
Space sp = SpaceFactory.getSpace("rspace:rspace");
sp.out ("TEST", "REPLICATED MESSAGE");
A nice way to run a script is to deploy something like this:
Add a file called say 90_script.xml to your deploy directory:
<script> server(6666); </script>
Then telnet localhost 6667 (please note the server says '6666' but you connect to 6666+1, this is BeanShell stuff.
At the bsh% prompt, you can type your space operations.
jPOS 2.0.0 has been released, the new development version is now 2.0.1-SNAPSHOT - see ChangeLog
jPOS-EE 2.0.7-SNAPSHOT has now upgraded dependencies and uses jPOS 2.0.0
jPOS-template has been upgraded to use jPOS 2.0.0 as well.
MavenCentral has been updated (2.0.0) and jPOS Maven Repository already has 2.0.1-SNAPSHOT available.
From time to time, we may ask for a message hex dump, and here is how a dump looks like:
0000 08 00 A0 20 00 00 00 80 00 00 04 00 00 00 00 00 ... ............
0010 00 00 00 00 00 00 00 01 32 39 31 31 30 30 30 31 ........29110001
0020 00 01 ..
See? It's ASCII text that one can easily copy and paste in order to load it in a simulator or test program (please move your mouse over the hex digits, you can see they are selectable).
It is extremely simple, you can capture a message using NetCat and then you can use the hd Unix command, or just send us the binary image in raw format, but please PLEASE P L E A S E, don't send us a screen capture in graphic format inside a Word document or inside a cell of an spreadsheet.
When you send a graphic capture of a dump, like this:
We need to re-type the dump in a text editor, which is error-prone and a waste of time. This is a very small example, but with large messages, the chances of introducing an error are high.
Another very common problem when we ask for a dump is that we get a high level representation of the message, some times in ASCII, copy and pasted into a message, but the mailers usually wrap around lines, not preserve blanks, and don't show unprintable characters, so it's extremely naive to think that we can do something useful with those kind of "dumps".
When we ask for a message dump, we don't want a full wall of IP-packets either, we are not debugging the TCP/IP protocol, we believe it works, so we are not interested in the session establishing, ICMP packets and IP-level headers.
We just ask, actually we cry for, a simple hex dump. Is that difficult?
genDocker task that installs a jpostemplate imageSee ChangeLog for details.
TransactionParticipants get called by the TransactionManager using their prepare, prepareForAbort, commit and abort callbacks, but for situations where one needs access to the Context in a deeper class, called by the participant (i.e. Managers), we now have a couple of static ThreadLocal based methods:
getSerializable()Context getContext() (in case your Serializable is actually an instance of org.jpos.transaction.Context)Long getId ()Please note returned values may be null when run outside the TM life-cycle.
Also note that the TM takes care of PAUSED transactions, setting these values on the resumed thread.
See ChangeLog - 6da5f3 for details.