how to configure the external properfiles into the OSGI - fuseesb

we are using the Jboss fuse 6.2 along with technical stack blueprint,camel ,activeMQ and Mybatis.
We need to know about how to configure the property files in OSGI ,
as per my knowledge we could configure .cfg files, but is there any simplest way to use like spring configuring the configuring.
In Our code we are reading from property files . using namespace ext:proeprtyplaceHolder giving that bean id and values we are giving .
Help to provide is there any simplest way to read the property files

There is several ways to add configuration, because OSGi services can access configuration via ConfigurationAdmin service. The blueprint also can access property values over it.
JBoss fuse using karaf, so you can use the following methods.
(There is some quotes from http://www.liquid-reality.de/display/liquid/2011/09/23/Karaf+Tutorial+Part+2+-+Using+the+Configuration+Admin+Service)
Configuration with Blueprint
The integration with our bean class is mostly a simple bean definition where we define the title property and assign the placeholder which will be resolved using the config admin service. The only special thing is the init-method. This is used to give us the chance to react after all changes were made like in the pure OSGi example.
For blueprint we do not need any maven dependencies as our Java Code is a pure Java bean. The blueprint context is simply activated by putting it in the OSGI-INF/blueprint directory and by having the blueprint extender loaded. As blueprint is always loaded in Karaf we do not need anything else.
<cm:property-placeholder persistent-id="ConfigApp" update-strategy="reload" >
<cm:default-properties>
<cm:property name="title" value="Default Title"/>
</cm:default-properties>
</cm:property-placeholder>
<bean id="myApp" init-method="refresh">
<property name="title" value="${title}"></property>
</bean>
After you can put a cfg file (which is a standard java property file) to
karaf's etc or deploy directory with the name of of the given persistent-id which is MyApp in our example. (For example: /etc/ConfigApp.cfg)
title=Configured title

Related

MobileFirst 8 javascript adapters and messages

i have some questions about MobileFirst Adapters:
We are implementing javascript adapters on a MobileFirst 8 server.
Where is the best place to write javascript utils functions?
I also have some utils on java classes (called from javascript adapters) and i need to use the ConfigurationAPI class to get properties. The problem is that the configurationAPI variable (instantiated with the #Context annotation) is always null. Why? How can i get properties values from Java code?
I have a lot of properties (for example low-level backend endpoints) that should be shared between all the adapters. At the moment i used the <property name="" displayName="" defaultValue="" /> syntax, should i copy and paste them in all adapters?! Or where should i put them?
Thank you
We are implementing javascript adapters on a MobileFirst 8 server.
Where is the best place to write javascript utils functions?
JavaScript adapters allow for a single .js file, so your best place for any adapters JavaScript code is the same .js file...
I have a lot of properties (for example low-level backend endpoints)
that should be shared between all the adapters. At the moment i used
the <property name="" displayName="" defaultValue="" /> syntax, should
i copy and paste them in all adapters?! Or where should i put them?
See my answer to the following question. Once you add custom properties you should be able to handle them in the same way I mention handling other values from the adapter.xml file: Unable to build adapters using profiles and properties in Maven
I also have some utils on java classes (called from javascript
adapters) and i need to use the ConfigurationAPI class to get
properties. The problem is that the configurationAPI variable
(instantiated with the #Context annotation) is always null. Why? How
can i get properties values from Java code?
I've sent a question internally and will let you know once I get an answer.

Multiple gemfire cache-server on same host machine

Hi i want to start more than one gemfire cache-server on same host using Spring gemfire 8.1.Please find below gemfire configuration file. I want to start GFServer1 and GFServer2 on same host i.e.HOSTNAME using Spring Gemfire configuration. I want to avoid gfsh command and start everything from eclipse and connect client to these servers on the same host.
Thanks in advance
<util:properties id="gemfireProperties">
<prop key="name">Locator_Dev</prop>
<prop key="mcast-port">0</prop>
<prop key="locators">HOSTNAME[1099]</prop>
<prop key="log-level">warning</prop>
<prop key="http-service-port">8181</prop>
<prop key="jmx-manager">true</prop>
<prop key="jmx-manager-port">1199</prop>
<prop key="jmx-manager-start">true</prop>
<prop key="start-locator">HOSTNAME[1099]</prop>
</util:properties>
<gfe:cache properties-ref="gemfireProperties" />
<gfe:cache-server id="GFServer1" auto-startup="true"
bind-address="HOSTNAME" port="40411" host-name-for-clients="HOSTNAME"
load-poll-interval="2000" max-connections="22" max-threads="16"
max-message-count="1000" max-time-between-pings="30000" >
<gfe:subscription-config eviction-type="ENTRY"
capacity="1000" disk-store="diskStore1" />
</gfe:cache-server>
<gfe:cache-server id="GFServer2" auto-startup="true"
bind-address="HOSTNAME" port="40412" host-name-for-clients="HOSTNAME"
load-poll-interval="2000" max-connections="22" max-threads="16"
max-message-count="1000" max-time-between-pings="30000" >
<gfe:subscription-config eviction-type="ENTRY"
capacity="1000" disk-store="diskStore1" />
</gfe:cache-server>
<gfe:disk-store id="diskStore1" queue-size="50"
auto-compact="true" max-oplog-size="10" time-interval="9999">
<gfe:disk-dir
location="D:\NP\WorkSpace\GemfireRegionSolutionNStart\disk-store\store_1"
max-size="20" />
<gfe:disk-dir
location="D:\NP\WorkSpace\GemfireRegionSolutionNStart\disk-store\store_2"
max-size="20" />
</gfe:disk-store>
<gfe:replicated-region id="customer" name="Customer">
</gfe:replicated-region>
<gfe:replicated-region id="bookMaster" name="BookMaster">
</gfe:replicated-region>
</beans>
The configuration you have posted will create two cache-servers within the same JVM, i.e it will open up two ports within the same process.
If this is not what you want, i.e you want two distinct process, in eclipse you will have to provide two runtime configurations to start the two servers.
Is there a specific question? As #Swapnil points out, this will start 2 GemFire "Cache Servers" (ServerSockets listening for Cache Clients) as you have appropriately configured on the same host within the same JVM. This will work regardless of how this is executed (i.e. IDE, command-line, from Gfsh or from Spring Boot).
Let us know if you have a more specific question, thanks!
So you can configure the LocatorLauncherFactoryBean, for example, like so...
<uti:properties id="gemfireProperties">
<prop key="log-level">config</prop>
<prop key="http-service-port">8181</prop>
<prop key="jmx-manager">true</prop>
<prop key="jmx-manager-port">1199</prop>
<prop key="jmx-manager-start">true</prop>
<prop key="locators">host1[10334],host2[11235],...,hostN[20668]</prop>
</util:properties>
<bean id="locator" class="org.spring.data.gemfire.config.LocatorLauncherFactoryBean">
<property name="gemfireProperties" ref="gemfireProperties"/>
<property name="memberName" value="SpringDataGemFireLocator"/>
<property name="bindAddress" value="10.124.12.24"/>
<property name="port" value="12480"/>
</bean>
As you may have noticed, this Locator can join other Locators in the GemFire Cluster, which were specified in the "gemfireProperties" bean with the "locators" GemFire System property.
NOTE: the "bindAddress" property to the LocatorLauncherFactoryBean is only necessary if the localhost where this Locator will be running has multiple NICs and you want to bind to a specific NIC.
Also, I have set the JMX Manager GemFire System properties to enable the Locator to become and actually start a Manager (on port 1199). This allows you to connect to this Locator from Gfsh either with gfsh>connect --locator=localhost[12480] or with gfsh>connect --jmx-manager=localhost[1199].
Basically, the "gemfireProperties" bean allows you to configure any valid GemFire System property.
Now, since this Locator is running from within your IDE, you will need to configure the "run profile" with a $GEMFIRE environment variable pointing at a GemFire distribution downloaded from Pivotal's website in order to get Pulse running from this Locator. This is expected by the GemFire Manager's ManagementAgent when making a decision of whether to 1. start the embedded HTTP Service (Jetty) running GemFire's out-of-box webapps (e.g. Pulse) and 2. whether it can find Pulse and start the webapp. The ManagementAgent looks for Pulse in the distro.
For instance, I set my $GEMFIRE environment variable to...
/Users/jblum/Downloads/Pivotal/GemStone/Products/GemFire/Pivotal_GemFire_820_b17919_Linux
Now, to get your individiual Spring-configured GemFire Servers to connect to the cluster, that is simple.
Again, you only need a "gemfireProperties" bean defined in each Spring GemFire Server XML configuration file with the "locators" GemFire System property defined, e.g. ...
<uti:properties id="gemfireProperties">
<prop key="log-level">config</prop>
<prop key="locators">localhost[12480]</prop>
</util:properties>
<gfe:cache properties-ref="gemfireProperties"/>
This configuration will enable the GemFire Data Nodes to connect to the cluster, and this cluster will be visible from Pulse, if everything is setup correctly.
Again, hope this helps.
Cheers,
John
OK... so you have a few options from within your IDE (e.g. Eclipse).
If you break the Spring config above into 2 separate Spring (Data GemFire) XML configuration files, each containing 1 of the <gfe:cache-server> elements, call these files, for example, spring-gemfire-server1-context.xml and spring-gemfire-server2-context.xml, you could run the Spring-based/configure GemFire "data nodes" and Cache Servers with the following...
SimpleSpringApplication
Where the argument to the simple little Java "main" program is the file system path to 1 of the Spring XML configuration files noted above.
Better yet, you can launch these Spring (GemFire) configs with a SpringBoot application using something like...
UsefulSpringBootGemFireApplication
As you can see here, you can use either the #Import annotation if you are configuring GemFire from Spring using Java-based Configuration (for example, UsefulSpringBasedGemFireConfiguration), or in your case, with XML using the
#ImportResoruce("/classpath/to/spring-gemfire-server1-context.xml") annotation.
It maybe possible (not sure) to pass a System property value into the #ImportResource annotation, like so...
#SpringBootApplication
#ImportResource("${spring-gemfire-context-xml-location}")
class SpringBootGemFireApplication {
...
}
Then, from within your IDE, you can create 2 separate "run profiles" using the same SpringBootGemFireApplication class and then setting the System property (e.g. -Dspring-gemfire-context-xml-location=/path/to/spring-gemfire-server1-context.xml) appropriately for each configuration.
Remember, you can use Spring's ResourceLoader path qualifiers (e.g. file:, http:, etc) to resolve your Spring GemFire config from different source locations (CLASSPATH, file system, etc)... see the table ("Table 7.1 Resource strings") in hyperlinked section of the Spring Framework Reference Guide.
In the worst case, you need to create 2 separate, but nearly identical SpringBoot application Java main classes to launch your 2 configuration files for each GemFire Data Node (& CacheServer) JVM process. However, hopefully using the System property approach allows you to recycle the same class in 2 separate run profiles.
So, this leaves you with 2 GemFire Data Node JVM processes now. But, what about he Locator?
Well, you can continue to embed the Locator in the GemFire Data Node Server JVM process as before, but if you really want a standalone Locator JVM process, then you can use the following, "experimental" class...
LocatorLauncherFactoryBean
This class uses GemFire's LocatorLauncher class to configure and bootstrap a GemFire Locator from Spring config. I created this class over 2 years ago for a customer POC as example of how a developer might configure a GemFire Locator from Spring config.
The Spring XML configuration (used by the SpringBootGemFireApplication #ImportResoruce annotation, in yet another "run profile" and System property combination), would look similar to the following...
locator.xml
Now, you have effectively achieved 3 separate GemFire JVM processes (2 Servers and 1 Locator). You can scale this from with our IDE to however many Servers and Locators you want, and Pulse will show all of these in the cluster, providing the cluster is configured correctly (Servers pointed at Locators, etc).
Hope this helps.
Cheers!
John

Dynamically change project stage value at runtime using JNDI

I need to change the value of the project stage dynamically ( at runtime ), based on the environment, using JNDI. From what I understand, the JNDI will override what is defined in web.xml. Is there a document / link that will help me with how I should code it? I am using websphere 8.5
In some examples I have seen that it is defined as resource-ref, but I am not sure I understand how is that used with JNDI to make it work and change the value at runtime.
Can someone help me with this?
As JSF 2.0 spec states, you can override context parameter javax.faces.PROJECT_STAGE via JNDI entry, which is looked via reference java:comp/env/jsf/ProjectStage.
To override the context parameter, you need to define following resource environment reference in your web.xml file:
<resource-env-ref>
<description />
<resource-env-ref-name>jsf/ProjectStage</resource-env-ref-name>
<resource-env-ref-type>java.lang.String</resource-env-ref-type>
</resource-env-ref>
in the application server configuration, you can define your ProjectStage value via Namespace binding ( in the web admin console select Environment > Name Space Bindings, define new String variable with jndi name jsf/ProjectStage and value Development or Production, depending on the environment).
Finally you need to bind your reference in the project with variable in JNDI. You can do it it 2 ways, via ibm-web-bnd.xml file, defining:
<resource-ref name="jsf/ProjectStage" binding-name="jsf/ProjectStage" />
Or during application installation, in the step were you provide mappings for Resource environment references.
For detailed discussion on this topic check Dynamically change project stage value at runtime using JNDI

IBM Worklight - How to use adapter domain and port properties taken from external file?

I have a web service. Its domain and port can be changed. So I want to read port and domain from file or db. When this information change, I update them in db or file.
Adapter XML:
<domain>${adp.hostname}</domain>
<port>${adp.port}</port>
worklight.properties:
adp.hostname=localhost
adp.port=10080
This is working fine. But I'd like to take adp.hostname and adp.port from file or db.
Something to remember about adapters is that you cannot change in real-time any of the properties set in the adapter XML once it is deployed.
Once the adapter is deployed, it is transformed into an object and is stored in memory. At this time, then, you can no longer interact with its "setup".
The only thing you can do, is to decide what will be the value of these properties before your deploy the adapter. For example, a different set of properties for QA/TEST/UAT/PROD environments...
To setup external properties, starting Worklight 6.0 and above, you can read this documentation topic: Configuring an IBM Worklight project in production by using JNDI environment entries
Specifically for Tomcat in its server.xml:
<Context docBase="app_context_path" path="/app_context_path">
<Environment name="publicWorkLightPort" override="false"
type="java.lang.String" value="9080"/>
</Context>
You change app_context_path to your project's context (project name)
You add environment child elements for each property you need
Important to remember: these properties must also exist in worklight.properties; those will be the default properties, and if using the above example they will be over-written and the environment properties will be used instead.
In the example above you can see that it will replace the default property publicWorkLightPort.

OSGI CXF singleton classloading issues

This question is now up for Bounty! First answer that solves this problem wins.
So I've recently discovered that bundles in OSGI are not 100% isolated from each other, especially when your bundles share a common bundle that has a singleton in it, which can result in two unrelated bundles overwritting the singleton. This issue has manifested itself with the CXF libraries. Let me give a detailed example of what is happening:
We have bundle A, B and the shared bundle CXF all in a FuseESB ServiceMix (An osgi platform). CXF's Bus class is a singleton and because of how OSGI has a single classloader per bundle it will share this singleton with every other bundle that uses CXF. So I seem to be unable to create different buses for bundle A and bundle B, which is important that I do because bundle A should be using SSL and bundle B should not be using SSL. This is even more frustrating given that bundle A and bundle B have nothing to do with each other at all other than that they must be deployed together on the same ServiceMix.
Now I've been at this problem for a while now (1-2 months) and I've read up a lot of different solutions. The problem however is that a lot of the solutions require me to have complete control over the source code and in this case I do not. Bundle A that I'm creating is using some proprietary third-party non-osgi library, called Xenara, which uses CXF. For business reasons beyond my control I MUST use this third-party library. Fortunately I do have access to the CXF spring bean file that this library uses.
My guess for solving this problem is that I need to some how make it so that bundle A can use its own personal instance of CXF or at least make it instantiate its CXF Bus that isn't shared with other bundles. Here are the methods I've tried or considered:
I embedded CXF into bundle A but unfortunately the classloader kept fetching CXF from outside of bundle A instead of looking on the classpath. Never figured out how to force it to search for CXF in bundle A first before searching outside of bundle A.
Suggestions were made to make bundle A into a service. I think there were some misunderstandings and people thought that the singleton was in A and not in CXF. Regardless I tried it and it didn't solve the problem. The CXF bus was still shared between bundle A and B.
Override the classloading so that bundle A uses a different classloader for loading the CXF classes. I don't fully understand the logic for this but I'm sure it will be very tricky given that a spring bean is being used to create the CXF bus and http-conduit. See (4) below to get a better idea.
In CXF there is a way to set the CXF bus and http-conduit for a given thread context. I really want to use this solution, but I can't figure out how to translate the CXF bean file into equivalent java code. The CXF spring bean file is provided below. Note I don't have access to the source code using this http-conduit, which is why I haven't used examples show in this link here at "Using Java Code" because I don't have access to the SOAPService, the wsdl, etc...
<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="systemPropertiesModeName" value="SYSTEM_PROPERTIES_MODE_OVERRIDE" />
<property name="searchSystemEnvironment" value="true" />
<property name="ignoreUnresolvablePlaceholders" value="true" />
</bean>
<cxf:bus>
<cxf:outInterceptors>
<bean class="com.xenara.messaging.security.IdentityAssertingOutInterceptor"
scope="singleton" />
</cxf:outInterceptors>
<cxf:features>
<wsa:addressing xmlns:wsa="http://cxf.apache.org/ws/addressing"/>
</cxf:features>
</cxf:bus>
<http-conf:conduit name="*.http-conduit">
<http-conf:client AllowChunking="false" Connection="Keep-Alive" />
<http-conf:tlsClientParameters disableCNCheck="true" secureSocketProtocol="TLS">
<sec:keyManagers keyPassword="${javax.net.ssl.keyStorePassword}">
<sec:keyStore type="JKS" password="${javax.net.ssl.keyStorePassword}"
file="${javax.net.ssl.keyStore}" />
</sec:keyManagers>
<sec:trustManagers>
<sec:keyStore type="JKS" password="${javax.net.ssl.trustStorePassword}" file="${javax.net.ssl.trustStore}" />
</sec:trustManagers>
<sec:cipherSuitesFilter>
<sec:include>SSL_RSA_WITH_3DES_EDE_CBC_SHA</sec:include>
...
</sec:cipherSuitesFilter>
</http-conf:tlsClientParameters>
</http-conf:conduit>
This sounds like the basic premisse of OSGi to me: isolation is provided, but you can do a lot of what you can in regular OSGi; such as, modify static members of a class, and since you all share that class (A presumably exports it, B and C import it), others will notice.
In most situations, I would advise you to not use static class state, since it is bound to mess something up for other bundles.
In your situation, it seems to me that bundle A is a library that has no real use being shared in the framework. I would package the library inside both of the using bundles, if you need real isolation, and not worry about the overhead too much.
For the record: this situation has nothing to do with Servicemix, it's basic Java: if we're talking about the same class, and someone changes a static property, others will notice. If this situation confuses you, you could read up a bit about the class loading and sharing mechanisms in OSGi.
The problem you are facing is fairly essential and basic. You have a static state in a supporting library CXF, while you still want shared instances of the libraries using CXF. You cannot modify the shared libraries (due to the sheer size), nor can you modify CXF (closed-source?). Let's call these shared libraries Foo and Bar.
Suppose you have the following classes:
CXF#1
Foo#1, using CXF#1
Bar#1, using CXF#1
WebApp#1, using Foo#1 and Bar#1
If I understand correctly, you now want another application to use the same instances of Foo and Bar, without using the same underlying library CXF#1. This amounts to the following situation.
CXF#2
CXF#1
Foo#1, using CXF#1 when called by App#1, using CXF#2 when called by App#2
Bar#1, using CXF#1 when called by App#1, using CXF#2 when called by App#2
WebApp#1, using Foo#1 and Bar#1
WebApp#2, using Foo#1 and Bar#1
This is just not possible; not in OSGi and not in any Java framework. An existing class cannot dynamically bind to another class, making the choice based on the calling Bundle. The only way to do this without modifying the libraries, is to duplicate the supporting libraries:
CXF#2
CXF#1
Foo#1, using CXF#1
Bar#1, using CXF#1
Foo#2, using CXF#2
Bar#2, using CXF#2
WebApp#1, using Foo#1 and Bar#1
WebApp#2, using Foo#2 and Bar#2
Indeed, this is a lot of effort and will explode the number of packages on disk and in memory. If the CXF package can only be used by a single application, the most logical solution is to duplicate the package and embed it everywhere you use it. Yes, this includes any and all libraries the package depends on.
A hacky/risky way to resolve this is as follows. You should be able to decompile the CXF class. This will allow you to modify the class as follows:
class CXF {
[...]
public static CXF getInstance() {
// based on the current Stack frame, determine which instance to return. Remember, the instance should be based on the WebApp bundle (while you still have shared libraries in between!)
}
}
This is not foolproof. Suppose your WebApp starts a callback thread originating from library A. This thread calls CXF.getInstance() -> The getInstance() method has no way of determining which WebApp started the callback thread.
The correct solution is to modify all libraries not to use the Singleton pattern. You can probably hack your way around the problem by implementing a special classloader, but this opens a whole other can of worms.
-- EDIT --
After reading up on CXF, it seems very strange that CXF exposes a Singleton class. The thing is made for OSGi! You are probably better off asking the question on the CXF mailing list; they will know all of the special sugar and reasons for making a singleton instance, and probably already thought about this usecase.