Recently, Windup team released version 2.0.0.Beta1, which outlines how the whole 2.x line will look like.
If you are too busy now to cope with downloading and trying a beta version, I've prepared a 5-minutes video.
This demo is similar to the previous one, except instead of installing Forge addons, you can run Windup 2.0 directly from the distribution archive.
Of course, the easiest way is to download it from JBoss Maven repository.
Enjoy!
Update: Check new video showing easier way to run Windup! Also with larger font and less background noise
Recently, Windup team released version 2.0.0.Beta1, which outlines how the whole 2.x line will look like.
If you are too busy now to cope with downloading and trying a beta version, I've prepared a 5-minutes video.
This demo shows the more geeky way to run - through installing Windup addons to Forge.
Youtube URL: https://www.youtube.com/watch?v=62mDIDP5HY0
2nd video to come soon.
Enjoy!
Windup 2, JBoss Migration tool, has come to phase when we can release first tech preview release.
This is a limited beta, which is targetted mainly for rule authors to get familiar with how Windup 2 works.
The downloadable offline .zip is in JBoss Maven repository.
The rest of the artifacts are also in JBoss Maven repository.
wget http://repository.jboss.org/nexus/content/groups/public/org/jboss/windup/windup-distribution/2.0.0.Beta1/windup-distribu… unzip windup-distribution-2.0.0.Beta1-offline.zip cd windup-distribution-2.0.0.Beta1/bin ./windup
At the prompt:
windup-migrate-app --input <path/to/your/app> --output /tmp/Windup/beta1/
For further usage instructions, execute:
man windup-migrate-app
Demo video coming soon!
Just saw a StackOverflowError in Javac.
Interesting fact is that it happens on Jenkins CI but not at my system, with the same JDK version on Linux.
[INFO] Compiling 40 source files to /mnt/hudson_workspace/workspace/Windup-daily/windup/rules-java-ee/target/classes The system is out of resources. Consult the following stack trace for details. java.lang.StackOverflowError at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:583) at com.sun.tools.javac.code.Types$UnaryVisitor.visit(Types.java:3803) at com.sun.tools.javac.code.Types.supertype(Types.java:1750) at com.sun.tools.javac.comp.Resolve.findField(Resolve.java:551) at com.sun.tools.javac.comp.Resolve.findField(Resolve.java:553) at com.sun.tools.javac.comp.Resolve.findField(Resolve.java:559) at com.sun.tools.javac.comp.Resolve.findField(Resolve.java:553) at com.sun.tools.javac.comp.Resolve.findVar(Resolve.java:602) at com.sun.tools.javac.comp.Resolve.findIdent(Resolve.java:1196) at com.sun.tools.javac.comp.Resolve.resolveIdent(Resolve.java:1396) at com.sun.tools.javac.comp.Attr.visitIdent(Attr.java:2162) at com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:1705) at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:431) at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:418) at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:2247) at com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1677) at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:431) at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:418) at com.sun.tools.javac.comp.Attr.attribArgs(Attr.java:504) at com.sun.tools.javac.comp.Attr.visitApply(Attr.java:1513)
Turns out to be caused by different RHEL Javac defaults.
MAVEN_OPTS=-Xss1024k fixed it.
I specifically use the "Invoke top-level Maven goal" in Jenkins CI, so "-Xss1024k" goes to the "JVM Options" field.
Those of you who are watching what's being developed to support migration remember a short period of development of WindRide, server config migration tool; and also WindUp, application assessment tool.
Both had limitations - not only by it's scope, but also Windup had too simple logic for the plugins. That was enough for most of use cases, but for any more complex analysis, rule authors would have to go to Java.
Now with Windup 2, we are targetting both scopes (server and applications), and will let users do much more from within the rules.
Windup 2 is actually an modular engine which lets you create high-level scanners, conditions, operations, and then assemble them into a logic in rules.
But still, for the majority of simple rules, users will still be creating a simple few-lines long rule. Currently in Java syntax, later in briefer Groovy syntax.
Stay tuned
Gone are the times of Pascal and Visual Basic. With Java, you can keep your code, which goes beyond basic algorithmic structure, readable and understandable.
Compare these two identical codes:
public void setParameterStore(final ParameterStore parent) { for (final Rule rule : config.getRules()) { if( ! (rule instanceof RuleBuilder) ) continue; ParameterizedCallback callback = new ParameterizedCallback() { @Override public void call(Parameterized parameterized) { Set<String> names = parameterized.getRequiredParameterNames(); if( ! (rule instanceof RuleBuilder) ) return; ParameterStore store = ((RuleBuilder) rule).getParameterStore(); for (Map.Entry<String, Parameter<?>> entry : parent) { String name = entry.getKey(); Parameter<?> parentParam = entry.getValue(); if (!store.contains(name)) { store.get(name, parentParam); continue; } Parameter<?> parameter = store.get(name); for (Binding binding : parameter.getBindings()) { if (!parentParam.getBindings().contains(binding)) throwRedefinitionError(rule, name); } for (Constraint<?> constraint : parameter.getConstraints()) { if (!parentParam.getConstraints().contains(constraint)) throwRedefinitionError(rule, name); } for (Transposition<?> transposition : parameter.getTranspositions()) { if (!parentParam.getTranspositions().contains(transposition)) throwRedefinitionError(rule, name); } if (parentParam.getConverter() != null && !parentParam.getConverter().equals(parameter.getConverter())) throwRedefinitionError(rule, name); if (parentParam.getValidator() != null && !parentParam.getValidator().equals(parameter.getValidator())) throwRedefinitionError(rule, name); } for (String name : names) { Parameter<?> parameter = store.get(name, new DefaultParameter(name)); if (parameter instanceof ConfigurableParameter<?>) ((ConfigurableParameter<?>) parameter).bindsTo(Evaluation.property(name)); } parameterized.setParameterStore(store); } private void throwRedefinitionError(Rule rule, String name) { throw new IllegalStateException("Subset cannot re-configure parameter [" + name + "] that was configured in parent Configuration. Re-definition was attempted at [" + rule + "] "); } }; Visitor<Condition> conditionVisitor = new ParameterizedConditionVisitor(callback); new ConditionVisit(rule).accept(conditionVisitor); Visitor<Operation> operationVisitor = new ParameterizedOperationVisitor(callback); new OperationVisit(rule).accept(operationVisitor); } }
and
public void setParameterStore(final ParameterStore parent) { for( int i = 0; i < config.getRules().size(); i++ ) { Rule rule = config.getRules().get(i); if( ! (rule instanceof RuleBuilder) ) continue; ParameterizedCallback callback = new ParameterizedCallbackImpl(rule, parent); } } private static class ParameterizedCallbackImpl implements ParameterizedCallback { parameterized.setParameterStore(store); }
Which one do you like more? In the first, the logic nests deeper and deeper and it's hard to keep the context in head. The second abstracts the implementation away and keeps just the name of the class, or, a contract.
Another example:
@SuppressWarnings("unchecked") public <T extends WindupVertexFrame> T findSingletonVariable(Class<T> type, String name) { Iterable<WindupVertexFrame> frames = findVariable(name); T result = null; Iterator<WindupVertexFrame> iterator = frames.iterator(); if (iterator.hasNext()) { Object foundObject = iterator.next(); // Check the type. if (!type.isAssignableFrom(foundObject.getClass())) { throw new IllegalTypeArgumentException(name, type, foundObject.getClass()); } result = (T) foundObject; // Check if there's just 1. if (iterator.hasNext()) { throw new WindupException("findSingleton called for variable \"" + name + "\", but more than one result is present."); } } return result; }
and
@SuppressWarnings("unchecked") public <T extends WindupVertexFrame> T findSingletonVariable(Class<T> type, String name) { Iterable<WindupVertexFrame> frames = findVariable(name); if( null == frames ) throw new WindupException("Variable not found: " + name); Iterator<WindupVertexFrame> iterator = frames.iterator(); if( ! iterator.hasNext() ) return null; Object obj = iterator.next(); // Check if there's just 1. if( iterator.hasNext() ) throw new WindupException("More than one frame present " + "under presumed singleton variable: " + name); // Check the type. if( ! type.isAssignableFrom(obj.getClass()) ) throw new IllegalTypeArgumentException(name, type, obj.getClass()); return (T) obj; }
Obviously, the second example's logic is clearer and eaiser to follow. The conditions, which can result in returning a special (null) value or throw an exception, are handled as soon as possible, and do not clutter the actual logic of the main task.
Conclusion:
For the sake of readability, try to keep your code flat, in the sense of not nesting loops and conditions too much.
Navštívil jsem pracovně Charlotte v Severní Karolíně, a protože většinu nákladů tvoří letenka, trochu jsem si to prodloužil.
Co tedy v Charlotte dělat v pracovním čase a co o víkendu?
Když se řekne Charlotte, většina našinců si bude myslet buď že to je městečko ve Francii, nebo nějaká vesnice na středozápadě. Omyl, je to 17. největší město USA Kolem 1,7 milionu obyvatel, s aglomerací přes 2,3. Je to hodně smíšené město, co se týká, řekněme, výrazných vzhledových odlišností. (Naplno se tady o takových odlišnostech nemluví, s výjimkou hraní "cards against humanity"). Ve srovnání s jinými městy USA je tu celkem levně, mimo centrum stojí potraviny cca o polovinu víc než v ČR. Prakticky všechno se tu dá platit kartou, včetně taxi a stánků na letišti. Já za celou dobu nepoužil hotovost (ani jsem ji nevezl )
Město vzniklo na křižovatce dvou velkých indiánských cest, čemuž vděčilo za svůj prvotní rozvoj, a možná i za budoucí určení - je to druhé největší centrum bankovního sektoru USA (po New Yorku). Je to vidět i v centru - většinu mrakodrapů tu vlastní a používají banky.
Není to vyloženě turistický cíl. Opravdu tu prakticky není co vidět. Ani v okolí žádné extra parky či cokoliv nenajdete. Památky žádné. Když jsem se ptal na aquapark, což byste ve městě s průměrnou denní letní teplotou kolem 36 stupňů čekali, místní se zamysleli a říkali - jooo, jeden bazén támhle někde na jihu má vlastně jednu skluzavku. Mno...
A pokud čekáte, že to nic aspoň uvidíte z výšky, tak taky vedle: Banky totiž po 9/11 znepřístupnily nejen střechy, ale prakticky celé budovy. Takže z otvíráku na flašky, aka Duke Energy tower, se nepodíváte. Jediné místo, kde snad je někdy možné shlédnout Charlotte z poloviční výšky, je restaurace Bentley v 27. patře - bentleyson27.com - ale ta v neděli asi nepremává, takže já neviděl.
Sami místní shrnují, že Charlotte skutečně moc co nabídnout nemá, ale že je celkem fajn pro život - poklidné relativně bezpečné čisté město s fungující infrastrukturou.
Struktura Charlotte je celkem jednoduchá:
Rušné cca obdélníkové centrum s mrakodrapy, obehnané dálničním okruhem, velké asi 1,5 x 2,5 km.
A kolem toho mraky parcel s rodinnými domky, které jsou sice každý jiný, ale styl je víceméně na jedno brdo.
Jihovýchod města je bohatší, bezpečný, klidný, bílý, prorostlý zelení.
Severozápad je potom chudší, nevím jak moc nebezpečný, ale kolegové mi tam nedoporučovali chodit, zejména ne v noci; rušnější (ve smyslu brněnského Cejlu) a vyprahlejší (kdo by platil za vodu na zalévání).
Hranicí mezi těmito dvěma je plus mínus Tyron Street.
Ve městě je slušná MHD. Místní říkají, že je pomalá a neefektivní. Vyzkoušel jsem, a je rychlá zhruba jako u nás. Ale doprava je tu celkově klidná a plynulá, takže ve srovnání s auty je skutečně tak 4x pomalejší - na rozdíl např. od Prahy, kde je metro skoro vždy bezkonkurenčně rychlejší.
Centrem zhruba podél Tyron Street prochází vláček. Lístek je za 2 dolary. Moc rychle se neposunuje, v rámci centra ani nemá cenu do něj nastupovat.
Dále jsou tu autobusy, celkem v pohodě, ale staví co pár metrů. Cesta z letiště do centra je tak na hodinu, autem ani ne 20 minut.
Za 8 dolarů si můžete půjčit kolo ze stojanů, které je první půlhodinu zdarma, a za každou další platíte $4. To má motivovat lidi ke krátkým popojížďkám. Když už v tom budete, podívejte se určitě na stezku Little Sugar Gree Way, která vede korytem podle potůčku na jihu kolem několika parků.
Taxi mají taxametr, je to drahé asi jako v Praze bez taxametru. Z letiště opravdu doporučuju vzít taxík. Telefon na ně je tu 444-4444, nebo tak nějak.
Je tu také jakési neoficiální taxi, které funguje přes aplikaci v mobilu, TODO: Zjistit.
Parkování je řešeno parkovacími domy, obvykle kolem $6 od osmi do tří.
No a nakonec, pěšky se tu chodí celkem dobře, po centru asi ani nemá cenu řešit něco jiného.
Sehnat bydlení doporučuju na AirBnB.com, pokud hledáte něco levnějšího, kolem $50 - tam lidi pronajímají svoje domácí pokoje.
Dále lze zkusit Couchsurfing.com, ale přišlo by mi blbý někomu okupovat stůl a tak, to je vyloženě na přespání. Navíc to tu moc nefrčí.
Další možností je hotwire.com, což je takový slevomat pro hotely. Já sehnal za $66 v Holiday Inn, což je prý dobrá cena. Na pokoji lednička, mikrovlnka, samozřejmě záchod, sprcha a nepraktické umyvadlo, a rychlá, ale nestabilní wifi. Je lepší jít s noťasem blíž k routru, který je někde na chodbě. Vidím tu i ethernetovou (RJ) zásuvku, ale nemám síťový kabel, takže netuším, jestli je živá. Jméno a heslo dostanete automaticky zdarma k pobytu.
Americká kuchyně je asi víceméně stejk. Vše ostatní jsou různé další světové. Jsou tu tendence sdružovat podniky jednoho druhu do jednoho místa, takže v jednom domě najdete italskou Mama's, Etiopian Cousine, Chinese food, French restaurant a další. Osobně nedoporučuju zkoušet fancy restaurace a dávat si medium rare steaky nebo sushi - aspoň můj středoevropský trávicí trakt se s tím nevyrovnal.
Jak už jsem psal, je zde tendence shlukovat podniky podobného rázu do jednoho místa. V případě klubů je to The Epicentre. Je to takové "klubový obchoďák" (jak to trefně označila Hanka). Je to asi 5patrový barák o velikosti bloku, ve kterém je asi 15 klubů, a pár obchodů. Do většiny se neplatí vstupné. Pivo je kolem 6 dolarů, dýško se tu dává cca. 10 %.
Barmani jsou ochotní, rádi vám vyberou pivo, ale točí se celou dobu jak čamrdy, takže na nějaké velké vybavování to není. To je škoda. protože tu obvykle úplně chybí nápojové lístky. Ale aspoň máte záminku pokecat s místníma, co si dát Na pokec tu slouží střešní stage, které jsou podstatně méně hlučné než ty vnitřní.
Ještě ochotnější jsou sekuriťáci. Ti vám rádi poradí, který klub co hraje, kde najít jakou sortu lidí. Například, pokud jako já hledáte electro, house, trance, chillout, tak to máte smůlu. Na to musíte do jednoho ze dvou dalších center: NoDa nebo The Music Factory Boulevard. Zkusil jsem jít do The Vault, což je venkovní stage, kde se hraje černošská muzika, a podle toho vypadá osazenstvo - byl jsem tam jediný odlišný, jinak samí "brothas". Ale jsou v pohodě, nekoukaj na vás jak když u nás vlezete do cikánské hospody. Akorát u baru je dost tlačenice, obvykle jsou hodně velcí a silní.
Pouliční ruch končí v 11, kromě těch výše uvedených center si tedy hospody stáhnou lidi z ulic dovnitř.
Vše potom úplně zavírá ve dvě. To je celostátní zákon. Poté už jedou jen strip cluby, kde jsem nebyl, ale údajně celkem draho a nuda - nalití mladí bankéři balí striptérky a snaží se být vtipní.
Já jel pracovně, tedy do RH office. Vzhledem k tomu, že místní pobočka je pro konzultanty, jako asi většina v US, je celkem malá - je to v podstatě jedna větší místnost a k ní dvě zasedačky. Nečekejte tu nic než 6 stolů a 8 židlí. Obvykle tu sedí tak 2-3 lidi. Narazíte tu na Matyáše, Brada, Lincolna, Josh, a další. Kuchyňka je společná pro celé patro, kde je asi 20 firem.
Kancelář je v 10. patře budovy Regus, která patří nějaké bance, která zabírá spodní patra až do 8. Celkem fajn výhled, ale lepší získáte např. ze střechy Holiday Inn. Jinak nějaký velký výhled asi nenajdete - mrakodrapy patří bankám, a ty nemají moc potřebu pouštět na svou střechu turisty (kterých tu beztak moc není).
Na závěr snad už jen dodám, že jsem ještě nikdy neviděl tolik veverek. Na jihovýchodě, kde je hodně zeleně, a v parcích, jsou tisíce veverek. Když se ubytujete v nějakém domečku, budou fám ráno čumět do okna
Kdyby někoho něco zajímalo, dejte vědět.
Další štace: Raleigh, možná New York. Škoda že propásnu Charlestone.
Pro elektronický klíč kontakt s českou státní správou si stát vynucuje klíč od České Pošty prostřednictvím služby PostSignum nebo dalších dvou agentur.
Stát neuznává klíče od autorit jako jsou VeriSign.
Ani jedna z tří uznávaných není např. v produktech Mozilly (Firefox, ThunderBird).
Proto je potřeba si importovat (do každého zvlášť) jejich klíče:
http://www.styxen.cz/kontaktyhttp://www.postsignum.cz/files/ca/postsignum_qca2_root.cer
http://www.postsignum.cz/files/ca/postsignum_qca2_sub.cer
http://www.postsignum.cz/files/ca/postsignum_vca2_sub.cer
dle návodu: http://www.postsignum.cz/files/navody/inst_ca_thunderbird/index.html
Do té doby se klíče budou tvářit, jakože nemají žádného Issuera.
Jelikož agentura 1. Certifikační Agentura dává v programu TWINS i komerční klíč zdarma, doporučuji zařídit si klíč u ní, i když to nezařídí na každé poště jako PostSignum.cz.
In case you would like to use a Java Decompiler...
Until recently, all of them are either unstable, or obsolete, or not finished, or commercial, or - in the best case - all of that. And if not - then they were commercial.
The obsoletnes typically proved as the fact that they can only decompile JDK 1.3 bytecode.
The only so-so working solution was to take the .class file and pre-process it so it becomes JDK 1.3 compatible, and then run JaD over it (one of those better old decompilers).
The situation was a bit chaotic as many of the sites are down, some decompilers used multiple names or had the originality level 6000 of naming itself "Decompiler" or "Java Decompiler", or JD, JaD, JADE, JODE, JDec, etc. in better case, but changing these abbrevs over time.
But recently, a new wave of decompilers is coming: Procyon, CFR, Krakatau, Candle, JBVD, EDJC.
Here's a list of decompilers as of May 2014.
2014. JDK 5, partly 6. Written in Java. Worth trying.
2014. JDK 6, 7, 8 support. Written in Java 6.
“CFR by Lee Benfield is well on its way to becoming the premier Java Decompiler. Lee and I actually work for the same company and share regression tests. We're engaged in a friendly competition to see who can deliver a better decompiler. Based on his progress thus far, there's a very good chance he will win--at least on decompiling obfuscated code :)”
2013. Written in Java. By Brad Davis @ RH. “only decompiles a subset of the JVM operations”.
2014. JDK 7 support? Written in Python.
“Includes a robust verifier. Focuses on translating arbitrary bytecode into valid Java code, as opposed to reconstructing the original code.”
2013. Academic Free License (AFL). Javassist approach. Unknown quality.
2011. Written in Java.
JD-Core and JD-GUI are written in C++.
Quite good, but no idea where to get it. Supposedly at MCP - http://mcp.ocean-labs.de
Also here: http://forum.xda-developers.com/showthread.php?t=2029842
“Hello, I would like to share this java decompiler with the community. FernFlower is the first analytic decompiler for java. It will decompile class files and jar files to human readable java code. Unlike JD-GUI it does not decompile to byte code. It also will deobfuscate the source if you ask it to. This tool should work well with dex2jar. The files are attached. It requires java to run.”
2002. Seems to be unstable.
Commercial, no fee for noncommercial use, no source code.
Needs JadRetro http://jadretro.sourceforge.net/
GPL. Last update 2007.
Last release 1996…
Commercial, patch to Mocha.
JDK 1.3; Free, GPL, not actively maintained
0.2.2 in 2002. Free, GPL. Written in C++.
2002, supports JDK 1.3. Free, GPL.
2008 - reportedly, a beta released. Otherwise it seems 2002. Free, GPL. Written in Java.
Pretty bad. "freeware", no source code.
Pretty bad.
So, TinkerPop is kind of set of libraries over Blueprints, a standardized API to access graph databases.
Of which Frames is something allowing wrapping the contents of the graph into Java objects.
Which is great, but in the current version, TinkerPop 2.5.0, the functionality is quite basic.
For example, you can't query for all objects of some class. You would expect this to be done, as it's not that hard to implement.
Thanks to Jesse Sightler who is working on this Frames "extension" in the Windup project.
For the migration project, I play with graph databases stuff.
As in most areas, this is rather an ecosystem than a project.
These are the very basics which I have asked during 1st hour.
Titan is an implementation of graph database.
TinkerPop is a set of APIs and libraries.
The most important is BluePrints, which is an API to query a database. Something like JDBC for graph dbs.
TitanGraph implements the BluePrints API.
<dependency> <groupId>com.thinkaurelius.titan</groupId> <artifactId>titan-core</artifactId> <version>0.4.4</version> </dependency> <dependency> <groupId>com.thinkaurelius.titan</groupId> <artifactId>titan-berkeleyje</artifactId> <version>0.4.4</version> </dependency>
Titan has the BluePrints API as dependency, so no need to include extra.
Titan comes with
Berkeley DB is the database used by default. You can change this by some System property (TODO).
So you need to add the titan-berkeleyje, otherwise you'd get:
Could not find implementation class: com.thinkaurelius.titan.diskstorage.berkeleyje.BerkeleyJEStoreManager at com.thinkaurelius.titan.diskstorage.Backend.instantiate(Backend.java:347) at com.thinkaurelius.titan.diskstorage.Backend.getImplementationClass(Backend.java:367) at com.thinkaurelius.titan.diskstorage.Backend.getStorageManager(Backend.java:311) at com.thinkaurelius.titan.diskstorage.Backend.<init>(Backend.java:121) at com.thinkaurelius.titan.graphdb.configuration.GraphDatabaseConfiguration.getBackend(GraphDatabaseConfiguration.java:1173) at com.thinkaurelius.titan.graphdb.database.StandardTitanGraph.<init>(StandardTitanGraph.java:75) at com.thinkaurelius.titan.core.TitanFactory.open(TitanFactory.java:40) at com.thinkaurelius.titan.core.TitanFactory.open(TitanFactory.java:29) at cz.oz.tinkerpoptry.Main.main(Main.java:21)
Other option is to use titan-all, but that might make the deps go big.
TitanGraph g = TitanFactory.open("/tmp/titan-rodokmen"); // Manipulation through BluePrints API. Vertex oz = g.addVertex(null); oz.setProperty("name", "Ondrej Zizka"); Vertex sz = g.addVertex(null); sz.setProperty("name", "Stanislava Zizkova"); Edge e = g.addEdge( null, sz, oz, "parent"); Edge e = g.addEdge( null, sz, oz, "parent"); jz0.setProperty("name", "Josef Zizka"); jz0.setProperty("man", true);
Voila, this should be enough. You'll get:
--- exec-maven-plugin:1.2.1:exec (default-cli) @ TinkerpopTry --- 0 [main] INFO com.thinkaurelius.titan.diskstorage.Backend - Initiated backend operations thread pool of size 8 83 [main] INFO com.thinkaurelius.titan.graphdb.database.serialize.kryo.KryoSerializer - Kryo serializer enabled with utf8: false ------------------------------------------------------------------------ BUILD SUCCESS
Recently, my EAP app on OpenShift stopped working. It wouldn't start. ctl_app -t start (-t is for trace log) shown:
[web-ozcz.rhcloud.com ...]\> ctl_app -t start Starting gear... MySQL already running Starting PHPMyAdmin cartridge httpd (pid 279843) already running Starting jbosseap cartridge jbosseap process failed to start An error occurred executing 'gear start' (exit code: 2) Error message: CLIENT_ERROR: Failed to execute: 'control start' for /var/lib/openshift/.../jbosseap /opt/rh/ruby193/root/usr/share/gems/gems/openshift-origin-node-1.21.6/lib/openshift-origin-node/model/v2_cart_model.rb:1313:in `block in do_control_with_directory' /opt/rh/ruby193/root/usr/share/gems/gems/openshift-origin-node-1.21.6/lib/openshift-origin-node/model/v2_cart_model.rb:1114:in `process_cartridges' /opt/rh/ruby193/root/usr/share/gems/gems/openshift-origin-node-1.21.6/lib/openshift-origin-node/model/v2_cart_model.rb:1276:in `do_control_with_directory' /opt/rh/ruby193/root/usr/share/gems/gems/openshift-origin-node-1.21.6/lib/openshift-origin-node/model/v2_cart_model.rb:1136:in `do_control' /opt/rh/ruby193/root/usr/share/gems/gems/openshift-origin-node-1.21.6/lib/openshift-origin-node/model/v2_cart_model.rb:1498:in `start_cartridge' /opt/rh/ruby193/root/usr/share/gems/gems/openshift-origin-node-1.21.6/lib/openshift-origin-node/model/v2_cart_model.rb:1437:in `block in start_gear' /opt/rh/ruby193/root/usr/share/gems/gems/openshift-origin-node-1.21.6/lib/openshift-origin-node/model/v2_cart_model.rb:80:in `block in each_cartridge' /opt/rh/ruby193/root/usr/share/gems/gems/openshift-origin-node-1.21.6/lib/openshift-origin-node/model/v2_cart_model.rb:1120:in `block in process_cartridges' /opt/rh/ruby193/root/usr/share/gems/gems/openshift-origin-node-1.21.6/lib/openshift-origin-node/model/v2_cart_model.rb:1118:in `each' /opt/rh/ruby193/root/usr/share/gems/gems/openshift-origin-node-1.21.6/lib/openshift-origin-node/model/v2_cart_model.rb:1118:in `process_cartridges' /opt/rh/ruby193/root/usr/share/gems/gems/openshift-origin-node-1.21.6/lib/openshift-origin-node/model/v2_cart_model.rb:78:in `each_cartridge' /opt/rh/ruby193/root/usr/share/gems/gems/openshift-origin-node-1.21.6/lib/openshift-origin-node/model/v2_cart_model.rb:1432:in `start_gear' /opt/rh/ruby193/root/usr/share/gems/gems/openshift-origin-node-1.21.6/lib/openshift-origin-node/model/v2_cart_model.rb:1441:in `start_gear' /opt/rh/ruby193/root/usr/share/gems/gems/openshift-origin-node-1.21.6/lib/openshift-origin-node/model/application_container.rb:446:in `start_gear' /usr/bin/gear:479:in `block (3 levels) in <main>' /usr/bin/gear:65:in `do_command' /usr/bin/gear:474:in `block (2 levels) in <main>' /opt/rh/ruby193/root/usr/share/gems/gems/commander-4.0.3/lib/commander/command.rb:180:in `call' /opt/rh/ruby193/root/usr/share/gems/gems/commander-4.0.3/lib/commander/command.rb:180:in `call' /opt/rh/ruby193/root/usr/share/gems/gems/commander-4.0.3/lib/commander/command.rb:155:in `run' /opt/rh/ruby193/root/usr/share/gems/gems/commander-4.0.3/lib/commander/runner.rb:385:in `run_active_command' /opt/rh/ruby193/root/usr/share/gems/gems/commander-4.0.3/lib/commander/runner.rb:74:in `run!' /opt/rh/ruby193/root/usr/share/gems/gems/commander-4.0.3/lib/commander/delegates.rb:11:in `run!' /opt/rh/ruby193/root/usr/share/gems/gems/commander-4.0.3/lib/commander/import.rb:10:in `block in <top (required)>'
There was no log I could use, and the message above was a dead end.
I've tried to start EAP on my own. Didn't work, saying:
org.jboss.modules.ModuleNotFoundException: org.jboss.as.standalone:main at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:240) at org.jboss.modules.Main.main(Main.java:385)
So I started going through the labyrinth of links in the OpenShift infrastructure, and found that there's a link vs. actual dirs mismatch:
/etc/alternatives/jbosseap-6.0/modules (this is a link) vs. /etc/alternatives/jbosseap-6/ (this is what exists on the system)
After fixing the link manually, EAP started working again.
I don't remember changing the link before. Did it happend during some infrastructure changes? Was I the only one?
Shortly before this happened, I was struggling with insufficient disk space and EAP crashed because of that. Was that related? ...
Hope this helps someone.
Besides Windup, there's a
nother tool which may help you migrate your applications from WebLogic, GlassFish or older JBoss servers to JBoss EAP 6: Tubame. (Github project here).
I have tried this tool recently. Here's some info.
Installation is a bit tricky:
When done, you should be able to find the right windows in Eclipse.
One is a tree with complex structure of chapters, categories and subcategories. Here you may edit the rules.
The other is the results window where Tubame shows the matched results.
To fill it, open a legacy web project and right-click on a project and in the menu, choose Tubame -> Knowledge base search / Dependency search.
A dialog will open. Depending on what are you migrating from, choose a .xml file from the migration-knowledge.
But - it has to be under your project's dir, so first copy e.g. git-migr-know/WLS9ToEAP6/Japanese/ to your project.
Then right-click your project and Refresh, and repeat the step with the dialog. Choose the .xml rules file and Next.
The sources will be scanned and finally, you'll see a table with the results.
Clicking on a table shows some documentation regarding migraton of that item.
Tubame appears to be an experimental project which may evolve into something generally useful. Currently, the best it can offer is quite a lot of simple rules which match JBoss EAP 4 or WebLogic 9 specific FQCN's and resources. When you get it running.
Tubame is an evolving project, open-sourced just recently, and needs your help. If you decide to try it for migration of your apps, please go to the Tubame project Github page, fill an issue if something doesn't work, suggest improvements, and at best - add your rules & make a pull request! Or just add them as an issue in the user-knowledge issues. Thanks!
This piece of information isn't easy to google up as a compact whole, so here you go:
The maven jboss-as plugin serves for easy deployment as a part of a build or just through maven.
First you have to add the plugin to pom.xml so maven knows about it:
<!-- JBoss AS plugin to deploy the war. --> <plugin> <groupId>org.jboss.as.plugins</groupId> <artifactId>jboss-as-maven-plugin</artifactId> <version>7.4.Final</version> <configuration> <hostname>${jboss-as.deploy.hostname}</hostname> <fileNames> <fileName>target/${plugin.war.warName}.war</fileName> </fileNames> </configuration> </plugin>
Notice that the <hostname> and <fileName> is generic so you can set the properties for devel, test and prod environment.
Then, simply follow the docs of the plugin:
mvn jboss-as:deploy mvn jboss-as:undeploy mvn jboss-as:redeploy
It's a bit inconvenient that you have to keep in mind whether the app is deployed or not and use deploy or redeploy accordingly.
When you run this goal, by default, it runs the 'package' phase first. If you just want to redeploy what's already built, use the 'redeploy-only' goal.
A hint about how to customize:
First, provide the defaults.
<properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <!-- Local vs. OpenShift vs. production. Controlled in profiles. --> <jboss-as.deploy.hostname>localhost</jboss-as.deploy.hostname> <!-- Where to deploy. --> <jboss-as.deploy.user>jboss-as.deploy.user is not defined (try settings.xml).</jboss-as.deploy.user> <jboss-as.deploy.pass>jboss-as.deploy.pass is not defined (try settings.xml).</jboss-as.deploy.pass> <plugin.war.warName>${project.build.finalName}</plugin.war.warName> <!-- To change to ROOT for "prod", to go to / context. --> </properties>
(The user and pass are not used in this example but you may need/want to.)
Then, in profiles, add the specifics.
In the OpenShift profile, the war is not deployed by maven - rather by openshift itself, after the build.
For production environment, we change the name to ROOT.war.
<profiles> <!-- OpenShift. --> <profile> <id>openshift</id> <build> <plugins> <plugin> <artifactId>maven-war-plugin</artifactId> <version>2.4</version> <configuration> <outputDirectory>deployments</outputDirectory> <warName>ROOT</warName> </configuration> </plugin> </plugins> </build> </profile> <!-- Production. --> <profile> <id>prod</id> <activation> <property><name>prod</name></property> </activation> <properties> <wicket.mode>development</wicket.mode> <!-- development | deployment --> <jboss-as.deploy.hostname>products.app.eng.bos.redhat.com</jboss-as.deploy.hostname> <plugin.war.warName>ROOT</plugin.war.warName> </properties> <!-- JBoss AS plugin - deploy automatically. --> <build> <plugins> <plugin> <groupId>org.jboss.as.plugins</groupId> <artifactId>jboss-as-maven-plugin</artifactId> <configuration> <force>true</force> <username>admin</username> <password>${essc.deploy.pass.prod}</password> <filename>ROOT.war</filename> </configuration> </plugin> </plugins> </build> </profile> </profiles>