myStr="Test"
myLowerCaseStr=${myStr,,}
myUpperCaseStr=${myStr^^}
echo "String: ${myStr}"
echo "Lower Case String: ${myLowerCaseStr}"
echo "Upper Case String: ${myUpperCaseStr}"
The output would be as follows:
String: Test
Lower Case String: test
Upper Case String: TEST
Spring Data JPA Queries are a great way to create queries derived from the method name without needing to write tons of boiler-plate code to create connection & query, execute it and then process the result set. This generally works fine for simple queries and method names are very explicit in pointing out what is being returned by that method so the code is more readable and maintainable. To make this work successfully, the method name has to follow certain conventions:
| Keyword | Sample | JPQL snippet |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Recently I was trying to grep for "load average" in the output of top and then redirect it to a file to save for later analysis - however the output file would be totally empty for quite some time. That is the time I realized that grep was buffering its output causing the output file to be empty. So the grep command was not writing to the file immediately but was collecting large amounts of data in its buffer before flushing that out to the file.
My original command was
top -b -u myusername -d 5 | grep -i 'load average' > /tmp/load_averages.log
Because this did not write anything to the output file for quite a while, I had to change it buffer only till it saw a newline in the output and then to flush out whatever it has gathered so far in its buffer as below:
top -b -u myusername -d 5 | grep -i 'load average' --line-buffered > /tmp/load_averages.log
And lo behold, tailing the output file shows the load averages being printed every 5 seconds (because of the -d 5 flag given to the top command)
Say you have a huge file, but want to extract only a specific range of lines from that file into another one. There are many ways to do this, but a very simple way would be to use sed as follows:
sed -n '$start_line,$end_linep;$end_lineq' input_file.txt > output_file.txt
This will print all lines from the start_line to end_line and stop processing once it reaches end_line.
Note that the p in the above command makes sed print the line and the q makes sed end once the specific line is processed. Since we have the print command inside the quotes, we suppress automatic printing of pattern space by specifying the -n switch. For example, to extract lines 1500 - 1700, we can use this command:
Another simple method is to use a combination of head and tail as follows:
head -n +$end_line input_file.txt | tail -n +$start_line > output_file.txt
Here the + before the line numbers tells the head to output up to that line number and for tail to output starting at that line number. So our command above uses head to get all lines till the last required line and then uses tail to get all lines including and following the required first line so we do not need to do any calculations in our head. For example, to extract lines 1500 - 1700, we can use this command:
head -n +1700 input_file.txt | tail -n +1500 > output_file.txt
An RPM package is a file consisting of a cpio archive that contains the files to be installed and a header that contains metadata information about the package.
You can use the simple utility tool rpm2cpio to convert the contents of an RPM package into a cpio archive and then use the cpio command to extract the contents of that archive without needing to install the RPM package.
rpm2cpio name_of_rpm_package.rpm | cpio -idmvNote that this will extract the files to the current folder.
Here is an explanation of the options used for the cpio command:
In my previous posts Using EJB Interceptors to add functionality to existing Beans, and Using EJB Interceptors to execute code AFTER service method completes, we saw how to use EJB3 Interceptors to add common concern features like logging, etc. to J2EE service methods.
In case you want to have common exception handling logic for all service method calls, you can wrap the return context.proceed(); in a try-catch block and handle the exception in the catch block as shown below:
package com.my.ejb.interceptors;
import javax.interceptor.AroundInvoke;
import javax.interceptor.InvocationContext;
public class MyInterceptor {
@AroundInvoke
public Object interceptorMethod(InvocationContext context) throws Exception {
try {
System.out.println("Before invoking method: " + context.getMethod());
return context.proceed();
} catch (Exception e) { // You can catch ALL or ONLY Specific Exceptions as per your requirement
System.out.println("Exception in method " + context.getMethod() + ": " + e.getMessage());
} finally {
System.out.println("After invoking method: " + context.getMethod());
}
}
}
Once this interceptor is created, we just need to add an "@Interceptors" annotation to the target EJB as:
import javax.interceptor.Interceptors;
@Interceptors({com.my.ejb.interceptors.MyInterceptor.class})
Now you should see log lines "Before ..." before the the method executes and "After..." after the method executes and in case of any exceptions in the metod call, you will see "Exception ..."
In my previous post Using EJB Interceptors to add functionality to existing Beans, we saw how to use EJB3 Interceptors to add common concern features like logging, etc. to J2EE service methods.
In case you want to run any piece of code after each service method call, you can wrap the return context.proceed(); in a try-finally block and add the "after" code in the finally block as shown below:
package com.my.ejb.interceptors;
import javax.interceptor.AroundInvoke;
import javax.interceptor.InvocationContext;
public class MyInterceptor {
@AroundInvoke
public Object interceptorMethod(InvocationContext context) throws Exception {
try {
System.out.println("Before invoking method: " + context.getMethod());
return context.proceed();
} finally {
System.out.println("After invoking method: " + context.getMethod());
}
}
}
Once this interceptor is created, we just need to add an "@Interceptors" annotation to the target EJB as:
import javax.interceptor.Interceptors;
@Interceptors({com.my.ejb.interceptors.MyInterceptor.class})
Now you should see log lines "Before ..." before the the method executes and "After..." after the method executes!
To add any decorations or cross-cutting features like logging, profiling or performance measurement for service method calls of existing enterprise beans, you can use EJB3 Interceptors that were provided starting with JavaEE5.
Interceptor is a method that wraps around the invocation of the actual business method call allowing you to apply the required feature and can either exist in the target class if it is very speficic to that class; or in an external class if it applies to multiple service methods. If it is a part of an external class, then it has to be the only method in that class having the annotation "@AroundInvoke"
This interceptor method takes the following form:
package com.my.ejb.interceptors;
import javax.interceptor.AroundInvoke;
import javax.interceptor.InvocationContext;
public class MyInterceptor {
@AroundInvoke
public Object interceptorMethod(InvocationContext context) throws Exception {
System.out.println("Going to invoke method: " + context.getMethod());
return context.proceed();
}
}
Once this interceptor is created, we just need to add an "@Interceptors" annotation to the target EJB as:
@Interceptors({com.my.ejb.interceptors.MyInterceptor.class})
And viola - it simply works, no need for any additionaly libraries or frameworks!
Note: Do not forget the return context.proceed(); call at the end of the interceptor method - this will allow the chain of interceptors to proceed and the target metod to be invoked!
git stash drop stash@{stash_index}
### OR
git stash clear
If you need to recover very recently deleted stashes, you can try the following two commands to try to recover them:
git fsck --unreachable | grep commit | cut -d ' ' -f3 | xargs git log --merger --no-walk2. Choose commit id of the stash that you want to restore and run the below command:
git stash apply [commit_id]
<script src="https://cdn.jsdelivr.net/gh/google/code-prettify@master/loader/run_prettify.js"></script>
<style>
li.L0, li.L1, li.L2, li.L3,
li.L5, li.L6, li.L7, li.L8 {
list-style-type: decimal !important;
}
</style>
<pre class="prettyprint linenums lang-sh"> ... your code ... </pre>
"bsh", "c", "cc", "cpp", "cs", "csh", "cyc", "cv", "htm", "html", "java", "js", "m", "mxml", "perl", "pl", "pm", "py", "rb", "sh", "xhtml", "xml","xsl"
<pre class="prettyprint"><code class="language-java">...</code></pre>
rsync -aihv --include='*/' --include='*.log*' --exclude='*' /source_folder/to/search/in/ /destination_folder/to/copy/to/
find /source_folder/to/search/in/ -name 'myapp*.log.201*' -exec rename -v .log. .oldlog. {} \; >> /temp/rename.log
for s1 in $(cat servers_list.txt); do
ssh -q ${s1} "grep 'search_string' /search/folder/*/*.log* | sed 's/^/${s1} => /'" >> /tmp/search.log
# Other commands here if required
done
foreach s1 in (cat servers_list.txt)
ssh -q ${s1} "grep 'search_string' /search/folder/*/*.log* | sed 's/^/${s1} => /'" >> /tmp/search.log
# Other commands here if required
end
server_name => [log line grepped from the log file]
