HttpModule Deployment aka HttpModule Installer - deployment

I have been working on a project which partially consists of a HttpModule. I would like to make setup of this HttpModule as simple as possible for admins. Thus, I am seeking any opinion or suggestion of technology/method as to the easiest method of deployment for this HttpModule.
If viewing the code is helpful, it can be found here: http://code.google.com/p/opendms-dot-net/source/browse/#svn%2Ftrunk%2FHttpModule

If your module is supposed to integrate with an existing web application, the simplest thing would probably be to just distribute the assembly and an example web.config, in a zip file. If your project is supposed to be installed as a stand-alone web application, you could create a "Web Setup Project".

Related

Project on Google go, imports of libraries

everyone.
I am new to Go language and currently I am trying to understand the basics of building Go applications. I met the following problem.
For example, I am using other libraries in my project. I have them locally, on my computer, so my project works fine.
I am loading my code on github and another programmer download it. As I understand, my code won't work, because this programmer doesn't have the libraries I used.
So the question is: What is the best way to share my project with all libraries it has? Should I upload these libraries in the separate repositories? Then to use my project, people need to look inside the code to detect which libraries I am using to download them one by one?
For example, in Java there is such thing like Maven or Ant, which downloads all required dependencies. Is there any tools like this for Go?
Let's call the main file of my project main.go
And I am using my own library: mathutil.go
what is the best way to make this project run on other computers?
Go's dependencies work very much like using Maven or IVY transitive dependencies. When someone does "go get" of your package, anything you depend on will automatically download.
For example, in your source:
import "github.com/foo/bar"
go will automatically download that to your $GOPATH/src/github.com/foo/bar along with your code.
Assuming the third party libs you use are hosted in a public repo (ie: github) then people don't need to do anything.
If the libraries you used are not available on a public repo, you will need to post them somewhere assuming their licensing allows.
Take a look at golang.org/doc/code.html for more details

Verify OSGi bundles dependencies (import-package) programmatically

I need to validate whether the imported packages of a bundle are fulfilled by a set of other bundles' export packages. This should not be very hard to implement but I know all the OSGi containers plus eclipse (when you do "validate bundles" in PDE) do this. I just don't know how to find that code. Does anyone know what classes/libraries I could use that already implement all this logic?
My goal is to give a list of files (bundles) in the file system and do an analysis whether the set of bundles is self-contained and if not to show all the missing external imports/requires. all this without actually having to run the bundles in a real container
You should look at the Resolver API in the OSGi spec. Apache Felix has a resolver implementation that is also used by the Equinox framework.

Integrating SproutCore front end in a Grails app

I'm evaluating SproutCore for possible use as a front end with an existing Grails application. How do people typically structure their SproutCore and Grails projects for this type of setup?
The SproutCore docs cover how to connect to a Grails back-end in the ToDos tutorial, but I haven't yet seen a tutorial for how to integrate the two to build a single war file.
We would prefer to have everything bundled up by the 'grails war' task so that we can continue to simply deploy a single war file to deploy the entire application (including the SproutCore front end). So calling the sc-build command on the SC project during the 'war' step in the Grails project seems like a reasonable first step. But where in the grails web-app to place the generated SC stuff, etc.? Would love to hear how people are doing this so as to not reinvent the wheel.
I tend to think of RIAs as a separate project from any back-end they use. With SC in particular this is true, as SC is a full application stack for use in the browser. So my advice is the treat the SC client as a separate project.
As you have indicated in your question, the problem becomes how to deploy the SC project with your war. Fortunately the answer is not too bad. Check out the last section of
http://grails.org/doc/latest/guide/17.%20Deployment.html
You will see that you can hook into the grails build process easily. In there all you need to do is invoke the sc-build command and copy the files into where js files go in a war. Just make sure the paths in the gsps that bootstrap the client are correct. SC generates a default index.html, you can probably just use that (copy it to the appropriate place) when you hook into the grails deployment process.

how can i use a shared lib in glassfish to avoid deployment of the huge libs?

I have to upload about 30M for my app since it uses a lot of libraries, log, web engine and so on.
I think there should be a way to share these libs on glassfish, but I failed to figure it out. I tried to put them in domain/lib/ext but does not work.
So where should I store these libs and how should I refer to them? thank you.
Why domaindir/lib/ext does not work?
from glassfish manual:
Optional packages are packages of Java classes and associated native code that application
developers can use to extend the functionality of the core platform.
To use the Java optional package mechanism, copy the JAR files into the domain-dir/lib/ext
directory, then restart the server.
Why domaindir/lib work?
To use the Common class loader, copy the JAR files into the domain-dir/lib or as-install/lib
directory or copy the .class files (and other needed files, such as .properties files) into the
domain-dir/lib/classes directory, then restart the server.
Using the Common class loader makes an application or module accessible to all applications
or modules deployed on servers that share the same configuration.However, this accessibility
does not extend to application clients.
If I remember well, you can also specify additional libraries in the classpath via the admin console (in Application Server > JVM settings or something like this). Then you can put them wherever you want.
(I had a quick look at Pascal's link, but I don't know if that's what they describe, if yes, my apologies for the duplicate answer.)
One option would be to put them in domains/domain1/lib. But actually, I suggest to read GlassFish equivalent to WebSphere's "shared libraries", including the comments.

Best practice for handling environment specific settings for a Java web app?

I have a Java web app that offloads some environment specific settings (Hibernate configurations, required directory paths, etc.) in a properties file that is ultimately packaged in the deployed WAR. If I wish to distribute this web app, what's the best way to handle the mangement of these settings? It's not feasible to ask the user to open up the WAR, update the properties file, repackage the WAR, and then deploy. I was thinking of either creating an installer (e.g. NSIS, WiX) that asks for the properties, writes them in the WAR, and then asks for the deployment location for the WAR. The other option is to have the properties file external to the WAR, and based on convention the web app will know where to read the file. What's the best practice in this case?
Some projects that require this sort of configuration, and face this issue, use the approach of building the projects (and the .war) on the server where it will be deployed.
So instead of:
Copy a pre-packaged .war file to a meaningful location
You get:
Check source code out of SCM (Subversion, CVS, etc.)
Configure to taste
Build the project (automated with Maven or Ant)
Deploy the project (also typically automated using Maven or Ant)
From here you can get fancy by checking each server's configuration files into SCM as well. This approach allows you to version & audit configuration changes.
I was also facing the same problem in the project. The developer before me had done crude fix for the solution which was adding all the required configuration in the hibernate.hbm.cfg.xml file and commenting them. The required configurations were uncommented as per the need. There is a better solution to problem however.
Use a configuration folder schema
Using configuration Parameter Reader
Use of ConfigurationReader component
Source : http://www.javaworld.com/javaworld/jw-11-2004/jw-1108-config.html