We are working with Apache Flink streaming framework lately which is very nice. Nevertheless, in the documentation we stumbled across some Java thing that I haven't seen before, this class
public class MyMapper extends RichMapFunction<String, Integer> {
private Counter counter;
#Override
public void open(Configuration config) {
this.counter = getRuntimeContext()
.getMetricGroup()
.counter("myCounter");
}
#public Integer map(String value) throws Exception {
this.counter.inc();
}
}
What does the #public mean ont the map method and what's even more interesting why isn't there are return declared in the method although the return type is defined as Integer?
Or is this simply some issue in their documentation?
Here is the page as reference Flink Docu
This seems to be an issue with the documentation.
The # in #public is not correct and should be removed, i.e., this should be the Java keyword public. The #Public annotation mentioned in another answer is not supposed to be used in user code but just in Flink's public interfaces.
The documentation page is about how to use metrics, so the author probably focused on the call to update the metric and forgot the return value of the map() method.
It would be great if you could open a JIRA issue to report the faulty docs. Thanks!
Related
Let's say I've an implementation of fund transfer. Now I want to add authentication functionality which should be done before fund transfer (considering we are already receiving username and password in existing request). Which pattern should we use and how we can achieve this without modifying calling class and existing implementation?
What I can think of at this moment is using decorator pattern after extending implementation class, but I believe still we will be required to modify the calling class.
Please find existing Interface and classes.
package sb.test.demo.fundtransfer;
public interface FundTransferService {
public boolean makeTransfer(TransferRequest request) throws Exception;
}
package sb.test.demo.fundtransfer;
public class FundTransferServiceImpl implements FundTransferService {
#Override
public boolean makeTransfer(TransferRequest request) throws Exception {
//Dummy Code
System.out.println("TransferDone");
return true;
}
}
package sb.test.demo.fundtransfer;
public class TestTransfer {
public static void main(String[] args) throws Exception {
TransferRequest request = new TransferRequest();
request.setSourceAccount(123456);
request.setDestinationAccount(654321);
request.setTranserAmount(1000);
request.setUserName("user1");
request.setPassword("pass1");
FundTransferService fts = new FundTransferServiceImpl();
fts.makeTransfer(request);
}
}
Now, I want want extend FundTransferServiceImpl to createFundTransferServiceNEWImpl which will add authentication.
package sb.test.demo.fundtransfer;
public class FundTransferServiceNEWImpl extends FundTransferServiceImpl {
#Override
public boolean makeTransfer(TransferRequest request) throws Exception {
//Dummy Code
System.out.println("Authenticating..");
super.makeTransfer(request);
System.out.println("TransferDone from NEW..");
return true;
}
}
Now, without changing TestTransfer.java and FundTransferServiceImpl.java how can I invoke makeTransfer of FundTransferServiceNEWImpl to add authentication? Or, is there any other way to achieve the same?
Please can anyone help me on this?
Thanks in advance!
you can make "FundTransferServiceNEWImpl" also implement the interface "FundTransferService" and provide the implementation that you wish in this only, if this was what you asked for!!
Now, without changing TestTransfer.java and FundTransferServiceImpl.java how can I invoke makeTransfer of FundTransferServiceNEWImpl to add authentication?
You can't without changing the bytecode of either TestTransfer (the caller) or FundTransferServiceImpl (the callee).
There are two ways to change the bytecode.
You can
edit the source file and compile
edit the bytecode before the class is loaded
Edit the source file
I would suggest to edit the TestTransfer class. The problematic line is
FundTransferService fts = new FundTransferServiceImpl();
because this line introduces the dependency from TestTransfer to FundTransferServiceImpl.
I would also suggest to implement the decorator by composition and not inheritence. E.g.
public class AuthenticationFundTransferServiceWrapper implements FundTransferService {
private FundTransferService fundTransferService;
public AuthenticationFundTransferServiceWrapper(FundTransferService fundTransferService){
this.fundTransferService = fundTransferService;
}
public boolean makeTransfer(TransferRequest request) throws Exception {
//Dummy Code
System.out.println("Authenticating..");
fundTransferService.makeTransfer(request);
System.out.println("TransferDone from NEW..");
return true;
}
}
The advantage is that the AuthenticationFundTransferServiceWrapper does only depend on the interface FundTransferService and not the implementation. This reduces dependencies and makes the class more flexible.
Editing the byte code
Editing the bytecode before the class is loaded is possible.
Take a look at
AOP (aspect oriented programming)
AspectJ
ASM (bytecode manipulation)
cglib
So you've identified decorator pattern and this answer implemented decorator correctly, but as this is a SOLID principles question I'm going to point out the flaw in that option.
To see the flaw in either inheritance or decorator, consider what happens when the authorization fails. If it throws a new exception type, that is a Liskov Substitution Principle Violation. If it changes the behavior by silently not transferring the funds, that is also an LSP violation. If you're going to rely on the boolean returned, you're not going to get a useful failure message back to the user or system admin.
As I see it, there is no way the client code can avoid knowing that the new implementation is checking authorized as it needs to handle either a new exception, or different return values.
Given that, I would recommend you add a new class, like this:
public final class TransactionAuthorizationService {
private final FundTransferService fundTransferService;
public AuthenticationFundTransferServiceWrapper(FundTransferService fundTransferService){
this.fundTransferService = fundTransferService;
}
public boolean authorizeAndMakeAndTransfer(TransferRequest request) throws Exception {
//Dummy Code
System.out.println("Authenticating..");
fundTransferService.makeTransfer(request);
System.out.println("TransferDone from NEW..");
return true;
}
}
Advantages:
Where before client code dealt with the interface FundTransferService you would have no idea until runtime which implementation they had and whether they would be authorizing transactions, now the client code now deals with the TransactionAuthorizationService and they call authorizeAndMakeAndTransfer so it is very clear.
As our new class is not implementing an existing interface, there is no Liskov Substitution Violation and is free to return different values or throw different exceptions.
Other tips:
Stop decorating methods with throw alls: throws Exception
Don't use InterfaceImpl as class names, look for what makes them concrete over the abstract interface.
I didn't find any example in the documentation. It just says: "Normalizes tokens extracted with StandardTokenizer.".
What does documentation mean with: "Normalizes"?
According to the API documentation:
Normalizes tokens extracted with StandardTokenizer.
In reality, though, the answer is: Absolutely nothing.
public class StandardFilter extends TokenFilter {
public StandardFilter(TokenStream in) {
super(in);
}
#Override
public final boolean incrementToken() throws IOException {
return input.incrementToken(); // TODO: add some niceties for the new grammar
}
}
That's about as simple as a TokenFilter gets. It takes in tokens, and spits them right back out again, unchanged.
In Lucene 2.X it did some work on apostrophes, removing dots from acronyms, etc, and in 3.X and 4.X, it kept that code around for backward compatibility. As of 5.0 that backwards-comptability support has been removed, and the filter no longer does anything at all (though it certainly may in the future).
I'm working on Lucene, as a Newbie and I'm searching a way to find in a tokenstream.
If it's a verb, a name, or other.
I see the method type() for the token's class but I'm using the class CharTermAttribute.
I have already tried to find a way on the API doc, but i don't found anything for this.
#EJP is correct, that Lucene doesn't know anything about parts of speech on it's own.
However, you could implement a custom filter that handles this well. Lucene's TokenStream API example implementation actually does exactly that. I'll include a few pertinent bits here, but also look over the complete example (starts about halfway down the page).
Two things, in particular, seem of primary interest. First, creating a custom PartOfSpeechAttribute interface extending Attribute. These Attributes are used to attach some attendant data to tokens during analysis. A simplified version of that provided in the example (again, visit the link above to see their more robust implementation):
public class PartOfSpeechAttribute implements Attribute {
public static enum PartOfSpeech {
Noun, Verb, Adjective, Adverb, Pronoun, Preposition, Conjunction, Article, Unknown
}
private PartOfSpeech pos = PartOfSpeech.Unknown;
public void setPartOfSpeech(PartOfSpeech pos) {
this.pos = pos;
}
}
Then you will need to implement your custom filter which adds these attrributes to each Token.
public static class PartOfSpeechTaggingFilter extends TokenFilter {
PartOfSpeechAttribute posAtt = addAttribute(PartOfSpeechAttribute.class);
protected PartOfSpeechTaggingFilter(TokenStream input) {
super(input);
}
public boolean incrementToken() throws IOException {
if (!input.incrementToken()) {return false;}
posAtt.setPartOfSpeech(determinePOS(termAtt.buffer(), 0, termAtt.length()));
return true;
}
// determine the part of speech for the given term
protected PartOfSpeech determinePOS(char[] term, int offset, int length) {
// ???
}
}
Then you would be able to extract the PartOfSpeechAttributes from the TokenStream much like you would any other attribute.
Of course, that doesn't answer how to determine the Part of Speech. The implementation of determinePOS is somewhat beyond the scope I can expect to cover here though. OpenNLP might be a good library for making that determination, among others.
There is also some as yet in development work on an OpenNLP analysis module that would definitely be work a look, though it doesn't look like parts of speech are handled by it yet, nor that it has got much love in in about a year.
I've got a simple class which get's validated using the boolean isValid() method, which works and of course the error message is at class/type level.
Here's my simple class:
public class NewPasswordDTO {
#NotNull
public String password;
#NotNull
public String confirmation;
#AssertTrue(message="Passwords must match.")
protected boolean isValid() {
return password.equals(confirmation);
}
}
But what I really want is something like that:
public class NewPasswordDTO {
#NotNull
#Equals("confirmation", message="...")
public String password;
#NotNull
public String confirmation;
}
So the error message would be set at field level and not at class/type level.
Is this possible somehow? Maybe using a custom Validator for that class?
Thanks in advance!
SOLUTION:
Thanks to Gunnar! I've just came up with a nice, universal solution :-). I simply used (means copy & paste) the code from Hibernates #ScriptAssert and ScriptAssertValidator and modified it slightly:
#ScriptAssert:
Add new String field(). (this is where the error message gets appended)
ScriptAssertValidator:
Inside the initialize method, make sure to also save the fieldName and message properties, because we need to access them in the next step
Add this snippet at the bottom of isValid method:
context.buildConstraintViolationWithTemplate(errorMessage)
.addPropertyNode(fieldName).addConstraintViolation();
Also add context.disableDefaultConstraintViolation(); somewhere inside the isValid method to not generate the default error message which else would get appended at class level.
And that's it. Now I can use it like that:
#FieldScriptAssert(lang="javascript", script="_this.password.equals(_this.confirmation)", field="password", message="...")
public class NewPasswordDTO { ... }
You either could use the #ScriptAssert constraint on the class (note that a constraint should always be side-effect free, so it's not a good idea to alter the state of the validated bean; instead you should just check whether the two fieldss match) or you implement a custom class-level constraint.
The latter also allows to point to a custom property path for the constraint violation, which it allows to mark the "confirmation" property as erroneous instead of the complete class.
Simple answer : It is not (unless you implement it) :http://docs.oracle.com/javaee/6/api/javax/validation/constraints/package-summary.html shows all annotation constraints.
Of course you could inject your string as a resource in your class by #producer and so on (which recently is discussed to be removed in jdk8), but you could not use this value for your assert. In reply to the comment:
This was asuming that the nature is a constant string which you would like to use as a string resource.And then of course it is possible to write your own class based on java.lang.string with a #Producer which is then #Inject - able. Though it is certainly not the way I personally would deal with constant strings.
If you’re using the Spring Framework, then as an alternative to the #ScriptAssert using a JSR 223 scripting, you can use the #SpELAssert that uses the Spring Expression Language (SpEL). The advantage is that it doesn’t need any JSR 223 compliant scripting engine which may not be available on some environments. See this answer for more information.
The latest security breach in Java7, where a applet can execute untrusted code on users machine. More information is available at http://www.h-online.com/security/features/The-new-Java-0day-examined-1677789.html.
But the question I have is: It is mentioned that all this is possible due to the execute() method introduced in Expression class. But there is nothing special that it does, which was not possible in previous versions. Here is the source:
#Override
public void execute() throws Exception {
setValue(invoke());
}
and for getValue() which exists since java1.4:
public Object getValue() throws Exception {
if (value == unbound) {
setValue(invoke());
}
return value;
}
getValue() does everything that execute() does. Then why so much fuss about the execute method??
If you look closely, the exploit code also calls .getValue(). Clearly, the vulnerability lies within invoke. execute is essentially a public interface to call the private invoke.
I reported a bug several years ago where the access checking in Expression isn't identical to the compiler's. Possibly this is another example.