I know, env-entry uses jndi and can be changed during runtime, where context-param cannot.
However, I can inject the values of both via #Resource, where type conversion is made automatically.
What is the difference (pros/cons) of using context-param or env-entry in web.xml.
Related
We're migrating an EJB 3.0 application to EJB 3.1 and would like to use #Stereotype to reduce some of the EJB configuration.
The annotations we plan to have are:
#Singleton
#ConcurrencyManagement(BEAN)
#PermitAll
#Interceptors or custom #InterceptorBinding annotation
#SecurityDomain("acme") JBoss / PicketLink
Of those I know that #Singleton can't be put into a #Stereotype and has to be on the EJB itself. What else can't be put into a #Stereotype?
Update
The specification [1], [2] says that
A stereotype encapsulates any combination of:
default scope, and
a set of interceptor bindings.
The examples then use Java EE 7 #Transactional which is an #InterceptorBinding which leads me to believe that none of the above annotations can be put into a stereotype.
The The Java EE 6 Tutorial states the following:
A stereotype is a kind of annotation, applied to a bean, that
incorporates other annotations. Stereotypes can be particularly useful
in large applications where you have a number of beans that perform
similar functions. A stereotype is a kind of annotation that specifies
the following:
A default scope
Zero or more interceptor bindings
Optionally, a #Named annotation, guaranteeing default EL naming
Optionally, an #Alternative annotation, specifying that all beans with this stereotype are alternatives
So as you saw yourself, the annotations you used are not in one of the mentioned groups.
My personal suggestion is, to be careful with creating and using stereotypes, since one then always have to know (or check) what it means, so for example I prefer using #Named #RequestScoped rather than #Model because saving one line of code does not make up to not see the scope at the first glance.
It possible in Resteasy to extract the URI mapping to an external, dedicated file?
Annotating classes and methods is quick and easy but I would like to have a file that maps the URIs to functions. Something like:
/teams/{team}/player/{player-id} TeamResource.fetchPlayer
As far as I know this is not currently supported as part of the JAX-RS specification, but I could see you being able to do this with byte code insertion at runtime using something like javassist.
Basically you would add the #Path annotations to the your resource classes at runtime with the values loaded from your uri mapping file. Once the annotations were added to the resource you would then inject them into Resteasy.
I tried to use Saxon in place of JDK's default implementation (Xalan I guess) for XML transformation and Xpath. In my code I am creating a CDATA node using document.createCDATASection(data) method. Code looks as given below:
CDATASection cdata = doc.createCDATASection("data");
Node valueNode = node.appendChild(doc.createElement("value"));
valueNode.appendChild(cdata);
Where node is some random node in my XML.
It works fine with JDK's default implementation and resulting XML looks like:
<node>
<value><![CDATA[data]]></value>
</node>
The same code starts behaving strange if I include Saxon maven artifact (Please note it is just inclusion and factory selection/instantiation is default, as it was earlier) and all the cdata nodes are treated as simple text nodes i.e. XML becomes:
<node>
<value>data</value>
</node>
which on retrieval is causing issues as that code specifically checks for cdata elements which in later case has been removed. I am not sure why this is happening (looks like I have not used it correctly). I also tried excluding Xerces artifacts from my POM (transitive dependency for Saxon) but no luck. Also, verified that implementation classes for DocumentBuilderFactory etc are being used from JDK itself. Experts please help me if I am doing something wrong.
Thanks in advance.
I guess your application is probably doing a JAXP identity transformation from a DOMSource to a StreamResult in order to serialize the DOM. The Saxon implementation of the JAXP identity transformation uses the serialization rules of XSLT, which have the effect of dropping CDATA sections. This is perfectly conformant with JAXP, even if it isn't what the default JDK implementation does.
If you are dependent on the behaviour of a particular implementation of the JAXP identity transformer, then you shouldn't be writing your application to pick up whatever implementation happens to be lying around on the classpath; you should instantiate the implementation you want explicitly.
This can be difficult of course if the code that invokes the identity transform is something you didn't write yourself and can't easily change. In that case the best approach is to set the system property javax.xml.transform.TransformerFactory to select Xalan, and where you want to invoke Saxon, do it explicitly rather than relying on the JAXP factory search.
I'm generating java code based on various WSDL's. We have a different WSDL for every new version of the WebService that we release, each with its own namespace.
The thing is that normally the changes are minimal from one release to another, but I want to keep classes divided by namespace.
Is there a way to configure JAXB so that the auto generated classes implement a single interface/extend a single class, so I can refer to either of them without changing my code?
Dummy example:
WebService method: listScripts(ResultSize size);
Auto generated classes:
com.test.ws1.ResultSize
com.test.ws2.ResultSize
Both classes are exactly the same. Is there a way to arrange them in a class hierarchy so my code is isolated from changes in version numbers? i.e. a com.test.ResultSize interface implemented by both classes?
XJC has an extension for this purpose
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc"
jaxb:extensionBindingPrefixes="xjc"
jaxb:version="2.0">
<xs:annotation>
<xs:appinfo>
<jaxb:globalBindings>
<xjc:superClass name="com.mycompany.xml.UserRootObject"/>
</jaxb:globalBindings>
</xs:appinfo>
</xs:annotation>
.
.
.
</xs:schema>
For more information see:
http://jaxb.java.net/nonav/2.0.2/docs/vendorCustomizations.html
The schema annotations can also be supplied via an external bindings file. For an example see:
How do you customize how JAXB generates plural method names?
It turned out that I can use a plugin provided in the JAXB2 Basics package:
Inheritance plugin
With this plugin I can specify different super classes for my generated ones, although I couldn't make the auto generated enums to implement a given interface.
To use it in Maven it was a pain (I'm generating classes from a WSDL, not using JAXB directly), so I switched to an external Ant task as specified in this blog
Is there a way to pre-load EJB instances (stateless) in JBoss 4.2.0? I know there isn't any configuration option for this, but could I write my own MBean or something to do this?
-Dave
It's probably not neccessary according to this article
in $JBOSS_HOME/server/default/conf/standardjboss.xml
you find
<container-pool-conf>
<MaximumSize>100</MaximumSize>
</container-pool-conf>
for both container-confgiurations Clustered Stateless SessionBean and
Standard Stateless SessionBean
Looking in the DTD shows MinimumSize as an optional element in container configuration for experimenting you could set the MinimumSize and check whether some server code cars about.
<!--
The container-pool-conf element holds configuration data for the
instance pool.
jboss does not read directly the subtree for this element: instead,
it is passed to the instance pool instance (if it implements
org.jboss.metadata.XmlLoadable) for it to load its parameters.
The default instance pools, EntityInstancePool and
StatelessSessionInstancePool, both accept the following configuration.
Used in: container-configuration
-->
<!ELEMENT container-pool-conf ((MinimumSize?, MaximumSize?,
strictMaximumSize?, strictTimeout?) | Synchronized)>