I try to implement most of the logic in any XPages application in Java. I don’t like the idea of attaching the jars or java code in the NSFs. I want to create repositories of java code that is available in all applications on a given server (maven). I know about the Domino/jvm /lib/ext folder. I also know I can use the JavaUserClassesExt=pathToJava resources in notes.ini
So the question is, are those methods mentioned above the best options to share java resources in an pure XPages environment or should I consider other alternatives?
You might check out this link, it will show you the basics of creating an "extension library"
http://www-10.lotus.com/ldd/ddwiki.nsf/dx/creating_an_xpages_library#Create+the+library+class
that you can use to implement a java jar across the whole server and replicate using the updatesite template to all your domino servers.
The XPages way to create shared resources for all applications for a given server is to code an OSGi plug-in (a.k.a. extension library). This way you can clearly declare the dependencies of your NSFs, it will survive reinstalls upgrades and when you use the updatesite.nsf approach can be shared between servers too.
There's a book detailing how to build one.
Related
I was curious about what being a "shared J2EE library" means, and the things that I should consider prior to saying that my JAR is a "shared J2EE library".
According to the Oracle docs, a shared J2EE library can be a "single, simple JAR". What does the term "simple" mean in this situation?
Are there restrictions on what a simple JAR that is a shared J2EE library can do or not do? Can my JAR spawn threads, do network I/O etc.? I understand that the J2EE framework was originally designed with libraries being treated as beans originally, and this bean design had some set of restrictions (eg. they weren't in charge of threads, network I/O etc.). But it seems like if I simply want my JAR to be a shared J2EE library, these restrictions for beans do not apply.
Finally, should my library be following the list of best practices for shared J2EE libraries, even if it is not a J2EE library, so that client web applications which refer to my library can follow best practices? Eg. Should my library be publishing both the "specification version" and "implementation version" and adhere to their semantics, or is this not our concern once we state we are not a shared J2EE library.
I think you're a bit confusing about java library and J2EE library.
Each JAR can be a java library. There are a lot of examples: Spring, apache-commons, junit, etc...
All that you need to do in order to use a JAR as a library in your application is include it in your classpath.
Those JARs can perform all the standar task provided by java API: Sockets, NIO, files, concurrency, etc...
You can configure your server to load this kind of libraries (just a normal JAR) into your applications. In this case, the server will include all the content of the JAR in your classpath automatically, but it does not resolve any J2EE annotation from it (#EJB, #Inject, etc...)
On the other hand, a J2EE shared library can contains J2EE objects. That's, it can contain EJBs, Servlets, and so on.
I am working in a University project which involves developing a Java-based JSF WebApp. For the development I will be using IntelliJ IDEA and Maven or Gradle (at this point I don't care which one, any of them will fit).
I will also be using JavaScript in the project and I would like to manage its dependencies with Bower.
I could easily throw a js folder inside the webapp directory. I have seen many examples of this, but I do not like it as an approach.
What I want to do is separate the server side implementation from the UI implementation. So, I guess that means having two modules in IntelliJ IDEA, one containing all the Java-based server implementation and another one containing the static web files.
How can I accomplish this using IntelliJ IDEA and/or WebStorm if necessary? Actually, can it be done? Any suggestions welcome/appreciated.
I have developed a web application which I am going to sell, but I face some security issues because I am going to provide a .war file to client machines and I found .war files can be easily extracted.
How can one provide security for war files to avoid being copied or extracted?
While searching I found Excelsior jet which converts web apps to native code but it's a trial version and I cannot afford its price so I want to know other alternatives.
A web app container cannot deploy an exe anyway. You can obfuscate your classes and maybe write a licensing module. If you prevent users from extracting your war you'll also prevent the container from deployment.
For example, you might use a Java Bytecode Obfuscater such as
yGuard
ProGuard
JODE
As for a licensing module, you may be able to use
this or this question.
The possible way is to
Use code obfuscator
Code in init() or somewhere check for license/access only one host.
Another option is to code your own classloader and implement it in modified web container
I have a Java application (a quite large one with many external .jar dependencies as well as dependencies on images) and I need to package it up so that someone can double click to run, for example. Or something easy like that.
It uses Java Persistence, so it requires a sql connection which is specified in the Persistence.xml file in the Java Project.
How can I package this up? I was thinking:
the installation process should validate that the user has MySQL installed and if not, direct them to install it
the installation process could ask the user to enter credentials for any database and then I could update the Persistence.xml at run time
These were two ideas I had...but I wasn't sure if there was a known solution to this problem. Any help would be much appreciated!
I think you should take a look at embedded database solutions, like H2. Also, you can package your application using maven's shadowing or jar plugin, having the jar-with-dependencies profile activated.
This will nicely rid you of checking for database servers running on the client machine, and also will give you the proper means of bundling the application in one nice JAR, albeit a little large.
Maven is a build ecosystem and toolset especially designed for building Java applications and executing the code -- and generally doing whatever else you can imagine that's possible to do with and to your code.
It has a rich API for developing plugins and many developers have exploited this feature. There are numerous plugins for building -- and launching -- and packaging your application as well as helping you manage your applications dependencies.
Maven's shadowing comes in the form of maven-shade-plugin, available here. What it does is that it helps you create a single JAR file from all your dependencies. Also, there is the maven-jar-plugin which offers a profile jar-with-dependencies. It is also accessible from here.
H2, on the other hand is a full-fledged RDBMS. This is the website: http://www.h2database.com/html/main.html, and here is a tutorial.
You can find information on embedding the database here:
How to embed H2 database into jar file delivered to the client?
Embedding the Java h2 database programmatically
h2 (embedded mode ) database files problem
I would also suggest you use a combination of H2/Hibernate/Spring which is a very easy setup and provides you with really rich features and an easy-to-use API.
I hope this helps you :)
Building a sophisticated installer that checks lots of dependencies, and runs on lots of different platforms (which I assume you want) is complicated.
I suggest that you look at an installer generator; see What is the best installation tool for java?
Another alternative that I've seen in a few products is to write a (non-GUI) installer or configurer in a scripting language like Perl.
I wrote an installer using ANT, but has no GUI. Also, I used Iz Pack (good option), so I think that depends on how smart do you want it to be, if you are supposed to use it, or a non-technical person, etc.
Are there ready solutions (gems, plugins, libraries, etc) for integration ruby (rails) applications and jbilling?
I didn't find even api client for ruby.
I need someone to share his experience with integration. Jbilling has web-service (SOAP ,Java RMI, Burlap) but there is no specific gem for easy accessing and editing data via API.
JRuby 1.6.0 was Released yesterday.
Lines from jbilling manual "All of the API classes are located in the jbilling_api.jar file located in your jBilling
distribution.
The API also makes use of several third-party libraries, such as the Log4j library and
Commons Logging, which provides a powerful logging infrastructure; Spring, which
handles configuration and remoting; CXF, a SOAP library; and Hessian, for
Hessian/Burlap support. You'll therefore need to provide the log4j.jar, commons-
logging.jar and spring.jar files in your class path, if your project does not already
include them.
"
Is that good practice to include so many jars in jruby rails application ?
You can try making your app run on JRuby and using the Java libraries directly. We did an experimental branch of our own app for a similar reason and found some useful projects in the process:
https://github.com/nicksieger/warbler/
https://github.com/calavera/trinidad
In the end we didn't go for JRuby, for various reasons that weren't necessarily of a technical nature.
What version of jB are you using? You could use this project as an example to do your integration.
You can also build such a project from scratch using wsdl2 java utility. Typically, you can access jBilling wsdl at localhost:8080/jbilling/services/jbilling?wsdl assuming jb is running on your local at port 8080.