In my WAS, there are two EARs. The first EAR looks up an ejb that is packaged in the second ear. My question is, since the two EARs are in the same WAS, do we still need to supply the property java.naming.provider.url as 'iiop://localhost:9810' or will the server locate the EJB automatically?
You don't need to.
If you don't specify it will look at the local Naming Server where both the EARs are running.
HTH
Manglu
Related
I am building application in javafx using Derby embedded DB. Do I need to create two separate builds in order to run it as client server ?
The primary differences are:
different syntax for the JDBC Connection URL, and
different Derby jars in the CLASSPATH.
It is possible to include both sets of Derby jars in the CLASSPATH, meaning that the only thing your application must vary at runtime in the JDBC Connection URL.
derbyclient.jar is significantly smaller than derby.jar, however, so if executable package size is crucial to you, you might find it worth the effort to have two different modes of packaging.
I'm looking to implement failover (master/slave) for Karaf. Our current
server setup has two application servers that have a shared SAN disk where
our current Java applications are installed in a single location and can
be started on either machine or both machines at the same time.
I was looking to implement Karaf master/slave failover in a similar way
(one install being shared by both app servers), however I'm not sure that
this is really a well beaten path and would appreciate some advice on
whether the alternatives (mentioned below) are significantly better.
Current idea for failover:
Install Karaf once on the shared SAN and setup basic file locking on this
shared disk.
Both application servers will effectively initiate the Karaf start script,
however only one (the first) will fully start (grabbing the lock) and the
second will remain in standby until it grabs the lock (if the master falls
over)
The main benefit I can see from this is that I only have to manage
deploying components to one Karaf installation and I only need to manage
one Karaf installation.
Alternatives:
We install Karaf in two separate locations on the shared SAN and setup to
lock to the same lock file.
Each application server will have their own Karaf instance, thus start
script to run.
This will make our deployment slightly more complicated (2 Karaf
installations to manage and deploy to).
I'd be interested if anyone can indicate any specific concerns that they
have with the current idea.
Note: I understand that Karaf-cellar can simplify my Karaf instance
management, however we would need to undertake another round of PoCs etc..
to approve our company use of cellar (as a separate product). Something
that I'd like to migrate to in the future.
Take a look at the documentation
This is from the documentation on how to set a lockfile for HA:
karaf.lock=true
karaf.lock.class=org.apache.karaf.main.lock.SimpleFileLock
karaf.lock.dir=<PathToLockFileDirectory>
karaf.lock.delay=10000
as can be seen there, you can also set a level for the bundle start-levels to start or not to start:
karaf.lock.level=50
I have been applying separate web.config files for each environoment as my ASP.NET application progresses through Development, IT, UA and Production and have been looking for a way to simplify this process.
In the past, these had been updated manually; this was tiresome and prone to human error. More recently, I've been using IBM's uDeploy to push the application with an environment-specific config file deployed with the application depending on the target environment.
I've seen many suggestions, such as separate config files (as per my current setup), use of pre-build events etc. However, I implemented a solution to this issue in our test environment whereby I assigned the database connection strings to environment variables on my application server. The relevant environment variable is then passed into my data access connection method.
In other words, each environment's application server has an environment variable with the same name but with a different value assigned. This solution is quite simple and easily implemented and appears to function correctly.
Does anyone else manage separate environment configurations in this way? Are there any disadvantages to this approach that I have failed to consider?
When configuring a data source on WebLogic 11g does anyone know if it's possible for the class specified as the connection pool driver to be deployed as a shared library rather than being installed in wlserver_10.3/server/lib?
The reason for wishing to do this is that we thought it might be more manageable to be able to deploy the driver in a complex production environment.
I've run some tests by deploying the jar file containing the driver with various deployment order values but always get "cannot load driver class" on server startup.
Thanks.
You can use the shared libraries from virtually anywhere keeping this major rule in mind, Weblogic must have permissions to read it.
If that criteria is met, please reference your jar in commEnv.sh "WEBLOGIC_CLASSPATH" and restart the server and you should be good to go. This is handy for shared mounts with common libraries but always always always make sure you can read the file.
A single Biztalk Server can have multiple Host processes. Is it possible to create an application config file for each host process? For example I would like to use Unity or log4net or whatever which needs such a configuration file.
Edit: Thanks at David Hall. To elaborate a bit more:
We have 12 Biztalk Servers in a group each running between 5 and 10 host processes. Some things the host processes run are unique to each process, but they also share a lot of code on the library level. The trigger for my question was the need to configure for example trace levels for the one system part (equivalent to host process) that currently gives trouble.
As an alternative it would help if I could figure out in which host process the current code is running, but I'll post that to a different question.
If I interpret your question correctly, you want to be able to have a separate version of the BTSNTSvs.exe.config file for each host instance?
So as well as the BizTalkServerApplication host instance, you have YourHostInstance host instances that you want to have a separate config for?
I don't 100% know that you cannot do this, but I am almost sure that it is not possible.
The reasons I'm fairly sure this isn't possible are:
The BTSNTSvc.exe.config file attaches to the main executable BTSNTSvc.exe
Config changes placed in BTSNTSvc.exe.config apply to all host instance regardless of their names.
I've just flipped through the BizTalk books I have to hand as well as some of the good web resources and can't find any mention of someone doing what you want.
So as far as I know, you will need to put the config settings for things like log4net into the BTSNTSvc.exe.config file, and have them the same for each host instance.
One way to get close to what you want would be to load application specific settings from the rules engine.