I am trying to get a list of the queue names and jndi names in java. I have tried using pcf and have only been able to get queue names. The documentation on the IBM sight has not been too helpful.
MQ Java PCF classes can be used to do a number of tasks like inquiring list of queues, channels etc. Also Add/Update/Delete number of queue manager objects can be done. But PCF classes can not be used inquiring JNDI names. JNDI names must be retrieved from a JNDI store like File/LDAP/J2EE JNDI and not in MQ queue manager.
HTH
Since your inquiry was tagged WebSphere, I'll assume some version of WebSphere Application Server (WAS). WAS includes a utility called dumpnamespace. Run it with the -h option to list its options. Aim it at your bootstrap port and it should do as its name implies.
Related
I have a number of demo environments that I would like to setup for different groups of customers. These would contain the same deployment apps (WAR's) but requiring different configurations. currently I'm using:
3 datasources (accessed by JNDI) per application (so each environment would need different databases)
some Naming/JNDI simple bindings which would need to be different by environment.
one activeMQ queue for environment, also identified via JNDI.
Would it be possible, on Wildfly 11, to configure the Naming, Datasources and ActiveMQ subsystems on a non-global manner ? Maybe by either configuring the subsystems on a server, host or deployment level? I don't mind having multiple Server or Hosts definitions with different network ports (8080, 8081, etc...)
I know that I can setup multiple instances of standalone running on the same machine, each with a different configuration file, but I would realy like to use the same Wildfly instance to manage this scenario. Is this at all possible ?
Thank you,
You should be using domain mode where you can manage several servers and assign to them different configuration profile https://docs.jboss.org/author/display/WFLY/Domain+Setup
I am implementing a service broker for my SaaS application on Cloud Foundry.
On create-service of my SaaS application, I create instance of another service (Say service-A) also ie. a new service instance of another service (service-A) is also created for every tenant which on-boards my application.
The details of the newly created service instance (service-A) is passed to my service-broker via environment variable.
To be able to process this newly injected environment variable, the service-broker need to be restaged/restarted.
This means a down-time for the service-broker for every new on-boarding customer.
I have following questions:
1) How these kind on use-cases are handled in Cloud Foundry?
2) Why Cloud Foundry chose to use environment variables to pass the info required to use a service? It seems limiting, as it requires application restart.
As a first guess, your service could be some kind of API provided to a customer. This API must store the data it is sent in some database (e.g. MongoDb or Mysql). So MongoDb or Mysql would be what you call Service-A.
Since you want the performance of the API endpoints for your customers to be independent of each other, you are provisioning dedicated databases for each of your customers, that is for each of the service instances of your service.
You are right in that you would need to restage your service broker if you were to get the credentials to these databases from the environment of your service broker. Or at least you would have to re-read the VCAP_SERVICES environment variable. Yet there is another solution:
Use the CC-API to create the services, and bind them to whatever app you like. Then use again the CC-API to query the bindings of this app. This will include the credentials. Here is the link to the API docs on this endpoint:
https://apidocs.cloudfoundry.org/247/apps/list_all_service_bindings_for_the_app.html
It sounds like you are not using services in the 'correct' manner. It's very hard to tell without more detail of your use case. For instance, why does your broker need to have this additional service attached?
To answer your questions:
1) Not like this. You're using service bindings to represent data, rather than using them as backing services. Many service brokers (I've written quite a few) need to dynamically provision things like Cassandra clusters, but they keep some state about which Cassandra clusters belong to which CF service in a data store of their own. The broker does not bind to each thing it is responsible for creating.
2) Because 12 Factor applications should treat backing services as attached, static resources. It is not normal to say add a new MySQL database to a running application.
We are using spring cloud sidecar with a node.js application. It would be extremely useful if we could serve up configuration from the spring configuration server and make that configuration available to the node application.
I would like the sidecar to resolve any property place holders on behalf of the node application.
The sidecar already hits the configuration server and I know that the Environment in the sidecar WILL resolve all the property place holders. My problem is, how do I efficiently expose all those properties to the node application? I could create a simple rest endpoint that accepts a key and then returns environment.getProperty(key) but that would be extremely inefficient.
I am thinking that I could iterate over all property sources (I know that not all property sources can be enumerated), collect a unique set of the names and then turn around and call environment.getProperty() for each name....
But is there a better way?
I have to imagine this is functionality that others have needed when using Spring Cloud in a polyglot environment?
Is there any way to configure JNDI so the lookup first checks localhost and if it doesn't find matching name it performs automatic discovery of other jndi servers?
My understanding of the documentation is that this is the default behavior when using clustering:
16.2.2. Client configuration
The JNDI client needs to be aware of
the HA-JNDI cluster. You can pass a
list of JNDI servers (i.e., the nodes
in the HA-JNDI cluster) to the
java.naming.provider.url JNDI
setting in the jndi.properties file.
Each server node is identified by its
IP address and the JNDI port number.
The server nodes are separated by
commas (see Section 16.2.3, “JBoss
configuration” on how to configure the
servers and ports).
java.naming.provider.url=server1:1100,server2:1100,server3:1100,server4:1100
When initialising, the JNP client code
will try to get in touch with each
server node from the list, one after
the other, stopping as soon as one
server has been reached. It will then
download the HA-JNDI stub from this
node.
Note - There is no load balancing behavior in the JNP client lookup
process. It just goes through the
provider list and use the first
available server. The HA-JNDI provider
list only needs to contain a subset of
HA-JNDI nodes in the cluster.
The downloaded smart stub contains the
logic to fail-over to another node if
necessary and the updated list of
currently running nodes. Furthermore,
each time a JNDI invocation is made to
the server, the list of targets in the
stub interceptor is updated (only if
the list has changed since the last
call).
If the property string java.naming.provider.url is empty or
if all servers it mentions are not
reachable, the JNP client will try to
discover a bootstrap HA-JNDI server
through a multicast call on the
network (auto-discovery). See
Section 16.2.3, “JBoss
configuration” on how to configure
auto-discovery on the JNDI server
nodes. Through auto-discovery, the
client might be able to get a valid
HA-JNDI server node without any
configuration. Of course, for the
auto-discovery to work, the client
must reside in the same LAN as the
server cluster (e.g., the web servlets
using the EJB servers). The LAN or WAN
must also be configured to propagate
such multicast datagrams.
If I understand correctly the default JNDI service runs on my local AS, right? So if I create an EJB and in jboss.xml (running JBoss) I name it "sth" than it is registered in my AS. Correct?
In big projects EJBs might be distributed through many servers - on one server EJBs doing sth and on another sth else. When calling JNDI loopup() I search only one server, right? So it means that I need to know where the EJB is registered... Is it true?
When you cluster your app you will usually configure the cluster so that you have one shared JNDI. In JBoss you do this using HA-JNDI (High Availability - JNDI) or equivalent. This is a centralized service with fail-over. In principle you could imagine having a replicated service for better throughput, but to my knowledge that is not available in JBoss.
In short, you will have only one namespace, so you don't need to know where it is registered.