I see that If I remove all launchers in install4j which are redundant to me as our project is webapp as a service, After doing build and executing the installer, The i4jruntime.jar present in C:\Program Files (x86)\Astra\.install4j does not contain com.install4j.api.update.UpdateChecker class. Is it mandatory to have
atleast one launcher? I am using install4j 7.0.2. Because of this the working Auto update functionality (Auto update for web app as a service with no launcher) has broken. Kindly help.
This is the "runtime shrinking" feature in install4j. If you start your webapp with a generated service launcher, the compiler will retain all referenced classes in the runtime, including the UpdateChecker.
You can disable runtime shrinking on the "General Settings->Media File Options" step by deselecting the "Shrink runtime library and remove all unused classes" check box.
Related
I'm trying to integrate an automatic update before the launch of my Java application without adding code to my application. If I read the documentation here (Section "Quick Start") correctly, this should be possible with the application template update downloader with silent version check. Yet, after following the docs, the updater itself is working just fine, but it is for some reason not invoked at application startup.
launcher integration configuration
Is there a way to do this?
EDIT 1:
Maybe this is relevant: the launcher is a .exe file that is generated by the application itself, and not a generated launcher by install4j
The automatic launcher integration only works for generated launcher executables. For external launcher executables you have to start the update downloader with the API. On the "Launcher integration" tab for the update downloader, click in the "Start integration wizard" button to get a corresponding code snippet. This requires that you add the install4j runtime to the compilation classpath (but not to the distribution), for more information see
https://www.ej-technologies.com/resources/install4j/help/api/
I would like to develop GUI application with plugins. The plugins contains VCL Forms which are inherited from Base Forms in the Plugin-Core library. The main application can select which plugin to load dynamically, and then which Form subclasses to display.
In the users side, I would like to deploy main .EXE, the Plugin-Core library, and many plugin libraries for different models. I could release new or modify existed plugin libraries to users to display new Forms for new devices without modifying the main .EXE and the Plugin-Core library.
The first version I developed uses DLL approach, namely both the Plugin-Core library and the plugins are in DLL form. Everything is just fine on the users side. However, in the developers side, the plugin DLL project can not be linked without Base Forms defined in the Plugin-Core DLL project. It means that the Base Forms are actually statically linked in each plugin DLL project, and if someday I modify the Base Forms and rebuild the Plugin-Core DLL project, I have to rebuild all plugin DLL projects and re-release plugin .DLL s to users, too.
After searching and asking in StackOverflow, I realized the limitation that VCL Forms can NOT be inherited across DLL boundary is due to RTTI conflict(?). The suggested solution is to modify the libraries from DLL to BPL form, which is the second version I developed. Everything is also fine except the following two:
The dynamic loaded Form from plugin BPL is separated from the main .EXE in Windows taskbar. It is not what I desired. The solution is that I enabled "Build with runtime packages" in the .EXE project.
After I enabled "Build with runtime packages" in the .EXE project, I have to release other .BPLs to the users, such as vcl.bpl and rtl.bpl. This is not perfectly what I desired.
I would like to know that the above two issues can be resolved at the same time? In my thought, I could resolve both two issues if I:
Disable "Build with runtime packages" in .EXE project.
Enable "Build with runtime packages" in all .BPL projects.
In this way, the .EXE can run without vcl.bpl and rtl.bpl bundled, and the plugin .BPL s can be loaded successfully because the dependent units are already part of the main .EXE? Am I correct? However, the "Build with runtime packages" checkbox is disabled in all .BPL project options. As a result I don't have a chance to check whether the solution works or not. I am sorry for the lengthy description and I can not attach picture due to company's Internet security policy.
The dynamic loaded Form from plugin BPL is separated from the main .EXE in Windows taskbar. It is not what I desired. The solution is that I enabled "Build with runtime packages" in the .EXE project.
After loading a BPL, pass the EXE's Application.Handle to the BPL and assign it to the BPL's own Application.Handle before it creates any Form instances.
Alternatively, on Windows 7+, you can have the EXE call SetCurrentProcessExplicitAppUserModelID() to establish a App ID for its taskbar button. Then each Form in the BPLs can use SHGetPropertyStoreForWindow() and IPropertyStore.SetValue(PKEY_AppUserModel_ID) to set the same App ID for their windows. Multiple windows with the same App ID are grouped together under a single taskbar button.
See MSDN for more details: Application User Model IDs (AppUserModelIDs)
I would like to know that the above two issues can be resolved at the same time? In my thought, I could resolve both two issues if I:
Disable "Build with runtime packages" in .EXE project.
Enable "Build with runtime packages" in all .BPL projects.
In this way, the .EXE can run without vcl.bpl and rtl.bpl bundled, and the plugin .BPL s can be loaded successfully because the dependent units are already part of the main .EXE? Am I correct?
No. BPLs cannot use the EXE's built-in units like that.
If you disable "Build with Runtime Packages", the RTL/VCL units will be statically linked into the executable file. The problem with doing that is multiple copies of a given unit cannot be loaded in memory at the same time, so you wouldn't be able to load multiple BPLs together (or even at all) if the same RTL/VCL units are statically linked into multiple BPLs, or even the EXE itself.
If you enable "Build with Runtime Packages", the executable file will be dependent on the RTL/VCL BPLs, which must then be deployed.
So, if your EXE and BPLs share common units, those units must be loaded via shared BPL(s) so only one copy of the units exist in memory. There is no avoiding that when writing custom BPLs. Which means at a minimum you usually have to deploy RTL.BPL if you are using basic RTL functionalities, and VCL.BPL for UIs.
I created a "dynamic web project" in eclipse and I added to the build path the requested libraries using a "user library". Why it is not sufficient to run the application and I need to copy the libraries in the lib folder of the project?
I understand that it should be a very simple concept, it should be connected on how eclipse and the server store libraries, but I can't find a simple answer.
It needs to end up inside "Web App Libraries" (as seen via Java Build Path > Libraries) in order to be present in the runtime classpath as well instead of only the compiletime classpath as you've currently apparently configured. The compiletime classpath is used when you write and compile code. The runtime classpath is used when the code is actually executed on server. Normally, user libraries are already manually supplied external to the webapp and server, e.g. via server configuration. But in your case this is apparently not the case.
One way to get an user library in runtime classpath of a webapp as well with help of Eclipse, the user library needs to be added in the "Deployment Assembly" section as well.
I'm having troulbe enabling JSF in Eclipse. I have installed the WPT tools that should have had JSF included but when I right click on my project, properties, facets, enable facets I get a warning saying "Further configuration required" I click this, and I'm notified that "At least one user library must be selected" However there are no libraries to select.
I can optionally select "Disable Library Configuration" but I don't know what effects this might have as Eclipse is telling me that i must configure a user library.
Should I download a separate Jar from the Mojarra and add this to my build? Or can I safely disable. Why wasn't it included with WTP like it was supposed to be?
"At least one user library must be selected" However there are no libraries to select.
You have to prepare them yourself by Window > Preferences > Java > Build Path > User Libraries.
I can optionally select "Disable Library Configuration" but I don't know what effects this might have as Eclipse is telling me that i must configure a user library.
When you choose this option, Eclispe will also tell you that the user takes the responsibility of configuring the classpath appropriately via alternate means.
Should I download a separate Jar from the Mojarra and add this to my build? Or can I safely disable.
That's one of the alternative ways. Whether you need to download it yourself depends on the project's target runtime. If it's for example a simple JSP/Servlet container which does not ship with bundled JSF, such as Tomcat 7, then you indeed need to install it yourself. Just dropping the JAR(s) in /WEB-INF/lib is sufficient (or defining it as an user library, of course). Eclipse will automagically do the right things for you (adding to build path, including in exported WAR, etc). However, if it's for example a more full fledged Java EE container, such as Glassfish 3, then you don't need to do anything as it already bundles JSF as part of Java EE API. Just disable the library configuration altogether.
Why wasn't it included with WTP like it was supposed to be?
They have JSF tools included. They do however not include JSF libraries. Or did you read otherwise? If so, where exactly? It must have been a misinformation or misinterpretation.
See also:
JSF 2.0 tutorial with Eclipse and Glassfish
Download javax.faces-2.1.17.jar file and create a new library from manage library option and add the jar file in that library. Click apply, now it will work
I need to configure my eclipse product to load all features/plugins in features/plugins directory. Now my product loads just plugins that are listed in metadata, so if I export some plugin directly from eclipse tool as "deployable plugins" it's loaded in my product, but if I put a plugin jar directly in plugins directory It doesn't appear (the same if I work with features)
I simply make new product configurations, put the feature that contains my application plugin and then exporting product I have this problem.
My eclipse version is 3.6.1
I think the problem is in the launcher configuration but I don't know what I have to change
In theory, your exported RCP application should simply pick up any new features and plugins you add later. However, make sure you put the extra stuff in the dropins folder of your RCP, since this is the expected location for manually installed features since the introduction of p2.
If for some reason it still doesn't work, try launching Eclipse with the -clean command line argument.
According to The Eclipse runtime options page, the -clean argument has the following effect:
[...] any cached data used by the OSGi framework and eclipse runtime will be wiped clean. This will clean the caches used to store bundle dependency resolution and eclipse extension registry data. Using this option will force eclipse to reinitialize these caches.
In my experience this can resolve many mysterious cases, where newly added plugins are not loaded by Equinox.