I have a section of code within a Web App, running in Tomcat 5.0, that makes a call to the javax.print.PrintServiceLookup method lookupPrintServices(null, null). Previously, this code returned an array of substantial size, listing all the printers on the server as expected. Rather suddenly one day recently, it started behaving differently, now returning a zero-size array of no printers instead. Checking rather thoroughly, I was not able to determine what might have changed to cause this method to behave differently now than it did before.
I made a small, stand-alone test program that contained this same method call.
PrintService[] printers = PrintServiceLookup.lookupPrintServices(null, null);
System.out.println("Java Version: " + System.getProperty("java.version"));
System.out.println("Printers found:");
if (printers != null) {
for (PrintService printer : printers) {
if (printer != null) {
System.out.println(" " + printer.toString());
}
}
}
System.out.println("End");
Running this program, it reacted differently, returning the full list of printers. Double-checking, I put the same code (using logging statements instead of System.print statements) in the context initialization method of the Web App, and it still returns zero printers. The method returns different results depending on whether it is run from the web app war or the stand-alone jar.
Some of my colleagues suggested that it might have to do with the Security Manager, and indeed, the documentation for the PrintService class says that certain properties of a Security Manager can alter results from the method call. However, after adding some code to my test to retrieve and view the Security Manager, it appears that there is none in either case.
try {
if (sec != null) {
System.out.println(sec.toString());
sec.checkPrintJobAccess();
}
System.out.println("*-*-*-*-*Printer Access allowed!!");
}
catch (SecurityException e) {
System.out.println("*-*-*-*-*Printer NOT Access allowed!!");
}
The result is that the Security Manager is null in both cases.
Trying it on a different server, both the web app and the stand-alone jar versions of doing things return no printers. There is no consistency that I can find.
What is going on here? What is causing this javax method call to return different results in different situations? What could have changed about the web app to alter its behavior between one day and the next?
Try starting the server with this option -DUseSunHttpHandler=true to initiate the HTTP URL Connection with JDK API instead of server API.
Hope this works for you too.
Related
I am developing an application for a DigitalPersona U.are.U 4500 fingerprint reader and using the U.are.U 2.2.3 SDK Java API.
The sample Java application that ships with the SDK works flawlessly.
However, when I try to do the same thing in my own sample application, the call to the Reader.Capture() method never returns, even though I can see the reader flashing when recording my fingerprint.
Below is a variation on the sample code I have tried with.
Other things I have tried:
Running the capture code in an instance of the class (i.e. not in a static context)
Running the capture operation in its own thread as well, but the results are the same.
Using the CaptureThread class from the demo application
The only difference I can see between my sample and the SDK sample app is that the latter is a graphical application. But why would that make a difference?
Unplugging the device causes the call to fail with an exception. That is about the only way I can get it to return.
import com.digitalpersona.uareu.*;
public class Main{
static Reader r;
public static void main(String[] args) {
try {
// Pick first available reader
ReaderCollection rc = UareUGlobal.GetReaderCollection();
rc.GetReaders();
r = rc.get(0);
if (r==null)
return;
// Open Reader
r.Open(Reader.Priority.COOPERATIVE);
System.out.println(r.GetStatus().status); // Outputs READY
// The following call just hangs and never returns...
Reader.CaptureResult
cr = r.Capture(Fid.Format.ISO_19794_4_2005, Reader.ImageProcessing.IMG_PROC_DEFAULT, 500, -1);
System.out.println(cr.quality.name()); // Just to test
} catch (UareUException e) {
e.printStackTrace();
}
}
}
The last two parameters, the two ints, passed to the Capture method are the resolution and the timeout respectively; passing -1 for the timeout blocks indefinitely. This is taken from the sample application as well.
I finally managed to get an example working.
Strange as it may seem, it only works in the context of a Java GUI application.
So, simply extending a JFrame and starting the reader capture on a separate thread seems to be sufficient.
This requirement is not specified anywhere in the SDK documentation that I can see.
UPDATE
It seems the problem is worse than I initially thought. Not only must the API be called in the context of a Java GUI application, but the GUI must also be in focus, otherwise the capture call simply does not return.
I have verified this with the example SDK applications. The Capture() method does not return if the apps are not in focus. This also applies to the C# examples, where the windows must be in focus, which suggests that this is built into the DLLs that ship with the solution.
This is terrible for our scenario, where we want to develop a local service that a browser can communicate with because, while the browser is in focus, obviously the Java application is not.
I faced the similar issue and it can be fixed by opening a reader in exclusive mode as below,
m_reader.Open(Reader.Priority.EXCLUSIVE);
Refer to below lines from documents,
public static final Reader.Priority COOPERATIVE
Client uses this priority to open reader in cooperative mode. Multiple clients with this priority are allowed. Client receives captured images if it has window with focus.
public static final Reader.Priority EXCLUSIVE
Client uses this priority to open reader exclusively. Only one client with this priority is allowed.
I have a testing application written in java-selenium. This app tests e-shop whether it is possible to buy products and many other functionalities.
Few days ago, I added a new functionality that tests whether the payment was successful. In case the order was not successful, "#errorBox" is added into the URL, therefore I am checking whether the URL consists of this sequence:
public void paymentCheck() {
String URL = driver.getCurrentUrl();
if (URL.contains("#errorBox")) {
data.put("paymentFailed", "true");
} else {
data.put("paymentFailed", "false");
}
}
If there is "#errorBox", paymentFailed = true is added to the dataset. Then I check its presence:
.paymentCheck();
if (dataRow.get("paymentFailed").equals("true")) {
resultLine.addTestResultLineItem(
new TestResultLineItemMessage("ERROR: Payment declined, transaction was not accepted.").setResult(Result.FAIL)
);
driver.quit();
}
And the problem is: When debugging, the check works just fine. When the app is ran directly, test fails because the application skips setting result as FAILED and does not kill the driver either.
Any ideas what is wrong here?
Any help is appreciated,
Thanks
When in debug model, some latency insert between each step, when run directly, we should add some sleep/wait before driver.getCurrentUrl() too.
From my experience, generally payment take little long time.
The script is working fine in debug mode and is failing in normal run. This is a clear indication of latency. Include Thread.sleep(seconds) in your code. Though it is not recommended to use thread.sleep(), it is a better option, since we don't know the nature of the application. Else you can try Implicit wait or explicit wait condition in your code.
When I run the following Java code on a Lotus Domino server, I get different results depending on where the code runs.
private void doViewStuff(Session session, PrintStream out) throws NotesException {
Database db = session.getDatabase(null, "myDatabase.nsf");
View view = db.getView("myViewName");
Document doc = view.getFirstDocument();
while (doc != null) {
out.println("doc: " + doc.getUniversalID());
doc = view.getNextDocument(doc);
}
ViewEntryCollection entries = view.getAllEntries();
ViewEntry entry = entries.getFirstEntry();
while (entry != null) {
System.out.println("entry: " + entry.getColumnValues());
entry = entries.getNextEntry(entry);
}
}
When I run the code on the server as a Java agent, there are 37235 documents in the view.
When I run the code in a standalone client, there are only 37217 documents in the view, and the code is much, much slower.
Details and execution environment:
The server version is 8.5.3, the NCSO.jar I used for the client has SHA-1 d879f8992aae49a06769a564217633a9e0fbd1b6.
The database myDatabase.nsf contains about 150000 documents, each with a file attachment.
The missing documents do not appear in a block, they appear between index 10000 and 20000.
In both cases the code runs as the same user account.
What might be the reason that 18 of the documents cannot be found?
Update and Clarification
Upon further inspection, it turned out that I had indeed run the code with different user accounts, and that the inaccessible document had some Reader Names fields.
On the server I had this configuration, although I configured the agent to "Run on behalf of" CN=User Name/O=domain. It didn't matter whether I ran the agent from the Domino Console or via HTTP:
effectiveUserName=CN=User Name/O=domain
commonUserName=domino01
userName=CN=domino01/O=domain
On the client I had this configuration:
effectiveUserName=[NotesException: Not implemented]
commonUserName=User Name
userName=User Name/O=domain
And that was even though I used this code in the client:
Session session = NotesFactory.createSession("127.0.0.1", "User Name", "password");
You say that in both cases the code runs as the same user account, so I want to trust that this is true. I presume, therefore, that you have ruled out Reader Names fields as cause of the discrepancy.
In that case, have you checked the IsValid() property of the ViewEntry objects when you process them in the agent running on the server? Perhaps the NCSO.jar implementation that you are using for the client-side code is filtering out the objects where IsValid() would return false.
I'm experiencing some problems when trying to retrieve the slot information for VMware clusters with admission failover level control policy enabled. I use the VI Java API.
When calling the following method:
clusterComputeResource.retrieveDasAdvancedRuntimeInfo()
I either get the following Exception:
java.rmi.RemoteException: VI SDK invoke exception:java.rmi.RemoteException: Exception in
WSClient.invoke:; nested exception is:
java.lang.NoSuchFieldException: slotInfo
at com.vmware.vim25.ws.WSClient.invoke(WSClient.java:122)
at com.vmware.vim25.ws.VimStub.retrieveDasAdvancedRuntimeInfo(VimStub.java:269)
or I get the result which is of type ClusterDasAdvancedRuntimeInfo
but I need the subclass ClusterDasFailoverLevelAdvancedRuntimeInfo in order to get the SlotInfo field (casting to the required sublcass doesn't work either).
I tried to access the web service of a vcenter directly via Soap UI and it worked without any problems, but with the vijava API it just doesn't.
Thanks in advance for any help!!!
After a lot of of debugging to see what the VI Java API does internally, I found out that if the web service client (wsc) is invoked with the name of the sublcass instead of the name of the superclass (as last parameter), the response will be converted correctly. This way the slot information can be retrieved without any problems. Here is the solution for those experiencing the same problems:
ClusterDasFailoverLevelAdvancedRuntimeInfo clusterDasFailoverLevelAdvancedRuntimeInfo = null;
try {
final Argument[] paras = new Argument[1];
paras[0] = new Argument("_this", "ManagedObjectReference", clusterComputeResource.getMOR());
clusterDasFailoverLevelAdvancedRuntimeInfo = (ClusterDasFailoverLevelAdvancedRuntimeInfo) serviceInstance.getServerConnection().getVimService().getWsc().invoke("RetrieveDasAdvancedRuntimeInfo", paras, "ClusterDasFailoverLevelAdvancedRuntimeInfo");
} catch (final Exception e) {
//error handling
}
(Note that this only works if admission control failover level policy is enabled!!!)
I'm working with the DFS Java API and was wondering whether anyone knows a simple way to configure a client-side timeout for service-calls that can be configured on the service context, for example?
I have experienced some rare occasions where a Documentum repository was not responding, that's why I am considering a general timeout for all DFS calls.
For testing a hanging service call, I created a dummy TBO implementation that simply blocks the thread for 10 minutes when updating the document:
#Override
public void saveEx(boolean keepLock, String versionLabels) throws DfException {
if (isNew() == false) {
try {
Thread.sleep(1000*60*10);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
super.saveEx(keepLock, versionLabels);
}
I'm not sure if this behaves exactly like a hanging service call, but at least in my tests it worked as expected - my invocations of the update method of the Object Service took about 10minutes.
Is there any configuration I have not yet found, or maybe a runtime-property to pass to the service context to configure the timeout?
I would prefer using existing features of DFS for this instead of implementing my own mechanism.
Have you tried editing the value in dfs-runtime.properties? I don't think the timeout can be context-specific, but you should be able to change it for the client as a whole.
Reposted from https://community.emc.com/message/3249#3249
"Please see the Server runtime startup settings section of the Deployment guide.
The following list describes the precedence that dfs-runtime.properties files take depending on their location:
local-dfs‑runtime.properties file in the local classpath
runtime properties file specified with ‑Ddfs.runtime.properties.file
dfs‑runtime.properties packaged with emc‑dfs‑rt.jar
For example, settings in the local-dfs‑runtime.properties file on the local classpath will take precedence of identical settings in the dfs‑runtime.properties file that is located in emc‑dfs‑rt.jar or the one specified with the ‑D parameter. The DFS application must be restarted after any changes to the configuration. As a best practice, use the provided configuration file that is deployed in the emc‑dfs‑rt.jar file for your base settings and use an external file to override settings that you specifically wish to change."