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.
Summary: | Add support for JBoss AS 7 / WildFly 8 | ||
---|---|---|---|
Product: | serverplugins | Reporter: | pekarna <pekarna> |
Component: | WildFly | Assignee: | ehsavoie <ehsavoie> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | arungupta, athompson, cheesus, chintan4fun, darkstar, drozenbe, geraldolmr, goran.popov, gsrao4712, hmichel, jasonec, jbader, jskrivanek, kganfield, kingsob, kosgeinsky, mahairod, marcusgy, markiewb, meme, misterm, mmirilovic, narve, pjiricka, raviparekh, rbento, ringerc, rkubacki, rsaraiva, sebastianovide, sylver, theshowmecanuck, vidhyadharantechdays, viggonavarsete, xehpuk |
Priority: | P1 | ||
Version: | 7.2.1 | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 253606 | ||
Attachments: |
Jboss & implentation patch
Patch to register, start & stop JBoss 7.1.1.Final with Netbeans 7.1 JBoss 7.1.1.Final patch modified patch updated patch Jboss As 7 Patch Jboss AS 7 icon JBoss AS 7 patch JBoss AS 7 patch updated patch patch patch improved patch |
Description
pekarna
2011-07-14 09:35:43 UTC
*** Bug 199489 has been marked as a duplicate of this bug. *** Current JBoss AS 7 documentation location is https://docs.jboss.org/author/display/AS7/Documentation Also articles here http://community.jboss.org/en/jbossas/dev/jboss_as7_development?view=documents#/?page=2 And there are people willing to help at #jboss-as7 @ FreeNode JBoss AS 7 Management API docs: https://docs.jboss.org/author/display/AS7/Management+API+reference What could be used for managing AS 7 is Arquillian's implementation of AS 7 container: https://github.com/jbossas/jboss-as/tree/master/arquillian/container-managed/src/main/java/org/jboss/as/arquillian/container/managed Also, how about using Arquillian's API for other containers as well? A good example of using the Arquillian Contianer SPI/APIs is the Arquillian Maven plugin: https://github.com/arquillian/arquillian-maven/tree/master/plugin/src/main/java/org/jboss/arquillian/maven Handles Start/Stop/Deploy/Undeploy operations. I can't stress how important this issue is to me. I've used and loved NetBeans since the Forte days but without support for JBoss AS 7.X, I'm switching to the inferior Eclipse IDE. Ugh! And this happens just when the eclipse user's on my team (all but me) were starting to see the light and potentially use NetBeans! Now, maybe I shouldn't let my inner voice speak here but I can't help but wonder if the latest NetBeans stewards are indifferent or worse concerning support for a competing application server. And if so, this certainly wouldn't bode well for broadening NetBeans user base. For what it's worth, at least as a workaround, the maven plugin is actually working pretty well for me. That can be run from NetBeans/Maven builds easily. Really, the big improvement would be getting the standalone.bat output into something that sucks less than a Windows command prompt... Tighter integration is desired, but this workaround is useful to those while we wait. I really wish that was good enough. Sadly, it's not. I've made the switch. I'd wish the netbeans projects had more community members instead of loorkers ppl this is an open source project, if you really need it then implement it You're right. Sorry about my tone. I think I'm just pissed off that I have to use Eclipse at the moment ;) I don't have any time to implement this one myself. (In reply to comment #6) > I can't stress how important this issue is to me. I've used and loved NetBeans > since the Forte days but without support for JBoss AS 7.X, I'm switching to the > inferior Eclipse IDE. Ugh! And this happens just when the eclipse user's on my > team (all but me) were starting to see the light and potentially use NetBeans! > > Now, maybe I shouldn't let my inner voice speak here but I can't help but > wonder if the latest NetBeans stewards are indifferent or worse concerning > support for a competing application server. And if so, this certainly wouldn't > bode well for broadening NetBeans user base. I know what you mean. I'm also the only Netbeans user on my team. They are glad about this issue. I almost couldn't believe it. That's disappointing. (In reply to comment #9) > I'd wish the netbeans projects had more community members instead of loorkers > ppl this is an open source project, if you really need it then implement it For sure you are right. Neverthless I'm curious to know the reason why the support for JBoss AS 7 is still missing ... I will suppose it's due to a lack of resources, so I'll try to see if I'm able to contribute. Could any one tell me which are the Netbeans modules related to AS support I should examine to have an idea of how big the task is ? Thank you. @lucabur I'm sure JBoss support is missing because Netbeans is an Oracle product now. I'm also sure their Weblogic support is brilliant :): http://netbeans.org/community/releases/71/relnotes.html (In reply to comment #12) > (In reply to comment #9) > Could any one tell me which are the Netbeans modules related to AS support I > should examine to have an idea of how big the task is ? > > Thank you. It is in j2ee.jboss4 folder (historical name). Feel free to contribute. Unfortunately the task is not that easy as JBoss 7 is (regarding the integration - api, files) significantly different from previous versions. If it would be simple the support would already be there. JBoss AS Jira issue: https://issues.jboss.org/browse/AS7-3842 Note that for JBoss AS 7.0, the docs were preserved at the old URL, and new docs for AS 7.1 is at https://docs.jboss.org/author/display/AS71/Management+API+reference . I've seen that former JBoss AS plugins use JSR-88. AS 7 supports that too; Can the plugin be just slightly modified to support AS 7 too? Or what's the problem? I would expect this to be a matter of implementing a one or few interfaces, but I looked at j2ee.jboss NetBeans module and find it quite difficult to orientate in that. Could someone point me to some docs about how to write a simple container plugin supporting start/stop/deploy/undeploy? (In reply to comment #17) > I've seen that former JBoss AS plugins use JSR-88. AS 7 supports that too; > Can the plugin be just slightly modified to support AS 7 too? > Or what's the problem? The plugin has 3 areas - registration, classpath and deployment. Usually JBoss (for some reason) changed the file/directory layout with every minor release so at least registration and classpath has to be fixed. In AS 7 they changed directories, files, domain layout etc - basically everything. JBoss plugin (and others) does not really use JSR-88. It was misdesigned from the beginning and server vendors implemented in different way. There are some JSR-88 interfaces in the code, but that's historical thing. > > I would expect this to be a matter of implementing a one or few interfaces, but > I looked at j2ee.jboss NetBeans module and find it quite difficult to orientate > in that. Could someone point me to some docs about how to write a simple > container plugin supporting start/stop/deploy/undeploy? You should fix the registration (wizard) code first and than check and debug start/stop/deploy/undeploy. It may work, but I would not be that optimistic. > The plugin has 3 areas - registration, classpath and deployment. What's classpath for? > Usually JBoss > (for some reason) changed the file/directory layout with every minor release so > at least registration and classpath has to be fixed. In AS 7 they changed > directories, files, domain layout etc - basically everything. That's where I would suggest the abstraction. Although the paths are different, there is still a directory for deployments, a directory with server's .jar's, a config directory... I guess I see it too naively though. > JBoss plugin (and others) does not really use JSR-88. It was misdesigned from > the beginning and server vendors implemented in different way. There are some > JSR-88 interfaces in the code, but that's historical thing. What then? Copying into a dir? I've also seen ProfileService which was in AS 5 and 6. Is that used? Or is that historical too? :) > You should fix the registration (wizard) code first and than check and debug > start/stop/deploy/undeploy. It may work, but I would not be that optimistic. Will try if time allows. *** Bug 209618 has been marked as a duplicate of this bug. *** Hi Petr Hejl, I have been working on this for a week. I took the latest netbeans code (main) and added my modifications on top of it. I modified, JBPluginUtils.java JBDeploymentFactory.java files to register JBoss AS 7. At the end of the registration and every time i start the server i get the following error as shown in the attachement. I see that javax.enterprise.deploy.spi.DeploymentManager is optional in JavaEE 7. How do I workaround this? Any pointer is appreciated. Also, since this being first time, I would like to know how to share my code changes and get reviewed/helped. SEVERE [org.openide.util.RequestProcessor]: Error in RequestProcessor org.netbeans.modules.j2ee.deployment.impl.ui.actions.StartAction$1 java.lang.UnsupportedOperationException: JBAS016163: Opaque deployment URI not implemented at org.jboss.as.ee.deployment.spi.DeploymentManagerImpl.getTargets(DeploymentManagerImpl.java:139) (In reply to comment #19) > > The plugin has 3 areas - registration, classpath and deployment. > What's classpath for? Project compilation. > > > Usually JBoss > > (for some reason) changed the file/directory layout with every minor release so > > at least registration and classpath has to be fixed. In AS 7 they changed > > directories, files, domain layout etc - basically everything. > That's where I would suggest the abstraction. > Although the paths are different, there is still a directory for deployments, a > directory with server's .jar's, a config directory... I guess I see it too > naively though. Well the abstraction is the plugin itself. You might introduce another level inside the plugin, but would it help really? At the end of the day you have to implement/change something in the plugin due to changes in the latest version of the server. Anyway feel free to implement such abstraction. > > > > JBoss plugin (and others) does not really use JSR-88. It was misdesigned from > > the beginning and server vendors implemented in different way. There are some > > JSR-88 interfaces in the code, but that's historical thing. > What then? Copying into a dir? I've also seen ProfileService which was in AS 5 > and 6. Is that used? Or is that historical too? :) Copying to the dir. Keep in mind that the plugin has a couple of years history (5+) and it was maintained by couple of people trying to support the jboss server which has been changing things quite a lot. So yes ProfileService is used, but not for everything and the functionality is in its own class for better maintenance (keeping the new things aside the old ones). > > > You should fix the registration (wizard) code first and than check and debug > > start/stop/deploy/undeploy. It may work, but I would not be that optimistic. > Will try if time allows. (In reply to comment #21) > Hi Petr Hejl, > I have been working on this for a week. I took the latest netbeans code (main) > and added my modifications on top of it. I modified, > > JBPluginUtils.java > JBDeploymentFactory.java It would be easier to discuss the patch you have. > > files to register JBoss AS 7. At the end of the registration and every time i > start the server i get the following error as shown in the attachement. > I see that javax.enterprise.deploy.spi.DeploymentManager is optional in JavaEE > 7. > > > How do I workaround this? Any pointer is appreciated. I'm not really sure. I would need to debug. It looks like that something used to work does not work with JBoss 7. > > Also, since this being first time, I would like to know how to share my code > changes and get reviewed/helped. Do "hg diff > jboss.patch" and attach the jboss.patch to the IZ. Thanks. Thanks Petr Hejl. After digging JBoss 7 source code (from http://grepcode.com/file/repository.jboss.org/nexus/content/repositories/releases/org.jboss.as/jboss-as-ee-deployment/7.0.2.Final/org/jboss/as/ee/deployment/spi/DeploymentManagerImpl.java#DeploymentManagerImpl) it looks like the LocalHostTarget is not supported anymore. I'm new to mercurial. Thanks for the HG help. Once i have some solid chunk I'll post the diff as you said. Thanks for your instant reply and support. Created attachment 116881 [details]
Jboss & implentation patch
This patch successfully registers JBoss AS 7 server in Netbeans IDE
Hi Petr Hejl, I couldnt get the hg setup work properly. Next time I'll post the proper hg diff. I have attached the svn diff. Let me know if it works. With this patch, I'm able to successfully register JBoss AS 7 server. Yet to work on the start/stop functionality. Created attachment 117948 [details]
Patch to register, start & stop JBoss 7.1.1.Final with Netbeans 7.1
This Hg patch registers, starts and stops JBoss 7.1.1.Final with Netbeans 7.1. It also lets you view the deployments
(In reply to comment #28) > Created attachment 117948 [details] > Patch to register, start & stop JBoss 7.1.1.Final with Netbeans 7.1 > > This Hg patch registers, starts and stops JBoss 7.1.1.Final with Netbeans 7.1. > It also lets you view the deployments Please can you provide a patch only with real changes? It looks like you changed formatting which make this patch hardly usable for review. Created attachment 117951 [details]
JBoss 7.1.1.Final patch
I have removed the unintended changes.
Since the hg cloned j2ee.jboss module didnt compile/run, i created a new project and copied the source files. Also looks like the main has changed after i cloned.
It will be a great help, if you can help me setup and run the cloned hg module directly. It will also eliminate the task of manually copying the change to clone and diff-ing them.
Hi Petr Hejl, Did it work for you? *** Bug 203155 has been marked as a duplicate of this bug. *** (In reply to comment #31) > Hi Petr Hejl, > Did it work for you? Yep, it is much readable now. I'll look at that later today. Thanks! Created attachment 118249 [details]
modified patch
Your patch updated to recent trunk.
Couple of notes/question/todos?
1) How did you determined the classloader cp?
2) The deployment actually times out.
3) There is CCE in trunk.
4) Compilation classpath - try to create web app with servlet.
Otherwise good work. I can look into 2, 3 perhaps 4 if time will allow.
(In reply to comment #30) > Created attachment 117951 [details] > JBoss 7.1.1.Final patch > > I have removed the unintended changes. > > Since the hg cloned j2ee.jboss module didnt compile/run, i created a new > project and copied the source files. Also looks like the main has changed after > i cloned. > > It will be a great help, if you can help me setup and run the cloned hg module > directly. It will also eliminate the task of manually copying the change to > clone and diff-ing them. http://wiki.netbeans.org/WorkingWithNetBeansSources http://wiki.netbeans.org/HgHowTos http://netbeans.org/community/contribute/patches.html This should help. Let me know. Created attachment 118250 [details]
updated patch
Temporarily fixed 3). Minor improvements.
Can one of you excellent fellows please tell me how to install this patch so I can use my Netbeans install to work with my JBoss server? Or at least point me to the documentation that tells me home? Thanks in advance, BR Apologize for the extra post but I could not edit an error I made. That tells me how? (In reply to comment #37) > Can one of you excellent fellows please tell me how to install this patch so I > can use my Netbeans install to work with my JBoss server? Or at least point me > to the documentation that tells me home? > > Thanks in advance, > > BR Apologize for the extra post but I could not edit an error I made. s/that tells me home?/That tells me how?/ (In reply to comment #34) Thanks Petr Hejl, for your time and support. Yes, i didnt work on the deployment part. Im yet to fix that. 1) I determined the valid jboss 7 location based on the jboss-modules.jar file (its a guess). I constructed the classloader cp incrementally by trial and error method; added the following jars. (serverRoot, "jboss-modules.jar").toURI().toURL()); (serverRoot, "bin"+sep+"client"+sep+"jboss-client.jar").toURI().toURL()); (jboss, "logging" + sep + "main" + sep + "jboss-logging-3.1.0.GA.jar").toURI().toURL()); (jboss, "threads" + sep + "main" + sep + "jboss-threads-2.0.0.GA.jar").toURI().toURL()); (jboss, "remoting3" + sep + "main" + sep + "jboss-remoting-3.2.3.GA.jar").toURI().toURL()); (jboss, "xnio" + sep + "main" + sep + "xnio-api-3.0.3.GA.jar").toURI().toURL()); (jboss, "msc" + sep + "main" + sep + "jboss-msc-1.0.2.GA.jar").toURI().toURL()); (new File(as, "ee" + sep + "deployment" + sep + "main" + sep + "jboss-as-ee-deployment-" + versionString + ".jar").toURI().toURL()); (new File(as, "naming" + sep + "main" + sep + "jboss-as-naming-" + versionString + ".jar").toURI().toURL()); (new File(as, "controller-client" + sep + "main" + sep + "jboss-as-controller-client-" + versionString + ".jar").toURI().toURL()); (new File(as, "protocol" + sep + "main" + sep + "jboss-as-protocol-" + versionString + ".jar").toURI().toURL()); 2)& 4) yes i will have to work on it. :) Yes, i looked at the tutorials before i started my work. Let me look at them more closely again. (In reply to comment #37) Im a new contributor to NetBeans. You may get a better advice from experts. But this is what you need to do. Follow the instructions given in links mentioned in comment #35 1. Download the source code from main 2. Download the patch 3. Open the module j2ee.jboss4 in netbeans 4. From the IDE menus, apply the patch 5. Build and run 6. Now in the target IDE (the new running instance), you should be able to register the JBoss AS 7.1.1.Final. Other option would be, (instead of steps 5 & 6) 5. Build 6. create NBM. ( right click the project; package as-> NBMs) 7. Using plugin manager install the new nbm (In reply to comment #39) > (In reply to comment #34) > Thanks Petr Hejl, for your time and support. Yes, i didnt work on the > deployment part. Im yet to fix that. > > 1) I determined the valid jboss 7 location based on the jboss-modules.jar file > (its a guess). I constructed the classloader cp incrementally by trial and > error method; added the following jars. > Ok, thanks. > > 2)& 4) yes i will have to work on it. :) > > Yes, i looked at the tutorials before i started my work. Let me look at them > more closely again. FYI this is what I do (I'm bit CL oriented ;) ): hg clone http://hg.netbeans.org/main-silver netbeans-repo cd netbeans-repo ant clean && ant build-nozip (you might need to configure -Xmx for ant) # change module, apply changes # I use patch -p1 < jboss.patch # build the module, now test it cd nbbuild/netbeans/bin ./netbeans # ok generate the patch hg diff --git > ~/mynewpatch.patch (In reply to comment #40) I tryed to build jboss module but i have some erros. Could someone check on it? compile-lib: [mkdir] Created dir: /home/marek/temp/netbeans-repo/db/build/lib-classes [javac] Compiling 61 source files to /home/marek/temp/netbeans-repo/db/build/lib-classes [parseprojectxml] /home/marek/temp/netbeans-repo/db/libsrc/org/netbeans/lib/ddl/impl/AbstractCommand.java:59: package org.openide.windows does not exist [parseprojectxml] import org.openide.windows.IOProvider; [parseprojectxml] ^ [parseprojectxml] /home/marek/temp/netbeans-repo/db/libsrc/org/netbeans/lib/ddl/impl/AbstractCommand.java:60: package org.openide.windows does not exist [parseprojectxml] import org.openide.windows.OutputWriter; [parseprojectxml] ^ [parseprojectxml] /home/marek/temp/netbeans-repo/db/libsrc/org/netbeans/lib/ddl/impl/AbstractCommand.java:66: package org.openide.windows does not exist [parseprojectxml] import org.openide.windows.InputOutput; [parseprojectxml] ^ [parseprojectxml] /home/marek/temp/netbeans-repo/db/libsrc/org/netbeans/lib/ddl/impl/AbstractCommand.java:59: package org.openide.windows does not exist [parseprojectxml] import org.openide.windows.IOProvider; [parseprojectxml] ^ [parseprojectxml] /home/marek/temp/netbeans-repo/db/libsrc/org/netbeans/lib/ddl/impl/AbstractCommand.java:60: package org.openide.windows does not exist [parseprojectxml] import org.openide.windows.OutputWriter; [parseprojectxml] ^ [parseprojectxml] /home/marek/temp/netbeans-repo/db/libsrc/org/netbeans/lib/ddl/impl/AbstractCommand.java:66: package org.openide.windows does not exist [parseprojectxml] import org.openide.windows.InputOutput; [parseprojectxml] ^ [parseprojectxml] /home/marek/temp/netbeans-repo/db/libsrc/org/netbeans/lib/ddl/impl/SpecificationFactory.java:118: warning: non-varargs call of varargs method with inexact argument type for last parameter; [parseprojectxml] cast to java.lang.Object for a varargs call [parseprojectxml] cast to java.lang.Object[] for a non-varargs call and to suppress this warning [parseprojectxml] String message = MessageFormat.format(NbBundle.getBundle("org.netbeans.lib.ddl.resources.Bundle").getString("EXC_UnableToOpenStream"), new String[] {dbFile}); // NOI18N [parseprojectxml] ^ [parseprojectxml] /home/marek/temp/netbeans-repo/db/libsrc/org/netbeans/lib/ddl/impl/SpecificationFactory.java:140: warning: non-varargs call of varargs method with inexact argument type for last parameter; [parseprojectxml] cast to java.lang.Object for a varargs call [parseprojectxml] cast to java.lang.Object[] for a non-varargs call and to suppress this warning [parseprojectxml] String message = MessageFormat.format(NbBundle.getBundle("org.netbeans.lib.ddl.resources.Bundle").getString("EXC_UnableToOpenStream"), new String[] {drvFile}); // NOI18N [parseprojectxml] ^ [parseprojectxml] /home/marek/temp/netbeans-repo/db/libsrc/org/netbeans/lib/ddl/impl/AbstractCommand.java:215: cannot find symbol [parseprojectxml] symbol : class InputOutput [parseprojectxml] location: class org.netbeans.lib.ddl.impl.AbstractCommand [parseprojectxml] InputOutput io = IOProvider.getDefault().getIO(NbBundle.getBundle("org.netbeans.lib.ddl.resources.Bundle").getString("LBL_Output_Window"), false); [parseprojectxml] ^ [parseprojectxml] /home/marek/temp/netbeans-repo/db/libsrc/org/netbeans/lib/ddl/impl/AbstractCommand.java:215: cannot find symbol [parseprojectxml] symbol : variable IOProvider [parseprojectxml] location: class org.netbeans.lib.ddl.impl.AbstractCommand [parseprojectxml] InputOutput io = IOProvider.getDefault().getIO(NbBundle.getBundle("org.netbeans.lib.ddl.resources.Bundle").getString("LBL_Output_Window"), false); [parseprojectxml] ^ [parseprojectxml] /home/marek/temp/netbeans-repo/db/libsrc/org/netbeans/lib/ddl/impl/AbstractCommand.java:217: cannot find symbol [parseprojectxml] symbol : class OutputWriter [parseprojectxml] location: class org.netbeans.lib.ddl.impl.AbstractCommand [parseprojectxml] OutputWriter ow = io.getOut(); //NOI18N [parseprojectxml] ^ [parseprojectxml] /home/marek/temp/netbeans-repo/db/libsrc/org/netbeans/lib/ddl/impl/ColumnListCommand.java:116: warning: non-varargs call of varargs method with inexact argument type for last parameter; [parseprojectxml] cast to java.lang.Object for a varargs call [parseprojectxml] cast to java.lang.Object[] for a non-varargs call and to suppress this warning [parseprojectxml] new String[] {tname, props.keySet().toString() } )); [parseprojectxml] ^ [parseprojectxml] /home/marek/temp/netbeans-repo/db/libsrc/org/netbeans/lib/ddl/impl/ColumnListCommand.java:120: warning: non-varargs call of varargs method with inexact argument type for last parameter; [parseprojectxml] cast to java.lang.Object for a varargs call [parseprojectxml] cast to java.lang.Object[] for a non-varargs call and to suppress this warning [parseprojectxml] new String[] {type, bindmap.toString() } )); [parseprojectxml] ^ [parseprojectxml] /home/marek/temp/netbeans-repo/db/libsrc/org/netbeans/lib/ddl/impl/ColumnCommand.java:87: warning: non-varargs call of varargs method with inexact argument type for last parameter; [parseprojectxml] cast to java.lang.Object for a varargs call [parseprojectxml] cast to java.lang.Object[] for a non-varargs call and to suppress this warning [parseprojectxml] new String[] {tname})); [parseprojectxml] ^ [parseprojectxml] /home/marek/temp/netbeans-repo/db/libsrc/org/netbeans/lib/ddl/impl/ColumnCommand.java:98: warning: non-varargs call of varargs method with inexact argument type for last parameter; [parseprojectxml] cast to java.lang.Object for a varargs call [parseprojectxml] cast to java.lang.Object[] for a non-varargs call and to suppress this warning [parseprojectxml] new String[] {type, bindmap.toString() })); [parseprojectxml] ^ [parseprojectxml] /home/marek/temp/netbeans-repo/db/libsrc/org/netbeans/lib/ddl/impl/CreateProcedure.java:143: warning: non-varargs call of varargs method with inexact argument type for last parameter; [parseprojectxml] cast to java.lang.Object for a varargs call [parseprojectxml] cast to java.lang.Object[] for a non-varargs call and to suppress this warning [parseprojectxml] new String[] {tname})); [parseprojectxml] ^ [parseprojectxml] /home/marek/temp/netbeans-repo/db/libsrc/org/netbeans/lib/ddl/impl/CreateProcedure.java:155: warning: non-varargs call of varargs method with inexact argument type for last parameter; [parseprojectxml] cast to java.lang.Object for a varargs call [parseprojectxml] cast to java.lang.Object[] for a non-varargs call and to suppress this warning [parseprojectxml] new String[] {String.valueOf(type), bindmap.toString() })); [parseprojectxml] ^ [parseprojectxml] /home/marek/temp/netbeans-repo/db/libsrc/org/netbeans/lib/ddl/impl/CreateTrigger.java:188: warning: non-varargs call of varargs method with inexact argument type for last parameter; [parseprojectxml] cast to java.lang.Object for a varargs call [parseprojectxml] cast to java.lang.Object[] for a non-varargs call and to suppress this warning [parseprojectxml] new String[] {tname})); [parseprojectxml] ^ [parseprojectxml] /home/marek/temp/netbeans-repo/db/libsrc/org/netbeans/lib/ddl/impl/CreateTrigger.java:200: warning: non-varargs call of varargs method with inexact argument type for last parameter; [parseprojectxml] cast to java.lang.Object for a varargs call [parseprojectxml] cast to java.lang.Object[] for a non-varargs call and to suppress this warning [parseprojectxml] new String[] {"EVENT", bindmap.toString() })); // NOI18N [parseprojectxml] ^ [parseprojectxml] /home/marek/temp/netbeans-repo/db/libsrc/org/netbeans/lib/ddl/util/PListReader.java:185: warning: non-varargs call of varargs method with inexact argument type for last parameter; [parseprojectxml] cast to java.lang.Object for a varargs call [parseprojectxml] cast to java.lang.Object[] for a non-varargs call and to suppress this warning [parseprojectxml] new String[] {new String(charr), tokenizer.toString()}), [parseprojectxml] ^ [parseprojectxml] /home/marek/temp/netbeans-repo/db/libsrc/org/netbeans/lib/ddl/util/PListReader.java:264: warning: non-varargs call of varargs method with inexact argument type for last parameter; [parseprojectxml] cast to java.lang.Object for a varargs call [parseprojectxml] cast to java.lang.Object[] for a non-varargs call and to suppress this warning [parseprojectxml] new String[] { tokenizer.toString() } ), [parseprojectxml] ^ [parseprojectxml] /home/marek/temp/netbeans-repo/db/libsrc/org/netbeans/lib/ddl/util/PListReader.java:291: warning: non-varargs call of varargs method with inexact argument type for last parameter; [parseprojectxml] cast to java.lang.Object for a varargs call [parseprojectxml] cast to java.lang.Object[] for a non-varargs call and to suppress this warning [parseprojectxml] new String[] { tokenizer.toString() } ), [parseprojectxml] ^ [parseprojectxml] /home/marek/temp/netbeans-repo/db/libsrc/org/netbeans/lib/ddl/util/PListReader.java:379: warning: non-varargs call of varargs method with inexact argument type for last parameter; [parseprojectxml] cast to java.lang.Object for a varargs call [parseprojectxml] cast to java.lang.Object[] for a non-varargs call and to suppress this warning [parseprojectxml] new String[] { tokenizer.toString() } ), [parseprojectxml] ^ [parseprojectxml] /home/marek/temp/netbeans-repo/db/libsrc/org/netbeans/lib/ddl/util/PListReader.java:395: warning: non-varargs call of varargs method with inexact argument type for last parameter; [parseprojectxml] cast to java.lang.Object for a varargs call [parseprojectxml] cast to java.lang.Object[] for a non-varargs call and to suppress this warning [parseprojectxml] new String[] {"','", tokenizer.toString()}), // NOI18N [parseprojectxml] ^ [parseprojectxml] Note: Some input files use unchecked or unsafe operations. [parseprojectxml] Note: Recompile with -Xlint:unchecked for details. [parseprojectxml] 6 errors [parseprojectxml] 15 warnings BUILD FAILED /home/marek/temp/netbeans-repo/nbbuild/templates/projectized.xml:108: The following error occurred while executing this line: /home/marek/temp/netbeans-repo/db/build.xml:59: Compile failed; see the compiler error output for details. Hi Petr Hejl, Thanks for the step-by-step instruction of CL setup. For some strange reason when I compile, the compilation stalls after a certain point. Console doesnt move, nor the command ends. Let me try once again and get back to you with appropriate information. Hope the plugin development is going fine. Let me know if you want me to work on the remaining part; more than happy to contribute to Netbeans. Didnt want to duplicate the effort; so I havent started anything on the remaining part. Also I have a proposal (once the plugin starts working as expected) to refactor the code such that all one have to do, when a new version of JBoss is released, is to extend some base class or a previous version and provide implementation for what is changed. Using @ServiceProvider and Lookup, we dont have to change anything in the existing code at all. Appropriate version handler can be chosen at runtime by a common controller. This also lets us avoid a lot of if-else condition. I understand that it's been there historically. But we can discuss further if you like this approach to refactor. Thanks. Working prototype https://github.com/okulikov/jboss-as7-netbeans (In reply to comment #43) > Hi Petr Hejl, > Thanks for the step-by-step instruction of CL setup. For some strange reason > when I compile, the compilation stalls after a certain point. Console doesnt > move, nor the command ends. Let me try once again and get back to you with > appropriate information. > > Hope the plugin development is going fine. > Let me know if you want me to work on the remaining part; more than happy to > contribute to Netbeans. > Didnt want to duplicate the effort; so I havent started anything on the > remaining part. Please feel free to continue on that. > > Also I have a proposal (once the plugin starts working as expected) to refactor > the code such that all one have to do, when a new version of JBoss is released, > is to extend some base class or a previous version and provide implementation > for what is changed. > > Using @ServiceProvider and Lookup, we dont have to change anything in the > existing code at all. Appropriate version handler can be chosen at runtime by a > common controller. This also lets us avoid a lot of if-else condition. Yep something which should be done. Might not be that easy. > > I understand that it's been there historically. But we can discuss further if > you like this approach to refactor. > > Thanks. (In reply to comment #44) > Working prototype https://github.com/okulikov/jboss-as7-netbeans Hi, perhaps you could join forces with pragalathan. BTW extexecution api could help you. The server seems to be using the server api which is generic and nice but does not provide any java related stuff. You need to use j2eeserver imo. P. (In reply to comment #46) > (In reply to comment #44) > > Working prototype https://github.com/okulikov/jboss-as7-netbeans > > Hi, > perhaps you could join forces with pragalathan. BTW extexecution api could help > you. The server seems to be using the server api which is generic and nice but > does not provide any java related stuff. You need to use j2eeserver imo. > > P. Thanks for directing. I was looking into GlassFish pluging as on example and they use also generic server api. So I decided that this way is safer :) I will inverstagate the j2eeserver Hi okulikov, I went through your code. Nice work. Few things such as viewing deployed applications and deploying new apps didnt work for me. I also noticed that you were using JBoss AS7 specific management client APIs to query the server state. If we were to use j2eeserver module, it has to be done using RMIServer (as per my understanding of earlier Jboss versions integration). The patch i have posted, let you register/start/stop your AS7 from Netbeans. What is not done is, 1. Deployment of applications 2. Querying the state of AS7 Petr Hejl, The issue that im currently facing while implementing the above usecases is, -The common module (i will find the name) (not the jboss4 module) tries to query some standard node from the RMI/JMX bean tree and is failing as the node/node location (in RMI/JMX tree) is changed in AS7. I have figured out the right nodes for the start/stop status of AS7 and added in the patch; but unable to find out the right node for these usecases. Also the call trace goes to different module. - I needed to run the changes in debug mode, hence i used the IDE rather than CLI. (Please let me know if it possible to run the changes in debug mode in CLI). Though I have main-silver source code, when I use IDE in debug mode, 95% of the time the source and break-points dont match. I tried with Netbeans 7.0/7.1/7.1.1 with main-silver. I think im missing some basic configuration here. Can you please tell me which source branch matches with which (at least one) version of Netbeans binary. This is taking more than 40% of my time. Any help is appreciated. Thanks, Pragalathan M Hi everyone! I'd like to show you my own solution for the JBoss 7 problem. I wrote my own standalone tool which runs outside Netbeans using Swing. All I needed was actually what Netbeans already offers for every server but JBoss 7: * Catching the server output * format the output using different colors and styles, e.g. INFO messages in gray, lines containing own packages in bold letters. * find text (match case and RegEx) * filter text (just like find) * quick filter: showing only INFO/WARN/ERROR messages or messages from my own package * start and stop the server You can test it here: http://www.bernhardrent.de/ServerConsole/ServerConsole.jar Copy it into your own directory and doubleclick the icon. If you started it the first time, it will open the Options window, where you can adjust your server settings and the name of your own packages which will be printed in bold letters. Or you can download the sources (as a Netbeans project): http://www.bernhardrent.de/ServerConsole/ServerConsole.zip Here are some screenshots and explanations: http://www.bernhardrent.de/ServerConsole/screenshots.html I'm using ServerConsole like that: 1. I deploy my web app using Maven: the war file is copied into the <jboss7>/standalone/deployments directory. You can use ant to copy it to the deployments directory, too. The point is: This tool does not deal with the deployment, it just catches the server output. 2. Then I start ServerConsole and start the server from there. If the JBoss 7 process is already running, i.e. you have started the server manually, it cannot catch the server output and you have to stop the server and restart him again. Issues: * Tested only on Windows 7, not on Linux, not on a Mac * Tested only on JBoss 7. Actually it just catches the output of any process (here: standalone.bat), so it can be used with any command-line tool that emits output * When the server crashes while shutting down (via jboss-cli.bat --connect command=:shutdown), my tool cannot gracefully handle that. If someone can provide me with information how to deal with that, I'd be eager to hear that * Minor swing issues concerning the layout (the quickfilter buttons on the left side have an unnecessary padding on the left and the right side) * Bugs which you have to discover and have to mail me Ok, enough for now. I hope you enjoy using this tool. Any bug reports, corrections, help and suggestions are very much appreciated. *** Bug 215338 has been marked as a duplicate of this bug. *** Hi everyone, Can you guys please help me to add Jboss 7.0.2 to my Netbeans 7.0.1? I noticed the patch file you have mention, but could not understood how to add this in Netbeans. I am a newcomer of this blog. Thanks in advance. (Replying in comments just since this is so high in Google that lots of people not used to bug trackers will be finding it): Hi iloverounak You commented on a bug tracker entry, not a blog. It's where software developers working on NetBeans discuss proposed changes and try to solve problems with the NetBeans code. I recommend you ask for help on the NetBeans forums if you're looking for general advice how to apply patches and compile NetBeans: http://forums.netbeans.org/ Just include a link to the bug report in your post so people know which patch you're talking about. The short version of the answer to your question is that you need to download the NetBeans source code, apply this patch using the "patch" command-line tool, then compile your own custom version of NetBeans You may have to adjust the patch code if it doesn't apply cleanly due to changes in NetBeans since it was written, too. I wouldn't recommend it for a beginner. See: http://wiki.netbeans.org/WorkingWithNetBeansSources People interested in this topic may wish to keep an eye on recent discussion on the topic, like: http://stackoverflow.com/questions/11557940/how-to-setup-jboss-server-with-netbeans Created attachment 124409 [details]
Jboss As 7 Patch
This patch features the following with respect to Jboss AS 7
1. Register Jboss AS7 server with the Netbeans IDE
2. Start the server
3. Stop the server
4. Deploy applications (tested JSP Web application. Need to test the rest)
5. Undeploy applications
6. View the deployed application in 'Services' panel
Known issues:
1. Compilation classpath is not populated.
2. While deploying applications, you will see the following error, though the deployment is successful.
"Browsing: ${client.url}
.../WebApplication2/nbproject/build-impl.xml:989: "
3. While un-deploying applications, you will see the following error, though the operation is successful.
"Deployment Manager not connected"
4. While expanding some server nodes(such as EJB modules, EAR Applications) you may see "Deployment Manager not connected" error.
5. When the server is down (not started), expanding "servers" node takes lot of time to get the JBossAS7 node's status
Created attachment 124410 [details]
Jboss AS 7 icon
Hi Petr Hejl, I need your help in resolving the above issues, 1 and 3 in particular. Any pointer is appreciated. Thanks, Pragalathan M *** Bug 209624 has been marked as a duplicate of this bug. *** Use this ant script to deploy on build, and undeploy on clean. http://stackoverflow.com/a/13372389/980442 Very helpful. *** Bug 222574 has been marked as a duplicate of this bug. *** Thanks for redirection. Is there any chance that this can make it into the daily builds? I also very much need this for my current job. ** EVERYONE, DON'T FORGET TO VOTE FOR THIS! ** This already has over 100 votes, so this should be top priority, correct? (In reply to comment #53) > Created attachment 124409 [details] > Jboss As 7 Patch > > This patch features the following with respect to Jboss AS 7 > 1. Register Jboss AS7 server with the Netbeans IDE > 2. Start the server > 3. Stop the server > 4. Deploy applications (tested JSP Web application. Need to test the rest) > 5. Undeploy applications > 6. View the deployed application in 'Services' panel > Hi pragalathan, I've just found some time to look at your last patch, however it is not compilable for me. I guess there is a missing class named JB7RemoteAction. Can you please upload a patch with this class included? Thanks. Created attachment 128998 [details]
JBoss AS 7 patch
This patch also addresses the classpath issue.
Hi Petr Hejl, Thanks for finding the missing file. I have attached the new patch. This patch also addresses the compilation classpath issue. However, I need to make appropriate changes JBJ2eePlatformFactory.java to cover all the cases of compilation classpath. -Pragalathan M I know this is probably a stupid question but could you tell me how add this patch to netbeans 7. *? dominik Hi dominik Refer to comment #40 or comment #41 (In reply to comment #64) > Hi Petr Hejl, > Thanks for finding the missing file. I have attached the new patch. This patch > also addresses the compilation classpath issue. However, I need to make > appropriate changes JBJ2eePlatformFactory.java to cover all the cases of > compilation classpath. > > -Pragalathan M I'm really sorry, but it seems JB7RemoteAction is still missing in the patch. If you use hg diff to generate the patch then perhaps the file is not added (use hg add). Thanks. Created attachment 129200 [details]
JBoss AS 7 patch
My bad. I should have checked it. Please check and let me know. Created attachment 129217 [details]
updated patch
Attaching updated patch with some cleanup targeted to daily. Includes icon as well. Apply with "hg patch --no-commit jboss.patch" on recent trunk.
Otherwise looks promising. I'll investigate this one: "While deploying applications, you will see the following error, though the
deployment is successful.
Browsing: ${client.url}".
Created attachment 129336 [details]
patch
Only API jars on CP. Detects start even when started with errors. Now I'm facing issue with some phantom persistence.xml being created on run preventing correct deployment.
Created attachment 129342 [details]
patch
Client url solved. TargetModuleID implemented in JBoss 7 always returns null from getWebURL().
Now I see the MalformedURLException on redeploy. It looks like JBoss set moduleID of TargetModuleID to war name yet it is not able to handle such TargetModuleID when passed to redeploy - it thinks it should be URL :( I'll try to do something about that. Created attachment 129463 [details]
improved patch
In this patch a lot of things is fixed. One major issue I noticed is possible thread leak do not recreation of DM. I do not see "not connected exception", but that might be related.
Feel free to apply and test/improve.
Adding myself to CC Hi I've pushed the patch plus some more improvements to jboss7 branch of web-main repository. Any testing welcomed. The patch attached to this issue does not reflect the latest updates anymore. I noticed open in browser action does not work due to missing context path because TargetModuleID implemented in JB does not return web url. (In reply to comment #76) > Hi I've pushed the patch plus some more improvements to jboss7 branch of > web-main repository. Any testing welcomed. > > The patch attached to this issue does not reflect the latest updates anymore. Does that mean it's part of the daily build? If not, where's this "web-main" repo and how do you install it? (In reply to comment #78) > (In reply to comment #76) > > Hi I've pushed the patch plus some more improvements to jboss7 branch of > > web-main repository. Any testing welcomed. > > > > The patch attached to this issue does not reflect the latest updates anymore. > > Does that mean it's part of the daily build? No. >If not, where's this "web-main" http://hg.netbeans.org/web-main > repo and how do you install it? Get sources: http://wiki.netbeans.org/HgHowTos#Getting_a_working_copy:_cloning_the_NetBeans_repository Switch to the branch: hg up jboss7 Build it: http://wiki.netbeans.org/HgHowTos#Doing_your_first_build Improvements to make deployment more reliable: http://hg.netbeans.org/web-main/rev/d24fe8ffebf1 http://hg.netbeans.org/web-main/rev/196050496802 I improved undeployment and classpath. I noticed the datasource does not work as it is completely different in AS7. Hi Petr Hejl, Im unable to clone web-main. I tried 4 times and each time waited for 2-4 hrs. Either it times out or no progress after 800+MB is downloaded. I have main and main-silver. Can I make use of them? Or is there any other way to test the changes? Thanks, Pragalathan M (In reply to comment #82) > Hi Petr Hejl, > Im unable to clone web-main. I tried 4 times and each time waited for 2-4 hrs. > Either it times out or no progress after 800+MB is downloaded. Perhaps you may try it again. In case there was some issue that has been already fixed. > I have main and main-silver. > > Can I make use of them? Or is there any other way to test the changes? Yep. In your main-silver change URL in .hg/hgrc to "http://hg.netbeans.org/web-main" and do "hg pull" and "hg update". This way your main-silver should became web-main. Then you can switch to branch by "hg up jboss7" and build it. Lot of things have been fixed recently. Thanks, P. > > Thanks, > Pragalathan M Thanks Petr Hejl. I converted main-silver to web-main. Let me test and post if I find anything. (In reply to comment #84) > Thanks Petr Hejl. I converted main-silver to web-main. Let me test and post if > I find anything. Hi Pragalathan, any findings? Adding Marian and Jirka on cc. This should be part of 7.3.1. Hi Petr, I have tested the following; it is working fine. 1. Servlet 2. JSF 3. EJB3 session bean 4. EJB injection in Servlet Datasource and entity beans are not working. Will test again and post in detail. (In reply to comment #87) > Hi Petr, > I have tested the following; it is working fine. > > 1. Servlet > 2. JSF > 3. EJB3 session bean > 4. EJB injection in Servlet > > Datasource and entity beans are not working. Will test again and post in > detail. The datasource creation is not supported now. But you can use datasources defined in the server if any... (In reply to comment #88) > The datasource creation is not supported now. But you can use datasources > defined in the server if any... Disclaimer: I'm not sure if you're referring to creating a datasource directly in Jboss, or creating a datasource within the app (which Jboss will install when deploying the app). I also haven't looked at this code, so if you were referring to creating a datasource directly in Jboss, or if I say something more obtuse than normal, please ignore me. :) As of JEE6, Java now has a standard way of specifying a datasource (from within the app which will be installed by the app server on deployment). Can this standard way be used when creating datasources instead of the Jboss specific descriptor? This way, the code can (hopefully) be reused for all plugins, and the packaged EAR will be more portable... (In reply to comment #88) > (In reply to comment #87) > > Hi Petr, > > I have tested the following; it is working fine. > > > > 1. Servlet > > 2. JSF > > 3. EJB3 session bean > > 4. EJB injection in Servlet > > > > Datasource and entity beans are not working. Will test again and post in > > detail. > The datasource creation is not supported now. Thanks Petr. I was trying to create a datasource in the IDE and it didnt work, as you have said. I will dig further and see what can be done. >But you can use datasources > defined in the server if any... Yes, I will try to use the existing one and see how it works (In reply to comment #89) > (In reply to comment #88) > > The datasource creation is not supported now. But you can use datasources > > defined in the server if any... > > Disclaimer: I'm not sure if you're referring to creating a datasource directly > in Jboss, or creating a datasource within the app (which Jboss will install > when deploying the app). I also haven't looked at this code, so if you were > referring to creating a datasource directly in Jboss, or if I say something > more obtuse than normal, please ignore me. :) > > As of JEE6, Java now has a standard way of specifying a datasource (from within > the app which will be installed by the app server on deployment). Can this > standard way be used when creating datasources instead of the Jboss specific > descriptor? This way, the code can (hopefully) be reused for all plugins, and > the packaged EAR will be more portable... Yes, this will still be packaged along with the app. However they are application server specific, be it GF, Tomcat or JBoss; I havent come across any unified approach to this other than going to spring and C3P0 of Hibernate which is altogether different and is not managed by your app server. It would help me if you can share some links relating the to the unified spec or example program. Merged to trunk and 7.3.1. Pragalathan, thank you very much for your contribution on this! Yup, you can specify them with annotations or by adding stuff to one of the various deployment descriptors: https://blogs.oracle.com/enterprisetechtips/entry/datasource_resource_definition_in_java IMHO the descriptor approach is better because you can more easily avoid checking in user names/passwords--just use placeholders and property substitution during the build. Of course I've never actually used it yet... Working great! A couple of nit-picky thing I did notice: - When adding a jboss 7 server to a maven project, it adds this to the pom file <properties> <netbeans.hint.deploy.server>JBoss4</netbeans.hint.deploy.server> </properties> Shouldn't that be JBoss7? :) - When adding a jboss 7 server to a maven project, it adds a "jboss-app.xml" descriptor. Since anything you can put in there (that Netbeans would care to implement in it's UI) now has an equivalent in a standard descriptor (in JEE6), why not create/use standard descriptors instead, so we can more easily port an app to...I don't know...Oracle's app servers? I guess you would have to support *reading* jboss-specific descriptors as well. Hey guys, how can I help testing this ? I currently have a brand new Ear=War+EJB Project being developed with Wicket, CDI etc running in JBoss7. Eclipse sucks big time and I would love test this against NetBeans. Do I need / can you provide a snapshot executable (linux x64) oder do I just have to add/replace some jars ? Cheers, Tom. (In reply to comment #95) > Hey guys, how can I help testing this ? You can just download the latest development build: http://bits.netbeans.org/download/trunk/nightly/latest/ (In reply to comment #94) > Working great! A couple of nit-picky thing I did notice: > > - When adding a jboss 7 server to a maven project, it adds this to the pom file > > <properties> > <netbeans.hint.deploy.server>JBoss4</netbeans.hint.deploy.server> > </properties> > > Shouldn't that be JBoss7? :) Nope it is internal server type. Which is for historical reason JBoss4. Change would probably cause some incompatibilities without any benefit. > > - When adding a jboss 7 server to a maven project, it adds a "jboss-app.xml" > descriptor. Since anything you can put in there (that Netbeans would care to > implement in it's UI) now has an equivalent in a standard descriptor (in JEE6), > why not create/use standard descriptors instead, so we can more easily port an > app to...I don't know...Oracle's app servers? I guess you would have to support > *reading* jboss-specific descriptors as well. If you feel there is a problem with that please file a separate enhancement. Thanks. Thanks for the nice work. I have been using it for a few days now (snapshot 2013020300001) and noticed the following: The deploy to the AS7 works fine and is successful. The redeploy reports a failure in the "run" tab but reports successful redeployment in the "JBoss Application Server" Tab. I think the failure is reported before redeploy finishes (too early). Run tab: pre-run-deploy: Distributing ...xxxportal.ear to [org.jboss.as.ee.deployment.spi.DeploymentManagerTarget@38879202] Deploying xxxportal.ear Failed xxxportal/nbproject/build-impl.xml:294: The module has not been deployed. See the server log for details. BUILD FAILED (total time: 7 seconds) JBoss Application Server tab: 00:36:39,530 INFO [org.jboss.web] (MSC service thread 1-1) JBAS018210: Registering web context: /xxxportal 00:36:39,873 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "xxxportal.ear" Not a big deal, but not 100% ok... ;) Any ideas what I could try / do different ? Finally took the time to try getting this to run without maven or glassfish jars. I had to manually download http://search.maven.org/#search|ga|1|a%3A%22jboss-javaee-all-6.0%22 and add the jar to my projects. Should we not have a ready-to-use "Java EE 6 from JBoss 7" library available for selection ? (The Standard EE API is not sufficient to use: "Absent code" exceptions...) (Adding the Glassfish EE was just a couple of clicks. Getting rid of it was trickier ;-) (In reply to comment #99) > Finally took the time to try getting this to run without maven or glassfish > jars. > > I had to manually download > http://search.maven.org/#search|ga|1|a%3A%22jboss-javaee-all-6.0%22 > and add the jar to my projects. > > Should we not have a ready-to-use "Java EE 6 from JBoss 7" library available > for selection ? > (The Standard EE API is not sufficient to use: "Absent code" exceptions...) > > (Adding the Glassfish EE was just a couple of clicks. Getting rid of it was > trickier ;-) I think "7.1.1.Final" from http://www.jboss.org/jbossas/downloads/ should have all the jars as it is a complete Java EE profile server. Isn't it? Yes, I think AS7 should have all available libraries bundled. (In reply to comment #93) > Yup, you can specify them with annotations or by adding stuff to one of the > various deployment descriptors: > > https://blogs.oracle.com/enterprisetechtips/entry/datasource_resource_definition_in_java > > IMHO the descriptor approach is better because you can more easily avoid > checking in user names/passwords--just use placeholders and property > substitution during the build. Of course I've never actually used it yet... Found an interesting document related to datasource configuration in Jboss as7. https://community.jboss.org/wiki/DataSourceConfigurationInAS7 It says, "Since Java EE6, the new annotation "@DataSourceDefinition" has existed to allow users to configure a data source directly from within their application. (Note that this annotation bypasses the management layer and as such it is recommended only for development and testing purposes.) This annotation requires that a data source implementation class (generally from a JDBC driver JAR) be present on the class path (either by including it in your application, or deploying it as a top-level JAR and referring to it via MANIFEST.MF's Class-Path attribute) and be named explicitly."
> I think "7.1.1.Final" from http://www.jboss.org/jbossas/downloads/ should have
> all the jars as it is a complete Java EE profile server. Isn't it?
What I meant to say is:
Of course JBoss comes with it's own libraries, as does Glassfish, both are
top level Application Servers (both are just "any other ee6 compliant
application server", with NetBeans benefiting Glasshfish...)
But to get Glassfish to run, is just a couple of clicks, because you can
say "Add Library" - "Java EE 6 from Glassfish".
For JBoss, that's an hour of work, because you need to find the correct
library(s) in the matching version(s), add it to NetBeans, download
Sources, configure Sources et all.
It would be easy if JBoss install had a "org/jboss/javaee6jboss.jar" somewhere,
with the source jar by the side, but it does not have it, or at least not
under a name where you would easily find it...
(of course that last thing is not a Netbeans problem, but..:)
It would be way cool, if there was a "Add Library" - "Java EE 6 from JBoss AS7".
Also, I believe some stuff, like the validation of JPA annotations in the
editor, uses glassfish classes, as I get no validation, but class not found
errors, when using Hibernate4/JBoss...
But I can't be sure if that's my fault, because I can't be sure of the setup,
since there is no "default standard"...
(In reply to comment #103) TL;DR version: my vote is "even though I use Jboss professionally myself, I don't want Netbeans developers wasting time with Jboss-specific configuration. Also, the ultimate goal of Oracle isn't to get people to use NetBeans (that's a stepping stone)--it's to get people to buy their app server and not someone else's. Soapbox version: but should NetBeans--owned by Oracle--put development effort into getting Jboss's vendor-specific stuff to work in NetBeans, thus facilitating vendor lock-in? Let Jboss do that. It's not my decision obviously, but I would be happy if the developers just focused on incorporating the new app-server agnostic equivalents , which are supported by JAS 7 and every other JEE 6+ app server. That way the code could be reused for all app servers and the NetBeans developers can more quickly move on to implementing all the other features I want. :) If a project already has Jboss-specific configuration files, the approach that would require the least "non-reusable" NetBeans developer effort and supports Oracle's goals best is to simply convert Jboss-specific config files to the new vendor-agnostic equivalents. In other words: - A developer opens her JBoss JEE project in NetBeans. The project has Jboss-specific config files. - The developer then specifies that the target server is JAS 7 in the project properties. - NetBeans warns that the config files will be converted to the JEE 6+ equivalents (and the old Jboss files will be backed up somewhere). The developer can either agree or disagree. - NetBeans can then pretty much forget that this is a Jboss project from that point on and present vendor-agnostic server configuration options, which can be reused for any JEE 6+ app server. The downside for the developer is that the project is now JEE 6 + only, but that shouldn't be too big a deal since they're targeting JAS 7. The upside for the developer is that it's easier to convert to another JEE 6+ app server in the future (like Oracle's) if they ever decide that Jboss is evil. Heh, I forgot to address the question. :) If NetBeans supports Jboss using the vendor-agnostic JEE 6 config files, you don't need any weird vendor-specific jars. In my Jboss projects I just use "javaee-api-6.0.jar" for EJBs/ EARs and "javaee-web-api-6.0.jar" for WARs (both with the "provided" scope) and everything works fine. Those are the only two jars you need for JEE6 projects, and they don't have to be included in the EAR/EJB/WAR if deploying to an app server. In fact, I've been meaning to open a bug because NetBeans shouldn't be trying to stick extra jars in my project for stuff like JSF--that's included already for any JEE 6+ app server. (In reply to comment #102) > https://community.jboss.org/wiki/DataSourceConfigurationInAS7 Exactly the approach NetBeans should support, since it's vendor-agnostic. It'll work for Jboss and every other JEE 6+ app server. (In reply to comment #106) > (In reply to comment #102) > > https://community.jboss.org/wiki/DataSourceConfigurationInAS7 > > Exactly the approach NetBeans should support, since it's vendor-agnostic. It'll > work for Jboss and every other JEE 6+ app server. I think it (@DataSourceDefinition) is already supported. Can you please check and let me know if there is any bug? Okay, I am not talking about implementing every JBoss specific / proprietary
feature. That is definetly up to RedHat, who chose to support Eclipse...
(and again, this about Standard EE so Glassfish proprietary should also
not be supported...)
> don't need any weird vendor-specific jars. In my Jboss projects I just use
> "javaee-api-6.0.jar" for EJBs/ EARs and "javaee-web-api-6.0.jar" for WARs (both
> with the "provided" scope) and everything works fine. Those are the only two
> jars you need for JEE6 projects, and they don't have to be included in the
> EAR/EJB/WAR if deploying to an app server.
Well, that's how I started, but I got
An annotation processor threw an uncaught exception.
Consult the following stack trace for details.
java.lang.ClassFormatError: Absent Code attribute in method that is not native or abstract in class file javax/persistence/AccessType
and that's where the Odyssey started...
Compile works fine using jboss-javaee-all-6.0-3.0.2.Final.jar ...
(In reply to comment #107) > I think it (@DataSourceDefinition) is already supported. Can you please check > and let me know if there is any bug? Yup. Is there documentation somewhere I can read so I know how it's supposed to work? (In reply to comment #108) > Well, that's how I started, but I got > > An annotation processor threw an uncaught exception. > Consult the following stack trace for details. > java.lang.ClassFormatError: Absent Code attribute in method that is not native > or abstract in class file javax/persistence/AccessType > > and that's where the Odyssey started... > > Compile works fine using jboss-javaee-all-6.0-3.0.2.Final.jar ... What' annotation gave the trouble? ...if it's a Jboss-specific annotation, obviously you're still going to need the jar that supplied the annotation ("provided" scope). But you bring up a good point--NetBeans might want to convert any Jboss-specific annotations to their generic equivalents as well as descriptors. > What' annotation gave the trouble? Ahem, javax.persistence.AccessType and that's not JBoss/Hibernate specific. "Absent Code Exception" might be the thing about "crippled EE6 API libraries" that Adam Bien keeps talking about, recommending to use "Java EE6 from Glassfish", and there we go again ;-) http://www.adam-bien.com/roller/abien/entry/trouble_with_crippled_java_ee (In reply to comment #112) > > What' annotation gave the trouble? > Ahem, javax.persistence.AccessType and that's not JBoss/Hibernate specific. Ah! JPA is in JSE, not JEE. So long as you're using Java 6 or better, you have it. If not, you need the javax.persistence jar. It has nothing to do with java EE, except it's normally used with it. If Jboss is including that in their API jar it makes me seriously question their packaging practices. In any case, you should definitely still include the persistence jar in your WAR/EJB if you're targeting Java 5. (In reply to comment #109) > (In reply to comment #107) > > I think it (@DataSourceDefinition) is already supported. Can you please check > > and let me know if there is any bug? > > Yup. Is there documentation somewhere I can read so I know how it's supposed to > work? 1. You can use the link that you have provided in comment #93 for code reference 2. Add your (only the) db driver to Jboss installation as stated in https://community.jboss.org/wiki/DataSourceConfigurationInAS7 3. Create entities and deploy Let me know if it helps. > Ah! JPA is in JSE, not JEE. So long as you're using Java 6 or better, you have > it. If not, you need the javax.persistence jar. It has nothing to do with java > EE, except it's normally used with it. If Jboss is including that in their API > jar it makes me seriously question their packaging practices. In any case, you > should definitely still include the persistence jar in your WAR/EJB if you're > targeting Java 5. Hmm, but it's (see the javaee in the URL): http://docs.oracle.com/javaee/6/api/javax/persistence/package-summary.html And the error disappears with "JavaEE from Glasshfish" instead of "JavaEE API". I am targetting Java6 or 7, not 5. May we come back to my initial topic, that it's NOT easy to get a standard JavaEE (not even JBoss proprietary) compiling for and running in JBoss AS7 with NetBeans... I think the point it proven now. (In reply to comment #115) > Hmm, but it's (see the javaee in the URL): > http://docs.oracle.com/javaee/6/api/javax/persistence/package-summary.html I stand corrected. I'm looking inside the jar file and it is included--it must be so people targeting java 5 don't need to include anything else. But once again it's a part of JSE, not JEE. > And the error disappears with "JavaEE from Glasshfish" instead of "JavaEE API". ... > I am targetting Java6 or 7, not 5. First, you're confusing an API with an implementation. Second, if you're compiling against java 6 there must be some issue with your config because (a) a problem as basic as "the included persistence jar doesn't work" would never see the light of day and (b) nothing should be using the persistence jar included in javaee-api-6.0.jar anyway. Can you send me a sample project with that problem? > May we come back to my initial topic, that it's NOT easy to get a > standard JavaEE (not even JBoss proprietary) compiling for and running in > JBoss AS7 with NetBeans... I think the point it proven now. That's simply not true. As I mentioned, I do it all the time. You throw in javaee-api-6.0.jar or javaee-web-api-6.0.jar with the provided scope and you're done. Can you send me an example project which shows a problem? (In reply to comment #116) > I stand corrected. I'm looking inside the jar file and it is included--it must > be so people targeting java 5 don't need to include anything else. But once > again it's a part of JSE, not JEE. That is, people *compiling against* java 5. What version can I expect this? It's marked FIXED, but 7.3 still prompts me to "Provide a valid JBoss Application Server 6, 5 or 4 Location". The target milestone (see fields at the top) is 7.3.1. Correct - development builds for NetBeans 7.3.1 can be downloaded here: http://bertram2.netbeans.org:8080/job/web-main-javaee7/ Is it possible to release this Jboss AS 7 support for current Netbeans 7.3? Maybe an update? Or maybe as a plugin? Yes, this is planned for NetBeans 7.3.1. Development builds of 7.3.1 can be downloaded here: http://bertram2.netbeans.org:8080/job/web-main-javaee7/ (In reply to comment #121) > Is it possible to release this Jboss AS 7 support for current Netbeans 7.3? > Maybe an update? Or maybe as a plugin? You may download new development version - JAS7 support works fine. Downloaded the latest night build, but couldn't deploy a hello world app in my local Jboss as 7.1.0. (LInux OS) When running the app from the IDE, JBoss AS 7 starts and the app starts being deployed but does not succeed. I get this stack trace: java.lang.ClassNotFoundException: org.jboss.remoting3.spi.ConnectionProviderFactory at java.net.URLClassLoader$1.run(URLClassLoader.java:366) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:423) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) Caused: java.lang.NoClassDefFoundError: org/jboss/remoting3/spi/ConnectionProviderFactory at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:211) at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:173) at org.jboss.as.ee.deployment.spi.DeploymentManagerTarget.<init>(DeploymentManagerTarget.java:89) at org.jboss.as.ee.deployment.spi.DeploymentManagerImpl.getTargets(DeploymentManagerImpl.java:148) at org.netbeans.modules.j2ee.jboss4.JBDeploymentManager$11.execute(JBDeploymentManager.java:706) at org.netbeans.modules.j2ee.jboss4.JBDeploymentManager$11.execute(JBDeploymentManager.java:702) at org.netbeans.modules.j2ee.jboss4.JBDeploymentManager$2.call(JBDeploymentManager.java:193) at org.netbeans.modules.j2ee.jboss4.JBDeploymentManager.invokeLocalAction(JBDeploymentManager.java:262) at org.netbeans.modules.j2ee.jboss4.JBDeploymentManager.executeAction(JBDeploymentManager.java:183) at org.netbeans.modules.j2ee.jboss4.JBDeploymentManager.getTargets(JBDeploymentManager.java:702) at org.netbeans.modules.j2ee.deployment.impl.ServerInstance.getTargetMap(ServerInstance.java:558) at org.netbeans.modules.j2ee.deployment.impl.ServerInstance.getTargets(ServerInstance.java:516) at org.netbeans.modules.j2ee.deployment.impl.ServerInstance._retrieveTarget(ServerInstance.java:1830) at org.netbeans.modules.j2ee.deployment.impl.ServerInstance.getDebugger(ServerInstance.java:973) at org.netbeans.modules.j2ee.deployment.impl.ServerInstance.isSuspended(ServerInstance.java:1022) at org.netbeans.modules.j2ee.deployment.impl.ServerInstance$1.run(ServerInstance.java:388) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1432) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2044) Caused: org.openide.util.RequestProcessor$SlowItem: task failed due to at org.openide.util.RequestProcessor.post(RequestProcessor.java:424) at org.netbeans.modules.j2ee.deployment.impl.ServerInstance.refresh(ServerInstance.java:378) at org.netbeans.modules.j2ee.deployment.impl.ServerInstance.start(ServerInstance.java:1089) at org.netbeans.modules.j2ee.deployment.impl.TargetServer.startTargets(TargetServer.java:549) at org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment.deploy(Deployment.java:186) at org.netbeans.modules.maven.j2ee.ExecutionChecker.performDeploy(ExecutionChecker.java:185) at org.netbeans.modules.maven.j2ee.ExecutionChecker.executionResult(ExecutionChecker.java:136) at org.netbeans.modules.maven.execute.MavenCommandLineExecutor.run(MavenCommandLineExecutor.java:212) [catch] at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:153) ---- I checked the jboss as 7 installation and it has the required jar under : /home/hanine/jbossas7/modules/org/jboss/remoting3/main/jboss-remoting-3.2.2.GA Second symptom: I can't start/stop the server from the SERVICES tab. Anyone having the same issue. Hi Hanine, Can you post your sample program? Also please try with Jboss 7.1.1 Final, and let me know if you see the same behavior. -Pragalathan M All, please do not use this issue for any problem you found in JBoss. File a separate issue. Sorry for the bother. Indeed, I replaced 7.1.0 by 7.1.1 and everything works fine. Thanks everybody for the great work. Netbeans Rock. Sorry for posting to this bug again, but since it is the main content of 7.3.1: I just noticed that currently nightlies do required Java 7.10 (and no longer work with any Java6) on MacOS - as apposed to NB 7.3.0 which still runs on Java6. Will 7.3.1, once released, run on Java6 or does it require Java7 like the current nightlies. Is there a real reason for this (possibly within this bug?) Requiring Java7 is a major issue for some OSX users, as Java7 is not available for OSX 10.6.8, forcing an upgrade / purchase of operating system upgrade from Apple (for no other reason, really ;-) Only select features from daily builds of get ported back to maintenance releases. I'm not a NetBeans guy, but I'm certain that 7.3.1 would be still compatible with JDK6, while netbeans 8 (due out in the fall, I think) would be the one that requires JDK7. By that time, JDK8 will be out and JDK7 will have been out over 2 years. This, by the way, is off topic for this bug. Please send future questions like this to the mailing list. I'm sure we've irritated more than a few people who read these comments expecting them to be related to JBoss. Hi Petr Hejl, I would like to know whether i can work or this as i did for jboss7.1.1, or someone is already looking into it. Also, if i can work on this, what branch should I use? Actually there is a separate plugin for Wildfly on update center maintained by Emmanuel Hugonnet. I've assigned this issue to him, but as you can see it is already resolved. Feel free to cooperate with him on the new plugin. He has done a great work. Thanks for your help, guys. (In reply to pragalathan from comment #131) > Hi Petr Hejl, > I would like to know whether i can work or this as i did for jboss7.1.1, or > someone is already looking into it. > > Also, if i can work on this, what branch should I use? The WildFly plugin doesn't support AS 7.1.1, it has basic support for EAP 6 and focus mainly on WildFly. downloaded netbeans 8.1 , tried to start wildfly version 9 using the plugin, am getting the error message address already in use When i click the wildfly server plugin options such as view console , and others it simply hangs on and does nothing (In reply to Ram19 from comment #134) > downloaded netbeans 8.1 , tried to start wildfly version 9 using the plugin, > > am getting the error message address already in use > > When i click the wildfly server plugin options such as view console , and > others it simply hangs on and does nothing @Ram19: Do not reopen issues, which have been solved years ago. The NB developers won't track those issues. Please file a new issue! Internal note: Revert back to previous state. Resolved fixed - version 7.2.1 (In reply to Ram19 from comment #134) Additionally, the 'address in use message' leads me to believe that it's not an issue with NetBeans, but rather you already have something running on that address/port. Make sure that you're not already running some other app server/servlet container like Tomcat, Glassfish, Jetty, etc. |