I'm just learning Websphere 8.5 and would like to know what is the simplest way to add a library, such as iText library so that it's available to all applications running on WAS.
I can see that both a Shared Library option is available in the Admin console and a some more advanced thing like "Business Level Application" which is made up of several assets.
What is the correct approach to achieve my goal ?
Thanks
You should not develop your applications with implicit dependencies which are in fact explicit. If the dependency is crucial for your application, it should be somehow marked as such.
With that said, there are two approaches in WebSphere - a shared library or OSGi bundle.
For the shared library concept, read Associating shared libraries with applications or modules.
If you use OSGi to develop your application(s), I'd recommend declare the dependencies in Application-Content of APPLICATION.MF and have them available in Internal or External bundle repositories.
I don't think BLA applies in your scenario, but would not be surprised to see how wrong I am.
p.s. Wonder why the question is tagged as websphere-7 since it refers to WebSphere 8.5?
Related
I sure am not the first person to wonder, yet it is really hard to find information on my question.
At the company I work at, the servers run WebSphere 8.5. In order to cut down installation time and memory usage, we created some shared libraries, where we have copy-pasted the common dependencies of our applications. Now you can see, that these can easily cause big problems when changing versions.
We have a Nexus Repository however, where every dependency our applications use can be reached. Since in our gradle projects, we have those dependencies listed anyway, it only seems logical for WAS to download and put these dependencies on the classpath of the application at startup (or whenever it wants to).
Is there a way to tell WAS where to look for these dependencies (our repo server) and what files to download? Is there a better solution to the problem?
There's no way to do this inside of the server at runtime. The best you can hope for is setting up the shared libraries during your deployment, single-sourced with your applications declared dependencies.
We have a very big web application containing many features.Now for maintainability we want to split the application in components so that can remove / add particular components (jars). For that one suggestion is coming is to use OSGI. I think converting jars into bundle will take huge effort. I think same functionality can be achieved by Maven. According to my understanding OSGI is packaging tool. If I can make Maven plug-in for each component then any particular component can be included or removed at compile as opposed to run time as in case of OSGI.
Modularizing the application using Maven will be simpler than OSGI. I have read similar post on this site and it commented that OSGI and Maven are like comparing apple with orange. But I think in one sense both are same as they both meant for packaging difference is one is used at run time and one for compile time
Looking forward for well though answer :)
best wishes
Shailesh
As you already hinted at yourself: you're comparing apple with orange.
OSGi is not a packaging tool.
OSGi bundles are plain JAR files with some OSGi-specific metadata in the Manifest file.
You can create OSGi bundles using Maven e.g. using the Maven Bundle Plugin (I can recommend this approach). So regardless if you're using OSGi or not I strongly recommend using Maven.
Here some use cases for OSGi:
You want to create different versions of your application e.g. for different customers. With OSGi you can just add/ remove bundles without having to touch any other configuration.
You need a plugin system so 3rd parties can provide plugins to your application
You want your application to be truely modular
You want to share some code with other applications but want to hide some internal classes
...
OSGI is much much more than a packaging tool. You could say that OSGI has a packaging tool inside. Maven is a packaging tool and a dependency manager. I'd say that, given the level of complexity and the use you say you'll make of this technology, go with Maven.
I am investigating possible frameworks for the future web-app I am tasked of building and Play framework 2.3 is pretty much sitting atop the list - however, I haven't used it until now (had used Spring and Maven in another life) and I have a particular requirement on the app itself so I wanted to hear advice/thoughts from people who have used Play so far (the language used will be Java 8).
The web-app consists of modules, some of which are stand-alone units that should be built as a jars (so that they can be accessed from command-line as a part of, say, batch script) as well as being built to function within the full-blown web-app.
Now, I've previously built apps with maven and I could imagine a way to do it with it but Play comes with its own build/dependency management tool (SBT) which I am unfamiliar with and don't know the capabilities of (is this even possible to achieve with SBT? How difficult would it be?).
That being said, I have done some cursory research on the subject and I know there is play2-maven-plugin, however the examples on the homepage deal with Scala (which I, as said above, unfortunately can't use).
What's certain is that I'd definitely like to escape from any "bridging" between SBT and maven - I wouldn't want to maintain two build systems and reconcile the differences between them together, that seems nightmarish.
Lastly, I've found in this SO thread, using maven with Play 2.3 may not even be an option (SBT apparently does somehow use Maven dependencies under the hood). After all, Play was conceived as partial departure from Java EE practices so it doesn't surprise me Maven is not natively supported. Also, Play integration with Maven proved to be troublesome.
I have no objection towards learning SBT or using just maven (if that's possible/advisable) - any of these approaches I am fine with, it's just the capabilities of SBT I am unfamiliar with (especially considering the requirement from above). Mixing SBT and maven seems frankly a bit scary and documentation on building Play with SBT seems scarce at this point.
Should I go with SBT or maven? What tutorials/docs would you recommend? Should I use Activator for getting to know SBT?
NOTE I was almost to flag the question as unclear what you're asking, but at the very end of it found the real questions I'm going to answer here.
Should I go with SBT or maven?
SBT or even better Typesafe Activator. Install it on your computer, and execute activator new myNewCoolPlayJava8App play-java to get started with Play and Java.
Apache Maven might be a viable option, but don't think it's going to be a time-saver (you'll be spending quite some time to get the configuration working).
What tutorials/docs would you recommend?
The official web site of Play Framework is enough to get started with the stack (and don't get stuck) - https://www.playframework.com/documentation. I very often use it and found it very informative. When I need a bit more in-depth information I use Google or StackOverflow (under playframework).
Should I use Activator for getting to know SBT?
No. SBT can live without Activator, but no vice versa. SBT's the foundation for Activator. See https://www.playframework.com/documentation/2.3.x/Build:
The Play build system uses sbt, a high-performance integrated build
for Scala and Java projects. Using sbt as our build tool brings
certain requirements to play which are explained on this page.
And from the Activator's docs (just at the very bottom of the page):
Activator applications use sbt under the covers. This means that
anything you can do in sbt you can do with an application in
Activator. For instance, sbt plugins can easily be added to
applications in Activator just like they would normally be added.
What is the difference between spring source dm server specific Import-Bundle and OSGi's Require-Bundle?
I am confused whether to use Import-Bundle or Require-Bundle in my project.
Import-Bundle is similar to Require-Bundle, it creates a complete dependency on the other bundle, including that bundle's dependencies. This transitivity is bad because you have no idea what you depend, creating the infamous "big ball of mud" problem we're so familiar with in Object oriented programming.
In OO, we've found a solution to this entanglement by using interfaces, they separate implementation from specification. OSGi is built around a similar albeit of an higher order concept of service contracts. These contracts (interfaces, permissions, helper classes) are stored in a package. In contract based programming you depend on the contracts, not the implementations. Ergo, an OSGi bundle should depend on packages since they represent the contracts.
Import-Package <=> interface
Import-Bundle/Require-Bundle <=> implementation class
Import-Bundle is NOT OSGi, it is a proprietary Spring extension. It is a cleaner form for Require-Bundle; the uncleanliness was necessary to support some Eclipse use cases. The OSGi decided not to adopt this header since the Require-Bundle/Import-Bundle is fundamentally broken if you want to build systems from components.
Ideally you should try to rather use Import-Package instead. It makes you bundles less dependent on each other. It also allows to show that you only depend on a part of a bundle. This is also important for managing versions. In OSGi you can define the versions of exported packages independent of the bundle version. So you can make sure you only change versions of an API if it really changes. This can make your app much more manageable.
It's explained here at SpringSource
So summarizing: Import-Bundle will import all exported packages of a certain bundle, it will resolve that when deploying, while Require-Bundle really requires a bundle with that type, and that relationship stays that way during runtime.
Normally they would behave pretty much the same. For example it can be different when:
You have 'split packages': packages that exist in multiple bundles, you might 'lose' dependencies with Import-Package / Import-Bundle that you can only express with Require-Bundle (Note that you really should avoid split packages if you can)
I think the Bundle->Package resolution is when you deploy that bundle. If you redeploy the bundle with the exported bundles to a version with different export, I don't think the bundle will notice. To be honest I'm not exactly sure about this one.
All in all, I'd say stick with the OSGi standard: Import-Package or Require-Bundle if you really need it. You'll have a bit more headers but you'll so many more options in the long run.
How can i control access to my bundles. I have a set of bundles that expose packages through export in MANIFEST.MF. Packages exposed are supposed to be used only within my set of bundles. No other external bundles should be allowed to use these packages using "import package".
Is there any way i can impose these restrictions?
You can take a look at OSGi Security (2.Security Layer OSGi Core Spec) to manage restrictions to various resources (bundles, packages, services etc.).
In your case you can set PackagePermission with IMPORT/EXPORT actions to your bundles. The other bundles will not have any permissions to import your packages.
First, is it a problem that someone else imports your package? Unless you're exporting implementations that no one should see (in which case you should reconsider your partitioning anyway), there is usually no problem in having some packages lying around that others may or may not import.
If you're sure you need to hide certain packages, there are no easy ways to do so. Some things that come to mind are
use a ResolverHook to restrict the visibility of your packages (only available from 4.3),
run your bundles in an embedded framework, and only expose the packages you want to share from that framework to the host.
However, both of these are pretty heavy-handed methods, and I would stay away from them unless you're e.g. building your own application server.