Jndi ldap log4j vulneraility - ldap

As the entire world know that the log4j vulnerability involves jndi ldap lookup attack. There cpuld be many other libraries using jndi ldap lookup for property resolutions. What is the possibilty people? Like Spring Property placeholder configurator? Not sure whether it uses jndi-ldap in similar way internally ? We need to explore the same.

Related

database connection in GeoServer

I am going to use redis as the web cache for geoserver, so I need to understand the database connection in geoserver. I have imported geoserver in Eclipse, and there are two projects named gs-sec-jdbc and gs-web-sec-jdbc. I do not know what the “sec" means and what are the differences between these two projects. Any help or tutorial is appreciated! Thank you !
These two modules are part of the security subsystem (gs-web-sec-jdbc is the web based user interface). They are almost certainly not the modules you are looking for.
If you intend to use redis to store WMS output images then you need to look at how GeoWebCache works.
If you want to provide a cache between GeoServer and a JDBC database then you will need to explore GeoTools' JDBC datastore mechanism.

JNDI properties file in Worklight

Can anyone please explain the significance of JNDI properties file in worklight app developement, Also is it mandatory to have one JNDI properties file for the mobile app developed using worklight to work.
thanks
djrecker
JNDI properties are not unique to Worklight. There is no requirement to use JNDI, rather it is simply a convenient method to lay out various properties that may be used in various environments (QA, UAT, PROD, ...) where you will find yourself deploying the Worklight Server.
As a Worklight Server has many properties that will be different per the environment (ports, hostnames, etc...), using JNDI properties you could better manage them in a single location (file). By not doing so, you may find yourself creating for example multiple .war files - a .war file per environment instead of 1 .war file for all environments, where the required properties for the environment are taken from a single file (the JNDI properties file).
You can read more about this, here: Configuring a Worklight project in production by using JNDI environment entries

IBM Worklight 6.2. Analytics JNDI properties in WAS ND

About Worklight 6.2 Analytics.
https://www-01.ibm.com/support/knowledgecenter/api/content/SSZH4A_6.2.0/com.ibm.worklight.monitor.doc/monitor/t_setting_up_production_cluster.html
There are several JNDI properties to configure but It is not explained how to configure them in WAS ND and in which scope must be configured (if this has sense)
For example the worklight.properties are configured as application properties during the application installation.
How are configured the analytics JNDI properties on WAS?
And also in which scope should them be configured, this is also struggling me. For example it says that properties like "analytics/shards" or "analytics/replicas_per_shard" must be configured in the first node, but for me these properties should be properties configured at cluster level, not at node level.
Also WAS ND topology is something completely dynamic and flexible, what happens if I remove that "first" node?
Ok, now I understand that when in the Worklight Analytics documentation talk about cluster it is not talking about WAS Cluster but about Elasticsearch cluster.
Taking into account this, configuring a cluster for Analytics does not mean to install the analytics.war in a WAS cluster, it means that you will install analytics.war file in a number of WAS servers (not WAS clusters, not WAS nodes) and with the ElasticSearch properties you will configure the ElasticSearch cluster.
Is this correct?
The specific answer to my question is that the value of the properties are set during the detailed installation of the analytics.war file as it is done with the Application Project WAR file, worklightadmin.war or worklightconsole.war.
It is only needed to set those properties if you are configuring Analytics in more than one server.

Is there a way to configure MDBs programatically?

I am currently working on a EJB 3.1 based project running on GlassFish that uses a custom built framework to configure the functionality of any SessionBeans. Using this we can enable, disable and re-configure most of the services at run-time. Unfortunately we can't extend this to support conifguration of MDBs. I would like to set the selector a MDB is using based upon the configuration information and re-configure this if the settings change.
Unfortunately I could only come up with a SessionBean that creates MessageConsumers natively on the JMS Sessions based upon the configuration and to have the JMS messages handleb by MessageListeners, but I was told this way we would be loosing concurrency and the transaction handling of the EJB system, as we would no longer be using MDBs this way.
So is there any way to do what I'm looking for using MDBs? Someone told me there are some planned extensions in new EJB and JMS spec drafts, but I couln't find a pointer to that particular topic.
No, MDBs are configured by the Deployer at deploy-time.
Similar question answered here: Configuring MappedName annotation in Message Driven Bean dynamically

Lookup a Message Driven Bean via JNDI

If I create a MessageDriven bean - is it available to other components in my app via JNDI? If so, how can I find/specify the name to look it up by? I'm deploying to glassfish if that makes any difference?
Assigning a JNDI name for an MDB is not required by Java EE specification (chapter 21.2.3 of EJB 3.0):
At the minimum, the EJB container must provide a JNDI API name space to the enterprise bean
instances. The EJB container must make the name space available to an instance when the instance invokes the javax.naming.InitialContext default (no-arg) constructor.
The business interfaces of other enterprise beans
[...]
MDBs don't qualify, as they don't have a business interface. Besides, since wiring up an MDB in another EJB/MDB would have little sense (what's your use case, BTW?), is probably skipped in Glassfish.
I've seen that WebLogic, for example allows that in its proprietary deployment descriptor, but I've never used it.