Good afternoon,
When I attempt to use the SMTP Appender, I get an odd error in the console. The error appears to occur when the XML file is loaded, as it isn't logged via any output stream except stdout. The contents of the appender are as follows (and I have confirmed that the error is in this block of XML). I've removed our server information.
<SMTP name="Mailer">
<Subject>[ERROR] (software name) on ${hostName} has thrown a fatal error</Subject>
<To>(a valid email in the form of a#a.com)</To>
<From>(a valid email in the form of a#a.com)</From>
<SMTPHost>(The Internal IP address of a server in the form of 192.168.0.1)</SMTPHost>
<SMTPPort>587</SMTPPort>
<BufferSize>512</BufferSize>
</SMTP>
Whether or not it is referenced in a logger, I receive the following error immediately upon running the program and running getLogger from the log manager. I've removed a couple of the file names and replaced them with a rough description of what the file is doing at that point.
2015-05-19 19:08:18,812 ERROR Unable to invoke factory method in class class org.apache.logging.log4j.core.appender.SmtpAppender for element SMTP. java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:137)
at org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:766)
at org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:706)
at org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:698)
at org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:358)
at org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:161)
at org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:361)
at org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:426)
at org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:442)
at org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:138)
at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:147)
at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:41)
at org.apache.logging.log4j.LogManager.getContext(LogManager.java:175)
at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:426)
at (Our Log Interface Class, which essentially just returns the log passed by the Apache log manager)
at (The global variable definition file, the first method to use getLogger)
at (The main method for our software, where the globals are loaded)
Caused by: java.lang.NoSuchMethodError: javax.mail.Session.setProtocolForAddress(Ljava/lang/String;Ljava/lang/String;)V
at org.apache.logging.log4j.core.net.SmtpManager$SMTPManagerFactory.createManager(SmtpManager.java:325)
at org.apache.logging.log4j.core.net.SmtpManager$SMTPManagerFactory.createManager(SmtpManager.java:299)
at org.apache.logging.log4j.core.appender.AbstractManager.getManager(AbstractManager.java:71)
at org.apache.logging.log4j.core.net.SmtpManager.getSMTPManager(SmtpManager.java:124)
at org.apache.logging.log4j.core.appender.SmtpAppender.createAppender(SmtpAppender.java:142)
... 21 more
2015-05-19 19:08:18,814 ERROR Null object returned for SMTP in Appenders.
2015-05-19 19:08:18,819 ERROR Unable to locate appender Mailer for logger fatalerror
The details of the configuration are correct (I know it's a valid IP, etc) - they worked in log4j 1. The error log tells me virtually nothing about the error, so I am hoping someone has heard of this before. Thanks everyone!
This is the important line from your stacktrace:
Caused by: java.lang.NoSuchMethodError: javax.mail.Session.setProtocolForAddress(Ljava/lang/String;Ljava/lang/String;)V
The setProtocolForAddress method has been part of JavaMail since version 1.4, so this suggests to me that you are using an old version of that JAR. If you are, try upgrading to a later version.
Note that log4j2 has many lookups, not just system properties. So you need to convert ${hostName} to ${sys:hostName}, and if you are using a lookup for the IP address, this may be the cause of the issue. (Try hardcoding all lookup values to exclude this possibility.)
Related
Hello I'm trying to figure out correct dependencies between org.mongodb:mongodb-driver-sync and org.springframework.data:spring-data-mongodb while using Mongo 4.4.6 database. Still getting:
2021-11-15 17:13:18,112 pool-9-thread-1 ERROR An exception occurred processing Appender console org.bson.BsonSerializationException: Detected unknown BSON type "\x73" for fieldname "tBatch". Are you using the latest driver version?
at org.bson.BsonBinaryReader.readBsonType(BsonBinaryReader.java:95)
at org.bson.codecs.BsonDocumentCodec.decode(BsonDocumentCodec.java:82)
at com.mongodb.internal.connection.ByteBufBsonDocument.toBsonDocument(ByteBufBsonDocument.java:158)
at com.mongodb.internal.connection.AbstractByteBufBsonDocument.entrySet(AbstractByteBufBsonDocument.java:100)
at org.apache.logging.log4j.message.ParameterFormatter.appendMap(ParameterFormatter.java:562)
at org.apache.logging.log4j.message.ParameterFormatter.appendPotentiallyRecursiveValue(ParameterFormatter.java:498)
at org.apache.logging.log4j.message.ParameterFormatter.recursiveDeepToString(ParameterFormatter.java:456)
at org.apache.logging.log4j.message.ParameterFormatter.formatMessage2(ParameterFormatter.java:189)
at org.apache.logging.log4j.message.ParameterizedMessage.formatTo(ParameterizedMessage.java:228)
at org.apache.logging.log4j.core.pattern.MessagePatternConverter.format(MessagePatternConverter.java:123)
at org.apache.logging.log4j.core.pattern.PatternFormatter.format(PatternFormatter.java:38)
at org.apache.logging.log4j.core.layout.PatternLayout$PatternSerializer.toSerializable(PatternLayout.java:345)
at org.apache.logging.log4j.core.layout.PatternLayout.toText(PatternLayout.java:244)
at org.apache.logging.log4j.core.layout.PatternLayout.encode(PatternLayout.java:229)
at org.apache.logging.log4j.core.layout.PatternLayout.encode(PatternLayout.java:59)
at org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.directEncodeEvent(AbstractOutputStreamAppender.java:197)
at org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.tryAppend(AbstractOutputStreamAppender.java:190)
at org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.append(AbstractOutputStreamAppender.java:181)
at org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
at org.apache.logging.log4j.core.config.AppenderControl.callAppender0(AppenderControl.java:129)
at org.apache.logging.log4j.core.config.AppenderControl.callAppenderPreventRecursion(AppenderControl.java:120)
at org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:84)
at org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:543)
at org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:502)
at org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:485)
at org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:460)
at org.apache.logging.log4j.core.config.AwaitCompletionReliabilityStrategy.log(AwaitCompletionReliabilityStrategy.java:82)
at org.apache.logging.log4j.core.Logger.log(Logger.java:161)
at org.apache.logging.log4j.spi.AbstractLogger.tryLogMessage(AbstractLogger.java:2198)
at org.apache.logging.log4j.spi.AbstractLogger.logMessageTrackRecursion(AbstractLogger.java:2152)
at org.apache.logging.log4j.spi.AbstractLogger.logMessageSafely(AbstractLogger.java:2135)
at org.apache.logging.log4j.spi.AbstractLogger.logMessage(AbstractLogger.java:2058)
at org.apache.logging.log4j.spi.AbstractLogger.logIfEnabled(AbstractLogger.java:1939)
at org.apache.logging.log4j.spi.AbstractLogger.debug(AbstractLogger.java:480)
at com.mongodb.internal.connection.ProtocolHelper.sendCommandSucceededEvent(ProtocolHelper.java:289)
at com.mongodb.internal.connection.LoggingCommandEventSender.sendSucceededEvent(LoggingCommandEventSender.java:142)
at com.mongodb.internal.connection.InternalStreamConnection.receiveCommandMessageResponse(InternalStreamConnection.java:306)
at com.mongodb.internal.connection.InternalStreamConnection.sendAndReceive(InternalStreamConnection.java:258)
at com.mongodb.internal.connection.UsageTrackingInternalConnection.sendAndReceive(UsageTrackingInternalConnection.java:99)
at com.mongodb.internal.connection.DefaultConnectionPool$PooledConnection.sendAndReceive(DefaultConnectionPool.java:500)
at com.mongodb.internal.connection.CommandProtocolImpl.execute(CommandProtocolImpl.java:71)
at com.mongodb.internal.connection.DefaultServer$DefaultServerProtocolExecutor.execute(DefaultServer.java:224)
at com.mongodb.internal.connection.DefaultServerConnection.executeProtocol(DefaultServerConnection.java:202)
at com.mongodb.internal.connection.DefaultServerConnection.command(DefaultServerConnection.java:118)
at com.mongodb.internal.connection.DefaultServerConnection.command(DefaultServerConnection.java:110)
at com.mongodb.internal.operation.CommandOperationHelper.executeCommand(CommandOperationHelper.java:343)
at com.mongodb.internal.operation.CommandOperationHelper.executeCommand(CommandOperationHelper.java:334)
at com.mongodb.internal.operation.CommandOperationHelper.executeCommandWithConnection(CommandOperationHelper.java:220)
at com.mongodb.internal.operation.FindOperation$1.call(FindOperation.java:631)
at com.mongodb.internal.operation.FindOperation$1.call(FindOperation.java:625)
at com.mongodb.internal.operation.OperationHelper.withReadConnectionSource(OperationHelper.java:462)
at com.mongodb.internal.operation.FindOperation.execute(FindOperation.java:625)
at com.mongodb.internal.operation.FindOperation.execute(FindOperation.java:77)
at com.mongodb.client.internal.MongoClientDelegate$DelegateOperationExecutor.execute(MongoClientDelegate.java:190)
at com.mongodb.client.internal.MongoIterableImpl.execute(MongoIterableImpl.java:135)
at com.mongodb.client.internal.MongoIterableImpl.iterator(MongoIterableImpl.java:92)
at org.springframework.data.mongodb.core.MongoTemplate.executeFindMultiInternal(MongoTemplate.java:2771)
at org.springframework.data.mongodb.core.MongoTemplate.doFind(MongoTemplate.java:2507)
at org.springframework.data.mongodb.core.MongoTemplate.doFind(MongoTemplate.java:2489)
at org.springframework.data.mongodb.core.MongoTemplate.find(MongoTemplate.java:856)
at org.springframework.data.mongodb.core.MongoTemplate.find(MongoTemplate.java:842)
Strange thing is that query is successfully executed, then response is passed to CommandListener and there, during logging it throws exception.
Could someone point me in right direction?
I have fixed it by using BsonDocument.clone() in commandStarted in CommandListener implementation. The problem was that during executing command, buffer position is modified, so we cannot rely on it later within commandSucceeded
A few minutes after initiating Karaf, I always receive this error. Cant figure out what the impact of this is or how to fix it:
opendaylight-user#root>Exception in thread "config-pusher" java.lang.SecurityException: Insufficient roles/credentials for operation
at org.apache.karaf.management.KarafMBeanServerGuard.handleInvoke(KarafMBeanServerGuard.java:289)
at org.apache.karaf.management.KarafMBeanServerGuard.invoke(KarafMBeanServerGuard.java:85)
at org.apache.karaf.management.boot.KarafMBeanServerBuilder$MBeanInvocationHandler.invoke(KarafMBeanServerBuilder.java:63)
at com.sun.proxy.$Proxy0.invoke(Unknown Source)
at com.sun.jmx.mbeanserver.MXBeanProxy$InvokeHandler.invoke(MXBeanProxy.java:150)
at com.sun.jmx.mbeanserver.MXBeanProxy.invoke(MXBeanProxy.java:167)
at javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:258)
at com.sun.proxy.$Proxy16.beginConfig(Unknown Source)
at org.opendaylight.controller.config.util.ConfigRegistryJMXClient.beginConfig(ConfigRegistryJMXClient.java:96)
at org.opendaylight.controller.netconf.confignetconfconnector.transactions.TransactionProvider.getTestTransaction(TransactionProvider.java:120)
at org.opendaylight.controller.netconf.confignetconfconnector.operations.editconfig.EditConfig.test(EditConfig.java:109)
at org.opendaylight.controller.netconf.confignetconfconnector.operations.editconfig.EditConfig.executeTests(EditConfig.java:96)
at org.opendaylight.controller.netconf.confignetconfconnector.operations.editconfig.EditConfig.getResponseInternal(EditConfig.java:75)
at org.opendaylight.controller.netconf.confignetconfconnector.operations.editconfig.EditConfig.handleWithNoSubsequentOperations(EditConfig.java:308)
at org.opendaylight.controller.netconf.util.mapping.AbstractLastNetconfOperation.handle(AbstractLastNetconfOperation.java:33)
at org.opendaylight.controller.netconf.util.mapping.AbstractNetconfOperation.handle(AbstractNetconfOperation.java:100)
at org.opendaylight.controller.netconf.persist.impl.ConfigPusherImpl.sendRequestGetResponseCheckIsOK(ConfigPusherImpl.java:342)
at org.opendaylight.controller.netconf.persist.impl.ConfigPusherImpl.pushConfig(ConfigPusherImpl.java:293)
at org.opendaylight.controller.netconf.persist.impl.ConfigPusherImpl.pushConfigWithConflictingVersionRetries(ConfigPusherImpl.java:135)
at org.opendaylight.controller.netconf.persist.impl.ConfigPusherImpl.internalPushConfigs(ConfigPusherImpl.java:103)
at org.opendaylight.controller.netconf.persist.impl.ConfigPusherImpl.process(ConfigPusherImpl.java:76)
at org.opendaylight.controller.netconf.persist.impl.osgi.ConfigPersisterActivator$InnerCustomizer$1.run(ConfigPersisterActivator.java:181)
at java.lang.Thread.run(Thread.java:745)
Has any one else experienced this or know how to fix it?
Karaf 3.0.1 has a known JMX bug that should be fixed in 3.0.2… if you don’t get your bin/karaf from "controller/opendaylight/distributions/opendaylight-karaf-resources" you will get this exception.
Edit this file:
karaf/target/assembly/system/org/opendaylight/controller/karaf-parent/1.5.3-SNAPSHOT/karaf-parent-1.5.3-SNAPSHOT.pom
And set ignorePermissions tag true.
References:
https://lists.opendaylight.org/pipermail/controller-dev/2014-September/006551.html
https://lists.opendaylight.org/pipermail/controller-dev/2014-September/006552.html
Using Lotus Domino 8.5.2 Fixpack 3
The title sums it up. I have an xpages application that uses java. It seems that any java changes I make, never become visible on the server. It sounds a dead ringer for a cache issue of some kind. The application runs on the server and I see System.out.println statements in the server log, but do not any of the changes I've made to those statements or any new ones I've added.
The code is set to Rebuild Automatically. Still, it never looks like the server sees the changes. Is there some special way I need to build the database (aside from the typical Rebuild All)? Do I need to reset or restart some process on the domino server for it to see the changes?
Any thoughts or ideas would be greatly appreciated.
EDIT 1
I'm returning to this project and, hence, this question. The specific error message I'm getting is:
[6815810:00012-05659] 03/19/2013 09:27:01 HTTP JVM: Managedbean Calendar could not be created Can't instantiate class: 'calendar.CalendarServices'.. java.lang.ClassNotFoundException: class java.lang.ClassNotFoundException: calendar.CalendarServices. For more detailed inform
ation, please consult error-log-0
[6815810:00012-05659] 03/19/2013 09:27:01 HTTP JVM: xml located in /local/notesdata/domino/workspace/logs
[6815810:00012-05659] 03/19/2013 09:27:01 HTTP JVM: com.ibm.xsp.exception.EvaluationExceptionEx: Error while executing JavaScript action expression
I've tried unchecking automatic build and doing a clean --> rebuild all. I've tried signing the nsf again. I've ensured that I'm on the acl. And, as recommended, I've tried the
restart task http
Command via live console. No matter what I do I'm getting this error. The odd thing is that this project is just a copy --> paste (with rename) of another one that works fine. So, the project works...until I change and recompile...
The log that exception above points to wasn't very helpful. It reads:
<CommonBaseEvent creationTime="2013-03-05T09:01:03.254-06:00" globalInstanceId="EL0a04a8b800013d3af27da200000008" msg="Managedbean Calendar could not be created Can't instantiate class: 'calendar.CalendarServices'.. java.lang.ClassNotFoundException: class java.lang.ClassNotFoundException: calendar.CalendarServices" severity="50" version="1.0.1">
<extendedDataElements name="CommonBaseEventLogRecord:level" type="noValue">
<children name="CommonBaseEventLogRecord:name" type="string">
<values>SEVERE</values>
</children>
</extendedDataElements>
<extendedDataElements name="CommonBaseEventLogRecord:sourceClassName" type="string">
<values>com.sun.faces.application.ApplicationAssociate</values>
</extendedDataElements>
<extendedDataElements name="CommonBaseEventLogRecord:sourceMethodName" type="string">
<values>createAndMaybeStoreManagedBeans</values>
</extendedDataElements>
<extendedDataElements name="CommonBaseEventLogRecord:Exception" type="string">
<values>javax.faces.FacesException: Can't instantiate class: 'calendar.CalendarServices'.. java.lang.ClassNotFoundException: class java.lang.ClassNotFoundException: calendar.CalendarServices
at com.sun.faces.config.ManagedBeanFactory.newInstance(ManagedBeanFactory.java:234)
at com.sun.faces.application.ApplicationAssociate.createAndMaybeStoreManagedBeans(ApplicationAssociate.java:291)
at com.sun.faces.el.VariableResolverImpl.resolveVariable(VariableResolverImpl.java:135)
at com.ibm.xsp.el.VariableResolverImpl.resolveVariable(VariableResolverImpl.java:71)
at com.ibm.xsp.javascript.ServerSideLocalObject.resolveVariable(ServerSideLocalObject.java:97)
at com.ibm.xsp.javascript.ServerSideLocalObject.resolveAttribute(ServerSideLocalObject.java:73)
at com.ibm.xsp.javascript.AbstractLocalObject._get(AbstractLocalObject.java:119)
at com.ibm.xsp.javascript.AbstractLocalObject.getPropertyReference(AbstractLocalObject.java:101)
at com</values>
<values>.ibm.jscript.engine.ProgramContext.findGlobalScopeIdentifier(ProgramContext.java:143)
at com.ibm.jscript.engine.ProgramContext.findIdentifier(ProgramContext.java:134)
at com.ibm.jscript.ASTTree.ASTIdentifier.interpret(ASTIdentifier.java:105)
at com.ibm.jscript.ASTTree.ASTMember.interpret(ASTMember.java:106)
at com.ibm.jscript.ASTTree.ASTCall.interpret(ASTCall.java:88)
at com.ibm.jscript.ASTTree.ASTArgumentList.interpretArguments(ASTArgumentList.java:63)
at com.ibm.jscript.types.FBSObject.call(FBSObject.java:153)
at com.ibm.jscript.ASTTree.ASTCall.interpret(ASTCall.java:175)
at com.ibm.jscript.ASTTree.ASTIf.interpret(ASTIf.java:85)
at com.ibm.jscript.ASTTree.ASTTry.interpret(ASTTry.java:109)
at com.ibm.jscript.ASTTree.ASTProgram.interpret(ASTProgram.java:119)
at com.ibm.jscript.ASTTree.ASTProgram.interpretEx(ASTProgram.java:139)
at com.ibm.jscript.JSExpression._interpretExpression(JSExpression.java:435)</values>
<values>
at com.ibm.jscript.JSExpression.access$1(JSExpression.java:424)
at com.ibm.jscript.JSExpression$2.run(JSExpression.java:414)
at java.security.AccessController.doPrivileged(AccessController.java:284)
at com.ibm.jscript.JSExpression.interpretExpression(JSExpression.java:410)
at com.ibm.jscript.JSExpression.evaluateValue(JSExpression.java:251)
at com.ibm.jscript.JSExpression.evaluateValue(JSExpression.java:234)
at com.ibm.xsp.javascript.JavaScriptInterpreter.interpret(JavaScriptInterpreter.java:220)
at com.ibm.xsp.binding.javascript.JavaScriptMethodBinding.invoke(JavaScriptMethodBinding.java:111)
at com.ibm.xsp.component.UIViewRootEx.invokePhaseMethodBinding(UIViewRootEx.java:1705)
at com.ibm.xsp.controller.FacesControllerImpl.invokePhaseMethodBinding(FacesControllerImpl.java:444)
at com.ibm.xsp.controller.FacesControllerImpl.access$0(FacesControllerImpl.java:438)
at com.ibm.xsp.controller.FacesControllerImpl$</values>
<values>ViewPhaseListener.afterPhase(FacesControllerImpl.java:506)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:218)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:120)
at com.ibm.xsp.controller.FacesControllerImpl.render(FacesControllerImpl.java:264)
at com.ibm.xsp.webapp.FacesServlet.serviceView(FacesServlet.java:219)
at com.ibm.xsp.webapp.FacesServletEx.serviceView(FacesServletEx.java:193)
at com.ibm.xsp.webapp.FacesServlet.service(FacesServlet.java:154)
at com.ibm.xsp.webapp.FacesServletEx.service(FacesServletEx.java:137)
at com.ibm.xsp.webapp.DesignerFacesServlet.service(DesignerFacesServlet.java:86)
at com.ibm.designer.runtime.domino.adapter.ComponentModule.invokeServlet(ComponentModule.java:538)
at com.ibm.domino.xsp.module.nsf.NSFComponentModule.invokeServlet(NSFComponentModule.java:1151)
at com.ibm.designer.runtime.domino.adapter.ComponentModule$AdapterInvoker.invokeServl</values>
<values>et(ComponentModule.java:803)
at com.ibm.designer.runtime.domino.adapter.ComponentModule$ServletInvoker.doService(ComponentModule.java:758)
at com.ibm.designer.runtime.domino.adapter.ComponentModule.doService(ComponentModule.java:527)
at com.ibm.domino.xsp.module.nsf.NSFComponentModule.doService(NSFComponentModule.java:1135)
at com.ibm.domino.xsp.module.nsf.NSFService.doServiceInternal(NSFService.java:523)
at com.ibm.domino.xsp.module.nsf.NSFService.doService(NSFService.java:352)
at com.ibm.designer.runtime.domino.adapter.LCDEnvironment.doService(LCDEnvironment.java:304)
at com.ibm.designer.runtime.domino.adapter.LCDEnvironment.service(LCDEnvironment.java:261)
at com.ibm.domino.xsp.bridge.http.engine.XspCmdManager.service(XspCmdManager.java:291)
Caused by: java.security.PrivilegedActionException: java.lang.ClassNotFoundException: class java.lang.ClassNotFoundException: calendar.CalendarServices
at java.security.AccessController</values>
<values>.doPrivileged(AccessController.java:255)
at com.sun.faces.config.ManagedBeanFactory.newInstance(ManagedBeanFactory.java:216)
... 51 more
Caused by: java.lang.ClassNotFoundException: class java.lang.ClassNotFoundException: calendar.CalendarServices
at java.beans.Beans.instantiate(Beans.java:194)
at java.beans.Beans.instantiate(Beans.java:75)
at com.sun.faces.config.ManagedBeanFactory$1.run(ManagedBeanFactory.java:222)
at java.security.AccessController.doPrivileged(AccessController.java:251)
... 52 more
</values>
</extendedDataElements>
<sourceComponentId component="Expeditor 6.2" componentIdType="ProductName" instanceId="" location="<server here>" locationType="Hostname" subComponent="com.sun.faces.application.ApplicationImpl" threadId="0" componentType="http://www.w3.org/2001/XMLSchema-instance"/>
<situation categoryName="ReportSituation">
<situationType xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ReportSituation" reasoningScope="INTERNAL" reportCategory="LOG"/>
</situation>
</CommonBaseEvent>
As ever, penny for your thoughts.
Also, thank you all for your feedback. I'm sorry I've been away for a bit and neglected this question. I really would like to figure this out.
You didn't mention Project -> Clean so try that first.
I had once similar problem that was caused by an underscore in class or package name.
If the problem exists also for XPages then it's a a general build problem. This can occur at least when developers with different Designer and/or ExtLib versions modify the application. When I had this problem the only way to fix it was to create a new application and copy paste everything there. In our case the other developer never had the problem.
This is just silly. My src folder wasn't on the build path. That was causing all the issues.
I am basically walking the LDAP tree in Active Directory.
At each level I query for "(objectClass=*)". When I do this on the root eg "dc=example,dc=com" I get the exception below. This works fine on our other LDAP instances. For some reason only on our Active Directory server I get this exception. I also get the same exception when using JXplorer on our Active Directory server.
From reading around online I found people saying you should turn on following, not sure what that means... So on my controls object (javax.naming.directory.SearchControls) that I pass with the query I call searchControls.setDerefLinkFlag(true). I also have tried setting it to false with the same result. Any a suggestions on what else could cause this? Maybe how I could fix it?
Note: In this post I changed the baseDn from dc=<my company domain> to example for my companies privacy.
javax.naming.PartialResultException: Unprocessed Continuation Reference(s); remaining name 'dc=example,dc=com'
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2820)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2794)
at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1826)
at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1749)
at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:368)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:338)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:321)
at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:248)
at com.motio.pi.gui.panels.useraccess.ldap.LDAPConnector.query(LDAPConnector.java:262)
at com.motio.pi.gui.selector.directory.CognosDirectoryBrowserController.expandCognosTreeNode(CognosDirectoryBrowserController.java:99)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.motio.pi.utils.PIThreadDelegate$1.run(PIThreadDelegate.java:54)
at java.lang.Thread.run(Thread.java:662)
So when I was creating my naming context with the method:
javax.naming.ldap.InitialLdapContext.InitialLdapContext(
Hashtable<?, ?> environment, Control[] connCtls)
In the argument environment there is a property with the name Context.REFERRAL and its value should be set to: follow. This was the setting that I needed.
If you get an exception while referral usage in follow (for example: connection timed out) you can use referral ignore but you dont want to get partial exception you can use 3268 port number instead of 389 this port is using global catalog for ldap. You can find info from following link;
https://technet.microsoft.com/en-us/library/how-global-catalog-servers-work(v=ws.10).aspx
Background: Hibernate connects to a database using a username and password entered into a GUI. Upon failure, instead of propagating the error up as an exception, it comes out as a stack trace in the logger. I don't know where the exception is being caught at. Also a tiny bit troubling is the following block:
if (reason != null) {
println("getConnection failed: " + reason);
throw reason;
}
My breakpoint is set at the throw line (and successfully triggers), but the println statement never generates output (MySQL is using some sort of logger setup I can't find an open file hand for). Any sort of trick for locating where an exception is caught?
EDIT 1:
I call
sessionFactory = /*AnnotationConfiguration*/ ac.buildSessionFactory();
The exception is caught by Hibernate somewhere between the java.sql.DriverManager class and my HibernateUtil class. I presume we can blame Hibernate deciding that I don't really want to see the exception. I want to convince hibernate to let me see the exception.
EDIT 2:
My stack is this:
java.sql.SQLException: Access denied for user 'user'#'machine' (using password: YES)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1055)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3491)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3423)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:910)
at com.mysql.jdbc.MysqlIO.secureAuth411(MysqlIO.java:3923)
at com.mysql.jdbc.MysqlIO.doHandshake(MysqlIO.java:1273)
at com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2031)
at com.mysql.jdbc.ConnectionImpl.<init>(ConnectionImpl.java:718)
at com.mysql.jdbc.JDBC4Connection.<init>(JDBC4Connection.java:46)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.mysql.jdbc.Util.handleNewInstance(Util.java:406)
at com.mysql.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:302)
at com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:282)
/* Exception is thrown on the next line (1st code block in original post). */
at java.sql.DriverManager.getConnection(DriverManager.java:582)
at java.sql.DriverManager.getConnection(DriverManager.java:154)
/* Begin hidden source calls */
at org.hibernate.connection.DriverManagerConnectionProvider.getConnection(DriverManagerConnectionProvider.java:110)
at org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:84)
at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:2009)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1292)
at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:859)
/* End hidden source calls */
at com.****.****.util.HibernateUtil.initialize(HibernateUtil.java:34)
I can't get the debugger to look at any point above the stack beyond DriverManager.java:582. Everything in the stack beyond that is not visible in the debugger.
First of all, as you mention that there is a logger, you should replace all println statements with log calls.
You can also add further log messages to identify what happens inside the app. Alternatively (or in combination with the above), you can step through the critical code part in the debugger to see where the exception actually happens.
Here's the end result: Line 116 of org.hibernate.cfg.SettingsFactory catches the sql exception and forces it to a log. No configuration is available to change this. It appears I'll be unable to tell my end-user why their connection fails unless I make use of the logs.
Netbeans, for some annoying reason after I gave it the source for Hibernate still wanted to call all of this "hidden source calls." Some time with VIM and reading the line numbers later, I've got it cleared up.
Set a breakpoint for the exception thrown, and when the debugger starts single step to see what happens. You Will probably only need a few steps before the print happens.