So I have some code which I'm testing to make sure it works nicely for authentication. It works fine against straight kerberos, so I figured there should only be some minor hiccups with AD. Unfortunately, I cannot get around a KrbException: KDC has no support for encryption type (14).
I know the error is an encryption type mismatch. But I can kinit just fine, it's only in the code that I hit an issue. I'm not setting anything, so I think it should be inheriting the same defaults as kinit, but that obviously isn't the case.
The code-
System.setProperty("sun.security.krb5.debug", "true");
System.setProperty("java.security.krb5.realm", "TEST.SQRRL.COM");
System.setProperty("java.security.krb5.kdc", "172.16.101.128");
System.setProperty("java.security.auth.login.config", "./conf/jaas.conf");
System.setProperty("javax.security.auth.useSubjectCredsOnly", "true");
// "Client" references the JAAS configuration in the jaas.conf file.
LoginContext loginCtx = null;
loginCtx = new LoginContext("Server", new LoginCallbackHandler("test".toCharArray()));
loginCtx.login();
subject = loginCtx.getSubject();
and the jaas.conf
Server {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=false
storeKey=true
useTicketCache=true
principal="accumulo#test.SQRRL.COM";
};
And, the stack trace-
>>>KRBError:
sTime is Tue Nov 27 18:16:36 EST 2012 1354058196000
suSec is 257213
error code is 14
error Message is KDC has no support for encryption type
realm is test.SQRRL.COM
sname is krbtgt/test.SQRRL.COM
msgType is 30
javax.security.auth.login.LoginException: KDC has no support for encryption type (14)
at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:696)
at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:542)
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 javax.security.auth.login.LoginContext.invoke(LoginContext.java:769)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:579)
at authenticators.KerberosAuthenticator.<init>(KerberosAuthenticator.java:37)
at main.ServerImpl.<init>(ServerImpl.java:91)
at main.PlugServer.run(PlugServer.java:22)
at main.PlugServer.main(PlugServer.java:42)
Caused by: KrbException: KDC has no support for encryption type (14)
at sun.security.krb5.KrbAsRep.<init>(KrbAsRep.java:66)
at sun.security.krb5.KrbAsReq.getReply(KrbAsReq.java:446)
at sun.security.krb5.Credentials.sendASRequest(Credentials.java:401)
at sun.security.krb5.Credentials.acquireTGT(Credentials.java:373)
at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:662)
... 15 more
Caused by: KrbException: Identifier doesn't match expected value (906)
at sun.security.krb5.internal.KDCRep.init(KDCRep.java:133)
at sun.security.krb5.internal.ASRep.init(ASRep.java:58)
at sun.security.krb5.internal.ASRep.<init>(ASRep.java:53)
at sun.security.krb5.KrbAsRep.<init>(KrbAsRep.java:50)
... 19 more
Exception in thread "main" java.lang.RuntimeException: javax.security.auth.login.LoginException: KDC has no support for encryption type (14)
at main.PlugServer.run(PlugServer.java:36)
at main.PlugServer.main(PlugServer.java:42)
Caused by: javax.security.auth.login.LoginException: KDC has no support for encryption type (14)
at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:696)
at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:542)
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 javax.security.auth.login.LoginContext.invoke(LoginContext.java:769)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:579)
at authenticators.KerberosAuthenticator.<init>(KerberosAuthenticator.java:37)
at main.ServerImpl.<init>(ServerImpl.java:91)
at main.PlugServer.run(PlugServer.java:22)
... 1 more
Caused by: KrbException: KDC has no support for encryption type (14)
at sun.security.krb5.KrbAsRep.<init>(KrbAsRep.java:66)
at sun.security.krb5.KrbAsReq.getReply(KrbAsReq.java:446)
at sun.security.krb5.Credentials.sendASRequest(Credentials.java:401)
at sun.security.krb5.Credentials.acquireTGT(Credentials.java:373)
at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:662)
... 15 more
Caused by: KrbException: Identifier doesn't match expected value (906)
at sun.security.krb5.internal.KDCRep.init(KDCRep.java:133)
at sun.security.krb5.internal.ASRep.init(ASRep.java:58)
at sun.security.krb5.internal.ASRep.<init>(ASRep.java:53)
at sun.security.krb5.KrbAsRep.<init>(KrbAsRep.java:50)
... 19 more
So, I got it past this stage. I can only guess that the DES support in active directory for Windows Server 2012 is broken, as I ended up tweaking my krb5.conf file and setting the two default ticket types and permitted types to just aes256-cts-hmac-sha1-96 and it worked for the one user. After enabling aes256 for other users in AD, it continued to work.
You need to access the user's account and check the 'use kerberos DES encryption types' checkbox.
You'll need to login to your DS as an admin to do this of course.
Looking at init() in KDCRep.java, the only part that looks it could be throwing your error is:
150 if ((subDer.getTag() & 0x1F) == 0x00) {
151 pvno = subDer.getData().getBigInteger().intValue();
152 if (pvno != Krb5.PVNO) {
153 throw new KrbApErrException(Krb5.KRB_AP_ERR_BADVERSION);
154 }
155 } else {
156 throw new Asn1Exception(Krb5.ASN1_BAD_ID);
157 }
It does seem a bit odd that the error's being printed as a KrbException, but it could work since KrbApErrException is a subclass of KrbException. init() can't throw any other subclasses of KrbException, though.
Scratch that. A better possibility is that it's one of the Asn1Exceptions in there, since the constructor in KrbAsRep.java catches and rethrows those errors as KrbExceptions (with an appropriate initCause that would match up pretty well with the stack trace).
"Identifier doesn't match expected value (906)" leads me to believe it's throwing a Asn1Exception(Krb5.ASN1_BAD_ID), since Krb5.ASN1_BAD_ID has value 906. That's not overly helpful, since that seems to be the default error in init().
See if you can generate the DerValue corresponding to your configuration and inspect it manually, seeing where init() would reject it, then step backward from there, looking at what part of your configuration created the erroneous bits.
Upon further inspection, the message "KDC has no support for encryption type" leads me to believe Krb5.KDC_ERR_ETYPE_NOSUPP must have been used. But, as that's only used for the default instance of Etype, that might not mean much.
Related
I am trying to instantiate and sign a protobuf message within a Corda flow; the original transaction is created by a JavaScript client, encoded as base64, and submitted to Corda. The Corda node decodes, signs and forwards to the public network.
The transaction, signing, and approval works fine (it actually executes in the Public Network), but upon returning the result it fails with the attached error.
Is there any mechanism to deserialize the protobuf transaction without breaking the [FiberDeserializationChecker]?
Thank you in advance!
Thu Mar 25 16:43:10 UTC 2021>>> on: java.io.InvalidObjectException: Deserialization via serialization delegate
Serialization trace:
validStart (com.hedera.hashgraph.sdk.TransactionId)
transactionIds (com.hedera.hashgraph.sdk.TokenAssociateTransaction)
associateTxn (net.aochain.corda.nodes.hederaTxn.AssociateTokenFlow)
logic (net.corda.node.services.statemachine.FlowStateMachineImpl)
at com.esotericsoftware.kryo.serializers.ObjectField.read(ObjectField.java:144)
at com.esotericsoftware.kryo.serializers.CompatibleFieldSerializer.read(CompatibleFieldSerializer.java:145)
at com.esotericsoftware.kryo.Kryo.readClassAndObject(Kryo.java:813)
at co.paralleluniverse.io.serialization.kryo.ReplaceableObjectKryo.readClassAndObject(ReplaceableObjectKryo.java:112)
at com.esotericsoftware.kryo.serializers.CollectionSerializer.read(CollectionSerializer.java:134)
at com.esotericsoftware.kryo.serializers.CollectionSerializer.read(CollectionSerializer.java:40)
at com.esotericsoftware.kryo.Kryo.readObject(Kryo.java:731)
at co.paralleluniverse.io.serialization.kryo.ReplaceableObjectKryo.readObject(ReplaceableObjectKryo.java:92)
at com.esotericsoftware.kryo.serializers.ObjectField.read(ObjectField.java:125)
at com.esotericsoftware.kryo.serializers.CompatibleFieldSerializer.read(CompatibleFieldSerializer.java:145)
at com.esotericsoftware.kryo.Kryo.readObject(Kryo.java:731)
at co.paralleluniverse.io.serialization.kryo.ReplaceableObjectKryo.readObject(ReplaceableObjectKryo.java:92)
at com.esotericsoftware.kryo.serializers.ObjectField.read(ObjectField.java:125)
at com.esotericsoftware.kryo.serializers.CompatibleFieldSerializer.read(CompatibleFieldSerializer.java:145)
at com.esotericsoftware.kryo.Kryo.readObject(Kryo.java:731)
at co.paralleluniverse.io.serialization.kryo.ReplaceableObjectKryo.readObject(ReplaceableObjectKryo.java:92)
at com.esotericsoftware.kryo.serializers.ObjectField.read(ObjectField.java:125)
at com.esotericsoftware.kryo.serializers.FieldSerializer.read(FieldSerializer.java:543)
at co.paralleluniverse.fibers.Fiber$FiberSerializer.read(Fiber.java:2156)
at co.paralleluniverse.fibers.Fiber$FiberSerializer.read(Fiber.java:2086)
at com.esotericsoftware.kryo.Kryo.readClassAndObject(Kryo.java:813)
at co.paralleluniverse.io.serialization.kryo.ReplaceableObjectKryo.readClassAndObject(ReplaceableObjectKryo.java:112)
at net.corda.nodeapi.internal.serialization.kryo.KryoCheckpointSerializer$deserialize$1$1.invoke(KryoCheckpointSerializer.kt:92)
at net.corda.nodeapi.internal.serialization.kryo.KryoCheckpointSerializer$deserialize$1$1.invoke(KryoCheckpointSerializer.kt:42)
at net.corda.nodeapi.internal.serialization.kryo.KryoStreams.kryoInput(KryoStreams.kt:20)
at net.corda.nodeapi.internal.serialization.kryo.KryoCheckpointSerializer$deserialize$1.invoke(KryoCheckpointSerializer.kt:81)
at net.corda.nodeapi.internal.serialization.kryo.KryoCheckpointSerializer$deserialize$1.invoke(KryoCheckpointSerializer.kt:42)
at net.corda.nodeapi.internal.serialization.kryo.KryoCheckpointSerializer$kryo$1.execute(KryoCheckpointSerializer.kt:70)
at com.esotericsoftware.kryo.pool.KryoPoolQueueImpl.run(KryoPoolQueueImpl.java:58)
at net.corda.nodeapi.internal.serialization.kryo.KryoCheckpointSerializer.kryo(KryoCheckpointSerializer.kt:66)
at net.corda.nodeapi.internal.serialization.kryo.KryoCheckpointSerializer.deserialize(KryoCheckpointSerializer.kt:80)
at net.corda.node.services.statemachine.interceptors.FiberDeserializationChecker$start$2.invoke(FiberDeserializationCheckingInterceptor.kt:103)
at net.corda.node.services.statemachine.interceptors.FiberDeserializationChecker$start$2.invoke(FiberDeserializationCheckingInterceptor.kt:53)
at kotlin.concurrent.ThreadsKt$thread$thread$1.run(Thread.kt:30)
Caused by: java.lang.RuntimeException: java.io.InvalidObjectException: Deserialization via serialization delegate
at co.paralleluniverse.io.serialization.kryo.ReplaceableObjectKryo.getReplacement(ReplaceableObjectKryo.java:129)
at co.paralleluniverse.io.serialization.kryo.ReplaceableObjectKryo.readReplace(ReplaceableObjectKryo.java:118)
at co.paralleluniverse.io.serialization.kryo.ReplaceableObjectKryo.readObjectOrNull(ReplaceableObjectKryo.java:107)
at com.esotericsoftware.kryo.serializers.ObjectField.read(ObjectField.java:132)
... 33 more
Caused by: java.io.InvalidObjectException: Deserialization via serialization delegate
at org.threeten.bp.Instant.readResolve(Instant.java:1176)
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 co.paralleluniverse.io.serialization.kryo.ReplaceableObjectKryo.getReplacement(ReplaceableObjectKryo.java:125)
From Matt Nesbit #R3 :
Their flow checkpoint is including objects that aren't kryo (de)serialisable. Most probably they need to hide any statics/native methods behind a SingletonSerialiseAsToken derived object probably held by a CordaService.
That probably includes their protobuf serialiser, but from this little info could be anything, since they appear to be also including Hedera Hashgraph
if you could share some more info or msg me on slack.corda.net I could help with getting you some more info
Matt and David reply send me through the right path.
You have to create a new class as described here. In our case, the deserializer event is included into an API, and that blocks the read from Kyro when the (de)serialization happens.
Thank you both!
I want to retrieve the list of X509Certificate from my smart card without logging in (without PIN).
My code is the following:
String conf = args[0];
Provider p = new sun.security.pkcs11.SunPKCS11(conf);
Security.addProvider(p);
KeyStore ks = KeyStore.getInstance("PKCS11");
1) ks.load(null, null);
2) ks.load(null, "".toCharArray());
The first test (1) fails with this StackTrace:
Exception in thread "main" java.io.IOException: load failed
at sun.security.pkcs11.P11KeyStore.engineLoad(P11KeyStore.java:763)
at java.security.KeyStore.load(Unknown Source)
at TestPKCS11.main(TestPKCS11.java:29)
Caused by: javax.security.auth.login.LoginException: no password provided, and n
o callback handler available for retrieving password
at sun.security.pkcs11.SunPKCS11.login(SunPKCS11.java:1184)
at sun.security.pkcs11.P11KeyStore.login(P11KeyStore.java:849)
at sun.security.pkcs11.P11KeyStore.engineLoad(P11KeyStore.java:751)
The second (2) fails with:
Exception in thread "main" java.io.IOException: load failed
at sun.security.pkcs11.P11KeyStore.engineLoad(P11KeyStore.java:763)
at java.security.KeyStore.load(Unknown Source)
at TestPKCS11.main(TestPKCS11.java:30)
Caused by: javax.security.auth.login.LoginException
at sun.security.pkcs11.SunPKCS11.login(SunPKCS11.java:1238)
at sun.security.pkcs11.P11KeyStore.login(P11KeyStore.java:849)
at sun.security.pkcs11.P11KeyStore.engineLoad(P11KeyStore.java:753)
... 2 more
Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_PIN_INVALID
at sun.security.pkcs11.wrapper.PKCS11.C_Login(Native Method)
at sun.security.pkcs11.SunPKCS11.login(SunPKCS11.java:1222)
My config is the following:
name=SmartCard
slotListIndex = 0
library=C:\gclib.dll
attributes(*,CKO_PUBLIC_KEY,*)={ CKA_TOKEN=true }
NB: I have a local tool (Classic Client ToolBox) that does not require the PIN to display the certificates.
Looks like Sun's provider always calls Login, no matter if you want to login or not. Frankly speaking, it can be that the only option is to change the approach, e.g. use some other way to access PKCS#11 devices (we have such mechanisms in our SecureBlackbox, for example).
On the other hand, possibility to retrieve information without logging in to the device, is a kind of information leak, and as such possibility to obtain the list or the certificates themselves depends on the particular device. What works on your device might not work on other devices.
I'm trying to connect to a SAP system via Java Middleware (Dell Boomi) to inspect existing document types.
When inspecting a base IDOC Type (e.g. ORDERS05) everything works ok.
When trying to inspect a custom type (e.g. ZORDERS05) I get a rather obscure exception from the java JCO classes:
Feb 25, 2016 6:56:56 PM CET WARNING [com.boomi.connector.sap.browse.SAPIDocSchemaBuilder buildSchema] Unable to find IDoc base type: ZORDERS05, extension:
com.sap.conn.jco.AbapException: (126) SEGMENT_UNKNOWN: SEGMENT_UNKNOWN Message 257 of class EA type E, Par[1]: ZHEADER, Par[2]: 740
at com.sap.conn.jco.rt.MiddlewareJavaRfc$JavaRfcClient.execute(MiddlewareJavaRfc.java:2083)
at com.sap.conn.jco.rt.ClientConnection.execute(ClientConnection.java:1185)
at com.sap.conn.jco.rt.ClientConnection.execute(ClientConnection.java:1014)
at com.sap.conn.jco.rt.RfcDestination.execute(RfcDestination.java:1458)
at com.sap.conn.jco.rt.RfcDestination.execute(RfcDestination.java:1428)
at com.sap.conn.jco.rt.AbapFunction.execute(AbapFunction.java:332)
at com.boomi.connector.sap.SAPConnection.executeFunction(SAPConnection.java:103)
at com.boomi.connector.sap.browse.SAPIDocSchemaBuilder.buildSchema(SAPIDocSchemaBuilder.java:49)
at com.boomi.connector.sap.browse.SAPSchemaBrowser.buildIDocProfile(SAPSchemaBrowser.java:210)
at com.boomi.connector.sap.browse.SAPSchemaBrowser.browse(SAPSchemaBrowser.java:84)
at com.boomi.connector.custom.CustomConnectorBrowseAction.browse(CustomConnectorBrowseAction.java:77)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.boomi.util.ClassUtil$InvokerWithClassLoader.invoke(ClassUtil.java:360)
at com.sun.proxy.$Proxy72.browse(Unknown Source)
at com.boomi.connector.BrowseMessageHandler.handle(BrowseMessageHandler.java:116)
at com.boomi.container.core.MessagePollerThread$BaseTask.handleMessage(MessagePollerThread.java:657)
at com.boomi.container.core.MessagePollerThread$AsyncTask.run(MessagePollerThread.java:742)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Any hint on how to troubleshoot this problem?
SAP side the objects seem to be really identical (both base types, no extension etc...)
The note from Ravindra HV is correct, this problem is caused from a misconfiguration on the SAP side.
In order to fix this the SAP team had to release the custom segments (ZHEADER) inside the custom IDOC type.
See answer to this: http://scn.sap.com/thread/3436578
I have an input file with # in the name (UPX#L.xxxxx001.xml). Spring Batch StaxEventItemReader failed to open this file. Is there anyway to escape this special character? Please advise.
This is my bean
<bean id="myItemReader" parent="myItemReaderParent" scope="step">
<property name="resource" value="file:#{jobParameters['toolf.input.file.name']}"/>
</bean>
<bean id="myItemReaderParent" class="org.springframework.batch.item.xml.StaxEventItemReader" scope="prototype">
<property name="fragmentRootElementName" value="MyRec"/>
<property name="unmarshaller" ref="myUnmarshaller"/>
</bean>
[INFO ]org.springframework.jms.listener.DefaultMessageListenerContainer#0-1[2015-02-05 10:27:23,487] - Sending notification for start of JobExecution: id=52760, version=1, startTime=Thu Feb 05 10:27:23 EST
2015, endTime=null, lastUpdated=Thu Feb 05 10:27:23 EST 2015, status=STARTED, exitStatus=exitCode=UNKNOWN;exitDescription=, job=[JobInstance: id=52759, version=0, JobParameters=[
{toolf.institutionSymbol=YDX , toolf.projectId=013832, toolf.orderId=678161, toolf.transmissionDate=20150205 10:27:23.392 EST, toolf.input.file.name=/batchdata/dataload/xxx/in/tool/UPX#L.xxxxx001.xml, toolf.out.root.directory=/batchdata/output, toolf.out.input.file.name.without.path=YDX.013832.678161.YbpUsSI#Picklists.d20150204.t140001.xml, toolf.out.working.directory/batchdata/dataload/xxx/in/tool/, timestamp=1423150043392}
], Job=[timeOfOrderLabelJob]]
[INFO ]org.springframework.jms.listener.DefaultMessageListenerContainer#0-1[2015-02-05 10:27:23,576] - Executing step: [toolPrologue]
[ERROR]org.springframework.jms.listener.DefaultMessageListenerContainer#0-1[2015-02-05 10:27:23,607] - Encountered an error executing the step
org.springframework.batch.item.ItemStreamException: Failed to initialize the reader
at org.springframework.batch.item.support.AbstractItemCountingItemStreamItemReader.open(AbstractItemCountingItemStreamItemReader.java:137)
at sun.reflect.GeneratedMethodAccessor260.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)
at org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
at $Proxy9.open(Unknown Source)
at org.springframework.batch.item.support.CompositeItemStream.open(CompositeItemStream.java:93)
at org.springframework.batch.core.step.tasklet.TaskletStep.open(TaskletStep.java:301)
at org.springframework.batch.core.step.AbstractStep.execute(AbstractStep.java:192)
at org.springframework.batch.core.job.SimpleStepHandler.handleStep(SimpleStepHandler.java:135)
at org.springframework.batch.core.job.flow.JobFlowExecutor.executeStep(JobFlowExecutor.java:61)
at org.springframework.batch.core.job.flow.support.state.StepState.handle(StepState.java:60)
at org.springframework.batch.core.job.flow.support.SimpleFlow.resume(SimpleFlow.java:144)
at org.springframework.batch.core.job.flow.support.SimpleFlow.start(SimpleFlow.java:124)
at org.springframework.batch.core.job.flow.FlowJob.doExecute(FlowJob.java:135)
at org.springframework.batch.core.job.AbstractJob.execute(AbstractJob.java:281)
at org.springframework.batch.core.launch.support.SimpleJobLauncher$1.run(SimpleJobLauncher.java:120)
at org.springframework.core.task.SyncTaskExecutor.execute(SyncTaskExecutor.java:48)
at org.springframework.batch.core.launch.support.SimpleJobLauncher.run(SimpleJobLauncher.java:114)
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 org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:229)
at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:52)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:40)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:117)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:129)
at org.oclc.tool.mule.launch.MuleJobLauncher.launchJob(MuleJobLauncher.groovy:74)
at org.oclc.tool.mule.launch.JobLauncher$launchJob.call(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:40)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:117)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:137)
at org.oclc.tool.mule.si.JmsMessageUnwrapper.unwrapMessage(JmsMessageUnwrapper.groovy:42)
at sun.reflect.GeneratedMethodAccessor596.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.springframework.expression.spel.support.ReflectiveMethodExecutor.execute(ReflectiveMethodExecutor.java:69)
at org.springframework.expression.spel.ast.MethodReference.getValueInternal(MethodReference.java:83)
at org.springframework.expression.spel.ast.CompoundExpression.getValueInternal(CompoundExpression.java:57)
at org.springframework.expression.spel.ast.SpelNodeImpl.getTypedValue(SpelNodeImpl.java:102)
at org.springframework.expression.spel.standard.SpelExpression.getValue(SpelExpression.java:102)
at org.springframework.integration.util.AbstractExpressionEvaluator.evaluateExpression(AbstractExpressionEvaluator.java:126)
at org.springframework.integration.util.MessagingMethodInvokerHelper.processInternal(MessagingMethodInvokerHelper.java:225)
at org.springframework.integration.util.MessagingMethodInvokerHelper.process(MessagingMethodInvokerHelper.java:125)
at org.springframework.integration.handler.MethodInvokingMessageProcessor.processMessage(MethodInvokingMessageProcessor.java:73)
at org.springframework.integration.handler.ServiceActivatingHandler.handleRequestMessage(ServiceActivatingHandler.java:64)
at org.springframework.integration.handler.AbstractReplyProducingMessageHandler.handleMessageInternal(AbstractReplyProducingMessageHandler.java:98)
at org.springframework.integration.handler.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:78)
at org.springframework.integration.dispatcher.UnicastingDispatcher.doDispatch(UnicastingDispatcher.java:110)
at org.springframework.integration.dispatcher.UnicastingDispatcher.dispatch(UnicastingDispatcher.java:97)
at org.springframework.integration.channel.AbstractSubscribableChannel.doSend(AbstractSubscribableChannel.java:61)
at org.springframework.integration.channel.AbstractMessageChannel.send(AbstractMessageChannel.java:157)
at org.springframework.integration.core.MessagingTemplate.doSend(MessagingTemplate.java:288)
at org.springframework.integration.core.MessagingTemplate.send(MessagingTemplate.java:149)
at org.springframework.integration.core.MessagingTemplate.convertAndSend(MessagingTemplate.java:189)
at org.springframework.integration.gateway.MessagingGatewaySupport.send(MessagingGatewaySupport.java:183)
at org.springframework.integration.jms.ChannelPublishingJmsMessageListener$GatewayDelegate.send(ChannelPublishingJmsMessageListener.java:424)
at org.springframework.integration.jms.ChannelPublishingJmsMessageListener.onMessage(ChannelPublishingJmsMessageListener.java:278)
at org.springframework.jms.listener.AbstractMessageListenerContainer.doInvokeListener(AbstractMessageListenerContainer.java:535)
at org.springframework.jms.listener.AbstractMessageListenerContainer.invokeListener(AbstractMessageListenerContainer.java:495)
at org.springframework.jms.listener.AbstractMessageListenerContainer.doExecuteListener(AbstractMessageListenerContainer.java:467)
at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:325)
at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:263)
at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1058)
at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListenerContainer.java:1050)
at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:947)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.IllegalStateException: Input resource must exist (reader is in 'strict' mode)
at org.springframework.batch.item.xml.StaxEventItemReader.doOpen(StaxEventItemReader.java:182)
at org.springframework.batch.item.support.AbstractItemCountingItemStreamItemReader.open(AbstractItemCountingItemStreamItemReader.java:134)
... 73 more
[INFO ]org.springframework.jms.listener.DefaultMessageListenerContainer#0-1[2015-02-05 10:27:23,612] - enter DetailLogStepExecutionListener.afterStep
[INFO ]org.springframework.jms.listener.DefaultMessageListenerContainer#0-1[2015-02-05 10:27:23,612] - exit DetailLogStepExecutionListener.afterStep
In a URL/URI, the # character is reserved, used to delimit the fragment identifier (which would have no meaning to the file: resource scheme). If you want to include this character as part of the path, it must be escaped with %23
Rather than concatenate your value to file: in your bean definition file, I recommend that you specify the parameter as a full URI/URI, rather than a filesystem path:
<property name="resource" value="#{jobParameters['toolf.input.file.url']}"/>
And set toolf.input.file.url to:
file:/batchdata/dataload/xxx/in/tool/UPX%23L.xxxxx001.xml
This will avoid any other escapement pitfalls you might encounter, like with characters #, !, =, etc.
If you must use a filesystem path as a parameter, you should be able to use:
<property name="resource" value="#{new java.io.File(jobParameters['toolf.input.file.name']).toURI().toURL()}"/>
From looking at your error message and the responses, your problem is clear, both Tunaki and Glenn Lane are partially correct, and I'm up-voting Glenn Lane for answering the question you asked, and doing it well.
From your reply to Glenn:
if (fileName.contains("#")) { def (value1, value2) = fileName.split("#") fileName = value1 + "%23#" + value2 } I tried this. Still doesn't work
Escaping will not help the situation.
The character is already being handled somewhere along the execution chain, Tunaki was correct in questioning the type error you were having.
From your error log:
[ERROR]org.springframework.jms.listener.DefaultMessageListenerContainer#0-1[2015-02-05 10:27:23,607] - Encountered an error executing the step
org.springframework.batch.item.ItemStreamException: Failed to initialize the reader
Coupled with the resource state exception Tunaki pointed out, we can conclude that is the case. There is insufficient information here to say why or where this occurring, but here are a two general categories:
Depending on how it's arriving at, or from, the file store the character may already removed from the file at that point in the process or aliased on the Store in a way the File handler can't deal with. For the reasons Glenn pointed out.
Depending on the Message or Job Handling in your execution chain it is being stripped out as it transformed into or out of a URI/URL call. For the reasons Glenn pointed out.
Yes. It is the # problem. Once the # is removed it works fine.
Based on the above statement the simple, quick, and dirty solution would be to be aware of this and handle it by stripping and injecting the # directly from the file or uri as needed. Based on your code snippet, you know how to do this.
The correct way to solve this would be to track down where the resource error is occurring and ensure that your file handling is consistent across the entire Job flow.
Without all the right code here and/or knowing more about your system configuration I can't be specific. There is simply not enough information between the bean and the error log to say exactly where this occurring only that this is exactly your problem.
Here are some possible suggestions:
I am assuming you've checked the file Store directly and hand removed the # and changed the file name in the job and it runs, based on your above statement.
Try to access the file on the store from a different java object using the same identifier and it works; Then check how your item reader implementation is handling the file access.
If it failed or that is not the failure point. Check that "#" value is the job file and if it's there and/or the only # when you perform the split.
If that all checks find out how it is arriving to the file store and that resource can be properly located in the store and that # is not also reserved in your implementation or requires special handling/configuration.
This will help narrow done the root cause.
Since the java 7 update 25 launched by Oracle our application no longer functions.
Initially we got some warning about codebase & sercurity tags missing in the Manifest file, which we fixed.
The problem we now end up with is that in the Console we only get the following lines:
#### Java Web Start Error:
#### null
We also get an application Error dialog with the message: Unable to launch the application.
The details button gives the following details in the Exception:
java.lang.NullPointerException
at com.sun.jnlp.JNLPClassLoader.getPermissions(Unknown Source)
at java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:206)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at desktop.DesktopProxySelector.<init>(DesktopProxySelector.java:24) <- code smippet below
at desktop.Main.main(Main.java:139) <- code smippet below
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.sun.javaws.Launcher.executeApplication(Unknown Source)
at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Thread.java:724)
The relevant code parts are:
Desktop.Main.main
/**
* Main method, starts the application
*/
public static void main(String[] args) {
System.setProperty("java.net.useSystemProxies", "true");
//Logger.getLogger("httpclient.wire.header.level").setLevel(Level.FINEST);
//Logger.getLogger("org.apache.commons.httpclient.level").setLevel(Level.FINEST);
java.net.ProxySelector.setDefault(new DesktopProxySelector(java.net.ProxySelector.getDefault()));
(The last line is line number 139)
desktop.DesktopProxySelector:
public class DesktopProxySelector extends ProxySelector {
public DesktopProxySelector(ProxySelector defaultSelector) {
URI httpsUri = new CentralConfigurationService().getCentralLocation();
(The last line is line number 24 where the exception occures)
Can someone give us some clues hints (or better a solution) for this new behaviour of java caused by this 'minor' update.
When we run the application straight from the cli using java -jar Desktop.jar the application wil run file, so the issue has clearly something todo with the changes in java web start.
#trashgod: the error clearly has something to do with the Permissions change in 7u25, since the NullPointerException occurs in com.sun.jnlp.JNLPClassLoader.getPermissions.
Just to explain what I think happens (I am a colleague of Wouter):
desktop.Main instantiates a desktop.DesktopProxySelector (our class),
desktop.DesktopProxySelector instantiates desktop.configuration.CentralConfigurationService
desktop.configuration.CentralConfigurationService instantiates a java.net.URI.
On the first line of the DesktopProxySelector init where the CentralConfigurationService is instantiated the getPermissions method, called by the JNLPClassLoader, throws the NullPointerException. So something is going wrong while loading the CentralConfigurationService class by java webstart with getting the permissions for the class. Could that have anything to do with the fact that a URI class is instantiated, which requires extra permissions (a connection to a remote uri is setup)?
Eventually the problem was solved.
The problem was caused between a mismatch in the included jar files in the main MANIFEST.MF file vs the jar files mentioned in the launch.jnlp.
Apperently it is now required to have all jar files that will be used also be present in the launch.jnlp file.
(In the past it was decided to keep this file manually in sink, which obviously was not always maintained in a propper way. Now this process is automated, so the problem should no longer happen to us.)