I can think of three reasons, and I'm sure there are more than that. But you don't need guesses. You need the actual reason. And that should be available somewhere in the logs of the server where the error occurred.
For one thing, there is only one constructor for javax.mail.Service (in J2EE), and it takes a Session and a URLName. So calling newInstance() will throw an InstantiationException because "the class has no nullary constructor." (I'm not sure if this would give a 500 error or not.)
"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer sscce.org
Ummmm, javax.mail.Service is also abstract, which makes it even harder to instantiate. But (a) we don't know if javax.mail is the package for the Service in question, and (b) even if it is, there's a good chance that the code is really trying to instantiate a subclass of Service, and we'd need to know which subclass, and what constructors are available.
Anyway, Paul C definitely has the right idea. We can spaculate about all sorts of possible causes for a problem like this, but solid data would be much more useful. It would be highly advisable to find out where the server error log is, to get more info.
Also, I recommend finding documentation for whatever class "blah.blah.blah..." is, to find out what constructors are actually available. Because marc's suggestion is not without merit. [ June 07, 2006: Message edited by: Jim Yingst ]
"I'm not back." - Bill Harding, Twister
posted 13 years ago
Yes.. I cannot post the code or log for this via company rules. I am interning and cannot figure out why this will not work. I have looked everywhere and tried alot of things to try and get this to work. So this might be just a dead issue. I am sorry I did not know if my syntax was wrong or something.
So if you're interning, then probably there's somebody else there who is responsible for that server? If so, then you should go to them and ask them where the stack traces for errors go in that server.
But if the server itself is part of your job, and you are setting it up and running it, then it would be your job to find out where the server puts those stack traces.
No, there's nothing wrong with the syntax of that statement. It just throws an exception when it's run. [ June 07, 2006: Message edited by: Paul Clapham ]
posted 13 years ago
Whatever this blah.blah.blah... class is, someone somewhere wrote it, and there should be documentation somewhere about it. Even if it's nothing more than a bare-bones javadoc that tells you what the constructor and method signatures look like. That would be enough to tell whether newInstance() has any chance of working or not. Chances are fairly good that there's no no-arg constructor, in which case you'll probably need to do something like
Some of these steps could be combined into one line, but an advantage of spelling things out the longer way is that if an error occurs, you're more likely to get a message pointing you to exactly the line that's the problem.
But again, this constructor thing might not be the problem at all - getting info from the logs should be a high priority.