I am using our Enterprise's Splunk forawarder which seems to be logging events in splunk like this which makes reading splunk logs a bit difficult.
{"log":"[https-jsse-nio-8443-exec-5] 19 Jan 2021 15:30:57,237+0000 UTC INFO rdt.damien.services.CaseServiceImpl CaseServiceImpl :: showCase :: Case Created \n","stream":"stdout","time":"2021-01-19T15:30:57.24005568Z"}
However, there are different Orgs in our Sibling Enterprise who log splunks thus which is far more readable. (No relation between us and them in tech so not able to leverage their tech support to triage this)
[http-nio-8443-exec-7] 15 Jan 2021 21:08:49,511+0000 INFO DaoOImpl [{applicationSystemCode=dao-app, userId=ANONYMOUS, webAnalyticsCorrelationId=|}]: This is a sample log
Please note the difference in logs (mine vs other):
{"log":"[https-jsse-nio-8443-exec-5]..
vs
[http-nio-8443-exec-7]...
Our Enterprise team is struggling to determine what causes this. I checked my app.log which looks ok (logged using Log4J) and doesn't have the aforementioned {"log" :...} entry.
[https-jsse-nio-8443-exec-5] 19 Jan 2021 15:30:57,237+0000 UTC INFO
rdt.damien.services.CaseServiceImpl CaseServiceImpl:: showCase :: Case
Created
Could someone guide me as to where could the problem/configuration lie that is causing the Splunk Forwarder to send the logs with the {"log":... format to splunk? I thought it was something to do with JSON type vs RAW which I too dont understand if its the cause and if it is - what configs are driving that?
Over the course of investigation - I found that is not SPLUNK thats doing this but rather the docker container. The docker container defaults to json-file that writes the outputs to the /var/lib/docker/containers folder with the **-json postfix which contains the logs in the `{"log" : <EVENT NAME} format.
I need to figure out how to fix the docker logging (aka the docker logging driver) to write in a non-json format.
I'm accessing an Oracle Database from a java application, when I run my application I get the following error:
java.sql.SQLException: ORA-00604: error occurred at recursive SQL level 1
ORA-01882: timezone region not found
You may also try to check the version of the Oracle jdbc driver and Oracle database. Just today I had this issue when using ojdbc6.jar (version 11.2.0.3.0) to connect to an Oracle 9.2.0.4.0 server. Replacing it with ojdbc6.jar version 11.1.0.7.0 solved the issue.
I also managed to make ojdbc6.jar version 11.2.0.3.0 connect without error, by adding oracle.jdbc.timezoneAsRegion=false in file oracle/jdbc/defaultConnectionProperties.properties (inside the jar). Found this solution here (broken link)
Then, one can add -Doracle.jdbc.timezoneAsRegion=false to the command line, or AddVMOption -Doracle.jdbc.timezoneAsRegion=false in config files that use this notation.
You can also do this programmatically, e.g. with System.setProperty.
In some cases you can add the environment variable on a per-connection basis if that's allowed (SQL Developer allows this in the "Advanced" connection properties; I verified it to work when connecting to a database that doesn't have the problem and using a database link to a database which has).
In a plain a SQL-Developer installation under Windows go to directory
C:\Program Files\sqldeveloper\sqldeveloper\bin
and add
AddVMOption -Duser.timezone=CET
to file sqldeveloper.conf.
Error I got :
Error from db_connection.java -->> java.sql.SQLException: ORA-00604: error occurred at recursive SQL level 1
ORA-01882: timezone region not found
ORA-00604: error occurred at recursive SQL level 1ORA-01882: timezone region not found
Prev code:
public Connection getOracle() throws Exception {
Connection conn = null;
Class.forName("oracle.jdbc.driver.OracleDriver");
conn = DriverManager.getConnection("jdbc:oracle:thin:#127.0.0.1:1521:tap", "username", "pw");
return conn;
}
new Code:
public Connection getOracle() throws Exception {
TimeZone timeZone = TimeZone.getTimeZone("Asia/Kolkata");
TimeZone.setDefault(timeZone);
Connection conn = null;
Class.forName("oracle.jdbc.driver.OracleDriver");
conn = DriverManager.getConnection("jdbc:oracle:thin:#127.0.0.1:1521:tap", "username", "pw");
return conn;
}
now it is working!!
Update the file oracle/jdbc/defaultConnectionProperties.properties in whatever version of the library (i.e. inside your jar) you are using to contain the line below:
oracle.jdbc.timezoneAsRegion=false
What happens is, that the JDBC client sends the timezone ID to the Server. The server needs to know that zone. You can check with
SELECT DISTINCT tzname FROM V$TIMEZONE_NAMES where tzname like 'Etc%';
I have some db servers which know about 'Etc/UTC' and 'UTC' (tzfile version 18) but others only know 'UTC' (tz version 11).
SELECT FILENAME,VERSION from V$TIMEZONE_FILE;
There is also different behavior on the JDBC client side. Starting with 11.2 the driver will sent the zone IDs if it is "known" to Oracle, whereas before it sent the time offset. The problem with this "sending of known IDs" is, that the client does not check what timezone version/content is present on the server but has its own list.
This is explained in Oracle Support Article [ID 1068063.1].
It seems it also depends on the Client OS, it was more likely that Etc/UTC fails with Ubuntu than RHEL or Windows. I guess this is due to some normalization but I haven't figured out what exactly.
in eclipse go run - > run configuration
in there go to JRE tab in right side panels
in VM Arguments section paste this
-Duser.timezone=GMT
then Apply - > Run
I had this problem when running automated tests from a continuous integration server. I tried adding the VM argument "-Duser.timezone=GMT" to the build parameters, but that didn't solve the problem. However, adding the environment variable "TZ=GMT" did fix it for me.
I ran into this problem with Tomcat. Setting the following in $CATALINA_BASE/bin/setenv.sh solved the issue:
JAVA_OPTS=-Doracle.jdbc.timezoneAsRegion=false
I'm sure that using one of the Java parameter suggestions from the other answers would work in the same way.
ERROR :
ORA-00604: error occurred at recursive SQL level 1 ORA-01882: timezone region not found
Solution:
CIM setup in Centos.
/opt/oracle/product/ATG/ATG11.2/home/bin/dynamoEnv.sh
Add this java arguments:
JAVA_ARGS="${JAVA_ARGS} -Duser.timezone=EDT"
In Netbeans,
Right-click your project -> Properties
Go to Run (under Categories)
Enter -Duser.timezone=UTC or -Duser.timezone=GMT under VM Options.
Click Ok, then re-run your program.
Note: You can as well set to other timestones besides UTC & GMT.
If this problem is in JDeveloper:
Change the project properties for both the model and the view project -> run/debug -> default profile -> edit
add the following run option:
-Duser.timezone=Asia/Calcutta
Make sure that the above time zone value is fetched from your database as follows:
select TZNAME from V$TIMEZONE_NAMES;
Along with that you'd want to check the time zone settings in your jdev.conf as well as in the JDeveloper -> Application Menu -> Default Project Propertes -> Run/Debug -> Default Profile -> Run Options.
I also same faced similar issue.
Environment:
Linux, hibernate project, ojdbc6 driver while querying oracle 11g database.
Resolution
TZ parameter was not set in linux machine, that basically tell oracle about the timezone.
So, After adding export statment "export TZ=UTC" at time of application start solved my problem.
UTC--> Change accorind to your timezone.
I had the same problem when trying to make a connection on OBIEE to Oracle db.
I changed my Windows timezone from (GMT+01:00) West Central Africa to (GMT+01:00) Brussels, Copenhagen, Madrid, Paris. Then I rebooted my computer and it worked just fine.
Seems like Oracle was not able to recognize the west central Africa timezone.
This issue happens as the code which is trying to connect to db, has a timezone which is not in db.
It can also be resolved by setting the time zone as below or any valid time zone available in oracle db.
valid time zone which can be found select * from v$version;
System.setProperty("user.timezone", "America/New_York");
TimeZone.setDefault(null);
I too had the same problem when i tried to create connection in JDeveloper. Our server located in different timezone and hence it raised the below errors as:
ORA-00604: error occurred at recursive SQL level 1
ORA-01882: timezone region not found
I referred many forums which asked to include timezone in the Java Options(Run/Debug/Profile) of Project properties and Default Project properties as -Duser.timezone="+02:00" bBut it didn't work for me. Finally the following solution worked for me.
Add the following line to the JDeveloper's configuration file (jdev.conf).
AddVMOption -Duser.timezone=UTC+02:00
The file is located in "<oracle installation root>\Middleware\jdeveloper\jdev\bin\jdev.conf".
In my case I could get the query working by changing "TZR" with "TZD"..
String query = "select * from table1 to_timestamp_tz(origintime,'dd-mm-yyyy hh24:mi:ss TZD') between ? and ?";
I was able to solve the same issue by setting the timezone in my linux system (Centos6.5).
Reposting from
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html
set timezone in /etc/sysconfig/clock e.g. set to ZONE="America/Los_Angeles"
sudo ln -sf /usr/share/zoneinfo/America/Phoenix /etc/localtime
To figure out the timezone value try to
ls /usr/share/zoneinfo
and look for the file that represents your timezone.
Once you've set these reboot the machine and try again.
Facing the same issue using Eclipse and a distant Oracle Database, changing my system time zone to match the time zone of the database server fixed the problem.
Re-start the machine after changing system time zone.
I hope this can help someone
java.sql.SQLException: ORA-00604: error occurred at recursive SQL
level 1 ORA-01882: timezone region not found
For this type of error, just change your system time to your country's standard GMT format
e.g. Indian time zone is chennai,kolkata.
Happens when you use the wrong version of OJDBC jar.
You need to use
11.2.0.4
For my case, i set the timezone at my OS level (ubuntu) with this command.
timedatectl set-timezone {timezone}
For example,
timedatectl set-timezone Africa/Kampala
This might be a bit late but It may help someone.
I encountered this issue while working on spring-boot application and failed to connect to the Oracle DB.
Error:
java.sql.SQLException: ORA-00604: error occurred at recursive SQL level 1
ORA-01882: timezone region not found
SELECT DBTIMEZONE FROM dual; -- This return: +00:00
timedatectl #The OS on the other hand returned correct time and timezone
Since I am not a system admin and not allowed to change system config, I had to apply a workaround in the codes.
spring.datasource.hikari.data-source-properties.oracle.jdbc.timezoneAsRegion=false
#Added the above into the application property file
The working solution came from the below link
Working solution URL
Edit
After the DBA patched the oracle with the missing timezone patches, The above (...timezoneAsRegion=false) was no longer needed.
For Spring-Boot Application - // add below two lines
#SpringBootApplication
public class Application {
public static void main(String[] args) {
// add below two lines
System.out.println("Setting the timezone"+TimeZone.getTimeZone("GMT+9:00").getID());
TimeZone.setDefault(TimeZone.getTimeZone("GMT+9:00"));
SpringApplication.run(Application.class, args);
}
}
moment version is 2.24.0
My date value is 2019-04-23 03:16:00 +0000 UTC
I use moment to let it become to Asia time just like:
const moment = require('moment');
const localTime = moment(date).format('YYYY/MM/DD HH:mm');
<Text>{localTime}</Text>
localTime will show 2019/04/23 11:16
It works when I test it on debug mode.
But when I close the debug mode localTime will be
invalid date
The issue happen both of Android and IOS.
Any ideas ?
For anyone else experiencing date/time issues with Moment on Android especially if you're moving from React Native 0.59 (or older) to 0.60+, it appears that Hermes changes the way the Android works with Moment/dates. However, it would work when the debugger was enabled. Turns out, when you run the debugger, it switches back to the Chromium engine (or V8?) from Hermes. Resulted in us having to use console logs to track down Moment parsing issues. Oddly, the issues also occurred when trying the same manipulations in Safari.
If you're parsing dates passed in via different vars for day, month, year and the day or month does not have preceding zeroes (ex: 01 vs 1) then I recommend doing this:
const momentFormat = { y: birthYear, m: birthMonth, d: birthDay };
return Moment(momentFormat).format('MMMM Do, YYYY');
This manually sets the values rather than relying on each value being correctly formatted or having to write custom code to ensure the day/month values have the 0 when needed.
Tried with a similar question earlier, but could not I make headway. So I did new tests and here is the new question:
I did a brand new installation of PHARO 1.4 and GEMSTONE 3.0.1.2 on the same machine. (Linux CENTOS). Loaded seaside 3.0 in Pharo and version 3.0.7.1 in Gemstone using the latest version of Gemtools (1.0 beta 87) with the latest version of glass workspace (1.0 beta 8.7.4).
I opened the workspace and evaluated:
(WAEmailMessage
from: (WAEmailAddress address: 'xx#aa.com' username: 'fromMe')
to: (WAEmailAddress address: 'shyam#localhost' username: 'shyam')
subject: 'Email Test')
body: 'This is a Test Email sent';
send.
(BTW, As the default mail host in Gemstone is "mailhost", I added the following line to the /etc/hosts file127.0.0.1 localhost mailhost ).
On Pharo the message is sent and received correctly, while in Gemstone I get
a MessageNotUnderstood occurred (error 2010), a UndefinedObject does not understand #'isEmpty', in the method
readSmtpResult
| result firstChar |
[self readWillNotBlockWithin: 5000]
whileFalse: [GsFile stderr log: 'Waiting for server to write...'].
result := self readString: 500.
result isEmpty =========================> HERE result is "nil".
ifTrue:
[self log: 'Empty result'.
^false].
The reason being that result returns a nil.
I tried with similar results also on MAC OS X which instead went into a loop in the lines above.
Using tcpdump -X -i lo tcp port 25 and WireShark, I noticed that for GEMSTONE, I saw NO activity while the packets were correctly exchanged for PHARO.
Evidently, I am doing something terribly wrong to get it wrong on two different systems.
Any idea ?
Thanks
Shyam.
result is nil because #readString: returned nil.
It seems that the peer does not send any data. As you already traced that there is no activity on port 25 going on, are you sure that the SMTP parameters are correct?
Seaside-Email contains code that you can use to configure your SMTP-Server.
Given you have your Seaside application seasideApp, you can do the following:
seasideApp configuration
addParent: WAEmailConfiguration instance.
seasideApp
preferenceAt: #smtpServer put: 'your.smtp.host';
preferenceAt: #smtpPort put: 25;
preferenceAt: #smtpUsername put: 'your.smtp.username.or.nil.if.unecessary';
preferenceAt: #smtpUsername put: 'your.smtp.password.or.nil.if.unecessary';
yourself.
Note that #smtpServer and smtpPort must be configured the way described, as they are used in the GemStone version of GRPlatform>>#seasideDeliverEmailMessage:. I opted to deliberately not use the GemStone defaults.
Also, setting the SMTP parameters this way is ment to work cross-platform; if it does not, please contact me directly.
I'm attempting to execute an uninstaller (written in AppleScript) through AuthorizationExecuteWithPrivileges. I'm setting up my rights after creating an empty auth ref like so:
char *tool = "/usr/bin/osascript";
AuthorizationItem items = {kAuthorizationRightExecute, strlen(tool), tool, 0};
AuthorizationRights rights = {sizeof(items)/sizeof(AuthorizationItem), &items};
AuthorizationFlags flags = kAuthorizationFlagDefaults |
kAuthorizationFlagExtendRights |
kAuthorizationFlagPreAuthorize |
kAuthorizationFlagInteractionAllowed;
status = AuthorizationCopyRights(authorizationRef, &rights, NULL, flags, NULL);
Later I call:
status = AuthorizationExecuteWithPrivileges(authorizationRef, tool, kAuthorizationFlagDefaults, (char *const *)args, NULL);
On Snow Leopard this works fine, but on Leopard I get the following in syslog.log:
Apr 19 15:30:09 hostname /usr/bin/osascript[39226]: OpenScripting.framework - 'gdut' event blocked in process with mixed credentials (issetugid=0 uid=501 euid=0 gid=20 egid=20)
Apr 19 15:30:12: --- last message repeated 1 time ---
...
Apr 19 15:30:12 hostname [0x0-0x2e92e9].com.example.uninstaller[39219]: /var/folders/vm/vmkIi0nYG8mHMrllaXaTgk+++TI/-Tmp-/TestApp_tmpfiles/Uninstall.scpt:
Apr 19 15:30:12 hostname [0x0-0x2e92e9].com.example.uninstaller[39219]: execution error: «constant afdmasup» doesn’t understand the «event earsffdr» message. (-1708)
After researching this for a few hours my first guess is that Leopard somehow doesn't want to do what I'm doing because it knows it's in a setuid situation and blocks calls that ask about user-specific things in the applescript.
Am I going about this all wrong? I just want to run the equivalent of "sudo /usr/bin/osascript ..."
Edit:
FWIW, the first line that causes the "execution error" is:
set userAppSupportPath to (POSIX path of (path to application support folder from user domain))
However, even with an empty script (on run argv, end run and that's it) I still get the 'gdut' message.
According to this thread. http://forums.macosxhints.com/showthread.php?t=90952&page=3 It appears that a security update was made to OS X that blocks setuid root scripts from being accessed via AppleScript.
I suspect this mechanism is blocking your code as well.
Unfortunately, I guess that means this is not working "by design".