I've got a really nasty problem...
I wrote a Red5 app and so on and it is running perfectly on my local computer.
Now the problem occurs =>
How can I make this program work on a remote server?
Local : Mac OS X 10.5 - Red5 0.63
Server: CentOS 5 - Red5 0.90
Maybe it's because of the version difference. But I can't test Red5 0.90 locally because it won't start up and I can't install the 0.63 version on the server because of missing dependencies (and broken links to them...)
Two thoughts:
Without error messages, code, a description of your application, etc. we can't really help.
Red5 has been in very active development over the years, and each tiny version change is significant. I would suggest figuring out how to get Red5 0.9 running on your local machine would be your first priority.
I solved it...
The XML files have totally changed in the last versions :D and I got a little bug in my program :P
The primary change was in the web.xml, comparing your applications web.xml to one of the 0.9 demos will show you the differences.
Related
I'm receiving the following error when trying to run a JSF App via IntelliJ IDEA with Glassfish.
The error shows the port out of range. The port is actually set to 63342. I'm curious if I should be using a set port in a lower range or if there is another way to resolve this error.
I ended up finding the solution in two ways.
I tried the link provided by #kolossus to Glassfish suddenly complaining of bogus port. The resolution there seemed to work fine, however I found that...
The second solution was uninstalling Glassfish 3.x and installing Glassfish 4 as it appears to work seamlessly with IntelliJ IDEA 13 EAP.
Both are likely valid solutions, but I've stuck to solution #2.
This is really two questions, but they are very closely related.
I am developing a Java application that will process emails stored in the UNIX style MailDir format. I am using the JavaMail API, and found JavaMailDir that should work as a provider capable of reading the format my email will be in.
The issue I am running into is that JavaMailDir seems to always expect your mail folder (the one passed into store.getFolder()) to begin with a dot. I only have access to a Windows machine for my development and initial testing. So, to test I copied some sample emails and the folder structure from a Linux system. When I try to read messages I get an exception because the file cannot be read. I can see through the API calls that messages so exist in the folders. It seems having the dot as the first character of a folder name seems to break opening the files on Windows.
My question would be is there any work around to get this working on Windows, or perhaps another provider that would provide the same capability and perhaps work better on Windows?
So, it seems like there is no really good work around to use JavaMailDir while doing my development on Windows. Ultimately I was able to build a version of Plexus Maildir that I saw referenced in another post. This will at least allow me to do development on a Windows machine until I move to testing in a real Linux environment.
Why not just set up Linux as a dual boot OS on your windows machine?
https://help.ubuntu.com/community/WindowsDualBoot
Truly understanding and double checking everything might total a day's work to get everything set up and working on your machine.
I recently updated OS X 10.6.6 as recommended by Software Update: http://support.apple.com/kb/HT4562
Now, even new appengine projects created with the eclipse plugin are broken. The jetty dev server starts, and then terminates after the info message that the server is running. There's no error information.
Ugh.
A gwt-only project created with the plugin works fine. The jetty server starts up and happily serves the application.
My question is, I guess, how I can get more information about what's going wrong, and ultimately how can I fix this? Even starting a project with the previous version of the jre does not help.
This is a known problem; see, for example here. The link leads to a workaround.
I am using the javax.comm API to help my program communicate with hardware over serial port. I am using the Windows 7 and NetBeans IDE 9.
I used the common Java program to check the available ports on my PC. The program compiled and ran without error. However it returned nothing.
What can I do to use the javax.comm API on Windows? It seems win32com.dll does not work with a 64-bit operating system.
This is how I got it to work.
I've tested it using JDK 1.6 (32bit) on my Windows 7 64bit machine.
Install 32bit JDK.
Copy 'win32com.dll' to JDK_HOME\jre\bin.
Copy 'javax.comm.properties'to to JDK_HOME\jre\lib.
Copy 'comm.jar'to to JDK_HOME\jre\lib\ext.
Now run your program and it should work.
Recent 2.2pre versions of RXTX include binaries for 64-bit windows. I think the latest RXTX information source has changed to this: http://rxtx.qbang.org instead of http://www.rxtx.org though.
At one point the RXTX library included drop-in support for using the javax.comm api. I'm not sure if it still does, but the main change then to use the "native" RXTX packaging was primarily just a package name change.
it seem the win32com.dll does not work with 64-bit Operating system
I think that is correct. In fact, according to the relevant download page, Oracle no longer supports the javax.comm API for any Windows platform.
However, I found this page which has a 64bit build of the DLL, among other things.
EDIT
By an astounding piece of research (i.e. following the links and reading stuff) I found the download page for the latest RXTX, which claims to have binaries for various platforms. If your platform is not there, try building from source. If that doesn't work, consider investing the effort in making it work.
I've integrated RXTX libraries into some of my earlier projects and i found out this bug it has while working with comm ports under windows, so you might want to check this first before going into some serious app design.
Communication works fine, never had any problem with that, but once you open the port you cannot close it and reopen, if you use method provided for closing port, your app just hangs, no exception no nothing. I found later the same behavior described by users on web, but never really found the solution to this problem.
Again, this might help you save some time, check it first.
Latest release, which is this http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip, doesn't have this issue no more. Unfortunately i think its solved only for windows, its still there on Linux binaries, and i haven't tried it on mac.
Have you got a look on RXTX ? I think it is still active.
I had this issue...on a 64 bit machine..running windows 7
a legacy application developed in jdk 1.4, for 32 bit windows... and using the win32 comm api binary
i tried the RXTX binary for 64 bit and i was able to communicate with my device on some level... but... there were other problems as my application referenced a version of the jpos library that internally was using the comm-api (had import javax.comm.*... in some Serial...Listener class)....
I installed a 32 bit jdk and setup the comm-api binaries for 32 bit windows as directed here...setup comm api on windows
all was fine afterwards
You might be interested at an alternative library I've authored: http://code.google.com/p/jperipheral/
I'm doing some portlet development for IBM WebSphere Portal 6.1. However, the deployment process is painfully slow. As this is my first time doing portlet development, I'm not too familiar with the various portal servers out there. I'd like some recommendations for a lightweight portal server on which I can deploy quickly for development.
Pluto is the answer!
http://portals.apache.org/pluto/
I'm very happy now. :)
I believe Liferay has become Sun's adopted strategy, if that has any bearing.
If you are using Websphere Portal server, you can use the lazy load of portlet applications at server startup. This would help in less server startup times as it would not start many administrative applications.
For more information, follow this link
http://www-01.ibm.com/support/docview.wss?uid=swg27015437
Hope this help you :)
I'm not familiar with each of their deployment characteristics, but here is a list of open source portals in Java: http://java-source.net/open-source/portals
I was in a similar situation a year or two ago.
The server takes a long time to come up regardless, but it doesn't actually have to be restarted with any little change. You only have to restart the server with major changes, otherwise, restart or redeploy the project to the server.
Nevertheless, the system wasn't snappy until I had three gigs of ram. I'd recommend first upgrading your workstation to support the server. They're called workstation class systems for a reason :) Get yourself an 8gb machine and tell your boss you will be twice as productive :)
I typically use hotdeployment of changes Java classes and JSP pages. This is the fastest way. We shared 1 server with 5 developers using hotdeployment of classes to PortalServer/installedApps/.ear/yourportlet.war and this worked great. However, now and then we did have to restart the server. If you changed deployement descriptors you still need to re-deploy the portlet WAR. Make sure the reloadingEnabled flag is set to false for the wps.war app on your development machine (restart picks up the change).
You can use developer mode explained here:
http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1/index.jsp?topic=/com.ibm.wp.ent.doc_v615/install/chg_dev_mode.html