I'm using Vaadin 7.4.3, tomcat 8. During the wizard to create Vaadin 7 project in eclipse, it has a checkbox called "Generate web.xml deployment descriptor".
The new way is to use annotation instead of specify it in the web.xml. Are there any configurations that I have to use web.xml because there's no annotation for it? Is it a good practice to always generate the web.xml even if you might not use it for Vaadin 7.1 projects and up?
Thanks
Yes, there are for sure some aspects of app that cannot be configured using annotations (i.e. there is no annotation to state that you want to have your session cookies "http-only" ).
I would recommend you to create web.xml file when it is needed. Sooner or later it would probably will be used, but don't worry too much in advance. It is not a dark magic to create web.xml file in existing project :)
Related
I would deploy my Vaadin custom themes in Websphere and reference them in some vaadin portlets deployed in Websphere Portal.
I'm using Websphere 8.5 and Vaadin 7. I found a lot of topic about the Tomcat and Liferay combination but nothing usefull for Websphere.
I also tried to set the vaadin.resources.path variable in the 'WP PortletContainerService' in Resources>Resource Environment>Resource Environment Providers and I set a resource with name 'std.portalcontext.vaadin.resources.path' but I can't see it in UI.
Thank you.
Setting that property on the portletcontainerservice is not going to help you because it is not one of the properties that the WebSphere Portal container is going to recognize as a property. I think you may have to do something like this https://vaadin.com/forum/#!/thread/2732876/2732875 specifically these https://vaadin.com/wiki?p_p_id=36&p_p_lifecycle=0&p_p_state=normal&p_p_mode=view&p_p_col_id=row-1&p_p_col_pos=1&p_p_col_count=3&_36_struts_action=%2Fwiki%2Fview&p_r_p_185834411_nodeName=vaadin.com+wiki&p_r_p_185834411_title=Developing+portlets+for+the+Websphere+Portal+Server
The main thing to do is this
In the portlet tag you have to set a value for the portlet-class. For this simple we can use the default Vaadin portlet class com.vaadin.server.VaadinPortlet; you also have to name you UI class as a portlet init parameter.
To let WPS find the Vaadin javascript and theme resources you have to use the portlet init parameter vaadin.resources.path. The value PORTLET_CONTEXT is a Vaadin constant value that makes the vaadin resources available in the portlets resource path.
Run the Maven build with clean package as goals and deploy the created war file in the portal administration. Create a blank portal page and add your portlet to the page. Your "Click me" portlet should look like this:
I have a Grails project and want to add existing filters from a JAR file.
I used the WebXmlConfig plugin, mentioned in this answer:
How to add filters to a Grails app
and that worked great for a single filter, but I can't figure out how to extend that to more than one filter.
Do I need to change approach and edit the web.xml template directly?
I'd use the pluginator plugin and put the definitions in doWithWebDescriptor just like you would in a plugin - you can add as many elements as you want. It's a slick plugin that lets apps do things that are generally only supported in plugins, like conveniently editing web.xml (although with a seriously weird DSL) and registering custom artifact types.
Struts2 Scope Plugin is no longer compatible with the latest version of Struts2-core (e.g. 2.3.15). What is the successor of the Struts2 Scope Plugin? Struts2 Conversation Scope Plugin? What is the migration effort? Experience?
Yes, It is the Struts2 Conversation Plugin. There is nothing such as a migration plan.
Best strategy is to identify annotations from the old scope plugin. Then replace the them one-by-one with the new annotations. E.g. Find #In/#Out annotations and replace them with #ConversationField (of course, where appropriate)
Follow the Quick-Intro here: http://code.google.com/p/struts2-conversation/
First I tried to update the scope plugin itself. This is pretty straight forward (change dependency, add a version to the maven compiler, replace findAnnotatedMethods by getAnnotatedMethods and fix the tests) and seems to work fine.
Nevertheless I decided to remove the plugin completely and use a simple SessionAware actions.
I have created web dynamic project with jsf2, Primefaces 3.4, Tomcat7.Application runs fine. If i deploy the EAR of the same project on Websphere8 instead of Tomcat7, I am getting Exceptions.I am not sure of what is happening. I am new to JSF2 and Wepshere8.
can you provide me the links on how to start sample jsf2 + primefaces project on Websphere 8
Thanks in advance.
Got it. Try to add com.sun.faces.config.ConfigureListener instead of org.apache.myfaces.webapp.StartupServletContextListener in your web.xml, restart your server and then run it.
The code should look like the following.
<listener>
<listener-class>com.sun.faces.config.ConfigureListener</listener-class>
</listener>
For using different implementations of JSF, the WebSphere Application Server JSF engine determines if the SUN RI or Apache MyFaces is used from the application server run time. After the JSF engine determines the implementation that is used, the correct listener class is registered with the web container. You do not need to add the com.sun.faces.ConfigureListener or the org.apache.myfaces.StartupConfigureListener to the web.xml file.
http://www-01.ibm.com/support/knowledgecenter/SSAW57_8.0.0/com.ibm.websphere.nd.doc/info/ae/ae/cweb_javaserver_faces.html
Please see above...
I too faced the same problem.
Websphere by default support sun impl and apache myfaces and its jsf 1.2.
To use jsf 2 implementation.
1.Make sure to remove servlet.jar from your application.Its need for tomcat however not in websphere.
2.Change the classloader policy for ear to parent last.Parent last means lib in your app will have higher priority.if not found will load from WAS class path.
3.Also make sure to change the webmodule class loader policy to parent last.
4.Restart websphere.
To solve the classloader of primefaces in websphere 8.5 classes replace the jsf
jsf-api
jsf-impl
javaee-api
for the native implementation of websphere
myfaces-api
myfaces-impl
I'm writing a Grails app which I'd like 3rd parties to augment at runtime. Ideally they would be able to add a JAR/WAR to the webapp directory which contains new domain, controller and service classes, new views, and other content.
Is there a simple way to do this within grails? Would it be simplest to create a startup script which copies the new classes etc. into the relevant directories and then updates grails.xml and web.xml?
You will be able to do this in version 2 of grails in which plugins will be also OSGI plugins http://jira.codehaus.org/browse/GRAILS/fixforversion/15421
It seems that the Grails plugins will actually fit quite well for this: http://www.grails.org/Understanding+Plugins
A plugin can do just about anything... One thing a plugin cannot do though is modify the web-app/WEB-INF/web.xml or web-app/WEB-INF/applicationContext.xml files. A plugin can participate in web.xml generation, but not modify the file or provide a replacement. A plugin can NEVER change the applicationContext.xml file, but can provide runtime bean definitions