We Keep Coding

Java Filter not working on production environment Websphere 8.5

I have a filter used for authorization. It's the first step entering application. Without it is not possible to do anything in the application.
I set a systemout on the very first line of doFilter method to monitor the behaviour, so comparing websphere server log files I'm sure that filter (same Ear deployed) on Test environment works and on Production environment not.
Maybe it's server configuration issue...?
I have access to read and modify WAS Console of test environment.
I have access only to read WAS Console of production environment.
So I can compare them, and maybe test some change on test environment to replicate the behavior and say to production administrator what exactly setup....
Any suggestion on which setting I can check (Was console, maybe in relation with Web.xml, etc...)?
Thx a lot for any suggestion.
EDIT
I was able to retrieve via FTP the EAR in InstalledApps of Production environment. I noted a file named "web_merged.xml" in which is missing the entry of the filter.
Maybe the problem is here? When is created and why? Why could be missing the entry there? How let WAS to create the right file (if the problem is there)?

The problem was the one on the EDIT in the question, webmerged.xml was wrong. We weren't able to understand why WAS generated this file in wrong way.
What I understand is generated during deploy and is a mix of web.xml of the applicatin with application server configuration.
That's a WebSphere issue, we guessed it has to do with application server cache. We asked to System Administrator to:
Uninstall the application
Stop the server in which the application was installed
Clear the cache
Restart the server
Reinstall application
From this point the file was generated in the right manner, as the application bahaviour.
Websphere version is 8.5

AWS Elastic Beanstalk "Impaired services on all instances."

I have a spring service that I'm trying to load load into AWS Beanstalk. When i create the environment and upload my .war file it just stays stuck on degraded. When i look through the logs for errors i cannot see any errors. Also when try and connect to my url, for example http://something.us-east-1.elasticbeanstalk.com/, i get a 502 error. I've already looked at the documentation provided by amazon that states the red degraded message means that all/most of the requests to you page are failing. Any idea how i can find the issue? See the screenshot below for the Enhanced Health Overview.

So, it turned out that i was getting an error in my logs but i was not able to see them. I had to ignore all of the eb-something log files. I needed to be looking at the web-1.log. This file may be named different depending on your instance and your environment but this is where i could actually see my error.

people who are finding their actual log can look up for this section in their EB log file.
/var/log/web.stdout.log

I had the same problem, with "Impaired services on all instances."
As suggested above, I ssh'd into the elastic beanstalk instance and looked at /var/log/web.stdout.log.
As I found there, my problem was that I was following a django tutorial and created a django config file with the WSGIPath pointing to the project name that was in the tutorial, but my actual project had a different name.
I corrected the mistake, wiped the elastic beanstalk instance and set up the environment again from scratch.
No problems at all this time, everything turned green immediately.

SEVERE: SAAJ0537: Invalid Content-Type. Could be an error message instead of a SOAP message

I want to run a java application which calls a web service. Everything works fine from the netbeans ide, but fails when I run the .jar generated. What could be the problem?
How can I check the content type that the error is pointing at?
the error says: "SEVERE: SAAJ0537: Invalid Content-Type. Could be an error message instead of a SOAP message. com.sun.xml.messaging.saaj.MessageImpl identifyContentType"
EDIT
I am realizing that the problem could be originated by the fact that the web service that Im consuming uses a custom data type, but I have no idea where to look.
Please help

Your question lacks the details that would help identify your problem (like, what web container are you using, some source code, etc) but I've encountered and resolved this same problem. I'm using Tomcat with Eclipse and apparently, the problem occurs because for some reason, Tomcat can't find some JARs even though I have specified them in my build path. The resolution is to put the JARs in the actual lib directory of Tomcat instead of in some project-specific location. (See this same case with log4j.)
What happens is this missing JAR causes the servlet to produce an internal server error when called. Tomcat generates an error page---which is of type "text/html"---and sends it back to client. So, client reads "text/html" instead of the expected "text/xml".
For a test this SOAP tutorial produces the specified error due to jaxm-api.jar but can be fixed with the solution I described above. I have verified this with Tomcat 7.
How can I check the content type that the error is pointing at?
A bit difficult to answer without some code. But if you are using javax.xml.soap.SOAPPart, it has methods to check the headers of the SOAP transaction. Check the javadocs. Shame it does not override toString(). But personally, I did not arrive at this answer with Java debug methods but via looking at TCP dumps.

GlassFish: email log handler

We need to send mail from a log handler in GlassFish v3.1.2.2.
We've tried to use smtphandler-0.6 and -0.7 with limited success. We install the jarfile to domain/lib/ext, and configure smtphandler's properties in domain/config/logging.properties. We've tried two ways of satisfying smtphandler's reliance on mail imports: 1) Editing its manifest classpath to point to ../../../../modules/javax.mail.jar, and 2) Putting javax.mail.jar in domain/lib/ext alongside the smtphandler jar. (We prefer the former approach so that the same javamail classes are used throughout the system. But it seems to make no difference, no worky either way.)
With either of these arrangements the behavior is the same:
The handler loads ok as shown by the JVM's verbose:class output.
Sometimes it sends mail for errors and warnings that occur during domain startup (like the expired certificate). Other times it fails as described below before ever sending mail.
It always fails once we've deployed our application and logged some application errors. We can tell that the handler is invoked - that's evidenced by the debugger and some primitive System.out "logging".
The root problem is a NoSuchMethodException: com.sun.mail.smtp.SMTPTransport.[init](Session, URLName). The failure to find the c'tor means the transport object can't be created; that eventually manifests as a NoSuchProtocolException.
We can see that the SMTPTransport class is loaded and that it has the requested c'tor. Our best theory is that class loading is somehow involved, but we've not been able to figure out exactly how. (Yet. We're working that angle now.)
Questions:
Are we deploying the handler to the correct location (domain/lib/ext) ?
Why does it (sometimes) send mail during an (empty, no apps) domain startup, but fail for logs emitted by our application? That's a race condition, surely, but what are those threads doing that occasionally works for a bit then reliably fails?
Are we right to think that all these indications together imply a class loading issue?
We've reproduced these symptoms on GlassFish versions 3.1.2.2 and 4, with JavaMail 1.4.4 and 1.5.
Thanks in advance for any help.

Looks like a bug was reported for this NoSuchMethodException when attempting to install log handler in GlassFish server. This issue was raised with the JavaMail team under Bug K6668 | GH144 - skip unusable Store and Transport classes which is fixed in JavaMail 1.5.3. Upgrading the JavaMail module in glassfish and all other copies deployed should correct the issue. It is also helpful to start glassfish with "glassfish/bin/asadmin start-domain -v" so you can see all bootstrapping messages.
•Are we deploying the handler to the correct location (domain/lib/ext)
Yes. You can deploy to domain/lib/ext but you have to include JavaMail 1.5.3 so you find the correct transport service. Otherwise, you can deploy the jar to the modules dir and add the HK2 metadata to make the smtphandler look like a service. This can be done by including new jar or modifying the existing smtphandler jar.
For GlassFish 3, the file META-INF/inhabitants/default must be added containing the following:
class=smtphandler.SMTPHandler,index=java.util.logging.Handler
For GlassFish 4, the file META-INF/hk2-locator/default must be added containing the following:
[smtphandler.SMTPHandler]
contract={java.util.logging.Handler}
scope=javax.inject.Singleton
The jar then has to be placed in the glassfish/modules folder along with upgrading javax.mail.jar.
Another option is to subclass smtphandler to look like a HK2 log handler service and add a preDestroy method to trigger the email on shutdown. This is described in the Oracle GlassFish Server 3.1 Administration Guide Part I section 7 titled Adding a Custom Logging Handler.
Under GlassFish 4 there are two different ways to locate a handler in the logging.properties. Handlers placed in domain/lib/ext use the standard handlers key in the properties file. Handlers placed in the glassfish/modules as a HK2 Service are loaded using the handlerServices key in the properties file.
#GF3 ext/endorsed or OSGI. GF4 ext/endorsed only.
handlers=smtphandler.SMTPHandler
#GF4 OSGI only, 'handlerServices' should not contain any whitespace characters between handlers.
handlerServices=com.sun.enterprise.server.logging.GFFileHandler,smtphandler.SMTPHandler
•Why does it (sometimes) send mail during an (empty, no apps) domain startup, but fail for logs emitted by our application? That's a race condition, surely, but what are those threads doing that occasionally works for a bit then reliably fails?
Difference in context class loader between messages logged by GF vs your web app. The CCL is used in JavaMail to locate the transport. Patching the 'sendBuffer' method should fix the behavior:
#Override
protected void sendBuffer() {
final Thread thread = Thread.currentThread();
ClassLoader ccl = null;
try {
ccl = thread.getContextClassLoader();
thread.setContextClassLoader(
javax.mail.Transport.class.getClassLoader());
} catch (SecurityException ignore) {
}
try {
super.sendBuffer();
} finally {
try {
thread.getContextClassLoader();
thread.setContextClassLoader(ccl);
} catch (SecurityException ignore) {
}
}
}
•Are we right to think that all these indications together imply a class loading issue?
Yes. The only way to really make this work right is to subclass or patch the smtphandler to look like an HK2 component and modify the CCL.
We need to send mail from a log handler in GlassFish v3.1.2.2.
We've tried to use smtphandler-0.6 and -0.7 with limited success.
Disclaimer: I'm a content developer for MailHandler included with JavaMail project.
An alternative to the smtphandler is the com.sun.mail.util.logging.MailHandler included with the JavaMail reference implementation.
Under GlassFish 4 you have to have glassfish/modules/javax.mail.jar that is JavaMail 1.5.3 or newer. An updated version can be downloaded from the JavaMail API homepage and can be used to replace the version bundled with GlassFish.
Next you have to modify the logging.properties for the domain. Here is a sample configuration you can include to get you started.
#Ensure no whitespace between handler class names.
handlerServices=com.sun.enterprise.server.logging.GFFileHandler,com.sun.mail.util.logging.MailHandler
com.sun.mail.util.logging.MailHandler.subject=com.sun.mail.util.logging.CollectorFormatter
#com.sun.mail.util.logging.CollectorFormatter.format=GlassFish 4.x:{0}{1}{2}{4,choice,-1#|0#|0<... {4,number,integer} more}
#com.sun.mail.util.logging.CompactFormatter.format=[%4$-7.7s] %7$#.140s
com.sun.mail.util.logging.MailHandler.level=WARNING
com.sun.mail.util.logging.MailHandler.filter=com.sun.mail.util.logging.DurationFilter
com.sun.mail.util.logging.MailHandler.pushLevel=WARNING
com.sun.mail.util.logging.MailHandler.mail.smtp.host=some-smtp-host
#com.sun.mail.util.logging.MailHandler.mail.user=some-user
#com.sun.mail.util.logging.MailHandler.authenticator=some-password
com.sun.mail.util.logging.MailHandler.mail.from=app#server.com
#com.sun.mail.util.logging.MailHandler.mail.sender=team#list.com
com.sun.mail.util.logging.MailHandler.mail.to=devs#bugfixers.com
com.sun.mail.util.logging.MailHandler.verify=resolve
com.sun.mail.util.logging.MailHandler.mail.smtp.quitwait=false
com.sun.mail.util.logging.MailHandler.mail.smtps.quitwait=false
com.sun.mail.util.logging.MailHandler.mail.smtp.connectiontimeout=45000
com.sun.mail.util.logging.MailHandler.mail.smtps.connectiontimeout=45000
com.sun.mail.util.logging.MailHandler.mail.smtp.timeout=45000
com.sun.mail.util.logging.MailHandler.mail.smtps.timeout=45000
For GlassFish 3 you have to install JavaMail (javax.mail.jar) under the domain/lib/ext or glassfish/lib/endorsed and test that this doesn't break any of your applications. This classloader configuration also works under GlassFish 4 and allows combining the MailHandler with MemoryHandler which can emulate the behavior of the smtphandler.
Next you have to modify the logging.properties for the domain. You can use the same sample as the GlassFish 4 except that you have to use the standard handlers tag instead of the handlerServices.
handlers=java.util.logging.MemoryHandler
java.util.logging.MemoryHandler.target=com.sun.mail.util.logging.MailHandler
java.util.logging.MemoryHandler.size=512
java.util.logging.MemoryHandler.level=INFO
java.util.logging.MemoryHandler.push=WARNING
com.sun.mail.util.logging.MailHandler.capacity=512
com.sun.mail.util.logging.MailHandler.level=INFO
com.sun.mail.util.logging.MailHandler.pushLevel=WARNING
com.sun.mail.util.logging.MailHandler.filter=com.sun.mail.util.logging.DurationFilter
com.sun.mail.util.logging.DurationFilter.records=512
com.sun.mail.util.logging.DurationFilter.duration=5*60*1000

Is there any attribute or option available in weblogic to restrict number of servlets?

I'm working on java project, which is using weblogic 10 as an application server. In this project there are around 11 servlets added in web.xml descriptor with url mapping. Whenever i'm adding new servlet, its not getting mapped to the url as wel as not getting invoked. What may be the problem. As, if I add the same logic in any of the existing servlet, its working fine.
Thanks in advance.

How is the question in the title of your post going to help you solve this problem?
Maybe you have another servlet that maps to the same URL pattern, or you have ambiguous URL patterns for your new servlet and already existing servlets (so that WebLogic doesn't know which one to call). Check the servlet mappings in your web.xml file.
Check the WebLogic management console to see if your servlet is deployed successfully, and check the logs of WebLogic for any deployment errors. Carefully read the error messages to find out what's wrong. If you don't understand them, add them to your post above, so that someone here can explain you what they mean.
If you go to an URL that's supposed to map to your servlet, then what do you get? An error message, or is it going to another servlet? If it's an error, then again, post the error message.