After JavaOne 2014, when the configuration topic was canceled from the EE8 list, David Blevins and others proposed to start an Apache project for several reasons:
Also to mention is that Mark Struberg and Gerhard Petracek, the guys behind Deltaspike, joined this project and actively contributed to it. I think it is worth it to have a deeper look at the project. This is what this blog is all about.
I've known almost since I started learning about Java that the Class-Path header field in a Manifest file specifies the relative runtime classpath for executable JARs (JARs with application starting point specified by another manifest header called Main-Class). A colleague recently ran into an issue that surprised me because it proved that a JAR file's Manifest's Class-Path entry also influences the compile-time classpath when the containing JAR is included on the classpath while running javac. This post demonstrates this new-to-me nuance.
The section "Adding Classes to the JAR File's Classpath" of the Deployment Trail of The Java Tutorials states, "You specify classes to include in the Class-Path header field in the manifest file of an applet or application." This same section also states, "By using the Class-Path header in the manifest, you can avoid having to specify a long -classpath flag when invoking Java to run the your application." These two sentences essentially summarize how I've always thought of the Class-Path header in a manifest file: as the classpath for the containing JAR being executed via the Java application launcher (java executable).
Figure 1 shows a spoiklin class diagram of a well-structured package.
Figure 1: A good package structure from Lucene.
Microservices, whatever one may do, one of the most important concept that was invented in last years. It is possible to resist SOAP 2.0 as much as long, but sooner or later they will come for you and will turn you into their faith, or you will come to them and please to baptise yourself by fire and a sword. As well as any architectural concept microservices has cons. You need to include some authorization logic in requests from external systems or other microservices in each microservice. This logic can be directly "hardcoded" in microservice (and it isn't important that is a separate library), or can be delegated to other microservice, or can be declared. What "can be declared" means? For example, it is possible to agree that the special HTTP header, or some data structure with user information, comes in each request to each microservice. And data in this structure is needed to be absolutly trusted. All three options have cons, but within article we will talk about the last. For implementation usually API Gateway pattern is used:
Typically API Gateway restricts amount of requests to internal services, authorizes client's requests, does logging and audit, distributes requests across clients and transforms data if it is necessary. Even nginx can be used for API gateway. Consider an authorization function for user requests. If HTTP protocol is used, the standard practice considers adding of a certain token (not important as we received it) in Authorization header:
This debate is very old, but I have something to say too. The question is whether a method may have multiple return statements or just one. The answer may surprise you: In a pure object-oriented world, a method must have a singlereturn statement and nothing else. Yes, just a return statement and that's it. No other operators or statements. Just return. All arguments in favor of multiple return statements go against the very idea of object-oriented programming.
This is a classical example: