SDK/J

Hi there,

I'm trying to find additional AAA documentation for the SDK/J platform. In the downloads section there is an archive file that has some JavaDoc files but I wasn't able to find any documentation walking through how AAA works and how it should be implemented. Is there documenation like this somewhere on the RIDP site?

Good morning.

Under advisement from Joe Gromley, we are creating this request to advise you of our intent to send our submission for Compatibility Testing of our Ricoh Xlet and to request the current document for submission. 

We are aiming for an approximate November 5th submission for pretest.

Please send the current instructional document for submission.

I have a customer that install our application, sets the printer to never go to sleep and has the auto log out timer to 15 seconds.  When they scan their badge our application opens and the printer immediately closes the application.  If the user touches the screen before scanning the badge the application works as expected.  I have attached the log files that I got from the client.

Hello

the attached version can be deployed success on lab machines, but if I request a demo signature for it, it shows error J522 when starting xlet.

- Please help to sign a demo  version for the attached client.

- In the future, how do I request a demo version correctly?

Thank you very much

Ngoc

Hello

Our SDK/J application is using apache lib httpcore 4.1.3 for communication with server. It has signed with the latest version 5.0.0.944

In the next version 6.0, we will replace Apache httpcore 4.1.3 by httpcore 4.1.10 to fix vulnerability issues in this lib.

The problem that httpcore 4.1.10 works on JavaTM 10x or higher device, it cannot work on JavaTM 7x or less device.

So we will create 2 versions of Kofax MFP client SDK/J application bases on 2 Apache libs above, althought everything else are same.

1st - KofaxRicoh client: it uses httpcore 4.1.3, supports JavaTM 7x device or higher, this version shouldn't be fixed vulnerability issues.
2nd - KofaxRicoh_SE client: it uses httpcore 4.1.10, supports Java 10x device or higher.

My question:

Should we open a Purchase Order to get signature for both versions, or should we open each one?

Do Ricoh charge testing fees for full cert against that client? or one is full cert, and another is mainternace?

Thank you very much

Ngoc

Hi,

We're documenting which MFPs fully support TLS 1.2 communications and which do not. Can you provide information on which communication paths support TLS 1.2 and how to enable it? For example, I'm pretty sure 7.x devices will never support TLS 1.2 but 10.x devices have a TLS 1.2 setting in the configuration page which enables the web server on the MFP to use TLS 1.2 but this doesn't seem to cause Java to use TLS 1.2. Further on from that I expect all Android apps to fully support TLS 1.2. Is there a table or document that shows a all-encompassing cross reference? If this is documented in the SDK I can do further research there as well.

Thanks,

Nick.

I was looking through the documentation for the device emulator and it wasn't clear if it can simulate a job. If it's possible to simulate a job what are the step to do this?

Hi there,

I was wondering if there is a way to pull the system's logout timer setting from an Xlet applicaiton.
 

Hi,

At a customer site they're experiencing Single-SignOn issues with Equitrac and ShareScan intermittently, mostly first thing in the morning across multiple devices (I think they have around 90, over the weekend logs were collected of 10 devices and out of those 3 showed the symptoms - those were MP C3503, MP C4503 and MP C5503 models). Analysis of the RLogs show that the issue is originating from the ShareScan client being left in a bad state following an unusual sleep-wake cycle.

What happens is that during long periods of inactivity, the device wakes up from sleep mode for some reason (likely no user interaction because this happens in the middle of the night), and after just 7-15 seconds it tries to go back to sleep again.

ShareScan receives the resume notification and tries to reconnect to the ShareScan server (connection is closed when going to sleep). This sometimes happens without any problems, but sometimes we've already got the answer back from the server (or sent the request and waiting on the response) and in the middle of processing.

This processing must be finished before we could safely go to sleep and therefore before entering this processing, we call LockMachineState.lockPowerOff().

This seems to have no effect on the device calling our suspend() method for some reason after that call. In the suspend method, we have to wait for the processing of the server interaction to be finished and that can take quite a while. Depending on timing, it can be several seconds, before we could safely go to suspended mode, but it seems that a timer kicks in within the device:

[stdout] [PowerModeDomain] debug: check_Transition_trNightStoppingLockTimeUp_Guard.

When this happens, it seems that the processing Thread and the suspend() thread of our app just dies, leaving it in a state of a half-finished processing, and that causes:

1. we can never release the lockPowerOff, because the app thinks it's still processing something, because the flag at the end of the processing can never be switched

2. we can not process further UI or server interactions, because the app thinks it's still processing something.

This ultimately leads to a frozen app and the user has to reboot the machine.

I'm looking for pointers how we could solve this, I now think that we cannot easily modify the app to always respect the 1 second time limit (or even 2) for the suspend method. We've already refactored the init, start, and resume methods to be in a separate thread, but we cannot do that with suspend and destroy, since it would incorrectly indicate to the device that we've done all cleanup when in fact we have not, and that could cause problems.

So, my questions I could think of currently are, do we have any means to:

1. Prevent the device from even entering the suspend() method and trying to go to sleep mode while we know we're in the middle of something that we cannot interrupt.

2. Prevent the device from immediately go to sleep mode after waking up (having at least a minute between resume and suspend)?

3. Indicate to the device that we're not yet ready to be suspended when the suspend method is called?

Or do you have any other suggestions to solve the issue?

I'm not attaching the RLogs at this time just because they're huge (over 300MB compressed), but if you want I can do that.

Thanks,

Sebestyen Bartha

Hi there,

I'm trying to create a dalp file that will set the icon on the home screen for our applciation. I've read through the Dalp file description but it lacks all the structure of a proper DTD file. Is there an example of a dalp (2.5) file that sets the home icon to an application specific icon or an actual DTD document that I can take a look at?