The problem
Our web app creates a java.net.URL passing our custom implementation of a URLStreamHandler to the constructor.
On that URL, we call url.openConnection().
The java.net.URL code calls openConnection() on our handler.
At this point, we get a NoClassDefFoundError for a class used by the handler.
This happens with Glassfish 3.1, but doesn't happen with Tomcat, WebLogic, and JBoss. (Also, it used to work on older versions of Glassfish.)
What I tried
I tried adding a glassfish-web.xml to tell Glassfish to load classes first from the web app (as expected), but this doen't solve the problem.
<glassfish-web-app>
<class-loader delegate="false"/>
</glassfish-web-app>
How can I solve this problem, and why is this happening?
GF delegation model always delegates java.* and javax.* up the classloader chain.
A NoClassDefFoundError can be caused by the JVM not finding a class, but also to a failure of that happened earlier in a static initializer. The message for the NoClassDefFoundError was Could not initialize class org.orbeon.oxf.resources.handler.HTTPURLConnection, and there was indeed an error that happened earlier in the static initializer for that class. Solving that error fixed the NoClassDefFoundError.
Related
This question is a follow up to my previous question, DryIOC Decorator and InResolutionScopeOf
What I'm trying to do is create EF DbContext instances in the resolution scope of both IAsyncRequestHandler and IAsyncNotificationHandler, meaning the context injected in a request can't be the same as one injected in a notification (published from a request). Since the notifications are published from inside the request handlers, this nesting is creating some troubles with my desired setup.
It is worth noting that each DbContext injected in a given IAsyncRequestHandler or IAsyncNotificationHandler instance needs to be the same across their own decorators.
I've created a dotnetfiddle with my attempt at setting this up https://dotnetfiddle.net/KiFCHY. (I've ommitted decorators in this example)
It contains a RequestHandler which prints a message when it is called, and it then publishes a notification, which prints another message. However, as you can see, the notification isn't called because MediatR cannot get the IAsyncNotificationHandler instance (because it can't resolve the DbContext).
Is this setup possible?
Thanks
Found the root cause: ResolveMany<object>(serviceType) which is used in MediatR setup.
An object identifies that you need to pass run-time required serviceType. But DryIoc has an issue of using service type object instead of required type to find the matching resolution scope. And an object is definitely not assignable to IAsyncNotificationHandler<T>.
Here is the modified fiddle
Stay tuned for the fix. I will update my answer with the fix version.
Updated with fix version
The fix is released with DryIoc 2.9.2. Here is fiddle which uses it. Thanks for asking and surfacing 2 issues - real use cases matter the most.
I am trying to migrate a legacy app that is using camel/cxf (offers some web services that include transformations) to Websphere Liberty 16.0.0.03 (IBM JRE 1.8). Tests are failing because the app uses extensions functions. I tried to disable secure processing as described here.
This change has no effect. That's why I try to switch to Saxon Implementation globally by setting System Property "javax.xml.transform.TransformerFactory=net.sf.saxon.TransformerFactoryImpl" in jvm.options config file. Again - this does not work.
While debugging I can see, that com.ibm.ws.webcontainer.osgi.mbeans.PluginGenerator$2 is overriding the Property with com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl during Server start. I can see a method "PluginGenerator.revertTransformerFactoryIfNeccessary" in the stack that seems to trigger the change. Afterwards all FactoryFinder.find() will return the non-Saxon implementation.
Can anyone suggest how to either disable secure-processing successfully
or
a way to successfully set a custom TransformerFactory?
BTW: It seems to me like these 2 are bugs - do I report these as regular PMR?
EDIT: possible workaround
As result of the helpful suggestions I added an '#WebListener' that will sets the System Property within the constructor (setting it in contextInitialized is too late as stylesheets seem to be compiled during application start and thus processing fails tests). I bundle this a "patch-jar" with the legacy app.
The Liberty web container plugin generator will only override the xml transformer factory if the IBM JDK is being used.
While the web container performs plugin generation using the IBM JDK, it will swap to an alternate transformer factory, and then reset to the IBM JDK default of which is com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl.
I think it is worth opening a PMR here. The PluginGenerator should not assume that it started with the default xml transformer factory, and should instead save off the value of javax.xml.transform.TransformerFactory and then restore it after plugin generation has completed.
Temp workaround:
Since the PluginGenerator only swaps the XML transformer factory if you're running on the IBM JDK, you could change to an alternate JDK until your PMR gets resolved.
I agree that this is a bug. The official route for reporting problems is a PMR, but there is enough here for us to understand the problem and fix it through our beta program. If you want to get an iFix on a released version of the product (rather than waiting for it to come out via the beta program) then you will need to raise a PMR.
I'm using the Java client library for the Directory API from here:
https://developers.google.com/api-client-library/java/apis/admin/directory_v1
The com.google.api.services.admin.directory.model.User model has changed from 1.16 to 1.19.
In the old version I used to be able to do this:
List<UserAddress> userAddressList = user.getAddresses();
for(UserAddress userAddress : userAddressList) {
///
}
But now user.getAddresses is returning an Object. Same deal for getOrganizations, phones, etc... These all return an Object which upon further inspection looks like:
List<ArrayMap<String, String>>
ArrayMap extends GenericJson.
What do I have to do to get at the UserAddress, other then going back to the previous version?
It's a bug (from my point of view) in the latest versions. Use an older one like 1.16, 1.17 or the first 1.18 (latest 1.18 also have the bug).
The same thing happened in the C# client and back in May 2015 a Google developer named Eric Koleda replied:
A change to the backend had the unintended consequence of changing the discovery document for the service, making the addresses field (and others) being marked as type=any. This causes problems for strongly types languages like .NET, as you've found. The team is aware of the issue but it's unclear when a fix will be available.
However the C# client still has this problem, so I would assume the Java client does as well.
Here are a couple of issues I found in Google's issue tracker specifically for this problem in the Java client, but neither has seen any progress yet:
Issue 3645: Broken code generator for Directory API in Java client: User class lacking explicit types
Issue 3730: Latest version of the Directory API client returns Object instead of correct class
I'm using ShrinkWrap to start Jetty server in my integration tests.
Problem:
When I start my test jetty-server and than make mockup of my controller - mockup doesn't work!
I suggest that the reason is different classloaders: JMockit - AppClassLoader, Jetty - WebAppClassLoader.
Question:
How to make mocking works fine?
P.S.
I've googled that -javaagent:jmockit.jar option may help. But it doesn't. Is it necessary for maven project based on 1.7 jdk?
ADDITION:
I've written demo to illustrate my problem. You can find it by the reference.
About my demo:
Except of ten stokes of code, it is identical to those project.
I've only added JMockit and a single mock to illustrate the problem.
You should see JettyDeploymentIntegrationUnitTestCase.requestWebapp method: in those method we make mock which doesn't work.
You can check that Jetty & JMockit loads classes by siblings classloaders, so JMockit simply doesn't see Jetty's classes
URLClassLoader
|
|-Launcher$AppClassLoader
|-WebAppClassLoader
The JUnit test in the example project is attempting to mock the ForwardingServlet class. But, in this scenario with an embedded Jetty web server, there are actually two instances of this class, both loaded in the same JVM but through different classloaders.
The first instance of the class is loaded by the regular classloader, through which classes are loaded from the thread that starts the JUnit test runner (AppClassLoader). So, when ForwardingServlet appears in test code, it is the one defined in this classloader. This is the class given to JMockit to mock, which is exactly what happens.
But then, a copy of ForwardingServlet is loaded inside the deployed web app (from the ".class" file in the file system, so not affected by the mocking as applied by JMockit, which is in-memory only), using Jetty's WebAppClassLoader. This class is never seen by JMockit.
There are two possible solutions to this issue:
Somehow get the class object loaded by WebAppClassLoader and then mock it by calling the MockUp(Class) constructor.
Configure the Jetty server so that it does not use a custom classloader for the classes in the web app.
The second solution is the easiest, and can be done simply by adding the following call on the ContextHandler object created from the WebArchive object, before setting the handler into the Jetty Server object:
handler.setClassLoader(ClassLoader.getSystemClassLoader());
I tested this and it worked as expected, with the #Mock doGet(...) method getting executed instead of the real one in ForwardingServlet.
I've beenworking with the IntraWeb framework on Borland C++Builder. Sometimes it happens that an application crashes because of a strange uncaught exception:
An unhandled application error has occured within My IntraWeb Application.
...
Error message raised by the application: Class TIWTimer not found
This happens when a new session is started. For example, by entering the address in a browser.
Also, the message appears in the classic IntraWeb error web page
The class that cannot be found is either TIWTimer or TIWButton but I think this is irrelevant.
The problem seems to occur randomly and sometimes goes away with a rebuild, but other times it will go away by rewriting the code or starting from a new project.
So, the question is, how come the link error is not found at link-time?
Why does it occur at all, since those classes belong to the standard IW library?
Has anyone had the same issue?
How can it be solved?
Use Intraweb XII in C++Builder XE2, it has good improvement and bug fixes.
in this version you can assign urls to forms, for example:
myhost/login.htm or myhost/login.aspx
for more information see this