I have a grails controller which handle fileupload.
I deployed the application on glassfish in windows and in ubuntu.
On windows deployment, the request object of
request.getFile("filename")
is of type commons.CommonsMultipartFile
while on ubuntu deployment the request is of type support.DefaultMultipart
What causes this different behavour?
Is there a way to make it consistent?
The application server is glassfish3.1.2
Anything grails supplies via the request.getFile(...) method should implement the Spring MultipartFile interface. As long as you stick to the methods available in the interface, you shouldn't need to worry about what concrete implementation you receive.
the problem solved after I upgraded the glassfish from 3.1.2 to glassfish 4 in windows and ubuntu.
there may be some other ways to solve this. but i solved this by upgrading the glassfish.
Related
I cannot access remote EJB beans of our application server within a web application running on Glassfish 3 web-profile using jndi lookup.
Using full profile for our web-application or even testing with a console application we have no problem accessing jndi remote beans.
Exception:
Unable to acquire SerialContextProvider for SerialContext
We just hoped to make our web servers more lightweight.
The Web Profile version of Glassfish only contains EJB Lite, which doesn't support #Remote interfaces. You need the Full Profile which supports the full EJB 3 spec.
From the oracle docs:
The Web Profile of the GlassFishTM Server supports the EJB 3.1 Lite
specification, which allows enterprise beans within web applications,
among other features. The full GlassFish Server supports the entire
EJB 3.1 specification. For details, see JSR 318.
You can find a comparision of features included in Web Profile and Full Profile here (It was made for Glassfish 3.1.1 but it should be nearly the same for Glassfish 4 except some newer versions of some features). You can find a nice feature comparision between EJB 3.1 Lite and Full in this article.
Update:
As you wrote in the comment (and the initial question) you are not using any enterprise beans directly in your web application, but you are retrieving bean instances via JNDI. This doesn't work with the Web Profile of Glassfish because the functionality for remote lookups is not there, e.g. the CORBA and ORB modules are missing (there are some basic CORBA OMG APIs but only because they are needed by other modules).
As your goal was to make the server more lightweight, maybe this is another option for you: You can remove unused components and modules with the pkg command-line-tool or with the graphical utility updatetool. You could install the Full Profile of Glassfish and then remove obsolete components step by step to make the server more lightweight. More details about the tools can be found in the oracle docs.
See also:
Can EJB 3.1 Lite be exposed via Remote interface?
How to know what glassfish is - full plaform or web profile?
EE6 web profile … no EJB container?
GLASSFISH-14459 corba classes are part of web profile
I am using grails framework to develop a web application. I need to generate the runtime server URL as follows: http:hostname:port/application/. In grails configuration we have an option to provide the serverURL using grails.serverURL.
My question is: Can we get the port number of server which the application is running at runtime? Is this possible?
Try this..
System.getProperty("server.port", "8080")
Enjoy...
If you have different profiles(config blocks) per environment, you can likely set the grails.server.port.http property in there.
I want to know that how to configure/run Activiti BPM in Grails?? I'm using fedora as my OS, Grails 2.1 . If their is any tutorial websites are is plz mention it also..
There is a plugin for Grails applications that provides much of Activiti within a Grails app. http://grails.org/plugin/activiti However, development has sadly stopped on it by the main developer. The last update was for Activiti 5.9 and Grails 2.1, though much of the plugin content seems to be built for older versions of Grails; for example, actions in the plugin's TaskController are all closures, not methods. Also, someone did issue a pull request to update it to 5.10.
I've been trying to puzzle through the source for that plugin myself. I keep vacillating between simply setting up a standalone Activiti server and utilizing the RESTful API from within a Grails Service class, importing a few of the Activiti classes into my Grails app, or trying to re-engineer the plugin to suit my needs (my site is stuck on Grails 2.0.1 for the time being).
I'm trying to include Grails applications into a Liferay portlet. I tried the Grails Liferay Portlets Plugin but it did not work for me at all.
Does anybody know any other possibilities? Which do you think is the best and why?
We had our Grails project integrated with Liferay at one point but it was a mess. Inevitably we pulled it out of Liferay and we were able to use Grails properly again. In our instance the question became, why are we using Liferay and do we really need it?
Now if you have a requirement for Liferay you might try simply using Spring Portlet support and use parts of Grails you like but not fully integration. Spring Portlets with Groovy were much easier and cleaner to do. If you simply want Grails goodies for services etc. you can try deploying a Grails WAR on the same tomcat and expose services to your portlets through REST, Hessian, Burlap or some other easy service serialization mechanism in Spring/Grails. In this case you have a Liferay UI app that calls your Grails services.
Once again, try some options, then decide if you truly need (or have) to use Liferay. With advances in Javascript UI packages, I'm not sure 'portlet' spec apps are as appealing as they once were and the word 'portal' is something that sounds good to management but inevitably means little to what needs to be implemented.
Based on advice posted here and here, I looked into and installed MyFaces CODI with my application. My biggest concern was overcoming the shortcomings of Weld's implementation of #ConversationScoped feature. After some hiccups I got it running on my GlassFish 3.1 development platform, and I converted all my beans to use
import org.apache.myfaces.extensions.cdi.core.api.scope.conversation.ConversationScoped;
In the end it seems like I am now not much further along than I was before. I do not have to call the conversation.begin() method anymore, which is good, but the beans hang around after the browser has left the page and come back.
What I was hoping for was the functionality of JSF 2.0 #ViewScoped that works with CDI. Once the user leaves the page, the backing bean should be discarded and re-created again if the user comes back. Is there a way to do this with CODI?
Incidentally, the documentation says it will pick up the #ViewScoped annotations and process them properly. I tried this and got and Weld wouldn't deploy it.
P.S. I am using myfaces-extcdi-dist-jsf20 version 0.9.5. I tried installing the core and JSF 2 optional module akibe but it would not deploy on my GlassFish/Weld platform. Any advice here much appreciated.
UPDATE 1: I ended up trying the ViewAccessScope annotation supported by CODI, and that seems to do what I wanted.
Follow-up question. The latest bundle that the maven repository that Apache maintains is 0.9.5 -- Can someone post the pom.xml segment that fetches the latest version?
Call conversation.close() before returning - ensure that you imported the correct annotation org.apache... and not javax... - see Wiki or use the ViewAccessScope instead. We are using: bundle in Glassfish 3.1.1 without problems. myfaces-extcdi-bundle-jsf20-1.0.1.jar is the only jar you need. Please also note that there is no "it". With CODI you have fine-grained groupable conversations instead of the monolithic and inflexible stuff you get with standard CDI conversations.
The set-up for the latest version with a Maven build is also in the Wiki.