In my grails 1.3.7 project, I have put all of my classes in com.mycompany.myapp, as you do. So this goes for services, controllers, domain classes. I have a filter that goes in its own package. My app works fine.
However, when I run grails doc, grails decides to create two pages for every class:
one in its right comp.mycompany.myapp package that has all the right Groovy Doc
the other takes all the above classes and pretends as if those also live in the default package.
So, target/docs contains two directories: 'DefaultPackage' and 'com', with DefaultPackage holding a copy of everything that lives under com/
Consequently, my groovy doc looks messy because there is two copies for each class.
How can I solve this?
It has been documented as a bug at GRAILS-6605. There is no workaround listed there for the bug.
I too faced the same issue and so created a plugin "Grails Runtime Docs" ( http://grails.org/plugin/grails-runtime-docs ) that solves this issue and generates both Java and groovy docs properly only 1 copy per class. It's grails aware and categorizes the classes into Controllers, Commands, Domains, Services and Tag Libraries. The groovy documentation is actually generated from runtime so as to include the dynamic methods also, adding "Dynamic Method Summary" & "Dynamic Method Detail" in the generated html docs, that provide their source information. Hope you find it useful.
Related
(Sample) Problem:
When a yaml source contains conflicting definitions, e.g. myClass and MyClass both generating into a java class MyClass with one overwriting the other, no warning or error occurs.
Other similar cases can occur the same way (e.g. via implicitly generated classes from complex entries of type: array).
Framing
has to work without modifying the source file
there is exactly one source file, for whatever that's worth
has to work as a Maven plugin
tested with swagger-codegen-maven-plugin 2.4.0 and 2.4.22
am familiar with JAXB2 and both of its common Maven plugins:
jaxb2-maven-plugin
maven-jaxb2-plugin
am not familiar with swagger-codegen-maven-plugin
did not find solutions (or even corresponding problem reports) using Google searches
swagger codegen strict
swagger-codegen-maven-plugin strict
swagger codegen name collision
swagger-codegen-maven-plugin name collision
swagger codegen resolve name collision
swagger-codegen-maven-plugin resolve name collision
found this closed issue describing a similar issue (silently generates corrupt code), which appears to be mostly unrelated and is alledgedly long fixed
Question
What is the proper solution that produces
an eagerly failing generation process
amended via externally configured customBindings
without touching the yaml source file
?
Solution ideas:
Use JAXB2 instead
JAXB2
fails generation where a generated file already exists
allows a separate customBindings.xjs file to modify generation of
classes
can be adapted to work with YAML using
JacksonJaxbYAMLProvider
However it seems that the common Maven plugins jaxb2-maven-plugin and maven-jaxb2-plugin do not support YAMl definition files (out of the box?). [1]
Use Mustache files to resolve the name collision
The Mustache language seems to provide the necessary facilities to implement rules similar to JAXBs xjb.
However
binding a Mustache template to a class has to be done by name (<class name>.mustache), aka. name collision in particular cannot be resolved from an external file [2]
this does not help with the silence of errors in generated code - one cannot fix the error, while unaware of it
1 - Searches for this topic have yielded one result that it does not work out-of-the-box (duh) and no results whether it can be made to work using the extensions interface both plugins support.
2 - I could not find the relevant part directly within Swagger codegen documentation, but here is a relevant part of the implemented-by-Swagger OpenAPI generator documentation.
change a config.properties file in a jar / war file in runtime and hotdeploy the changes ?
my requirement is something as follows, we have a "config.properties" in a jar/war file , i have to open the file through a webpage and after the user has made necessary changes to it, i have to update the "config.properties" in jar/war file and hot deploy it. can we achieve this feat ? if so can you please point me to relevant sites/documents so that i can jumpstart on this.
I will strongly recommend your architecht rethink this solution. What you describe should be done through JNDI or a similar technique, not through reloading properties.
Deployments should be considered static - that any given web container allows for magic trickery should not be depended on, and WILL break some day (most likely at the most inconvenient time).
You've got a couple of problems off the top of my head:
ensuring that nothing is holding static references to a java.util.Properties that has previously loaded your config.properties file.
most servlet engines will unpack your war to a working directory so the properties file you load won't be the one in the war, it will be the unpacked one. This means your changes
will be overwritten when you restart the servlet engine because this is typically one of the points the war is unpacked.
While these problems aren't insurmountable I've always found it much easier to implement this sort of behavior by storing the properties in JNDI (as Thorbjørn suggests) or a database (while being careful about the static references I mentioned in point 1).
The JNDI/database solution has the nice side effect of easing deployment into multiple environments because each typically has it's own registry/database.
Even that I agree with the comments explained before, I could suggest one solution:
Apache Commons Configuration extension gives you the posibility to do something like:
config.setReloadingStrategy(new FileChangedReloadingStrategy());
That could make the trick to change the configuration file on a runtime basis with no code at all.
However, like JNDI and other methods of web application configuration, the security is a concern. Be careful on which parameters you can/must be able to configure.
Background
We have an existing webapp, built with Struts 2 and Freemarker, of which I’ve created a variation by copying some of the code and templates. Kludgy, but manageable. We will however soon be making quite a few other variants (which need to be individual WARs), making copying untenable. My thought is to instead put all the shared stuff into a jar included with each webapp: the common files could be maintained in one place, and even better a given webapp could override files from the classpath. So far I've been able to do this with the code, but the Convention plugin is making it difficult to do the same for the Freemarker templates.
Problem
Thus far our webapp has relied on Convention to find the Freemarker “action results” (i.e. templates) for actions at application start-up, saving us from having to tediously annotate each of them. If I've traced things correctly, the class DefaultResultMapBuilder is responsible for finding the actions results; in particular, the method createFromResources looks in the webapp and then on the classpath for template files matching our actions.
This is exactly what I want – except that we put our templates under /WEB-INF to protect them from outside access (using the struts.convention.result.path constant in our Struts configuration). This has worked fine until now, with ALL template files located under /WEB-INF, but it’s not working with files also on the classpath. DefaultResultMapBuilder can certainly find files on the classpath, but only when webapp templates are under the context root directly, as any classpath templates have to be in a package structure equivalent to the directory structure of templates under the context root. For action results to be found when “struts.convention.result.path" starts with “/WEB-INF/” would require a root package called “web-inf” – but of course hyphens are not allowed in package names.
(Note that this issue is independent of the TemplateLoader classes that are later used to actually grab the template files. The loading process is readily configurable to look in many places – but the app never gets that far if the ‘action results’ are not found at startup. It would be nice if both processes used the same configuration...)
Solutions?
So… I could move all our templates outside of /WEB-INF but really I’d rather not. Or I could provide specific annotations for each action class, and again I’d rather not (and indeed it might suffer from the same issue).
Or I could make my own implementation of ResultMapBuilder by copying and very slightly changing DefaultResultMapBuilder (every member in the latter is private, so I can't extend the class and change just the relevant parts – alas!), and then figure out how to override the "struts-plugin.xml" Struts config file (to change the org.apache.struts2.convention.ResultMapBuilder bean), and thus I could get Convention to ignore "/WEB-INF" when looking on the classpath. Or perhaps better, to always prefix the path with "/WEB-INF/" when looking in the ServletContext.
But maybe there's an easier way? Some undocumented bit of configuration magic?
If I create a Grails app called a-b-c-d, doing a grails create-domain-class User will result in Grails creating a class User in the sub-directory grails-app/domain/a/b/c/d, giving it the package a.b.c.d. How do I prevent Grails from creating these package names?
You should definitely use packages, but you can customize the default package by changing the value of grails.project.groupId in Config.groovy. The default value is appName which is your application name, but you can change it to any value package, e.g. 'com.foo.bar'.
In addition you can specify the package when running a create script, and if you do want to create classes in the default package, you can use this syntax:
grails create-service .Person
and it won't use a package.
I have no idea, this sounds like a bug. There are two obvious workarounds
change your app to have a name without dashes
don't use the Grails commands create-domain-class, create-controller-class, etc. I never use these commands because they don't actually do anything other than creating the class (and a corresponding empty test class). Personally, I find it easier just to create the class myself than to run the Grails command
You can specify the package when you call the cli command...
grails create-domain-class your.package.name.User
Grails question: Confused about using a package to hold domain classes.
I'm using Netbeans on Mac to check out Grails.
When I create domain classes without using a package holding it, I can just go to localhost:8080/gTunes and the expected .gsp page is rendered properly.
However when I use a package (com.g2one.gtunes) to hold a domain class (Song), I don't see the .gsp page when I go to localhost:8080/gTunes. Instead I see a Directory view of folders/files such as META-INF, WEB-INF, etc. In order to see the expected .gsp page, I have to type in the specific URL localhost:8080/gTunes/index.gsp
In my research I've seen people talk about adding the following line but I can't figure out where to add it.
<%#page import="path.to.domains.*"%>
Any help is appreciated.
Thank you.
You need to add that import to the top of your GSP pages that use the domain class that you put in a package. Don't forget you'll also need an import in your controllers unless that are in the same package.
Add the specified line as the very first line in the GSP you are trying to render (show).
Figured out why I way I was having this issue. I'm going through Definitive Guide to Grails 2nd Edt on mac with NetBeans. I ran into this problem when I
created 'gtunes' project at /Users/name/NetBeans/gtunes
deleted 'gtunes' project and /Users/name/NetBeans/gtunes
created another project with same name at /Users/name/NetBeans/gtunes. I type in some code and run it and I run into the error I posted.
To get around this error,
I create 'gtunes' project located at /Users/name/NetBeans/gtunes
I right click on 'gtunes' project in NetBeans, issue 'Clean' command. Than I see some files are removed from ~/.grails/... in Output window
I right click on Album.groovy (possibly Song.groovy also) and issue 'Generate Views', NOT 'Generate All'
Run the project and it works!
Thanks all for comments and hopefully my mistake will help others avoid same mistake.