You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@netbeans.apache.org by "mbien (via GitHub)" <gi...@apache.org> on 2024/07/16 23:08:14 UTC

[PR] Lazy init SMO backend and increase timeout [netbeans]

mbien opened a new pull request, #7587:
URL: https://github.com/apache/netbeans/pull/7587

    - initialize SMO backend only when needed
    - bump request timeout to 15s, since the response time is fairly unpredictable
    - java 17 renovation: instanceof, records, Stream/Colleciton API
   
   
   So I noticed since https://github.com/apache/netbeans/pull/7569 this exception when NB is started and closed _before_ the maven indexer is initialized:
   
   ```
   INFO [org.netbeans.NetigsoModule]: Can't load com.google.gson.JsonElement in package com.google.gson
   java.lang.IllegalStateException: Bundle "reference:file:ide/modules/com-google-gson.jar" has been uninstalled
   	at org.eclipse.osgi.framework.internal.core.AbstractBundle.checkValid(AbstractBundle.java:1175)
   	at org.eclipse.osgi.framework.internal.core.BundleHost.checkLoader(BundleHost.java:183)
   	at org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:225)
   	at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java:1212)
   	at org.netbeans.core.netigso.NetigsoLoader.doLoadClass(NetigsoLoader.java:89)
   [catch] at org.netbeans.NetigsoModule$DelegateCL.doLoadClass(NetigsoModule.java:236)
   	at org.netbeans.ProxyClassLoader.selfLoadClass(ProxyClassLoader.java:260)
   	at org.netbeans.ProxyClassLoader.doFindClass(ProxyClassLoader.java:189)
   	at org.netbeans.ProxyClassLoader.loadClass(ProxyClassLoader.java:140)
   	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:528)
   	at org.apache.maven.search.backend.smo.SmoSearchBackendFactory.create(SmoSearchBackendFactory.java:48)
   	at org.apache.maven.search.backend.smo.SmoSearchBackendFactory.createDefault(SmoSearchBackendFactory.java:41)
   	at org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl.<init>(NexusRepositoryIndexerImpl.java:185)
   	at java.base/jdk.internal.reflect.DirectConstructorHandleAccessor.newInstance(DirectConstructorHandleAccessor.java:62)
   	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:501)
   	at java.base/java.lang.reflect.ReflectAccess.newInstance(ReflectAccess.java:132)
   	at java.base/jdk.internal.reflect.ReflectionFactory.newInstance(ReflectionFactory.java:259)
   	at java.base/java.lang.Class.newInstance(Class.java:804)
   	at org.openide.util.lookup.implspi.SharedClassObjectBridge.newInstance(SharedClassObjectBridge.java:41)
   	at org.openide.util.lookup.MetaInfServicesLookup$Item.getInstance(MetaInfServicesLookup.java:490)
   	at org.openide.util.lookup.AbstractLookup$R.allInstances(AbstractLookup.java:1033)
   	at org.openide.util.lookup.AbstractLookup$R.allInstances(AbstractLookup.java:1013)
   	at org.openide.util.lookup.ProxyLookup$LazyCollection.computeSingleResult(ProxyLookup.java:1348)
   	at org.openide.util.lookup.ProxyLookup$LazyCollection.computeDelegate(ProxyLookup.java:1186)
   	at org.openide.util.lookup.ProxyLookup$LazyCollection.access$900(ProxyLookup.java:1114)
   	at org.openide.util.lookup.ProxyLookup$LazyCollection$1.hasNext(ProxyLookup.java:1314)
   	at org.netbeans.modules.maven.indexer.OnStop.run(OnStop.java:48)
   	at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1403)
   	at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
   	at org.openide.util.lookup.Lookups.executeWith(Lookups.java:287)
   	at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2018)
   ```
   
   I am not completely sure why this happens. The gson wrapper can be found just fine when `NexusRepositoryIndexerImpl` is initialized normally, but when it is loaded from for the first time
   https://github.com/apache/netbeans/blob/1b31400eaaa7d118ebb7c2b053f0b96c95f987e3/java/maven.indexer/src/org/netbeans/modules/maven/indexer/OnStop.java#L48-L52
   it causes the exception. Lazy loading SMO fixes it.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists


Re: [PR] Lazy init SMO backend and increase timeout [netbeans]

Posted by "mbien (via GitHub)" <gi...@apache.org>.
mbien merged PR #7587:
URL: https://github.com/apache/netbeans/pull/7587


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists


Re: [PR] Lazy init SMO backend and increase timeout [netbeans]

Posted by "mbien (via GitHub)" <gi...@apache.org>.
mbien commented on PR #7587:
URL: https://github.com/apache/netbeans/pull/7587#issuecomment-2233460269

   I am no osgi expert but this would be a plausible explanation:
    - when NB shuts down it shuts down the osgi impl, this prevents new osgi jars from loading
    - now NB runs the on-stop task which calls `Lookup.getDefault().lookupAll(RepositoryIndexerImplementation.class))`
    - this can initialize `NexusRepositoryIndexerImpl` if it wasn't used yet, osgi classloading is essentially disabled and will now throw `Bundle "reference:file:ide/modules/com-google-gson.jar" has been uninstalled`
    
   so this is mostly harmless, lazy loading SMO is an easy fix and should have no side effects


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists


Re: [PR] Lazy init SMO backend and increase timeout [netbeans]

Posted by "mbien (via GitHub)" <gi...@apache.org>.
mbien commented on PR #7587:
URL: https://github.com/apache/netbeans/pull/7587#issuecomment-2234076087

   thanks for the review, I will try to split cleanup the rest from now on again. 
   
   My opinion about misuse of records for final classes with immutable fields:
   
   if its a private or package private non-API utility, I would personally go with whatever is most concise or reads best. There absolutely are problems with record overuse, but this is often a problem in API. Interfaces on top and records on the bottom can look convenient, but as soon you need an additional field which can't be passed through the canonical constructor you designed yourself into a corner and have to recompute state in methods again and again.
   
   So I do agree that record overuse can cause problems, but I think in situations where you can change back to a final class at any point in future - it is no real problem. You get a good `toString()` for free which helps when debugging.
   
   `var` overuse however... does actually obfuscate code since it hides types entirely, now add inline hints again and it often uses more space than without `var` - but you know that this is my personal pet peeve ;)


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists