Can I create a module for NetBeans that runs in the background as soon as the user opens the NetBeans IDE? For example, I am building a plugin that captures the source code of the active JTextComponent (active code editor) in NetBeans, but I would like this plugin to always run in the background without having to be activated by the user clicking a button or pressing some key combination.
Is this possible, and if so, what is the best way of doing it?
Yeah, just create a "Install.java" inside the root package of your module and subclass it with ModuleInstall class, then start a process that runs continuously inside the restored() methods. The restored() method gets called on module installation and everytime netbeans starts. So your process will start as soon as the module is loaded in Netbeans.
ModuleInstall
Also checkout this section from DevFaqModulesGeneral.
Programmatic registration - ModuleInstall classes The module system
allows you to provide a ModuleInstall class, which runs some code
during startup or when the module is loaded, and can run cleanup code
when it is uninstalled or disabled. This is the least desirable way
to do things, because running code on startup means slowing down
startup. Before you use such a class, be sure there is no declarative
way to do what you're trying to do; see:
DevFaqModulesDeclarativeVsProgrammatic
To have some code run on startup/installation/uninstallation/etc., add
a line like the following to your module's manifest file:
OpenIDE-Module-Install: org/netbeans/modules/paintcatcher/PaintCatcherModule.class
This line should be part of the group of lines at the top of the
manifest, with no blank lines before it. It is a pointer to a class
file inside the module. The class file must extend the class
org.openide.modules.ModuleInstall. There is a wizard in the
development support to create and register such a class for you.
Related
I'm using install4j to create an installer for my java application.
I'm using executable level "As invoker" and in the first start after installation, the application works fine calls all my loggers from the main class and all other classes. On the second start, an application doesn't call my main class. If I use the executable level "Administrator" application works fine.
Can somebody explain to me how to fix this?
I'm in the process of trying to write a VSCode extension to support basic SNES application development. I already have a basic grammar definition and build task, so I have syntax highlighting, and am able to build my project with Ctrl+Shift+B using the bass v14 assembler, but now I'm trying to figure out how to launch the project using launch.json. I've already worked through the official docs and played around with the mock debugger project, but I can't seem to figure out how to adapt it for my extension. To start, I'm using the bsnes-plus emulator as my debugger. There isn't really any command-line or IPC interface that will actually allow me to implement a proper debug adapter, so all I really want to do is to run the program and pass it my output file to launch. For the time being, I'm assuming that bsnes-plus.exe is located in my $PATH, but eventually I'll try and figure out the best practices for external executable dependencies for an extension.
So here are my current questions:
Is the "program" field of launch.json my compiled application, or is it bsnes-plus.exe?
If "program" is my application, where do I specify bsnes-plus.exe? Or vice versa.
Is there a way to specify my own project-level variables, e.g. $OUTPUT so that I don't have to hard-code the output filename into both the build task and the launch task?
At one point, I was able to get the launch command to open bsnes-plus, but not load the game, and when I closed it, VSCode complained that the debugger terminated unexpectedly and immediately re-opened bsnes-plus. How do I avoid this? Do I need to write a debug adapter even though it's not going to actually do anything other than launch the application, just so I can tell VSCode that it exited cleanly?
Is the "program" field of launch.json my compiled application, or is it bsnes-plus.exe?
This is entirely up to the debug extension. It's just passed through to the debug adapter. It usually corresponds to the specific app/script being debugged though, not the runtime that's running it, so I would suggest it should be your compiled application.
If "program" is my application, where do I specify bsnes-plus.exe? Or vice versa.
You can put it any other field. In Dart, we have a dartPath field that can be passed through to the debug adapter. It's usually populated silently by the DebugConfigurationProvider.resolveDebugConfig though (we detect the SDK by searching PATH) so the user never needs to add it.
Is there a way to specify my own project-level variables, e.g. $OUTPUT so that I don't have to hard-code the output filename into both the build task and the launch task?
You can't make your own variables, but using resolveDebugConfig you can manipulate the launch config yourself before it's passed to the debug adapter, which probably allows you to do what you need here (eg. you could do a string replace on program - or you could even just add it if it's not set, allowing a launch.json-less launch too).
Do I need to write a debug adapter even though it's not going to actually do anything other than launch the application, just so I can tell VSCode that it exited cleanly?
I'm not sure what happened here without more details, but having a debug adapter probably makes the most sense - for example if you want to make the Stop/Restart buttons work on the toolbar, you'd probably want a debug adapter that can terminate and/or restart the process.
Recently, I was assigned the task to create a deployment package for an application which btw, I'm totally new at. So far, so good.. Now there is a requirement to extract files from a zip file which will be bundled with the setup file. So, I had to write custom actions in the 'Commit' section of the Installer class. I added the Installer class in a new project of type 'Class Library' under the same solution. I wrote the code after 'base.Commit(savedState)'.
I tried showing MessageBox at the event entry point, used Debugger.Launch(), Debugger.Break() but somehow, no matter what I do, it seems that the custom action is not willing to be hit at all and the application just installs itself. I searched a lot of sites and blogs but no help so far.
I've assigned my installer class (SampleApp.exe, in my case) to all the Custom Action's modes (Install, Commit, Rollback and Uninstall) in the Deployment project. Any help.
P.S. I'm using a Visual Studio 2010 setup project.
Thanks, in advance!
You should probably be trying a class library Dll, not an executable (which is typically for something like a service).
You don't need it all the nodes if all you're doing is calling at Commit. And why Commit? Install is just the same in most cases.
If you're not seeing a MessageBox then probably your CA isn't being called, and that may because it's not a class library. Note that your CA is not running in the interactive user context - it's being called from an msiexec process running with the system account, so you must be very explicit about (say) the path to the zip file, and any user profile folders will probably fail because the system account doesn't really have them.
What files are these and where are they going on disk? If they are user profile files you can install the zip files to a per machine location and then have the application itself unzip the files to the desired location on first launch. Unzipping from within your setup is not good practice - it is error prone and bad design.
Using the application allows proper exception handling and interactivity (the user can be informed if something goes wrong). Set some registry flags in HKCU when you have completed the unzipping so it doesn't happen more than once, and perform the unzip once per user.
Using Visual Studio 2012:
I created an "ASP.NET Empty Web Application" (using C#).
I used NuGet to install the FubuMVC package.
When I run the application (using IIS Express), I get the "Welcome to FubuMVC!" page which tells me to delete the FubuMVC.GettingStarted.dll file and to set the home page.
So I do both of those things, implementing a HomeController that simply returns "Hello World" from Index.
Rather than the expected "Hello World", I get an IIS error: The Web server is configured to not list the contents of this directory.
What have I done wrong?
try this
cmd => don't forget to run as administrator
%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -ir
Just tried reproducing your problem with a brand new project; it turns out that problem is that the instructions in the example haven't kept up with the changes in FubuMVC.
The instructions tell you to create a class called 'MyHomeController' and add the Index() method to it. This used to work, because one of the default rules for routes was to use any class with a name that ends in 'Controller'.
But the default has been changed in more recent versions, and the rule now looks for classes ending in 'EndPoint'.
So if you change the name of the class from 'MyHomeController' to 'MyHomeEndpoint', it should work.
Also, remember that the application pool needs to restart for the new configuration to take effect, so you might have to touch your web.config (or force IISExpress to restart).
Did you activate FubuMVC in your Global.asax? I usually see that error when there is no FubuMVC application.
So in Application_Start() (or whatever it's really called), you'll need something like:
FubuApplication.DefaultPolicies().StructureMap(new Container()).Bootstrap();
Where you're telling it:
1.) What are the policies/conventions to use
2.) What's your IoC container
Usually if I run into this it's because I've got a conflict with a route and a folder in the project. For example, I might have a folder called 'Unit' and inside it I have a class called 'UnitEndpoint' with a method 'get_unit' (which should map to '/unit' as a route, assuming I'm using the FubuMVC defaults).
In that case, browsing to '/unit' will result in this error because IIS thinks I'm trying to list the contents of the 'Unit' folder. Renaming the endpoint or the folder to remove the conflict will fix it (e.g., renaming the 'Unit' folder to 'Units').
I suggest that you recompile your application or at least touch your global.asax -- looks like you need to rerun the App_Start method.
I am currently debugging a web application which uses a drools ruleset inside an EJB to process business rules. It's deployed inside a JBoss server. I've configured eclipse to run the server so I could use Debug on Server functionality of eclipse.
When I reach the class that fires the drools ruleset, the server loses focus and returns after all the rules are fired. Is there a way where I could trace what rules are being fired? Right now, what I do is put logs inside the *.drl files so I know where the application is inside the rules engine.
you can get the generated java source code of any rule when you add a file with name drools.packagebuilder.conf to your %USERHOME% directory.
The file must contain the following instruction:
drools.dump.dir = d:/myDroolsJavaSourceCode
The directory d:/myDroolsJavaSourceCode - Directory (or any other given name) must exist otherwise the Drools Packagebuild will stop execution.
Then you can add this directory to your Eclipse Environment as new project (probably you have to remove the flag 'Default Location' to choose the 'myDroolJavaSourceCode').
Then you can open the file in Eclipse and set break points in the editor.
May be you must attach the directory also during debugging execution twice.
Best regards!
Christof
As far as I know you can't debug drl file. What we did was to encapsulate the logic of when and then in a method, so that you can at least debug that.
Maddy
What I did is I downloaded the sources for drools-engine and compiled the drl files to their java sources. When you run the app, you'll have an option to attach sources when the break point reaches the engine. It's still hard to trace the rules that are fired (multiple rules from different drls can be fired) but it's better than just sysout logging.