This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 222408 - System broken due to apache logging provided by org-netbeans-libs-amazon module
Summary: System broken due to apache logging provided by org-netbeans-libs-amazon module
Status: NEW
Alias: None
Product: webservices
Classification: Unclassified
Component: SoapUI (show other bugs)
Version: 7.2
Hardware: All All
: P2 normal (vote)
Assignee: omatzura
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-11-19 15:38 UTC by rdelaplante
Modified: 2012-12-13 20:13 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 195376


Attachments
stacktrace (5.52 KB, text/plain)
2012-11-19 15:38 UTC, rdelaplante
Details

Note You need to log in before you can comment on or make changes to this bug.
Description rdelaplante 2012-11-19 15:38:12 UTC
Build: NetBeans IDE 7.2 (Build 201207171143)
VM: Java HotSpot(TM) 64-Bit Server VM, 23.1-b03, Java(TM) SE Runtime Environment, 1.7.0_05-b06
OS: Windows 7

User Comments:
rdelaplante: Reported a bug, then in the exception report tab I saw it said "Yo can check bug #12345 in Bugzilla for more information."  I clicked the bug link and got this exception




Stacktrace: 
java.lang.ClassNotFoundException: org.eclipse.mylyn.commons.net.AuthenticationCredentials
   at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
   at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
   at java.security.AccessController.doPrivileged(AccessController.java:0)
   at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
Comment 1 rdelaplante 2012-11-19 15:38:14 UTC
Created attachment 128076 [details]
stacktrace
Comment 2 Marek Fukala 2012-11-30 09:51:59 UTC
Jardo. I do not understand how the log4j makes the system broken and if there's an alternative for the bundling.
Comment 3 Marek Fukala 2012-12-05 12:44:02 UTC
Jardo, can you please answer the comment#2?
Comment 4 Jaroslav Tulach 2012-12-06 07:34:57 UTC
If you look at
http://statistics.netbeans.org/exceptions/messageslog?id=630873
you will see warnings like

Will not load class org.apache.log4j.RollingFileAppender arbitrarily from one of ModuleCL@75efb813[org.netbeans.modules.html.validation] and ModuleCL@55378d8e[com.eviware.soapui.netbeans.module] starting from SystemClassLoader[549 modules]; see http://wiki.netbeans.org/DevFaqModuleCCE

and

Will not load class org.apache.commons.logging.impl.Jdk14Logger arbitrarily from one of NetbinoxLoader delegating to org.apache.commons.logging_1.1.0 and ModuleCL@322f8695[org.netbeans.libs.amazon] starting from SystemClassLoader[549 modules]; see http://wiki.netbeans.org/DevFaqModuleCCE

which later prevents essential Mylyn modules to start and renders the bugtracking subsystem unusable.


We should have one org.apache.commons.logging available in the system and not its copies all over including ide/modules/ext/log4j-1.2.15.jar and enterprise/modules/ext/aws-sdk/commons-logging-1.1.1.jar. Btw. possibly only the second failure is the critical one.
Comment 5 Denis Anisimov 2012-12-06 07:49:18 UTC
I have no idea why  Jaroslav Tulach thinks this is 
webservices/manager functionality. It has no any relation to it. Find 
the appropriate  area and reassign the issue correctly.
Comment 6 Jaroslav Tulach 2012-12-06 08:08:14 UTC
The bug seems to be in an amazon releated and there is a single bugzilla category for amazon:

$ grep amazon .nbbugzilla-components 
websvc.saas.services.amazon = webservices/manager
Comment 7 Denis Anisimov 2012-12-06 09:50:28 UTC
(In reply to comment #6)
> The bug seems to be in an amazon releated and there is a single bugzilla
> category for amazon:
> 
> $ grep amazon .nbbugzilla-components 
> websvc.saas.services.amazon = webservices/manager

Yes, that's the correct websvc.saas.services.amazon = webservices/manager.
But I have no idea how the issue in the org-netbeans-libs-amazon module 
relates to this information. 
May be the key of your misunderstanding is 
websvc.saas.services.amazon != org-netbeans-libs-amazon ?
Try to change your "grep" condition.
Comment 8 Jaroslav Tulach 2012-12-06 09:54:48 UTC
Maybe the content of .nbbugzilla-components is not up-to-date. Anyway I am almost sure the bug belongs to enterprise area. Passing to Petr who may have more insight into Hg -> Bugzilla mapping of his team modules.
Comment 9 Petr Jiricka 2012-12-06 12:18:43 UTC
enterprise/modules/ext/aws-sdk/* belongs to Amazon Cloud component, reassigning.

Regarding the mapping, I found Amazon Cloud here: http://quality2.netbeans.org/dashboard/web/viewmapping.php

Cc'ing Lada - Lado, what is the relationship between this page, and the .nbbugzilla-components file? Shouldn't there be just one source of truth?
Comment 10 Vladimir Riha 2012-12-06 12:41:00 UTC
(In reply to comment #9)
> Cc'ing Lada - Lado, what is the relationship between this page, and the
> .nbbugzilla-components file? Shouldn't there be just one source of truth?

Unfortunately there is no relation. Until now I didn't know about .nbbugzilla-components file and I don't how this file is being used. If it should be some mapping module-component then it really seems to be outdated/incomplete.

Mapping at the URL above is used only in dashboard to process source lines statistics.
Comment 11 David Konecny 2012-12-06 21:40:54 UTC
(In reply to comment #4)
> We should have one org.apache.commons.logging available in the system and not
> its copies all over including ide/modules/ext/log4j-1.2.15.jar and
> enterprise/modules/ext/aws-sdk/commons-logging-1.1.1.jar. Btw. possibly only
> the second failure is the critical one.

Jarda,

libs.amazon is a wrapper module around 'AWS SDK for Java' and enterprise/modules/ext/aws-sdk/commons-logging-1.1.1.jar is one of the AWS SDK's internal files. The file was part of SDK download and I do not think it would be a good idea to arbitrarily change SDK's dependencies. It may or may not impact the SDK. Does module system provide some mechanism how to deal with this scenario? I read http://wiki.netbeans.org/DevFaqModuleCCE but I'm not sure how to apply it. The SDK from libs.amazon is only used from cloud.amazon module.

Any advice would be appreciated. Thanks.
Comment 12 David Konecny 2012-12-10 21:16:04 UTC
Jarda, please advice how this should/could be resolved. Thanks.
Comment 13 Jaroslav Tulach 2012-12-10 21:54:06 UTC
Assigning to Petr as the one responsible for the area and the one responsible for his people. Executive summary is to not export apache packages twice. You can either share them or not export them.
Comment 14 Petr Jiricka 2012-12-10 22:12:29 UTC
I am confused, is libs.amazon exporting commons-logging? I see its <friend-packages> does not mention anything about commons-logging.
Comment 15 Marek Fukala 2012-12-11 13:06:27 UTC
The situation is the same with html.validator. It uses log4j-1.2.15.jar only internally and exposes no API.

I agree that duplicating libraries makes no sense if there are no strong reasons for it (e.g. dependency on some very specific version) 

As I haven't found any nb module sharing the log4j, I can take the latest version of http://logging.apache.org/log4j/1.2/, create o.apache.log4j module and add an implementation dependency to such module in html.validator along with removing the bundle log4j  from the html.validator. 

But this will not fix the issue until the com.eviware.soapui.netbeans.module does the same, or will it Jardo???
Comment 16 Petr Jiricka 2012-12-11 20:13:43 UTC
Assigning back to Jarda - thanks in advance for clarification.
Comment 17 Jaroslav Tulach 2012-12-13 11:33:46 UTC
The NetBeans module system supports duplicated classes only if they are in isolated modules and nobody tries to load them dynamically using system class loader (accessible via Thread.currentThread().getContextClassLoader()). 

Apparently somebody is trying to load Jdk14Logger classes from the SystemClassLoader. I can trigger to error using following action:

@ActionID(
        category = "Build",
        id = "df.LoadCommonLogging")
@ActionRegistration(
        displayName = "#CTL_LoadCommonLogging")
@ActionReference(path = "Menu/File", position = 0)
@Messages("CTL_LoadCommonLogging=Load Common Logging")
public final class LoadCommonLogging implements ActionListener {

    @Override
    public void actionPerformed(ActionEvent e) {
        try {
            ClassLoader l = Thread.currentThread().getContextClassLoader();
            Class<?> c = l.loadClass("org.apache.commons.logging.impl.Jdk14Logger");
            JOptionPane.showMessageDialog(null, "Loaded ok: " + c);
        } catch (ClassNotFoundException ex) {
            Exceptions.printStackTrace(ex);
        }
    }
}

Having dependency on shared libraries provided by NetBeans already would fix the issue.
Comment 18 Petr Jiricka 2012-12-13 14:10:37 UTC
Thanks Jarda for the investigation. The main argument against using the common module is, as David writes in comment 11: "The file was part of SDK download and I do not think it
would be a good idea to arbitrarily change SDK's dependencies."

On the other hand, since we already have library wrapper module o.apache.commons.logging which uses the exact same version of commons.logging as the Amazon SDK (and there are 6 modules that already depend on it), it should be possible to switch to this library. 

I understand that another possibility would be to find out which module is accessing the commons.logging classes using Thread.currentThread().getContextClassLoader() and avoid that. But for that we would need to be able to reproduce - right now I can't.

So one question to Ryan: where can one find the com.eviware.soapui.netbeans.module plugin version [4.5.0 120329] that you use? That would help us reproduce I guess. Thanks.
Comment 19 rdelaplante 2012-12-13 15:06:32 UTC
I downloaded SoapUI open source version from here:
http://sourceforge.net/projects/soapui/files/soapui-netbeans-plugin/
Comment 20 David Konecny 2012-12-13 19:53:25 UTC
(In reply to comment #18)
> On the other hand, since we already have library wrapper module
> o.apache.commons.logging which uses the exact same version of commons.logging
> as the Amazon SDK (and there are 6 modules that already depend on it), it
> should be possible to switch to this library. 

We can do this but that's not the cause of this problem AFAICT.

I run grep on cloud.amazon module for "getContextClassLoader" and found nothing. That does not guarantee that AWS SDK itself does not uses context classloader. Running grep on eviware/soapui I found http://www.soapui.org/xref/com/eviware/soapui/SoapUIExtensionClassLoader.html but I cannot say whether that's the cause of this problem or not. If this bug report only happens after eviware/soapui gets installed into NetBeans then owner of eviware/soapui NetBeans module should evaluate this.
Comment 21 Petr Jiricka 2012-12-13 20:13:44 UTC
Ok, we even have a bug category for the SoapUI plugin, so I am reassigning. Ole, can you please look into this as the SoapUI author? Thanks.