java.lang.IllegalArgumentException occurs after download V3 and select domain1 to register
Steps To Reproduce:
1. Start Netbean IDE Dev 09112 build on a Solaris x86b machine
2. Select to activate Glassfish V3 plugin
3. Select to add server > select Download V3 now > select domain1 > click Finish
java.lang.IllegalArgumentException: Trying to add a library of unknown type: j2se
[catch] at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1005)
Created attachment 75732 [details]
just to clarify... was this the 7.0 dev build or the nbjavaee6 dev build?
It's a nbjavaee6 dev build. I build its myself
issue 157287 seems like it is a related problem.
so does issue 150486
The v3 module does not depend on the java cluster (since it is in the ide cluster).
The j2se library type is in the java cluster...
This allows the user to follow this path and end up with the result described here.
if we make glassfish.javaee depend on java.j2seplatform the issue clears up... but that doesn't seem like the right fix.
JavaEEServerModuleFactory.ensureCometSupport should be prepared for there to be no j2se library type defined. This would
happen if the java cluster were not enabled.
Perhaps the Java functionality is disabled due to the ergonomics cluster? If so, add ERGONOMICS keyword.
on exception... add a property change listener to the library manager to try to create the library later on. the theory
is that the j2se type will get defined and some other module will register a j2se library successfully. Once that
happens, this library should register successfully.
if I build the IDE and then clean the ergonomics jar from the build I cannot reproduce this issue.
Following jglick's advice about the keyword. I will keep the issue assigned to me since there is still a problem with
the plugin code.
Probably the library is registered before the right declaration is parsed.
checked in fix for symptom... but it doesn't address the fact that the j2se library type should be available at the
point where the code to create the libraries is called.
Tomáši, we have a problem. The IAE from
is correct. The j2se library type is unknown. Of course, because j2se library type is defined in Java and Java is
Shall the IAE be changed to warning only? I can do that, if you tell me.
Shall the code in glassfish.javaee.JavaEEServerModuleFactory be modified?
Thanks in advance for your valuable insight.
One thing that I noticed while working on this...
There are a number of modules activated when the GF v3 module is activated... but java.j2seplatform is not one of them.
When I looked at some of the project info in java.j2seplatform, I noticed that it is only expose apis to the two import
So, it kind of makes sense that the module isn't activated...
If you can modify the module "glassfish.javaee" to have dependency on "java.j2seplatform", then I guess this problem
will also be fixed.
java.j2seplatform only exports to friends... so we would need to change both projects.
I have already changed the serverplugin to avoid triggering the IAE... but that 'fix' is really kind of a hack.
Integrated into 'main-golden', will be available in build *200901281643* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Vince Kraemer <email@example.com>
Log: #156658 : don't throw exception if j2se library type isn't registered yet... try later
"java.j2seplatform only exports to friends... so we would need to change both projects" - no, you need a runtime dep,
not a compile-time dep. Friend packages apply only to compile-time deps. Any module can declare a runtime-only dep on
any other module if it wants.
Somewhat better style would be for java.j2seplatform to declare that it provides a token, say
'org.netbeans.spi.project.libraries.LibraryTypeProvider.j2se', and for glassfish.javaee (and any other module which
needs to create j2se-type libraries) to require this token.
Created attachment 76348 [details]
Provides/requires between glassfish.javaee and java.j2seplatform
Works. BTW I picked the name 'org.netbeans.spi.project.libraries.LibraryTypeProvider.j2se' because the prefix is the
actual FQN of the service which is provided. Such a convention would help make token names less arbitrary.
I agree with Jesse's name choice for the token.
I agree as well (I prepared my patch before seeing Jesse's comment). Can you please integrate this patch, then?
I do not own java.j2seplatform, so that module's owner should export the token before I start to use it, right?
Obviously, there needs to be changes to the architecture documents in both modules, too. The owner of java.j2seplatform
would need to publish changes to the apichanges doc, too.
Should be made as one Hg changeset. If you do not feel comfortable patching java.j2seplatform, assign to jjancura,
jtulach, jglick, or just prepare a final patch including recommended token and arch.xml and ask for final review of impl.
The DEFECT part of this is resolved... so I am going to convert this to an ENHANCEMENT.
Are you sure there is no remaining defect? The exception is not thrown anymore, but the glassfish library is not going
to be available in Library Manager, imho.