I don't think this to be P3 enhancement.

Consider following (NB6.1):
1) install attached Geronimo server plugin module
2) register server with it (Geronimo 2), do not start it
3) create visual jsf web project (J2EE 1.4, Java EE 5 support on the server side has still bugs)
4) run the project - failure because of JMX usage

Created attachment 55948 [details]
geronimo module

Marking as incomplete until I better understand rationale of supporting JMX with Visual Web).

Are Visual Web projects expected to be interoperable with JMX?

I'm surprised this issue comes up post 6.0.  Visual Web has been using an InitialContext since NetBeans 5.5.
Then is it that there was no motivation to use JMX with Visual Web projects in 5.5 or this is a recent discovery ?

This was marked as an enhancement since:
1) (An alternative to using an Initial Context) is a big change to Visual Web projects
2) It is risky or may not be possible to use another lookup than JMX

correction to the previous comment:

> 2) It is risky or may not be possible to use another lookup than JMX

should say:

"It is risky or may not be possible to use another lookup than an InitialContext"

in desc2

> 4) run the project - failure because of JMX usage

I think you meant "the project" is a visual web project

Still, not sure if this will be fixed for 6.1

Clarified:

1) install attached Geronimo server plugin module
2) register server with it (Geronimo 2), do not start it
3) create visual jsf web project (J2EE 1.4, Java EE 5 support on the server side has still bugs)
4) run the created visual web project (created in step 3) - failure because of JMX usage in serverplugin (not in project)

I think Geronimo is not needed to reproduce this issue.

Executing JMX is sufficient, no?

Also, please follow up :

> I'm surprised this issue comes up post 6.0.  Visual Web has been using an InitialContext since NetBeans 5.5.
> Then is it that there was no motivation to use JMX with Visual Web projects in 5.5 or this is a recent discovery ?

Probably there were no plugins using jndi based jmx connection. Or users using them didn't install visual jsf.

This issue is not about using jmx in project - it is about interoperability with other plugins using jndi based jmx
connection.

This really isn't a defect.  Creating an InitialContextFactoryBuilder was by design.  Creator/Visual Web require an
InitialContext at design-time (not when an Application server is running)  The reason is component binding uses a
CachedRowSet library to get a connection (initially when DnD a database table onto the page) and an InitialContext is
required to bind the connection and the data source.  The Sun CachedRowSet library is not a NetBeans library and
requires a JNDI lookupn (can't be done through NetBeans APIs)

The workaround is just don't create Visual Web projects with other open projects from modules that require an InitialContext

The workaround is just don't create Visual Web projects with other open projects from modules that require an
InitialContext  (in the same IDE session)

Hi John, sorry, this *is* a defect. VW breaks other modules that depend on JMX - without VW these modules work well. We
can argue about the priority or whether this is fixable for 6.1, but we need to acknowledge that this is a defect.

Are any Customers blocked by this issue ?

Also, please provide use cases .

This still hasn't been answered -- Is there a module that also requires an InitialContext and is used within a Visual
Web project ?

Use case was provided in desc7. The module (geronimo server plugin) posted as an attachement, which should be made
available on experimental update center soon.

Server plugins:

geronimo
resin
jetty (upcoming)

And anybody from the community who will write the plugin using the same way (jndi url in jmx).

This is the use case I'm inquiring about :

> This still hasn't been answered -- Is there a module that also requires an InitialContext and is used within a Visual
Web project ?

If doable, will cause a rearchitecture of visualweb.

It seems the only way to avoid creating an InitialContextFactoryBuilder is to use properties when creating an initial
context

Any update on this issue? As an author of Jetty plugin I am interested how it will be solved...

Do you use Jetty with Visual Web projects?

If no then as long as Visual Web projects aren't created then Jetty projects aren't affected

And what if the answer is yes?? Assume I have my plugin installed into full IDE and have opened visualweb project for
another server along with web project for Jetty. In this configuration it won't work. I don't consider advising not to
use them at the same moment as a suitable solution. Visual plugin *is* interfering with other modules using jmx
connection with jndi in their url and this *should* be addressed.

AFAIK, the only way to solve this is for visual web to drop dataproviders and rowsets.  For this to happen this will
have to be escalated.  Could be discussed on internal aliases.

*** Issue 145798 has been marked as a duplicate of this issue. ***

It's been a while since I know details of JNDI impl well, but I think none of NetBeans modules should really set
InitialContextFactory[Builder]. If needed it should be done by NB core/openide with an API for other modules to plug
their context into it.

But that should not prevent modules like VisualJSF to use contexts internally. Instead of calling
  javax.naming.Context ctx = new javax.naming.InitialContext();
I would define an helper method returning directly your e.g. DesignTimeContext and use that method wherever you need
initial context. That should work, no?

> I think none of NetBeans modules should really set InitialContextFactory[Builder]

If any modules set InitialContextFactory then no modules can use JNDI for lookups.
So, no modules should be allowed to do this.

Unfortunately, this was the original design of Creator before "joining" NetBeans as a module.

> If needed it should be done by NB core/openide with an API for other modules to plug their context into it . ... 
define an helper method returning directly your e.g. DesignTimeContext and use that method wherever you need initial
context. 

I think this should work but by creating the  in openide/core and there are a few "client" modules, this may not be
efficient.  Modules that require a JNDI lookup would have check the substring of the lookup name before executing.
Otherwise the wrong client module's code may be executed.
In visualweb, I check the name first.  If it doesn't match then I return null.  

John, I'm not sure I follow your last paragraph. The openide/core solution would be a proper solution needed if
different modules wanted to share/work on the same JNDI content. But that's I think is not the case of VisualJSF, right?
All you want is define your own Context into which VisualJSF dependant modules will write/read something. In that case
privately created Context could be offered to all these modules via for example

  Context org.netbeans.modules.visualweb.dataconnectivity.utils.ContextProvider.getInitialContext();

which would return instance of DesignTimeContext. Do you think that could that work?

Attempting to fix 

*** Issue 151835 has been marked as a duplicate of this issue. ***

Build: NetBeans IDE Dev (Build 200809270201)
VM: Java HotSpot(TM) Client VM, 11.0-b15, Java(TM) SE Runtime Environment, 1.6.0_10-rc-b28
OS: Windows XP, 5.1, x86

User Comments: 


Stacktrace: 
java.lang.IllegalStateException: FacesModel was not loaded for DataObject, dataObject=org.netbeans.modules.visualweb.project.jsfloader.JsfJspDataObject@589127[C:\Work Files\PPortal\pluginportal~mercurial\pluginportal\PluginPortal\web\CategoryPage.jsp]
        at org.netbeans.modules.visualweb.designer.jsf.JsfForm.loadFacesModel(JsfForm.java:3020)
        at org.netbeans.modules.visualweb.designer.jsf.JsfForm.access$000(JsfForm.java:131)
        at org.netbeans.modules.visualweb.designer.jsf.JsfForm$.modelSetAdded(JsfForm.java:369)
        at org.netbeans.modules.visualweb.insync.ModelSet.fireModelSetAdded(ModelSet.java:179)
        at org.netbeans.modules.visualweb.insync.ModelSet.getInstance(ModelSet.java:255)
        at org.netbeans.modules.visualweb.insync.ModelSet$.run(ModelSet.java:217)

Created attachment 74293 [details]
stacktrace

It seems that the initializing of the context is not synchronizes, while the code can be accessed from various threads.
Looking into it.

For now I am only attempting to fix the synchronization of the old impl.

To the core of the problem, i.e. to avoid using the NamingManager.setInitialContextFactoryBuilder. Yes, it is true, it
is desired to be avoided (in order to not clash with other modules).
I vaguely remember this was raised as an issue in the old Creator days, but it was opposed to change. In sum I needed to
know whether some code (third party impl - i.e. code we can't change) depends on the initial context to be set or not.
However I don't remember the answer. Based on that we would know if we could get rid of it. 

In any case, there seems to be no manpower on that module now, and I mark it as 'next'.
The workaround will remain, if your module set initial context you need to disable dataconnectivity module.

At the end I am not fixing the synchronization issue, it might not be as I anticipated. The reason could be also problem
with the mentioned clash.

This issue has already 5 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=53951

*** Issue 157025 has been marked as a duplicate of this issue. ***

Build: NetBeans IDE 6.5 Beta (Build 200808111757)
VM: Java HotSpot(TM) Client VM, 10.0-b19, Java(TM) SE Runtime Environment, 1.6.0_05-b13
OS: Windows Vista, 6.0, x86

User Comments: 


Stacktrace: 
java.lang.IllegalStateException: [Winsys] TopComponent org.netbeans.core.multiview.MultiViewCloneableTopComponent throws exception/error from its componentOpened() method.
Please repair it! Probable cause is at javax.naming.spi.NamingManager.setInitialContextFactoryBuilder(NamingManager.java:692)
        at org.openide.windows.WindowManager.logThrowable(WindowManager.java:361)
        at org.openide.windows.WindowManager.componentOpenNotify(WindowManager.java:300)
        at org.netbeans.core.windows.WindowManagerImpl.notifyTopComponentOpened(WindowManagerImpl.java:976)
        at org.netbeans.core.windows.Central.addModeOpenedTopComponent(Central.java:764)
        at org.netbeans.core.windows.ModeImpl.addOpenedTopComponent(ModeImpl.java:311)
        at org.netbeans.core.windows.WindowManagerImpl.topComponentOpenAtTabPosition(WindowManagerImpl.java:1084)

Created attachment 76685 [details]
stacktrace

This issue already has 22 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=53951