Develop Reference

Collect custom Doc annotations in Java/Kotlin project?

I'm going to use lots of custom documentation notes all around code base of Kotlin and Java project. Seems like reasonable choice would be to use annotation.
As far as I know annotation is some sort of magic, handled by build tools. But I need to work with it in the Kotlin/Java code.
So we have two files /src/some/thing.kt
package some
annotation class Doc
#Doc
private fun some_doc() {
println("some doc")
}
and /src/generate_docs.kt
fun main() {
Find and call all the functions over all
the codebase marked with #Doc
And then run some other code to process
those notes and output HTML docs
}
How could it be done? Basically I can do it by manually writing all those calls, but I hope there's a better way.
fun main() {
some_doc()
another_doc()
yet_another_doc()
...
couple tens or hundreds more lines
And then run some other code to process
those notes and output HTML docs
}
If possible I would like to avoid Maven plugins and magic and just have plain old Java/Kotlin code I can run as java GenerateDocsKt.

Identify the tools behind this REST application?

I am having to make use of some existing code. I cannot contact the previous developer. Part of it is a REST application. I can see how it works, but there is a lot of stuff that looks like code duplication. Or there is a tool of some kind which is taking some of the sources and creating articfacts and other sources from that, or it is creating templates, in which code was added. It looks a bit like Jersey but I have not used this in work, so I am not sure. I tried searching for the annotations, but that is not helpful. I may be missing the build files. It was in an eclipse project and I do not seem to have the .project directory.
This project has a lot of partial implementations that got set aside. I am having problems distringushing those from code that should work.
Looking for just "UserEmail", I see:
src/com/gs/dao/user/UserEmailDao.java
src/com/gs/dao/user/UserEmailDaoImpl.java
src/com/gs/service/UserEmailService.java
src/com/gs/service/UserEmailServiceImpl.java
This is not just 4 times the necessary code. Something is driving this structure. But what is it? Any suggestions?
I am seeing code like:
#ApiController("1.0")
public class UserEndpoint extends BaseEndpoint {
Logger logger = Logger.getLogger(UserEndpoint.class);
#Autowired
public UserService userService;
#Autowired
public UserContactService userContactService;
....
The directory structure looks like this:
src/com/gs/cache
src/com/gs/cache/local
src/com/gs/cache/mem
src/com/gs/servlet
src/com/gs/constants
src/com/gs/common
src/com/gs/dao
src/com/gs/dao/service
src/com/gs/dao/service/attr
src/com/gs/dao/user
src/com/gs/dao/user/attr
src/com/gs/dao/comm
src/com/gs/dao/comm/attr
src/com/gs/dao/vg
src/com/gs/dao/vg/attr
src/com/gs/dao/general
src/com/gs/dao/general/attr
src/com/gs/dao/exception
src/com/gs/elasticsearch
src/com/gs/service
src/com/gs/service/utils
src/com/gs/service/helper
src/com/gs/graph
src/com/gs/graph/gateway
src/com/gs/threads
src/com/gs/async
src/com/gs/async/test
src/com/gs/async/handler
src/com/gs/async/impl
src/com/gs/util
src/com/gs/util/xss
src/com/gs/nlp
src/com/gs/exception
src/com/gs/cassandra
src/com/gs/cassandra/dao
src/com/gs/search
src/com/gs/search/service
src/com/gs/rest
src/com/gs/rest/common
src/com/gs/rest/api
src/com/gs/rest/api/test
What the heck is all this stuff? :-)

You're probbaly not going to get one response that answers this. And you may get shut down for the question being too broad, but I will try. First off:
src/com/gs/dao/user/UserEmailDao.java
src/com/gs/dao/user/UserEmailDaoImpl.java
src/com/gs/service/UserEmailService.java
src/com/gs/service/UserEmailServiceImpl.java
That's a pretty common java pattern, You have an email service, and you split that into an interface and an implementation. You might consider it overkill (if the implementation never changes), but some of the tools being used might require interfaces. Same thing with the UserEmailDao data access object. It's pretty normal for java developers to split everything into an interface and an implementation, though it drives people using dynamic languages crazy.
As for what's generating the REST app, you need to track down where the ApiController annotation is coming from. It looks like it might be wrapper around a Spring MVC class. Post the import statement for that annotation, or just follow it your IDE.
Spring is definitely being used to wire the entire app together.
It looks like a pretty typical medium sized java application to me. From the directory structure, I doubt there is any code generation going on.
If there's a pom.xml (maven file) in the application root, that'll tell you everything you need to know about the application.

Getting empty sequence for the complex type in generated XSD when developing JAX-WS web services

I seem to be having an issue with Java and NetBeans when it comes to writing web services.
I have searched for a couple of days with no luck, finding people with the same issue as me with zero replies.
I have created a web service which returns a complex type (LoginReply), and that complex type contains an array of another complex type (AppInfo)
However when I generate the WSDL from this, the complex type definition in the XSD is blank, and manually adding the information still makes the web service return null even when data is successfully passed to the web service.
<xs:complexType name="appInfo">
<xs:sequence/>
</xs:complexType>
LoginReply: http://pastebin.com/Umx6ayvi
AppInfo: http://pastebin.com/566WnZ4H
If anyone could point out what I'm doing wrong, or if this is a bug with NetBeans, I'm new to Java so I can't rule out that I'm simply not understanding something, but I'm close to pulling my hair out here.
EDIT:
Just noticed when i deploy to tomcat via NetBeans I get the following error:
WARNING: duplicate class definition bug occured? Please report this : uk/co/example/ComplexTypes/LoginReply$JaxbAccessorM_getApplications_setApplications_[Luk_co_example_ComplexTypes_AppInfo;
java.lang.ClassFormatError: Illegal class name "uk/co/example/ComplexTypes/LoginReply$JaxbAccessorM_getApplications_setApplications_[Luk_co_example_ComplexTypes_AppInfo;" in class file uk/co/example/ComplexTypes/LoginReply$JaxbAccessorM_getApplications_setApplications_[Luk_co_example_ComplexTypes_AppInfo;
Notice the random L before co_uk_example. My research suggests this is an old bug that should be fixed, and that no one else has reported this issue in over a year, no sure where to go from here.
Another edit:
Just added a new web method on the service that simply gets a list of appInfo and returns it to the client. This still fails the same way with NetBeans refusing to generate a sequence inside AppInfo.
I'm sure I'm missing something to declare the class, but I have checked it countless times to ensure I'm not missing anything.

warning gives you good hint: "WARNING: duplicate class definition bug occured"
your ws implementation class directly uses LoginReply class which directly uses AppInfo (+you are maybe also directly using this class in your ws implementation) => jaxb finds it
#XMLSeeAlso(...) tells jaxb to "link" referenced class
=> two definitions of the same class (not sure if it is by design or a bug that jaxb is not able to handle this case more gracefully)
to fix this just remove #XmlSeeAlso from your LoginReply class and you should be fine

This Issue came down to a very simple mistake. The AppInfo class was using non-standard getters and setters.
public void SetAppID(int AppID)
{
this.AppID = AppID;
}
This is INCORRECT (notice the capital on the Set), it should be:
public void setAppID(int AppID)
{
this.AppID = AppID;
}
Using a capital is not standard for JavaBeans and as such JAX-WS didn't know how to generate WSDL for this class. Thanks too shyam from the following link for answering the question
How to return a custom complex type in JAX-WS web services?

I don't think you can send "complex types" over the net (programmed port types) in http protocol, however an array may be implicitly converted to a delimited string set , check the docs for data transfer.

intellij not resolving el variables within JSP code inspection or autocomplete

To summarize the answer shown here Code assist in (jsp /jstl) view for Spring MVC model objects in Eclipse
is not working for me at all, is there a setting that I need to change ?
I have just downloaded the sample spring-mvc-showcase on github, and it doesn't work out of the box on that project (with either 11.1.3 or EAP 12 version both full enterprise editions), see below (I have no idea where it gets formBean from) :
Here is an example from my own project,the screen shot below (bottom frame) shows my controller adding a string attribute to model and returning correct view name. I would then expect shopString to be offered up as autocomplete option when editing that view, however it is not :
sg is a javascript variable - so great it should be there, but where is "shopString" ?.
Is there a setting I need to change or something else I am missing to get this functionality (using 11.1.3 enterprise edition with all the spring plugins).
It is also failing on spring specific variables :
IS their an open source (one of the spring tutorial projects?) where this definitely works ... or is there a setting I need change in my Intellij install (I have tested with a brand new download of the version 12 EAP) ?
One more screenshot below shows all my spring coifg files set up correctly via autodetection, but the code inspections fails ... this is the spring-mvc-showcase project :

There's a standard way to do this, which is not IntelliJ-specific.
<jsp:useBean id="someModel" scope="request" type="foo.bar.SomeModelClass"/>
The type attribute here does not need to be a concrete class, it can be an interface type as well. Typically you'd put these declarations at the start of your JSP/JSPX files, to provide something like a "declaration of model inputs".
Using JSPs in such a declarative way was recommended in the original book on Spring, in fact (Expert One-on-One J2EE Design and Development.). IntelliJ has been providing full code completion for such pages since at least 7 years.
Note that there are additional relevant convenience features in IntelliJ: if an EL variable reference is marked as undefined, you can press Alt-Enter to select a QuickFix, which will insert a declaration like above. It will even try to figure out the actual type, based on the properties you're accessing.

As I understand Spring, there is no declaration for definitions of variables that you may put into your model. The call model.addAttribute() may add an object to the model, either identified by a parameter or automatically generated by the class name of the object.
So imagine the following case where you have more than one method:
#RequestMapping("foo") public String foo(Model model) {
model.addAttribute("model", new Foo());
return new Random().nextBoolean() ? "page" : "someOtherPage";
}
#RequestMapping("bar") public String bar(Model model) {
model.addAttribute("model", new Bar());
model.addAttribute("model", new Foo());
model.addAttribute("model", new Bar());
return new Random().nextBoolean() ? "page" : "someOtherPage";
}
and the JSP would be something like
<c:out ${model.value} />
Since there is no proper mapping of which controllers may under some circumstances forward to which views, nor what exactly lies within the model, your IDE has no real chance to provide you with proper information.
But to support the IDE in suggesting you some useful information, you can use type hints. Therefore, you have to copy the whole reference of an object, e. g. foo and add a JSP comment like:
<%--#elvariable id="foo" type="com.mycompany.SomeObject"--%>
The warning will vanish and the full IDE support is on your side, allowing you to traverse the fields of foo.
One of the nicest things is that the unused getter warnings will vanish, too. You can directly call the show usages action directly from the JSP or the POJO.
This also works with JSF and particularly within JSF components. Pretty neat feature to have this kind of code completion, showing warnings and errors.
Hope that helps you with your switch to Intellij Idea.
Edit: I also reported this finding to a friend wo wrapped the whole thing into a nice blog entry. Maybe you're interested in reading it: open link

This got fixed in the latest release of intellij 122.694

I faced with similar issue when start writing my own interceptor. Problem was that I start using refference in my view resolver configuration
don't use contruction like this
<bean id="internalResourceViewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver">
<property name="prefix" ref="prefix"/>
<property name="suffix" ref="suffix"/>
</bean>-

Methods for getting annotation metadata in Java

I'm working on a JSR-303 validation framework for GWT. Some of you may have heard of it even though it is a small project. Here is gwt-validation.
In the old days (v1.0) it used a marker interface for each class and each class had metadata generated separately. This was bad because it was not part of the JSR-303 standard and we moved on to the next idea.
In version 2.0 it scans the classpath at runtime using Reflections. This is great. The downside is that it doesn't seem to be able to work inside of containerized environments or those with special restrictions.
This is probably my fault, look at the following code:
//this little snippet goes through the classpath urls and ommits jars that are on the forbidden list.
//this is intended to remove jars from the classpath that we know are not ones that will contain patterns
Set<URL> classPathUrls = ClasspathHelper.forJavaClassPath();
Set<URL> useableUrls = new HashSet<URL>();
for(URL url : classPathUrls) {
boolean use = true;
for(String jar : this.doNotScanJarsInThisList) {
if(url.toString().contains(jar)) {
use = false;
break;
}
}
if(use) {
useableUrls.add(url);
}
use = false;
}
ConfigurationBuilder builder = new ConfigurationBuilder()
.setUrls(useableUrls)
.setScanners( new TypeAnnotationsScanner(),
new FieldAnnotationsScanner(),
new MethodAnnotationsScanner(),
new SubTypesScanner()
)
.useParallelExecutor()
;
this.reflections = new Reflections(builder);
I'm using the filter to remove jars that I know can't have annotations in them that I'm interested in. As I mention this gives a huge speed boost (especially on large classpaths) but the ClasspathHelper.forJavaClassPath() that I'm basing this on probably isn't the best way to go in container environments. (e.g. Tomcat, JBoss)
Is there a better way or at least a way that will work with a container environment and still let my users filter out classes they don't want?
I've looked, some, into how the Hibernate Validation project (the reference implementation for JSR-303) and they appear to at least be using (at least in part) the Annotations Processing in Java 6. This can't be all of the story because that didn't show up until JDK6 and Hibernate Validator is JDK5 compatible. (See: hibernate documentation)
So, as always, there's more to the story.
I've read these threads, for reference:
About Scannotation which has been pretty much replaced by Reflections.
This one but it uses File and I'm not sure what the implications are of that in things like GAE (Google App Engine) or Tomcat.
Another that goes over a lot of the things I've talked about already.
These threads have only helped so much.
I've also read about the annotation processing framework and I must be missing something. It appears to do what I want but then again it appears to only work at compile time which I know isn't what is done by Hibernate Validator. (Can anyone explain how it does scanning? It works on GAE which means it can't use any of the IO packages.)
Further, would this code work better than what I have above?
Set<URL> classPathUrls = ClasspathHelper.forClassLoader(Thread.currentThread().getContextClassLoader());
Could that correctly get the classloader inside of a Tomcat or JBoss container? It seems scan a smaller set of classes and still finish okay.
So, in any case, can anyone help me get pointed in the right direction? Or am I just stuck with what I've got?

You could take a look at Spring's annotation support.
Spring can scan annotations in files (using asm IIRC), and works in and out of a container.
It may not be easy because it goes through Spring's Resource abstraction, but it should be doable to reuse (or extract) the relevant code.