How to put "log4j2.xml" into a module classpath?
Hi all, Firstly apologies. After ~ 15 years with a netbeans platform based product I have never needed to do this. I've struggled for hours trying to add a file (not a jar) to the classpath. "XML ConfigurationFactory will look for log4j2.xml in the classpath." How do I make "log4j2.xml" available in a module classpath? There are many many examples ... but I've found none for a NB platform module. Any direction would be much appreciated. Thx -Damian
Re: Platform wrapped jar cannot access META-INF/service impl via ServiceLoader
Geertjan, Emi and Boris, Many thanks for responding. It seems that Lookup and ServiceLoader are similar, yet different enough to be troublesome. I will need to do more testing, but first I will try to inject the services I need via a method, and not via META-INF/resources. Much appreciated. -Damian On Sat, 17 Aug 2019 at 21:38, Boris Heithecker wrote: > Are you sure that the services your third-party jar wants to look up via > java.util.ServiceLoader.load(Clazz.class) are registered as > META-INF/services entries? > The problem could be that Lookup.getDefault().lookup(Clazz.class) also > looks up services registered in the system file system (layer.xml) in the > /Services subdirectory. > Also, are you sure that your third-party jar does not specify a particular > class loader it finds appropriate when looking up up the service, i.e. > using the method signature java.util.ServiceLoader.load(Clazz.class, > MyLoader.class)? In the default case, > java.util.ServiceLoader.load(Clazz.class) uses > Thread.currentThread().getContextClassLoader() to look up the required > service, but this may be jdk implementation dependent. > Does your external jar require the service at an early phase during > start-up? The implementing module may not be fully ready yet. > Also, make sure no attempt is made to double load the service interface > class from two different classloaders. The NetBeans classloader system > allows, in principle, multiple definitions of the same class with the same > qualified name. But these are not available on the context classloader. > Look through the logs, you get it warning saying something like ".. won't > arbitrarily load class x from class loader y and z". > Maybe this helps. > Boris > > > On Sat, 17 Aug 2019 at 08:12, Damian Carey wrote: > >> Hi all, >> >> We have a "mature" (10+ year old) Netbeans Platform Swing product, which >> has 35+ modules. This all works well. >> >> As usual, when one Netbeans module provides an Implementation we find it >> from other Netbeans modules using the usual idiom ... >> Provider: puts entry in META-INF/services >> Consumer: MyClass myObj = Lookup.getDefault().lookup(MyClass.class); >> >> Our current issue is that we need to add an external jar that is NOT >> built using Netbeans, so it can't use Lookup. I have placed this external >> jar into a module wrapper, and one of our modules depends on it so we can >> successfully start this service as appropriate. Again, everything is >> perfect with this setup. >> >> The problem is that this external jar is looking for services from our >> Netbeans platform product, it is seeking them using standard java >> ServiceLoader capability, but the implementations are not found. >> >> I *think* that if we use the Netbeans System ClassLoader then it CAN >> locate the implementations, however we don't want to use the system >> classloader because it will cause other issues. >> >> Does anyone have any suggestions on how a wrapped jar might access >> Netbeans META-INF/services implementations via vanilla Java ServiceLoader >> SPI interface? >> >> Any suggestions would be hugely appreciated. >> >> Many thanks, >> -Damian >> > > > -- > Boris Heithecker > > > Dr. Boris Heithecker > Lüneburger Str. 30 > 28870 Ottersberg > Festnetz: +49 4205 315834 > Mobil: +49 170 6137015 >
Platform wrapped jar cannot access META-INF/service impl via ServiceLoader
Hi all, We have a "mature" (10+ year old) Netbeans Platform Swing product, which has 35+ modules. This all works well. As usual, when one Netbeans module provides an Implementation we find it from other Netbeans modules using the usual idiom ... Provider: puts entry in META-INF/services Consumer: MyClass myObj = Lookup.getDefault().lookup(MyClass.class); Our current issue is that we need to add an external jar that is NOT built using Netbeans, so it can't use Lookup. I have placed this external jar into a module wrapper, and one of our modules depends on it so we can successfully start this service as appropriate. Again, everything is perfect with this setup. The problem is that this external jar is looking for services from our Netbeans platform product, it is seeking them using standard java ServiceLoader capability, but the implementations are not found. I *think* that if we use the Netbeans System ClassLoader then it CAN locate the implementations, however we don't want to use the system classloader because it will cause other issues. Does anyone have any suggestions on how a wrapped jar might access Netbeans META-INF/services implementations via vanilla Java ServiceLoader SPI interface? Any suggestions would be hugely appreciated. Many thanks, -Damian
Re: jTestField
Swing & all GUI toolkit work takes a while to get your head around, especially if you have only worked on the backend, and there is way too much to put in a few emails. One idea is that Swing (as any GUI toolkit) is fundamentally single threaded. The first thing that strikes me is "setFocus()". More typically you would call a "request-Focus()" type method, and even that would be put in Swing's Event Dispatch Thread (EDT) with an "invokeLater" call. I've hacked around in Swing for 10+ years - but I'm far from an expert. Perhaps stop trying to control the focus (try to leave that to Swing where possible). If you are playing / learning it might be good to follow an existing start-to-finish tutorial. Just some clues, so YMMV. Cheers, On Tue, 11 Jun 2019 at 09:09, wrote: > I hope you folks will bear with me. It’s been 12 years since I retired and > used Java and I never coded the GUI. My job was the backend. > > I’ve designed the form using NetBeans and it does most of the work. > But I’m having trouble with events and focus in jTextField. > > Entering data and depressing entry allows access to the contents the user > has entered but doesn’t go to the next field. Depressing tab moves the > focus to the next field but does not allow access to the data in the first > field. > > I’ve tried to find a .setFocus and am rewarded with about 6 options none > of which do what I want. > > I have searched docs and tutorials and obviously not found the right one. > > Any help will be appreciated. > > There are 10 types of people in the world, > those that understand binary and those that don't. >
Re: NB Platform - running unit tests on multiple machines
OK. I *think* I have a solution.
Ant could not pick up the environment variable without some help.
Issue described in
https://stackoverflow.com/questions/17571595/env-java-home-not-found-ant
HTH & YMMV
Answer ...
Step 1. Set Operating System Environment variable
=
MY_PROJ_PATH = C:/my/path/to/project
(for me, the folder that contains the "build" folder)
Step 2. Tell ANT where environment variables are
-
For each module ... in Important Files > Build Script
add the line ...
before the existing ...
Step 3. Update the test.unit.run.cp.extra
-
javac.source=1.7
test.unit.run.cp.extra=\
${env.QL_PROJ_PATH}/build/cluster/modules/com-acme-impl-nmb1.jar:\
${env.QL_PROJ_PATH}/build/cluster/modules/com-acme-nmb2.jar:
On Sat, 4 May 2019 at 13:04, Tushar Joshi wrote:
> Many years ago (10+?) I used a relative path, but that is not good enough
>> because the relative path is different depending on if you are running unit
>> tests for an individual module, or for the whole module suite.
>>
>> Any suggestions would be most appreciated.
>>
>
> I would check if I can use environmental variables in the file and try
> using something like $PROJECT_HOME before all my paths, so it can be
> changed without changing the file. I have not tried it but may be worth a
> try.
>
> with regards
> Tushar
>
