I've been running into some issues with the ejbdoclet Ant task, specifically, it is giving me output such as the following:
[ejbdoclet] XJavaDoc Ignoring class myClass in
/path/myClass.java. It was generated (Wed Mar 28 16:59:12 EDT 2012) after XJavaDoc's timestamp was reset (Wed Mar 28 16:58:52 EDT
2012)
You will note that the file is being ignored because it was generated after the timestamp on the file. The source files are currently sitting on an NFS share connected to the build cluster and for various resasons, generating the files on the local machines will not be posible. As such, I have used the force="true" tag as documented as follows:
<ejbdoclet ejbSpec="2.0" destdir="${common.generated}" force="true">
However, it is not being respected by XDoclet, any thoughts as to what might be going on?
Oddly enough, this appears to be an error where the message that was provided didn't accurately reflect what was expected. The error message indicates that the file is being ignored due to the fact that it's date stamp is in the future when compared to the one that ejbdoclet is using to determine if the files should be generated. This actually bypasses the force attribute so the error is actually with regards to the system clocks not being synchronized as opposed to with ejbdoclet itself per se.
Related
I need to display the date and time of actual log info within the tomcat8-stdout log file for my tomcat 8.5 installation, I found one solution of adding this line to the logging.properties file, but it didn't work, the following is what i added to logging.properties:
java.util.logging.ConsoleHandler.level = FINE
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
java.util.logging.ConsoleHandler.encoding = UTF-8
java.util.logging.SimpleFormatter.format=%1$tF %1$tT [%4$-7s] %5$s %n
(My actual logging file without the line spacing)
Right now it’s just a bunch of data that has without timestamps. I just wanted the standard yyyymmdd hhmmss that precedes the INFO or ERROR, etc in stdout log output.
My Tomcat setup is running on Java 8 and Tomcat is starting using windows services.
Any help provided to solve this issue will be appreciated and thank you in advance.
As of version 5.0 eXist-db no longer supports dynamically passing the option expand-xincludes=no to the Saxon processor during serialization. As such, I have to configure this in a Saxon config file. However this configuration does not seem to work - the xincludes are still being expanded in output.
Steps:
Following this comment and Saxon docs I created a configuration file called saxon-config.xml with the #xInclude="false" parameter:
<configuration xmlns="http://saxon.sf.net/ns/configuration" edition="HE">
<global xInclude="false"/>
</configuration>
I saved this in eXist's /etc/ directory and pointed to this file in the attribute in eXist's conf.xml:
<transformer class="net.sf.saxon.TransformerFactoryImpl" caching="no">
<attribute name="http://saxon.sf.net/feature/version-warning" value="false" type="boolean"/>
<attribute name="http://saxon.sf.net/feature/configuration-file" value="/Applications/eXist-db-5.2/etc/saxon-config.xml" type="string"/>
</transformer>
Yet the serializer still expands all the xincludes on output.
As a test to see if Saxon is reading the config, I put a deliberate error in the Saxon config file and Saxon objected.
Have I configured this for xInclude correctly?
--- adding more about workflow ---
Serialization in eXist 5.0 is performed in Xquery with the function fn:serialize().
I obtain a node (testing shows that this action does not expand xi:includes automatically in eXist) = $mydoc
I pass the node to the function with certain parameters, for example
fn:serialize($mydoc, map {"indent":true(),"method":"xml", "omit-xml-declaration":false()})
Output has expanded xinclude
I noticed this message on a recent mailing list, perhaps it's relevant.
My reading of this is that it's eXist doing the serialization with XInclude expansion, and this has nothing to do with Saxon. This doesn't solve your problem but hopefully it means you will be able to look in the right place for a solution; nothing you do with Saxon configuration options is going to make any difference.
Hi Ihe,
See the eXist documentation on XInclude, particularly the section on error handling:
https://exist-db.org/exist/apps/doc/xinclude
Joe
On Thu, Jun 18, 2020 at 7:50 AM Ihe Onwuka <ihe.onwuka#gmail.com> wrote:
5.2.0
On Thu, Jun 18, 2020 at 6:31 AM Jean-Paul Rehr <rehrjb#gmail.com> wrote:
Which version of eXist? Prior to 5.0 you can use
declare option exist:serialize "expand-xincludes=no";
in your Xquery declarations to allow/disallow Xinclude expansion (assuming you are using Xquery to execute the transformation). After 5.0...this no longer has an effect. Hopefully it will be reintroduced or another method discovered (see https://github.com/eXist-db/exist/issues/3446).
On Thu, Jun 18, 2020 at 11:12 AM Ihe Onwuka <ihe.onwuka#gmail.com> wrote:
A short while ago I wrote a transform that was supposed to transform a certain input element to an Xinclude element.
eXist blew up because it tried to resolve Xinclude call as soon as I attempted to store the transformation in the database.
Is that supposed to happen? Including the xsl list because am wondering whether this was a use case for namespace aliasing.
I have since solved the problem another way so the question is of academic interest only.
_______________________________________________
Exist-open mailing list
Exist-open#lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/exist-open
I have installed PySNMP (version 4.4.6) and am attempting to call the following function (part of a larger class):
def walk(self):
#Walks OID to scavenge for information.
oids={}
for (errorIndication,
errorStatus,
errorIndex,
varBinds) in nextCmd(SnmpEngine(),
CommunityData(self.cs),
UdpTransportTarget((self.device.split(".")[0], 161), timeout=60, retries=0),
ContextData(),
ObjectType(ObjectIdentity("1.3.6.1.4.1.14179.1.2.5.5"))):
print((errorIndication,
errorStatus,
errorIndex,
varBinds))
and repeatedly receive the following output:
(RequestTimedOut('No SNMP response received before timeout',),
I have triple-checked to make sure that my community string, SNMP version, device name, port, and OID are correct. I have altered the Transport timeout variable 60 seconds with no luck. My first thought was that it might be a firewall issue, but then I tried to run the simple example included in the documentation:
from pysnmp.hlapi import *
g = getCmd(SnmpEngine(),
CommunityData('public'),
UdpTransportTarget(('demo.snmplabs.com', 161)),
ContextData(),
ObjectType(ObjectIdentity('SNMPv2-MIB', 'sysDescr', 0)))
print(next(g))
And receive the exact same output. Does anyone know what might be causing this? Unfortunately I'm on a server with few admin rights, so I can't go digging through module files changing anything. Thanks in advance for the help!
Your code looks good. For as long as you get the right hostname/IP out of self.device.split(".")[0].
May be you are not getting response from your SNMP agent for one reason or the other. I'd try public SNMP agent:
$ snmpwalk -v2c -c public demo.snmplabs.com 1.3.6
SNMPv2-MIB::sysDescr.0 = STRING: Linux zeus 4.8.6.5-smp #2 SMP Sun Nov 13 14:58:11 CDT 2016 i686
...
To make sure you do not have connectivity/firewall problems. Consider trying snmpwalk against your local SNMP agent as well. If you can't have Net-SNMP installed, consider trying snmpclitools for conducting this experiment.
Trying to sync from a mac to a linux machine, I get multiple failures with a message of the following type:
100% 00:00 ETAFailed [www/sandbox/my-vue-buefy-project/node_modules/spdy-transport/lib/spdy-transport/protocol/spdy]:
Failed to set modification time of file /users/guerrini/www/sandbox/my-vue-buefy-project/node_modules/spdy-transport/lib/spdy-transport/protocol/.unison.spdy.1db0b477154fc6ddf40346e8e27082da.unison.tmp/constants.js
to 1970-01-01 at 1:00:00 (0.000000):
the time was set to 2018-04-12 at 8:49:57 (1523515797.000000) instead`
It seems that it cannot set the modification time and that it uses the current time instead. But, unfortunately, after this the synchronisation of all the files with the above modification date fails.
Moreover, I have tried to set modification date to the given time by hand with "touch" and it works.
I am working verifying the jar files present on remote unix boxes with that of built on local machine(Windows & Cygwin) with same JVM.
As a POC I am trying to verify if same checksum is produced with jar files generated on my machine with consecutive builds, I tried below,
Generated the jar file first time using ant script
Calculated the checksum (e.g. "xyz abc")
Generated the jar file again with same ant script without changing anything
I got different checksum but same byte count (e.g. "xvw abc")
I am not sure how java internal processes produce the class files and then the jar files, Can someone please help me understand below points
Does the cksum utility of unix/cygwin consider timestamp of the file while coming up with the value?
Will the checksum be different for compiled class files/jar file produced if we keep every other things same [Compiler version + sourcecode + machine + environment]?
Answer to question 1: cksum doesn't consider the timestamp of the archive (e.g. jar-file) but it does consider the timestamps of the files inside the jarfile.
Answer to question 2: The checksums of the individual class-files will be the same with all other things the same (source-code, compiler etc.) The checksums of the jar-files will be different. Causes of differences can be the timestamp of the files inside the jarfile or if files are put into the archive in different orders (e.g. caused by parallel builds).
If you want to create a reproducible build with gradle you can do so with the config below:
tasks.withType(AbstractArchiveTask) {
preserveFileTimestamps = false
reproducibleFileOrder = true
}
Maven allows something similar, sorry I don't know how to do this with ant..
More info here:
https://dzone.com/articles/reproducible-builds-in-java
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318