This content has been marked as final. Show 11 replies
Eclipse tooling for WLP and OSB is available, but it is not distributed as part of OEPE. Also, while core OEPE supports a wide range of WLS versions, both WLP and OSB tooling is tightly coupled to both a particular OEPE version and a particular server version. There may not be an OEPE-compatible versions of these tool sets that support the older versions of servers that you are using.
The best thing I can recommend is to ask questions on what's supported on WLP and OSB forums:
WLP: WebLogic Portal
OSB: SOA Suite
I've been working with Oracle Workshop for Weblogic for over 3 years and it isn't working as well as I hoped.Care to elaborate?
hmmm...the best way to describe it is "flaky". Intermittently, there are WLS deployment or IDE errors. It also occasionally (and randomly) hangs, is slow, and strange behaviour is very common. Just as randomly, errors will go away.
My team is very frustrated with the product and the behaviour is not conducive to receiving support from forums such as this or Oracle support (the problems can't be reliably or reasonably reproduced). Some on my team have far worse problems with the product than others. I'm on the "not excruciatingly painful to use it" end of the scale.
So, we're looking for alternatives (OEPE). But OEPE doesn't look promising given the server software we're using (10gR3) and how old it is.
I see. And you're hoping that OEPE would be better. Since Workshop is Eclipse, I would expect the OEPE support from various products to simply be reincarnations of the same Eclipse plugins - and perhaps the behavior to be similar.
"the best way to describe it is "flaky". Intermittently, there are WLS deployment or IDE errors. It also occasionally (and randomly) hangs, is slow, and strange behaviour is very common. Just as randomly, errors will go away."
Seeing the errors (from the workshop log and the server log) would be helpful. Without any other information, my best guess is that Workshop and/or WLS is low on memory, or even that the machine they are running on is low on memory. Workshop memory can be increased with the arguments -Xmx and -XX:MaxPermSize in <workshop>/workshop.ini. The memory settings for wls are in the <domain>/bin/setDomainEnv file.
Somethings that you might find chewing up a lot of memory is many/large xml schemas - they get compiled into xmlbeans and held in memory. If you have several projects in a single workspace, you might consider putting them in separate workspaces.
Held in memory on the server or on the IDE? Or does it matter?
I haven't noticed a correlation between xml volume and 'flakyness' but maybe once a large number of schemas have been in a workspace you can never get rid of them. This doesn't seem likely to me, but what is your opinion?
On a related note, does anyone know why a portal web project or web service project would require jsf when publishing? This used to just be a nuisance, just an error in the log that didn't seem to matter. But something has changed in my environment and now when it starts crying about not having the jsf libraries it won't deploy. Before anyone asks 'what changed?' I have no idea, but it used to work and now it doesn't..I have to assume SOMETHING changed.
Held in memory on the server or on the IDE?In the IDE. I've seen this cause problems for folks with an ODSI dataspace with large sets of "standard" schemas - Department of Justice is one that comes to mind, another is some insurance industry set of schemas. Another possible issue is making modifications to schemas. You might find jconsole useful for watching the memory. You might find the jrockit vm is better with memory usage than hotspot(Sun). The -vm setting in workshop.ini
Regarding jsf (and any issue, for that matter) - if you provide the error message/stack trace etc. it makes it easy for someone to search the bug database - even if they know absolutely nothing about jsf. There are some bits that are required on the server to permit deployment from Workshop. If your server is from a bea-home that does not have workshop installed - it's not going to work.
I expected the same thing too...that OEPE would probably work the same as Workshop...except for the fact that I can get a 64 bit version of Eclipse and then get OEPE installed...while Workshop is 32 bit. The 64 bit Eclipse would give us the flexibility throw memory at it in hopes of dealing with how memory hungry the projects/OEPE would be. As well, you pointed out that ODSI is not supported by OEPE. So, it isn't exactly the same as Workshop.
I have tinkered with the -Xmx and -XX:MaxPermSize variables in Workshop and WLS over a year ago. I remember fiddling with it for a few days. Sometimes I went too high or low and it made Workshop/WLS unstable or stop working altogether. I settled on the values that seem to work best for us:
and for WLS:
I haven't tried setting up multiple workspaces just to separate projects out for the sole purpose of allowing each workspace to have more memory flexibility. I assume that I could deploy projects from both workspaces at the same time to the same domain?
Something else you could try - change the javaw command in workshop.ini to java so it has a 'console' window. Then when workshop gets slow/flakey, hit control-break in the console window to get thread dumps to see what it is doing. (or kill -3 <pid> on unix).1 person found this helpful
Also - bad or misconfigured proxy settings in workshop will make it behave poorly (for instance, if the first proxy server it goes to does not exist). URLs in schemas/wsdls may require accessing the internet. There. I'm pretty much out of ideas.
thanks, Mike. The console window is a good idea and I'll try it for a little while to see what things I can find. My command prompt doesn't seem to hold the entire thread dump...how do I capture the whole thread dump?
What do I do with the thread dump once I do get one? What do I look for?
We do have a proxy server so misconfiguration there has been a problem in the past and I'll keep my eye on that.
I appreciate you taking the time to help me sort this out...
On your window, right-click -> Properties. Set the Screen Buffer Size -> Height to 9999. That should hold your thread dump. The thread dump is just a snap-shot, so to find something that workshop is spending a lot of time in, take several of them and look for common things between them.
What to look for? In general, you can ignore the short stack traces. Look for a long-ish stack trace that "looks" busy - compiling, deploying, searching, making an http request - look at the method names and guess.