I am trying to generate a schema diagram using Schemacrawler but it is generating empty png file. I couldn't find the problem. Below are the command is used:
call java -classpath ../../_schemacrawler/lib/*;lib/* schemacrawler.Main -driver=oracle.jdbc.driver.OracleDriver -url=jdbc:oracle:thin:#localhost:1521:orcl -user=certus2713 -password=certus2713 -schemas=certus2713 -tables="certus2713.NTH_USERS" tabletypes=TABLE -loglevel=CONFIG -infolevel=standard -command="graph" -Gdpi=300 -g=schemacrawler.config.properties -outputformat=png -outputfile=D:\dev\database-diagram.png %*
echo Database diagram is in database-diagram.png
SchemaCrawler is behaving as designed. -tables takes a regular expression. You probably intended to say -tables=certus2713\.NTH_USERS Note that there are no double-quotes, and there is a slash before the dot to make it literal. Or, better still, use -tables=.*\.NTH_USERS
Sualeh Fatehi, SchemaCrawler
Related
When I applied pattern in JDL, the generated entity classes has #Patternannotation, but the value for that annotation is not the exact pattern which applied in JDL.
For example, if I've defined patterns as pattern('/[^\\s]+.*[^\\s]+/') and in java
it reflects as
#Pattern(regexp = "[^\\\\s]+.*[^\\\\s]+")
If you noticed in java class, there are 4 (slash) which indeed should be 2 only. Because of this functionality is getting failed.
It looks to me like you are trying to use regex control characters in your pattern, which do not need to be doubled up in your JDL: see https://www.jhipster.tech/jdl/entities-fields, especially the part under "Regular Expressions" where it says: "/.../ the pattern is declared inside two slashes... \ anti-slashes needn’t be escaped"
So it's acting correctly. Since you have double-backslants in your JDL, Java is correctly interpreting it with quadruple-backslants. Your solution is just to use single backslants in your JDL, as per the documentation.
I'm writing some code with Slick and I'd like to be able to print the "Slick Query Tree" - is it possible somehow?
I assume you want to see the abstract syntax tree for queries?! You can watch this movie: http://youtu.be/THlvR9bXHIc - it is also referenced at "http://slick.typesafe.com/docs/" below "Screencast 1: Introduction to the query compiler".
AFAIK you can use method toNode and nodeChildren in your own slick code to recursively traverse the AST.
We log them.
See Slick logging with slf4j-simple
See the available loggers here https://github.com/slick/slick/blob/master/common-test-resources/logback.xml
You'll need to look at the compiler ones.
I'm trying to remove the directory prefix from $soy:
a=${soy#*$PREFIX}
then changing slashes per dots:
b=${a//\//.}
the goal is to convert a file-path to a module path inside a program.
Anyways, is there any way to do this i one expression using composition?
This doesn't work :(
${${soy#*$PREFIX}//\//.}
According to this blog comment at Linux Journal, you can't do multiple operations in one expression.
I am trying to do an XSL transform on an xml structure in a bpel assignment statement. There is a syntax problem, but I am having trouble finding official documentation. There are examples all over the internet but I have not found a clear explanation. Here is my best shot. What do the last two parameters do? Why is eclipse saying the first argument must be a literal, even though test3.xsl is a string?
<bpel:assign validate="yes" name="Assign">
<bpel:copy keepSrcElementName="no">
<bpel:from>
<![CDATA[bpel:doXslTransform("test3.xsl", $personalInfoServiceOutput.parameters), "middle", $positionSkillManagementInput]]>
</bpel:from>
<bpel:to variable="positionSkillManagementInput"></bpel:to>
</bpel:copy>
</bpel:assign>
The signature of doXSLTransform looks as follows:
object bpel:doXslTransform(string, node-set, (string, object)*)
The first parameter is the name of the XSLT script, the second parameter is an XPath identifying the source document (e.g. a variable, part, nodeset, node). The third and the fourth parameter is a key-value pair, the string is the key and the object is the value. Those pairs are mapped into the script's parameter context so that you can access these values by their name in the script. There can be any number of these pairs.
The best resource to look up such things is the WS-BPEL 2.0 specification, doXSLTransform is described in Sect. 8.4
When I use the following code :
<bpel:copy keepSrcElementName="no">
<bpel:from>
<![CDATA[bpel:doXslTransform("parseSample.xsl", $output.payload)]]>
</bpel:from>
<bpel:to variable="output"></bpel:to>
</bpel:copy>
I also get the error, that first argument must be literal string.
But, when I deploy my service (with error) to wso2 bps, it works fine.
You can try with this.
I faced the same issue. Agree with NGoyal. Shows error in BPEL but works when deployed.
i have something like
<s:link view="/member/index.xhtml" value="My News" propagation="none"/>
<s:link view="/member/index.xhtml" value="#{msg.myText}" propagation="none"/>
where the value of myText in the messages.properties is
myText=My News
The first line of the example works fine and replaces the text to "My News", but the second that uses a value from the resource bundle escapes the ambersand, too "My News".
I tried also to use unicode escape sequences for the ambersand and/or hash with My\u0026\u0023160;News, My\u0026#160;News and My\u0026nbsp;News in the properties file without success.
(Used css no-wrap instead of the previous used xml encoding, but would be interested anyway)
EDIT - Answer to clarified question
The first is obviously inline, so interpreter knows that this is safe.
The second one comes from external source (you are using Expression Language) and as such is not safe and need to be escaped. The result of escaping would be as you wrote, basically it will show you the exact value of HTML entity.
This is related to security (XSS for example) and not necessary i18n.
Previous attempt
I don't quite know what you are asking for but I believe it is "how to display it?".
Most of the standard JSF controls contain escape attribute that if set to false won't escape the text. Unfortunately it seems that you are using something like SeamTools which does not have this attribute.
Well, in this case there is not much to be done. Unless you could use standard control, maybe you should go and try to actually save your properties file as Unicode (UTF-16 BigEndian in fact) and simply put valid Unicode non-breaking space character. Theoretically that should work; Unicode-encoded properties files are supported in latest version of Java (although I cannot recall if it was Java SE 5 or Java SE 6)...