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.
Related
I am developing acceptance tests for an application and mocking all external API calls in WireMock. It is a java (Spring boot) application. In intellIj debugger it gets stuck in break points saying "Collecting data" when I try to see the content of a variable or object. If I try to resume the program it shows waiting until the last debugger command completes and gets stuck. during this the IntellIj keeps using it's maximum memory.
Note:
This question is not similar to this. As over there it is a stand alone application and here it is a web application having it's external API calls being mocked by WireMock, and none of there mentioned answered helped my case.
I have installed a few plugins recently and thought they might be the problem so have removed them.
I console I am able to see the API calls being made properly as I could see there response coming.
I am using IntellIj ultimate edition 2020.2 right now on a Windows 10 system without Admin access.
I have been stuck with this for a while and any help would be useful.
Edit: It got this resolved by downgrading my IntelliJ IDEA.
I finally got it resolved by downgrading by IntelliJ IDEA to 2020.1.2 from 2020.2
I am trying to debug a simple DropWizard application in Eclipse, in an attempt to familiarise myself with it. I can start the jvm from the command line like this:
java -Xdebug -agentlib:jdwp=transport=dt_socket,address=9999,server=y,suspend=n -jar dropwizard-0.0.1-SNAPSHOT.jar server config.yaml
And then connect to it as a remote java app.
Or I can find the application class (containing the main method) in eclipse and launch the application in debug that way.
Both these methods appear to successfully start the application in debug, and sure enough, if I set a break point somewhere, it gets hit.
My problem, however, is that Eclipse would normally at this point give me some control over the application but in this case is rather oddly not allowing me to resume, or use any step commands. I can't do anything other than terminate the application.
Perhaps I am having a stupid morning, but I cannot fathom why this is happening.
Can anyone shed any light on this and how I can gain the control required to debug?
I cannot be certain, but I believe this may have been due to an unintended mix of 32bit and 64bit components.
I had the same problem with a project I was much more familiar with a few days later, and in that case it was resolved by changing the buildpath to use the 64bit JDK. I was previously deploying it to a 64bit tomcat with the 32bit jdk on the build path when this happened.
Clearly the situation is a little different with dropwizard as its deployment is self-contained, but similarly altering the build path there seemed to resolve this for me.
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.
A few days back, while the built-in server (Tomcat v5.5) in eclipse was running, and while I was modifying the code, the server used to recompile and restart itself. I've gotten into a problem from the last day, where, the server DOESN'T load the LATEST version of the code I'm writing, instead, (I'm assuming) it compiles its own internal cache. Yesterday evening, I fixed that problem by (as I can remember) by clearing some cache or something. But, I did the same today, and its malfunctioning in both ways -- by not compiling the latest version and -- not auto restarting when I modify the code. I've even tried restarting eclipse but the server is still compiling its own code which CAN'T be seen in the workspace.
[EDIT]
I've now resolved the problem which was with something with importing the right add-on library to the working directory.
While the embedded Tomcat in Eclipse should recompile the classes/JSP:s/whatever it falls victim of its own caching which causes it to load old versions of the classes after reloading. So yes, the new classes actually exist in the embedded Tomcat but since the cache isn't cleaned properly (or maybe not at all) it won't reload classes automatically and thus has to be restarted every single time you've made a change.
Additionally it seems that there's some bugs in the Eclipse Server controller which causes the auto-reloading to just stop working at times. Basically it's a bit of a mess and all you can do is to restart it continuously. Or use Jetty which is a lot faster to use when developing.
Use Jetty instead?
I have occasionally found that Eclipse gets confused about something, and frequently the easiest way is just to dump the current Eclipse tree, and unpack a new one, in which you rebuild your workspace.
We use projectSet.psf's in our source repository which makes the above process something that can be done in about a minute.
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.