Wrapped vs Bare in Doc/Lit web services

Best explanation that I have seen to date.  Includes a description of the constraints that need to be applied to wsdl to make it work

http://atmanes.blogspot.co.uk/2005/03/wrapped-documentliteral-convention.html

PermGen In Grails

Found this useful tidbit on Grails Facebook page - how to fix Grails permgen issues

• Hi ,default ram size occupied by jvm is 64MB you can increase it manually by the code given by santosh CATALINA_OPTS="-Xms256m -Xmx1024m -XX:MaxPermSize=256m". configure the above code in tomcat config file.

  Friday at 09:40 ·  ·  1
• 

  Prabhat Roy ‎2)Some time memory leak causes this problem, than abome wont work use profiler and chekout the code , dont include unnecessary jars and check the code module by module remove unneccessary object creation , if required call garbage collection explicitly to kill the useless objects. its bit difficult to debug.

  Friday at 09:44 ·  ·  1
• 

  Prabhat Roy ‎3)(a)Put JDBC driver in common/lib (as tomcat documentation says) and not in WEB-INF/lib
  (b)Don't put commons-logging into WEB-INF/lib since tomcat already bootstraps it

  Friday at 09:46 · 
• 

  Prabhat Roy new class objects get placed into the PermGen and thus occupy an ever increasing amount of space. Regardless of how large you make the PermGen space, it will inevitably top out after enough deployments. What you need to do is take measures to flush the PermGen so that you can stabilize its size. There are two JVM flags which handle this cleaning:
  
  -XX:+CMSPermGenSweepingEnabled
  This setting includes the PermGen in a garbage collection run. By default, the PermGen space is never included in garbage collection (and thus grows without bounds).
  
  -XX:+CMSClassUnloadingEnabled
  This setting tells the PermGen garbage collection sweep to take action on class objects. By default, class objects get an exemption, even when the PermGen space is being visited during a garabage collection.

  Friday at 09:47 · 
• 

  Prabhat Roy finally , in rare condition if nothing works than restart the server :)

  Friday at 09:

JAXBElement and generateElementProperty

This had me perplexed for a while.

http://docs.oracle.com/cd/E19879-01/820-1072/ahiid/index.html

So, if you have for example a  name attribute which is a String and has minOccurs="0" nillable="true" for its schema element then there are 2 representations for "no value":

<person>
<name xsi:nil="true"/>
<age>21</age>
</person>

and:

<person>
<age>21</age>
</person>

Note that an empty String element is not the same:


<person>
<name/>
<age>21</age>
</person>

This can be interpreted as an empty String, "", rather than nil.

With this definition its not possible to marshal that in a way that does't lose information if you go direct to String, because you have to pick a representation when you unmarshal.

That is if you perform the marshalling activities xml -> String -> xml you have to pick which representation of nil to use in the final XML, and you have no information to allow you to determine which representation you came from.  So its possible they may end up different.

That's not good.  So JAXB doesn't do that by default.  Instead it wraps elements like this in JAXBElement rather than String so its xml -> JAXBElement -> xml, and the representation is preserved.

Said another way, you can avoid using JAXBElement if you pick the representation of nil you want for XML, by having minOccurs="0", nillable="false" for example.

Or, you can tell JAXB how to do it when you do wsdl2java by providing a binding file that contains generateElementProperty="false".

Interesting Grails Pugin - Melody

System reporting within your app.

http://grails.org/plugin/grails-melody
http://code.google.com/p/javamelody/