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 187745 - jax-rpc web svc support is broken in nb68 nb69 and nbdev builds
Summary: jax-rpc web svc support is broken in nb68 nb69 and nbdev builds
Status: VERIFIED FIXED
Alias: None
Product: webservices
Classification: Unclassified
Component: JAX-RPC (show other bugs)
Version: 6.x
Hardware: PC Windows 7 x64
: P2 normal with 1 vote (vote)
Assignee: emiddio
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-17 17:26 UTC by emiddio
Modified: 2010-06-30 17:24 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description emiddio 2010-06-17 17:26:10 UTC
nb68 still has problem than cannot compile a jax-rpc web-service against gfv3.x;
see bug 11872 -- it was declared fixed; but now is broken differently.

can create the web service(with nb68); but build fails; can build against gfv211 and then
deploy to gfv3.x;

nb69 and nbdev20100613 refuse to let you create a jax-rpc web service against
gfv3.x -- a couple of months ago nbdev builds did not have this problem. message claims jax-rpc not supported on  gfv301 -- which is not correct.

you can create the jax-rpc webservice against gfv211 and then change the server to gfv301 and things work just fine.(with nb69,nbdev)


the only way to build jax-rpc on nb69 is to dnload the jax-rpc plugin from http://deadlock.netbeans.org/hudson/job/nbms-and-javadoc/lastStableBuild/artifact/nbbuild/nbms/updates.xml.gz -- the latest dev builds location -- not avail from nb69 plugins.

jax-rpc should be easily available for nb6.9 users --since there is broken support in nb68 for jax-rpc with gfv3.x servers -- and because many still like to use jax-rpc.

its not the ONLY IDE YOU NEED if you have to use earlier versions to maintain older code.
Comment 1 Milan Kuchtiak 2010-06-18 12:26:22 UTC
Fixed:
http://hg.netbeans.org/web-main/rev/a36d390dedcd

WS wizards were disabled for GlassFish V3. The reason was probably that some time ago JAX-RPC services were not working with GlassFish V3 (Prelude).

Apologizing for inconvenience.
Comment 2 emiddio 2010-06-18 17:42:15 UTC
thanks;

dont forget to make the jax-rpc plugin avail from the default dnload site when released.
Comment 3 Quality Engineering 2010-06-19 03:38:51 UTC
Integrated into 'main-golden', will be available in build *201006190001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/a36d390dedcd
User: mkuchtiak@netbeans.org
Log: #187745: enable JAX-RPC WS wizard for GlassFish V3
Comment 4 Milan Kuchtiak 2010-06-21 13:05:48 UTC
QA engineer, please can you verify the fix ?
Thanks.
Comment 5 Milan Kuchtiak 2010-06-21 13:44:02 UTC
> dont forget to make the jax-rpc plugin avail from the default dnload site when
released.

There was a decision to remove JAX-RPC from the Stable Update Center to Development Update Center. 
I think "Development UC" is not the proper category for this kind of plugin, where particularly this plugin represents some older technology and it's not expected its farther development.

Would it be, at least, possible to make Development UC easily available from the Plugin Manager ?
Comment 6 Jiri Kovalsky 2010-06-21 14:07:05 UTC
It is of course possible to register additional Update Centers in the Plugins Manager however I would not recommend doing that or at least be extra cautious, because development plugins can easily destabilize the IDE. For more information see this FAQ:

http://wiki.netbeans.org/FaqPluginsInDevelopment
Comment 7 Jaroslav Pospisil 2010-06-21 14:18:11 UTC
Verified with latest dev build.
Comment 8 rbalada 2010-06-21 15:01:47 UTC
main #a36d390dedcd transplanted to release691 #9b0769ce9246
Comment 9 emiddio 2010-06-21 16:57:24 UTC
regarding " There was a decision to remove JAX-RPC from the Stable Update Center to
> Development Update Center. 
"

i wish there was a way for the netbeans users to have input into these types of decisions, and to also be informed of them before being forced to "discover" them as deficiencies after a release.

the reality is older technology is still used -- and to force users to use an older version of netbeans seems to defeat the idea of "ONLY IDE YOU NEED".


thanks

gary
Comment 10 Jiri Kovalsky 2010-06-22 08:35:51 UTC
I understand your frustration emiddio. It would be nice if we could forever support every technology that was once added to NetBeans but we are not able to do that especially with half of the resources we used to have. Given the fact we can only improve and maintain limited amount of functionality. Fortunately, NetBeans IDE is open source project so if community wants it can take over these put-aside projects, test accordingly, fix it and publish it [1] on the Update Center.

[1] http://wiki.netbeans.org/UpdateCenterProcess
Comment 11 emiddio 2010-06-22 20:03:22 UTC
i expected the answer in your reply;

but questions reamain from my inquiry --

why is the community not informed of these decisions before they occur in 
the release -- for technologies that will be dropped ?

why are community opinions regarding dropped technologies not being 
requested.
-- the community seems to have no voice .

in this case -- the older technology -- works -- did not need support -- all 
we need is the plugin to be available -- i can find it at latest dev build 
plugin site.

gfv3.x -- is currently shipping with support for jax-rpc -- at some point in 
future it may be dropped , and glassfish has said in the future jax-rpc may 
be dropped -- why not drop jax-rpc from netbeans at that time?

your link http://wiki.netbeans.org/UpdateCenterProcess suggests the 
community can get the plugin published -- i will have to study the link in 
detail -- but it does work now in nb691 and nbdev -- so -- can we get it 
published ???

thanks

gary -- emiddio is my middle name
Comment 12 emiddio 2010-06-22 21:47:23 UTC
also consider consistency --

nb69 allows adding of Sun Appserver 8.2, and i have also added AS8.1

because these j2ee 1.4 servers only support jax-rpc, not jax-ws, or jax-rs,

it seems support for jax-rpc should only be dropped when support for these servers is dropped.

gary
Comment 13 Jiri Kovalsky 2010-06-30 16:10:21 UTC
I will try to answer your questions.

1. We don't ask community for approval to remove some feature, because it wouldn't make sense. It's easy to say "No, let it in." but then community must take the functionality over and actively maintain it. Since 2000 this never happened as far as I remember.

2. Our goal is NOT supporting 100% of use cases which means that if some technology exists in GlassFish we can but don't necessarily have to support it.

3. As for bringing JAX-RPC back to the Update Center, we could publish it again but in such case we would need your close cooperation. Would you be willing to test it [1] and confirm that there are no P1/P2 bugs in the plugin?

Thanks for your feedback and help Gary!

[1] JAX-RPC Web Services plugin on Development UC: http://deadlock.netbeans.org/hudson/job/nbms-and-javadoc/lastStableBuild/artifact/nbbuild/nbms/extra/org-netbeans-modules-websvc-jaxrpckit.nbm
Comment 14 emiddio 2010-06-30 16:43:18 UTC
one question you did not answer -- but i think i heard a response from on the nbusers mailing list -- what about advance publication of technologies to be dropped from netbeans ???
--------------------------------------------

i am willing to test -- time permitting; it there a specific list of test cases ?

------------------------
i have as8.1 as8.2, gfv2ur2, gfv211, gfv301 installed on machines -- but usually try to make sure j2ee1.4 support still works with the newer glassfishes;

in the past i have built/tested all the tutorials and samples from Sun's java EE tutorials -- for both j2ee1.4, ee5, and recently ee6(found and reported a bunch of bugs, fixed some and reported fixes also); worked with all the examples provided with the netbeans4_1_j2ee1.4 tutorial bundle also;

i found many bugs and fixed many bugs(tutorial bugs, not reported); i would test with each newer release(tutorials) as it was made available.

when i found netbeans bugs i began reporting them a few years ago.

usually i revisit the code at times when newer releases appear and when i need to remember something;

that is how i keep seeing feature removal -- pointbase support in nb651(i think),bugs appearing in the Services/Databases for browsing pointbase nodes(nb67 i think), now jax-rpc;

i only partially used the SOA/ESB, and VisualJSF support stuff before its removal -- i was learning other things first.

i even took all the j2ee1.4 Petstore1.4 and AdventureBuilder -- where all they had was ANT/ASANT scripts -- and made netbeans projects from them so i could build and easily debug/step thru code when running -- and found/fixed many bugs in them also. Learned a bunch about j2ee 1.4 EJB and CMP during that exercise.

and many/most of the j2ee 1.4 tutorials, and Samples(all Ant/Asant based) i also made netbeans projects from -- for the same reason -- to not have to use command line ANT -- and i do not mean free-form projects -- fully functional projects with webservices nodes appearing, EJB's showing up where they should with CMP fields being visible and ability to GUI edit the CMP/EJB stuff -- which took lots of time and reverse engineering at times to get to fit into a netbeans project.
Comment 15 Jiri Kovalsky 2010-06-30 17:24:37 UTC
Great, thanks for your offer. The test specs are two: one for JAX-RPC Web Service Client [1] and one for JAX-WS 2.1.2 Web Service Client [2].

[1] http://qa.netbeans.org/modules/j2ee/netbeans%206.1/WSClientJAXRPC.html
[2] http://qa.netbeans.org/modules/j2ee/netbeans%206.1/WSClientJAXWS.html

Once you complete your test of JAX-RPC Web Services plugin in the NetBeans IDE 6.9, let us please know your findings and then we will decide if the bugs you report allow publishing on the Update Center or not. Thanks a lot upfront!

As for the informing community about features to be dropped in advance, we know that we failed in the past especially with regards to UML and VW. However, we learned from that lesson and want to make a better job in this communication for the next release.