I am creating a REST service in glassfish (which uses Jersey as the JAX-RS impl.). I want to deploy my service as an OSGI bundle which works fine, I add the "Web-ContextPath:" in the manifest and then use an annotated #javax.ws.rs.ApplicationPath application object. This all makes the service usable but then, I want to use container based security. I found I can use security contrains in a web.xml and then do the user-to-role mappings in sun-web.xml. That said, a OSGI bundle does not have either.
Is there a set of annotations and or parameters to the manifest where I can specify application roles, security constrains and role-user mappings (I think the latter can just be globally configured)?
Thanks!
Here's how I would try this:
Use a library that would automatically detect OSGi services with specific annotations, and translate them to REST resources. For Jersey, you could try this: https://github.com/hstaudacher/osgi-jax-rs-connector
Use OSGi embedded application server like jetty (or tomcat) which provides the OSGi HTTP Service implementation.
Configure Jetty/Tomcat. This should be easy now as the Jetty/Tomcat bundles can pick up configurations from the configuration area.
It would also save a lot of time to use Karaf which would do all the packaging related work for you, including providing features like embedded Jetty with externalized configurations, etc. But that's totally up to you.
Related
I have a project deployed on websphere 8.5. However, there are certain classes that are creating conflict due to jar version errors in project and the ones provided by websphere default.
Can anyone help to point mechanism to resolve conflict.
I have done something similar in weblogic which provides option in welogic.xml to exclude / include jars from project.
This is the use case for the "isolated shared libraries" feature in the WebSphere server. For any technologies for which you need to bring your own version rather than use the version provided with the server, place the necessary jars into some directory outside the application, create a shared library pointing to that location, select the "use an isolated class loader" option in the library configuration, and associate the library with the application(s) that require it. The application will search the isolated library class loader before delegating to its parent loaders, and classes there will be found instead of server-provided versions.
A few cautions: This should ONLY be used for technologies that you are 100% certain that you need your own version rather than the server's. The "parent last" style of class loading used by isolated shared libraries includes some risk of conflicts between class loaders, and avoiding it (by using APIs provided by the server) is generally the safer option.
Note, too, that not everything can be overridden. The Servlet, EJB, and JPA APIs, for example, will break application startup if included in an isolated shared library, because the server containers require consistent versions of the API classes when processing application objects. Also, you cannot bring an API of any technology without an associated implementation - doing that is usually a recipe for a VerifyError or LinkageError caused by duplicate visibility to multiple versions of the API.
I am doing the following:
porting several legacy applications from WebLogic to JBoss EAP 7. Some of the components being ported are EJBs. Others are servlet apps that invoke these EJBs. These EJBs are deployed in ejb-jars. I know that I could wrap this whole thing into a big EAR file but we don't want to do that. The servlets and the EJB jars need to be separately deployable components.
Then there is the logging setup. We are using log4j2 and we want to keep independent of the JBoss logging setup. I have created a JBoss module that contains all the log4j2 jars with the proper dependencies, and logging works.
The servlet runs and logs, invokes the EJBs and they work.
The only problem is how to configure the EJB's logging. In a Web App like the servlet, it's easy, just specify the log4j logging configuration file in web.xml. What's the analog for an ejb jar? I couldn't think of a way.
I tried the following: Add a logger/appender to the configuration of the servlet app for the EJB package and specify a new file. It doesn't work. The new logfile does get created but nothing gets written to the logfile. There should be output, but there isn't, so evidently when the EJB runs, its LogManager is not using the configuration specified in the servlet.
What is the right way for specifying a log4j2 configuration in an EJB deployed in an EJB jar on JBoss EAP7?
I had previously posted in this space a solution involving use of the #postConstruct and #preDestroy methods to initialize and shut down LoggerContext objects.
This plan fell apart when I tried to extend it to stateless session beans. It worked okay for Stateful Beans. Or so I thought. Eventually I found an Oracle document on EJB Restrictions which exposed the weaknesses in what I was doing. My "solution" included a non-final static LoggerContext member of the EJB class. I found a way to make it final, which did allow the stateless case to work. But I was increasingly dissatisfied with my approach. Even in the stateful case, I found issues that might bite me later in a clustered environment.
What I now come to believe is that I should not do what I was trying to do.
I can't even imagine the complexity of what a static final LoggerContext would look like if an EJB were distributed to another machine in the cluster. Objects like LoggerContext don't belong as members, static or not, of container-managed objects like EJBs.
It's not even clear that EJBs are the right implementation technology for what I am trying to build. My use cases are not really transactional so the case for EJB implementation is not strong so one possible path leads away from EJBs altogether.
The real message is that if EJBs or other container-managed components are indicated, it's probably best to use the container-provided logging system. I like log4j2, but until JBoss supports it, it's best to stick with container-provided log4j1 or some other framework.
I am working one POC where I want to create plugin based web application. Main application will have all the spring mvc context. Plugins can write spring controllers but they cannot have their own spring context file. What I want is when plugin is installed all its controller is scanned (plugins controller need to be in specific package so for that package component scan will be defined in parent context) and ready to use. I am able achieve the installation part however when I am trying to access bundle/plugin controller end point through rest call I get no mapping found error.
Has anyone tried something like this? It will be great if I can get reference to some example.
Thanks!!!
If you remove the spring part, I've already done this with
a) Apache Wicket and Pax Wicket
b) Vaadin
For a) you might want to look at the Apache Karaf WebConsole.
For b) take a look at this rather "old" showcase of mine.
Both of those showcases use either standard OSGi services or Blueprint for the services (http-services) and the discovery of new "web-components" or views.
I am new to CQ5. I created a bundle that is configurable via the OSGi console. Now, I need the value that is configured on the console to be returned to my content page. I am not sure how to proceed with this. Looking for any tutorial or help. Thanks in advance.
Assuming the configured value is available via an OSGi service, you can access that service from java code using an #Reference SCR annotation with a suitable build setup to generate the corresponding OSGi metadata. You can also access OSGi services from scripts, in JSP that's done using sling.getService(YourService.class) in a script where you have called or its CQ equivalent.
I'm developing a web application (ASP.NET 3.5) that will consume a number of web services. I have created a separate dll-project for each web service: these projects contains the service reference and client code.
However, the calling website MUST have the <system.serviceModel> information (the <bindings> and <client> nodes) in it's web.config, even though this information is also in the dll's app.config file! I have tried copying the serviceclass.dll.config over to the bin directory of the website, but this didn't help.
Is there any way to centralize the configuration of a WCF client?
I've only limited WCF experience, all with BasicHTTP bindings. But I'm allergic to WCF's xml files and have managed to avoid them thus far. I don't recomend this generally but I put the configuration details in my apps existing configuration store and then apply them programatically. E.g. With a Web service proxy I use the constructor for the Client that takes 'bindings'and 'endpoint' and programatically apply the settings to the bindings & endpoint.
A more elegent solution appears to be descibed here: Reading WCF Configuration from a Custom Location, but I haven't tried it yet.
From my experience, library projects never read app.config.
So you can really delete the file because it is not used. The library's host configuration is read instead, so that is the only place the endpoint and binding configuration should be.
It's possible to forgo xml config and build up the Binding and Endpoint classes associated with the service in the constructor or a custom "Service Factory". iDesign has some good information on this:
http://www.idesign.net/idesign/DesktopDefault.aspx?tabindex=5&tabid=11
(See In Proc Factory)
In their approach, you set attributes on your services to specify at a high level how they should work (ie [Internet], [Intranet], [BusinessToBusiness]), and the service factory configures the service according to best practices for each scenario. Their book describes building this sort of service:
http://www.amazon.com/Programming-WCF-Services-Juval-Lowy/dp/0596526997
If you just want to share configuration XML config, maybe use the configSource attribute to specify a path for configuration: http://weblogs.asp.net/cibrax/archive/2007/07/24/configsource-attribute-on-system-servicemodel-section.aspx
Remember that a configuration file is is read by an executable that has an entry point. A library dll does not have an entry point so it is not the assembly that will read it. The executing assembly must have a configuration file to read.
If you would like to centralize your web configs then I would suggest you look into nesting them in IIS with virtual directories. This will allow you to use the configuration inheritance to centralize whatever you need.
There are 2 options.
Option 1. Working with channels.
If you are working with channels directly, .NET 4.0 and .NET 4.5 has the ConfigurationChannelFactory. The example on MSDN looks like this:
ExeConfigurationFileMap fileMap = new ExeConfigurationFileMap();
fileMap.ExeConfigFilename = "Test.config";
Configuration newConfiguration = ConfigurationManager.OpenMappedExeConfiguration(
fileMap,
ConfigurationUserLevel.None);
ConfigurationChannelFactory<ICalculatorChannel> factory1 =
new ConfigurationChannelFactory<ICalculatorChannel>(
"endpoint1",
newConfiguration,
new EndpointAddress("http://localhost:8000/servicemodelsamples/service"));
ICalculatorChannel client1 = factory1.CreateChannel();
As pointed out by Langdon, you can use the endpoint address from the configuration file by simply passing in null, like this:
var factory1 = new ConfigurationChannelFactory<ICalculatorChannel>(
"endpoint1",
newConfiguration,
null);
ICalculatorChannel client1 = factory1.CreateChannel();
This is discussed in the MSDN documentation.
Option 2. Working with proxies.
If you're working with code-generated proxies, you can read the config file and load a ServiceModelSectionGroup. There is a bit more work involved than simply using the ConfigurationChannelFactory but at least you can continue using the generated proxy (that under the hood uses a ChannelFactory and manages the IChannelFactory for you.
Pablo Cibraro shows a nice example of this here: Getting WCF Bindings and Behaviors from any config source
First of all class libraries (DLLs) do not have their own configuration, however they can read the configuration of their host (Web/Executable etc.). That being said, I still maintain an app.config file on the library projects as a template and easy reference.
As far as the service configuration itself is concerned, WCF configuration can make somebody easily pull their hair out. It is an over-engineered over-complicated piece. The goal of your applications should be to depend least on the configuration, while maintaining flexibility of deployment scenarios your product is going to come across.