I am trying to step through an entire path and its single layer of sub directories. For each file, I need to read five data fields and output them to a delimited text file. I'm able to read from a single text file and validate my output on screen; after that I'm stuck. I cannot seem to to find the right parameters for FileVisit. Some specific questions are comments in my code posted below. And although I'm no nearly that far yes, I'd like to get some idea for writing to an output file, namely whether the place I wish to put it is the most logical one.
I've reviewed the https://stackoverflow.com/questions/9913/java-file-io-compendium and JavaDocs' info on the File Visitor
http://docs.oracle.com/javase/7/docs/api/index.html?java/nio/file/FileVisitor.html .
However, I'm still not able to get FileVisitor working properly.
#Bohemian suggested changing interface to class which I've done.
import java.nio.files.*;
public class FileVisitor<T>
{
Path startPath = Paths.get("\\CallGuidesTXT\\");
Files.walkFileTree(startPath, new SimpleFileVisitor(startPath))
\\ ^^^^^^
\\ errors out, <identifier expected>
{
#Override
public FileVisitResult visitFile(Path file, BasicFileAttributes attrs)
throws IOException
{
Files.list(file);
return FileVisitResult.CONTINUE;
}
// do my file manipulations here, then write the delimited line
// of text to a CSV fle...is this the most appropriate place for that
// operation in this sample?
}
}
SSCCE below...but comments in the version above point to specific questions I'm having.
import java.nio.*;
import java.util.*;
public class FileVisitor<T>
{
Path startPath = Paths.get("\\CallGuidesTXT\\");
}
Files.walkFileTree(startPath, new SimpleFileVisitor(startPath) {
#Override
public FileVisitResult visitFile(Path file, BasicFileAttributes attrs)
throws IOException {
Files.list(file);
return FileVisitResult.CONTINUE;
}
});
I'm a little rusty in Java but here's a rough idea of where I think you're going:
import java.nio.files.*;
public class MyDirectoryInspector extends Object
{
public static void main(String[] args) {
Path startPath = Paths.get("\\CallGuidesTXT\\");
Files.walkFileTree(startPath, new SimpleFileVisitor<Path>() {
#Override
public FileVisitResult visitFile(Path file, BasicFileAttributes attrs)
throws IOException
{
String firstLine = Files.newBufferedReader(file, Charset.defaultCharset()).readLine();
System.out.println(firstLine);
return FileVisitResult.CONTINUE;
}
}); // <- you were missing a terminating ");"
}
}
That should walk through the directories and print the first line of each file to std out. I haven't touched Java since 1.6 so the JDK7 stuff is a little new to me too. I think you are getting confused as to what's a class and what's an interface. In my example we start with a basic class called MyDirectoryInspector to avoid confusion. It's enough to give us a program entry point, the main method where we start the inspection. The call to Files.walkFileTree takes 2 parameters, a start path and a file visitor which I have inlined. (I think the inlining can be confusing to some people if you're not used to this style.) This is a way of defining the actual class right in the place where you wish to use it. You could have also defined the SimpleFileVisitor separately and just instantiated it for your call as follows:
import java.nio.files.*;
public class MyDirectoryInspector extends Object
{
public static void main(String[] args) {
Path startPath = Paths.get("\\CallGuidesTXT\\");
Files.walkFileTree(startPath, new SimpleFileVisitor<Path>());
}
}
public class SimpleFileVisitor<Path>()) {
#Override
public FileVisitResult visitFile(Path file, BasicFileAttributes attrs)
throws IOException
{
String firstLine = Files.newBufferedReader(file, Charset.defaultCharset()).readLine();
System.out.println(firstLine);
return FileVisitResult.CONTINUE;
}
}
It may make more sense, if you are just getting started, to keep things all separated. Define your classes without inlineing, take it one step at a time and make sure you understand each piece in isolation. My 2nd example gives you 2 individual pieces, a custom file visitor that can be used to print the 1st line of each file it visits and a program that uses it with the JDK Files class. Now let's look at another approach that omits the syntax:
import java.nio.files.*;
public class MyDirectoryInspector extends Object
{
public static void main(String[] args) {
Path startPath = Paths.get("\\CallGuidesTXT\\");
Files.walkFileTree(startPath, new SimpleFileVisitor());
}
}
public class SimpleFileVisitor()) {
#Override
public FileVisitResult visitFile(Object file, BasicFileAttributes attrs)
throws IOException
{
String firstLine = Files.newBufferedReader((Path)file, Charset.defaultCharset()).readLine();
System.out.println(firstLine);
return FileVisitResult.CONTINUE;
}
}
With the generics left off you have to declare file parameter as an Object type and cast it later when you choose to use it. In general, you don't want to replace an interface definition with a class definition or confuse the two as they are used for entirely different purposes.
Java interface can not have any implementations (ie code) - only method signatures.
Try changing interface to class:
public class FileVisitor<T> {
...
Now to answer your revised post...
You have a bracket in the wrong place:
Files.walkFileTree(startPath, new SimpleFileVisitor(startPath) {
#Override
public FileVisitResult visitFile(Path file, BasicFileAttributes attrs)
throws IOException {
Files.list(file);
return FileVisitResult.CONTINUE;
}
});
I moved the bracket after new SimpleFileVisitor(startPath) to enclose the visitFile method. What you have here is an anonymous class - that's where you provide an implementation "on the fly".
Related
I'm coding in Groovy and am having trouble with the Java 8 #Repeatable meta-annotation. I think I'm doing everything right, but it appears that Groovy is not recognizing #Repeatable. Here's my sample code; I'm expecting the information from both annotations to get stored in MyAnnotationArray:
import java.lang.annotation.*
class MyClass
{
#MyAnnotation(value = "val1")
#MyAnnotation(value = "val2")
void annotatedMethod()
{
println("annotated method called")
}
public static void main(String... args)
{
MyClass ob = new MyClass()
ob.annotatedMethod()
java.lang.reflect.Method m = ob.getClass().getMethod("annotatedMethod")
List annos = m.getAnnotations()
println("annos = $annos")
}
}
#Target(ElementType.METHOD)
#Retention(RetentionPolicy.RUNTIME)
#Repeatable(MyAnnotationArray)
public #interface MyAnnotation
{
String value() default "val0";
}
public #interface MyAnnotationArray
{
MyAnnotation[] MyAnnotationArray()
}
What happens is that I get this error:
Caught: java.lang.annotation.AnnotationFormatError: Duplicate annotation for class: interface MyAnnotation: #MyAnnotation(value=val2)
java.lang.annotation.AnnotationFormatError: Duplicate annotation for class: interface MyAnnotation: #MyAnnotation(value=val2)
Which is exactly what I get if I leave out the #Repeatable meta-annotation.
The code works fine if I leave out one of the duplicate MyAnnotations; then there is no error, and I then can read the annotation value as expected.
Is it possible that Groovy doesn't support the #Repeatable meta-annotation? I couldn't find any documentation that states this outright, though this page hints that maybe this is the case (scroll down to item 88).
seems to be not supported
i used java 1.8 and groovy 2.4.11
after compiling and de-compilig the same code i got this:
java:
#MyAnnotationArray({#MyAnnotation("val1"), #MyAnnotation("val2")})
public void annotatedMethod()
{
System.out.println("annotated method called");
}
groovy:
#MyAnnotation("val1")
#MyAnnotation("val2")
public void annotatedMethod()
{
System.out.println("annotated method called");null;
}
so, as workaround in groovy use
//note the square brackets
#MyAnnotationArray( [#MyAnnotation("val1"), #MyAnnotation("val2")] )
public void annotatedMethod()
{
System.out.println("annotated method called");
}
full script (because there were some errors in annotation declaration)
import java.lang.annotation.*
class MyClass
{
//#MyAnnotation(value = "val1")
//#MyAnnotation(value = "val2")
#MyAnnotationArray( [#MyAnnotation("val1"), #MyAnnotation("val2")] )
public void annotatedMethod()
{
System.out.println("annotated method called");
}
public static void main(String... args)
{
MyClass ob = new MyClass()
ob.annotatedMethod()
java.lang.reflect.Method m = ob.getClass().getMethod("annotatedMethod")
List annos = m.getAnnotations()
println("annos = $annos")
}
}
#Target(ElementType.METHOD)
#Retention(RetentionPolicy.RUNTIME)
#Repeatable(MyAnnotationArray)
public #interface MyAnnotation
{
String value() default "val0";
}
#Retention(RetentionPolicy.RUNTIME)
public #interface MyAnnotationArray
{
MyAnnotation[] value()
}
also tried against groovy 3.0.0-SNAPSHOT - the result is the same as for 2.4.11
Yes, Groovy has supported "repeatable" annotations for a long time even in Java 5 so long as retention policy was only SOURCE. This is what allows multiple #Grab statements for instance without the outer #Grapes container annotation. Being only retained in SOURCE makes them useful for AST transformations and within the Groovy compiler itself (and other source processors) but not really useful anywhere else. We don't currently support #Repeatable at all but plan to in a future version.
I can't seem to make this work let alone compile and I am at loss at how to fix it. My teacher gave us the following code (simplified for question's sake):
public static void doing1(String s) {
// add code here
}
public static void doing2(char start, char end) {
// add code here
}
public static int doing3(int num) {
// add code here
}
public static void doing4(Scanner keyboard) {
// add code here
}
I know what needs to go in each method (the work I mean) I just don't know how to print it out in the main method. We cannot change the code given to us, only add to it.
Thank you!
Overloading a method means having the same method name but the method signature (the parameters passed in) is different. So, what you have isn't actually an overload, it is for unique methods because they all have different names. As far as not compiling... what you posted looks fine - perhaps you have an error above or below that code. I believe this is what you are looking for:
public static void doing(String s) {
// add code here
}
public static void doing(char start, char end) {
// add code here
}
public static int doing(int num) {
// add code here
}
public static void doing(Scanner keyboard) {
// add code here
}
Here's a reference on overloads from the almighty John Skeet
I remember reading an example which shows how to set member of a mocked object, for ex:
MyClass mockedClass = mock(MyClass.class);
//and something like this to set `someVariable` with some value
Mokito.set(mockedClass.someVariable, actual_value_intended_to_be_set);
Unfortunately I am not able to find that link again. Can someone give a reverence to
such examples or explain it here ?
If you want your mock's outward behavior to look like mockedClass.someVariable has actual_value_intended_to_be_set, you can write:
when(mockedClass.getSomeVariable()).thenReturn(actual_value_intended_to_be_set);
Happy mocking!
Is 'this' perhaps what you are looking for?
public class MyClassTest {
#InjectMocks private MyClass mockedClass;
#BeforeMethod(groups = { "unit" })
public void setup() throws Exception {
mockedClass = new MyClass();
MockitoAnnotations.initMocks(this);
Mockito.when(getSomeVariable()).thenReturn(actual_value_intended_to_be_set);
}
#Test(groups = { "unit" })
public void testMyClass() throws Exception {
//almost too trivial an example since you just setup this.
Assert.assertEquals(getSomeVariable(), actual_value_intended_to_be_set);
}
}
It creates your MyClass object and sets the return value as well.
Does anyone have idea about writing unit test case for ATG using Mockito? I came across following discussions while goggling -
Automated unit tests for ATG development and
Using PowerMock to obtain the ATG Nucleus in testing results in NPE
But need a help in setting up Nucleus and other dependencies (DAS, DPS, DSS etc.) and a sample test class for droplet using Mockito.
We are using ATG Dust where we have to set all the dependencies. I am wondering if we can replace ATG Dust completely with Mockito. Here is the example how we are writing the test cases -
A Base class for setting Nucleus -
package com.ebiz.market.support;
import java.io.File;
import java.util.Arrays;
import atg.nucleus.NucleusTestUtils;
import atg.test.AtgDustCase;
import atg.test.util.FileUtil;
public class BaseTestCase extends AtgDustCase {
public atg.nucleus.Nucleus mNucleus = null;
private final String ATGHOME="C://ATG/ATG9.4//home";
private final String ATGHOMEPROPERTY = "atg.dynamo.home";
protected void setUp() throws Exception {
super.setUp();
String dynamoHome = System.getProperty(ATGHOMEPROPERTY);
if(dynamoHome == null)
System.setProperty(ATGHOMEPROPERTY, ATGHOME);
File configpath = NucleusTestUtils.getConfigpath(this.getClass(), this.getClass().getName(), true);
FileUtil.copyDirectory("src/test/resources/config/test/", configpath.getAbsolutePath(), Arrays.asList(new String [] {".svn"}));
copyConfigurationFiles(new String[]{"config"}, configpath.getAbsolutePath(), ".svn");
}
public File getConfigPath() {
return NucleusTestUtils.getConfigpath(this.getClass(), this.getClass().getName(), true);
}
}
Writing the test case by extending the base class -
public class BizDropletTest extends BaseTestCase {
private BizDroplet bizDroplet;
#Before
public void setUp() throws Exception {
super.setUp();
mNucleus = NucleusTestUtils.startNucleusWithModules(new String[] { "DSS", "DPS", "DAFEAR" }, this.getClass(),
this.getClass().getName(), "com/ebiz/market/support/droplet/BizDroplet");
autoSuggestDroplet = (AutoSuggestDroplet) mNucleus.resolveName("com/ebiz/market/support/droplet/BizDroplet");
try {
bizDroplet.doStartService();
} catch (ServiceException e) {
fail(e.getMessage());
}
}
/**
Other methods
*/
}
So, how Mockito can handle these? Again, for me the target is to replace ATG Dust with Mockito completely because ATG Dust take lot of time in running tests due to huge dependencies.
Thanks.
Using Mockito you don't setup Nucleus or other dependencies (unless you need it). You simply mock the objects that you need to use.
Consider a simple class ProductUrlDroplet that retrieves a product from the repository and then outputs a url based on this. The service method would look something like this:
public void service(DynamoHttpServletRequest pRequest, DynamoHttpServletResponse pResponse) throws ServletException, IOException {
Object product = pRequest.getObjectParameter(PRODUCT_ID);
RepositoryItem productItem = (RepositoryItem) product;
String generatedUrl = generateProductUrl(pRequest, productItem.getRepositoryId());
pRequest.setParameter(PRODUCT_URL_ID, generatedUrl);
pRequest.serviceParameter(OPARAM_OUTPUT, pRequest, pResponse);
}
private String generateProductUrl(DynamoHttpServletRequest request, String productId) {
HttpServletRequest originatingRequest = (HttpServletRequest) request.resolveName("/OriginatingRequest");
String contextroot = originatingRequest.getContextPath();
return contextroot + "/browse/product.jsp?productId=" + productId;
}
A simple test class for this will then be:
public class ProductUrlDropletTest {
#InjectMocks private ProductUrlDroplet testObj;
#Mock private DynamoHttpServletRequest requestMock;
#Mock private DynamoHttpServletResponse responseMock;
#Mock private RepositoryItem productRepositoryItemMock;
#BeforeMethod(groups = { "unit" })
public void setup() throws Exception {
testObj = new ProductUrlDroplet();
MockitoAnnotations.initMocks(this);
Mockito.when(productRepositoryItemMock.getRepositoryId()).thenReturn("50302372");
}
#Test(groups = { "unit" })
public void testProductURL() throws Exception {
Mockito.when(requestMock.getObjectParameter(ProductUrlDroplet.PRODUCT_ID)).thenReturn(productRepositoryItemMock);
testObj.service(requestMock, responseMock);
ArgumentCaptor<String> argumentProductURL = ArgumentCaptor.forClass(String.class);
Mockito.verify(requestMock).setParameter(Matchers.eq(ProductUrlDroplet.PRODUCT_URL_ID), argumentProductURL.capture());
Assert.assertTrue(argumentProductURL.getValue().equals("/browse/product.jsp?productId=50302372"));
}
}
The key components are that you need to initialise the class you want to test (testObj). You then simply construct the response for each of the input parameters of the objects you are going to use (in this case productRepositoryItemMock represents the RepositoryItem and productRepositoryItemMock.getRepositoryId() returns a String that you can then test against later).
You will also notice that this test only validates the service method and not the individual methods. How you do it is up to you but generally I've been focused on testing my service and handleXXX methods in the formhandlers and droplets.
Testing the XXXManager, XXXUtil and XXXService classes will all have their own tests and should be 'mocked' into the droplets and formhandlers. For these I would write tests for each method though.
PowerMockito only really comes into the picture when you need to mock static methods and classes and the documentation does enough to explain that.
I'm writing a Groovy script based on commons-io that monitors some source directory and synchronizes its files with some destination directory.
#Grab(group='commons-io', module='commons-io', version='2.4')
import org.apache.commons.io.monitor.*
import org.apache.commons.io.FileUtils
class BaseSynchronizedFileListener extends FileAlterationListenerAdaptor {
def srcDir
def destDir
/* Given a source file, returns the destination file */
File destination(File file) {
new File(destDir, file.getAbsolutePath() - srcDir.getAbsolutePath())
}
}
class CopyOnWriteListener extends BaseSynchronizedFileListener {
#Override
void onFileChange(File file) {
FileUtils.copyFile(file, destination(file))
}
#Override
void onFileCreate(File file) {
FileUtils.copyFile(file, destination(file))
}
}
class DeleteOnDeleteListener extends BaseSynchronizedFileListener {
#Override
void onFileDelete(File file) {
FileUtils.deleteQuietly(destination(file))
}
}
In addition to straight file copies, I want to support Less->CSS compilation, wherein .less files in the source directory are synchronized with .css files in the destination directory.
#Grab(group='org.lesscss', module='lesscss', version='1.3.3')
import org.lesscss.LessCompiler
class CompileLessOnWriteListener extends BaseSynchronizedFileListener {
def compiler = new LessCompiler()
#Override
File destination(File file) {
File dest = super.destination(file)
new File(dest.parentFile, dest.name - '.less' + '.css')
}
void compile(File less) {
compiler.compile(less, destination(less))
}
#Override
void onFileChange(File less) {
compile(less)
}
#Override
void onFileCreate(File less) {
compile(less)
}
}
The problem I'm encountering is when I attempt to create class DeleteCssOnDeleteLessListener to handle the situation when .less files are deleted (which, in turn, deletes the corresponding .css file) -- the code I need to do this exists in two different inheritance trees.
CompileLessOnWriteListener contains the destination() method
DeleteOnDeleteListener contains the onFileDelete() method to delete the CSS file returned by the destination() method
Is there a "Groovy way" to selectively mixin or inherit methods from both of these classes into a new class?
Or do I just need to bite the bullet and create a common super class for CompileLessOnWriteListener and DeleteCssOnDeleteLessListener?
Update
Changed the implementation. Lets see if i got the idea. You need:
Inherit two methods
"Inherit" constructor
It needs to be an instance of an interface
I think a heavy metaprogramming helps here. We can declare two objects to DeleteCssOnDeleteLessListener delegate methods to, and these objects will be accessing properties from it.
For the interface, i think you are better using the as Interface operator.
Dynamically "inherit" the constructors may get tricky. Since it is only two properties, i've declared them. You can delegate the getProperty/setProperty to one of the other two objects, if you prefer DRYing your code:
class DeleteCssOnDeleteLessListener {
def destDir, srcDir
def onLessDelete(file) {
onFileDelete destination( file )
}
}
class CompileLessOnWriteListener {
def destination(file) {
"destination $file from $srcDir"
}
}
class DeleteOnDeleteListener {
def onFileDelete(file) {
"onFileDelete $file and $destDir"
}
}
def delete = new DeleteCssOnDeleteLessListener(destDir: "dest/dir", srcDir: "src/dir")
def compileLess = new CompileLessOnWriteListener()
def deleteOnDelete = new DeleteOnDeleteListener()
delete.metaClass {
destination = compileLess.&destination
onFileDelete = deleteOnDelete.&onFileDelete
}
compileLess.metaClass.getProperty = { property -> delete.getProperty property }
deleteOnDelete.metaClass.getProperty = { property -> delete.getProperty property }
assert delete.onLessDelete("style.less") == "onFileDelete destination style.less from src/dir and dest/dir"
It's not very "Groovy", in my opinion, nor very efficient looking, but at least this approach solves my problem without having to create a common superclass:
class DeleteCssOnDeleteLessListener extends DeleteOnDeleteListener {
#Override
File destination(File f) {
new CompileLessOnWriteListener(destDir: this.destDir, srcDir: this.srcDir).destination(f)
}
}