Questions
Why does it use localhost?
What does keystone have to do with it?
I can't seem to configure a keystone endpoint
Context
App: Spring Boot (1.5.6) REST API
Hibernate 5.2
Hazelcast 3.9 - as 2nd-level cache only
hazelcast-jclouds 3.7.1
jclouds-compute and jclouds-allcompute 2.0.2
Openstack cloud for VMs running the app
The Setup
I have my hazelcast.xml configured as follows:
<discovery-strategies>
<discovery-strategy class="com.hazelcast.jclouds.JCloudsDiscoveryStrategy" enabled="true">
<properties>
<property name="modules">org.jclouds.logging.slf4j.config.SLF4JLoggingModule</property>
<property name="provider">openstack-nova</property>
<property name="endpoint">http://dev.nova.cloud.youdontknow.net:8774/v2/</property>
<property name="identity">redacted</property>
<property name="credential">cens0red</property>
</properties>
</discovery-strategy>
</discovery-strategies>
The problem
App initialization fails. Here's some log tidbits:
[TRACE] o.j.r.internal.RestAnnotationProcessor : looking up default endpoint for org.jclouds.openstack.keystone.v2_0.AuthenticationApi.public abstract org.jclouds.openstack.keystone.v2_0.domain.Access org.jclouds.openstack.keystone.v2_0.AuthenticationApi.authenticateWithTenantNameAndCredentials(java.lang.String,org.jclouds.openstack.keystone.v2_0.domain.PasswordCredentials)[bnet-web, PasswordCredentials{username=redacted, password=*****}]
[TRACE] o.j.r.internal.RestAnnotationProcessor : using default endpoint Optional.of(http://localhost:5000/v2.0/) for org.jclouds.openstack.keystone.v2_0.AuthenticationApi.public abstract org.jclouds.openstack.keystone.v2_0.domain.Access org.jclouds.openstack.keystone.v2_0.AuthenticationApi.authenticateWithTenantNameAndCredentials(java.lang.String,org.jclouds.openstack.keystone.v2_0.domain.PasswordCredentials)[bnet-web, PasswordCredentials{username=redacted, password=*****}]
[TRACE] o.j.rest.internal.InvokeHttpMethod : << converted AuthenticationApi.authenticateWithTenantNameAndCredentials to POST http://localhost:5000/v2.0/tokens HTTP/1.1
And here's bits of the exception stack traces:
Caused by: com.hazelcast.core.HazelcastException: Failed to get registered addresses
at com.hazelcast.jclouds.JCloudsDiscoveryStrategy.discoverNodes(JCloudsDiscoveryStrategy.java:93)
at com.hazelcast.jclouds.JCloudsDiscoveryStrategy.discoverLocalMetadata(JCloudsDiscoveryStrategy.java:106)
at com.hazelcast.spi.discovery.impl.DefaultDiscoveryService.discoverLocalMetadata(DefaultDiscoveryService.java:91)
...
Caused by: org.jclouds.http.HttpResponseException: Connection refused: connect connecting to POST http://localhost:5000/v2.0/tokens HTTP/1.1
at org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(BaseHttpCommandExecutorService.java:122)
...
at com.sun.proxy.$Proxy147.authenticateWithTenantNameAndCredentials(Unknown Source)
at org.jclouds.openstack.keystone.v2_0.functions.AuthenticatePasswordCredentials.authenticateWithTenantName(AuthenticatePasswordCredentials.java:43)
Other Notes
Looks like it's using the default keystone address configured in org.jclouds.openstack.keystone.v2_0.KeystoneApiMetadata - but I don't know how that's involved.
By looking at the code, I think hazlecast-jclouds is not prepared to manage generic APIs. When connecting to a provider, you don't need to specify the endpoint, as it is well-known (the AWS endpoints, Google, Azure, etc), but when using generic APIs such as OpenStack or CloudStack, you need to tell jclouds where to connect. Unfortunately, it looks like hazlecast-jclouds lacks support for configuring custom endpoints for generic APIs.
A quick look at the code suggests that it could be easy to add, though. The properties that are taken into account are defined in the JCloudsDiscoveryStrategyFactory, and then read in the ComputeServiceBuilder to create the jclouds context.
I'm not familiar with Hazlecast, but I'd say that adding the definition for the "endpoint" property, and then, if present, configuring it by calling the jclouds contextBuilder.endpoint(endpoitn) method should do the trick.
Related
I am using WebSphere 8.5.5.18.
As of now I'm using Component-Managed Authentication Alias for my DataSource. But I want to use Container-Managed instead. When I just change the Security settings in Data Sources → Security settings I am getting error in logs. It is unable to fetch records.
Exception Stacktrace:
Check the SQL Statement (preparation failed).
--- Cause: java.sql.SQLException: [jcc][t4][10205][11234][3.72.54] Null userid is not supported. ERRORCODE=-4461, SQLSTATE=42815 DSRA0010E: SQL State = 42815, Error Code = -4,461
at org.springframework.jdbc.support.SQLStateSQLExceptionTranslator.doTranslate(SQLStateSQLExceptionTranslator.java:97)
at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:72)
at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:80)
at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:80)
at org.springframework.orm.ibatis.SqlMapClientTemplate.execute(SqlMapClientTemplate.java:212)
at org.springframework.orm.ibatis.SqlMapClientTemplate.queryForObject(SqlMapClientTemplate.java:271)
Basically the database is not being accessed properly when settings are changed from Component-Managed Authentication to Container-Managed Authentication alias.
When I run with Component-Managed Authentication, its working fine.
Does changing security setting to Container Managed Authentication alias, require some other/additional setting/changes? Or do I need to change my underlying Spring ibatis code to make it work?
Any help on configuring/implementing Container-Managed Authentication Alias in websphere would be appreciated.
Container-managed authentication applies when your code (or any third party code that executes upon its behalf) looks up the data source with a resource reference that specifies the resource authentication as container or leaves resource authentication unspecified, in which case it defaults to container.
Component-managed authentication applies when your code (or any third party code that executes upon its behalf) looks up the data source without a resource reference, or uses a resource reference that specifies the resource authentication as application.
Here are some examples of resource references that use container authentication:
// resource injection can be used on a web component (servlet) or ejb component
#Resource(name = "java:comp/env/jdbc/ds1ref", lookup = "jdbc/ds1", authenticationType = Resource.AuthenticationType.CONTAINER)
DataSource ds1;
#Resource(name = "java:comp/env/jdbc/ds2ref", lookup = "jdbc/ds2")
DataSource ds2;
...
// code that looks up one of the above resource references
DataSource ds = InitialContext.doLookup("java:comp/env/jdbc/ds1ref");
Here is an example of a resource reference defined within a web.xml deployment descriptor:
<resource-ref>
<res-ref-name>java:comp/env/jdbc/ds3ref</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
<lookup-name>jdbc/ds3</lookup-name>
</resource-ref>
If third party code, such as Spring, is looking up a data source on your behalf and you would like it to use container authentication, you will need to define a resource reference with container managed authentication, such as shown above in the examples, and supply its resource reference name to the third party software in place of however you are doing so currently. If you are unsure where this is done, it might help to search for occurrences of the configured JNDI name of the WebSphere data source within the application.
I have a server.xml with jndi configuration that works and can connect to database (validated with small program using #Resource), but when I try to use an application that is spring based, I can never login to the database. I am successfully getting the jndi reference, but it just never logs in and gives me invalid username/password.
I have searched this to death on google, and haven't found anything that can point in the right direction.
You should post the specific details about your configuration and resource references. One way to cause the error you are seeing would be to configure a dataSource with the user/password specified only within the default container authdata (dataSource with nested containerAuthData element, or with a containerAuthDataRef specified). When you use #Resource, you are getting container authentication by default, and the user/password would be used. However, if Spring is directly looking up the data source (no resource reference) or specifies a resource reference with application authentication, then the user/password of the default container authdata would not apply. However, if instead you configure user/password on the vendor properties element that is nested under dataSource, then it will reply regardless of the authentication type.
Example of data source configuration where user/password will only be used for container authentication:
<dataSource id="DefaultDataSource" jndiName="jdbc/oracle">
<containerAuthData user="user1" password="pwd1"/>
<jdbcDriver libraryRef="OracleLib"/>
<properties.oracle URL="jdbc:oracle:thin:#//localhost:1521/SAMPLEDB"/>
</dataSource>
Example of data source configuration where user/password apply regardless of whether container or application authentication are used,
<dataSource id="DefaultDataSource" jndiName="jdbc/oracle">
<jdbcDriver libraryRef="OracleLib"/>
<properties.oracle URL="jdbc:oracle:thin:#//localhost:1521/SAMPLEDB" user="user1" password="pwd1"/>
</dataSource>
invalid username/password is an oracle error message, so you may be:
pointing to the wrong DB (where user does not live)
using the wrong user
using the wrong password
Try the connection in SQL Plus, if it works there, then problem in the code/configuration.
I'm new to openshift and currently trying to set up my websocket application there, but have some issues. While I'm trying to connect to
ws://app-domain.rhcloud.com:8000/path
I get the following exception:
Caused by: java.lang.IllegalArgumentException: No 'javax.websocket.server.Server Container' ServletContext attribute. Are you running in a Servlet container that
supports JSR-356?
at org.springframework.util.Assert.notNull(Assert.java:112)
at org.springframework.web.socket.server.standard.AbstractStandardUpgradeStrategy.getContainer(AbstractStandardUpgradeStrategy.java:68)
at org.springframework.web.socket.server.standard.TomcatRequestUpgradeStrategy.getContainer(TomcatRequestUpgradeStrategy.java:83)
at org.springframework.web.socket.server.standard.TomcatRequestUpgradeStrategy.getContainer(TomcatRequestUpgradeStrategy.java:46)
at org.springframework.web.socket.server.standard.AbstractStandardUpgradeStrategy.getSupportedExtensions(AbstractStandardUpgradeStrategy.java:88)
at org.springframework.web.socket.server.support.DefaultHandshakeHandler.doHandshake(DefaultHandshakeHandler.java:214)
at org.springframework.web.socket.server.support.WebSocketHttpRequestHandler.handleRequest(WebSocketHttpRequestHandler.java:127)
... 25 more
When I run application locally everything works fine with the following url:
ws://localhost:8090/path
For both cases I use Tomcat 7.
Spring Config:
<websocket:handlers allowed-origins="*">
<websocket:mapping path="/fight-core" handler="webSocketHandler"/>
<websocket:handshake-interceptors>
<ref bean="webSocketHandshakeInterceptor"/>
</websocket:handshake-interceptors>
</websocket:handlers>
Also I've tried with websocket-api dependency in my pom.xml and w/o it
Kidnly advice
Apparently it's not about Spring nor Tomcat, but Openshift's routing layer; it looks like websocket support is still experimental, see:
* a blog post from 2012 explaining the situation
* Openshift official documentation
For plain WebSocket connections (ws://), requests are directed to port
8000, while WebSocket Secure connections (wss://) use port 8443, as
shown in the following example: http://example.example.com:8000
https://example.example.com:8443
I am facing an issue connecting spring data solr to solr running on openshift.
<solr:solr-server id="solrServer"
url="http://solr-dashapramathi.rhcloud.com/" />
<bean id="solrTemplate" class="org.springframework.data.solr.core.SolrTemplate"
scope="singleton">
<constructor-arg ref="solrServer" />
</bean>
is my configuration. i have also tried the url as "http://solr-dashapramathi.rhcloud.com/#/dashapramathi" I am running Solr 4.10.1 on openshift.
The error is as below:
IOException occured when talking to server at: http://solr-dashapramathi.rhcloud.com/dashapramathi; nested exception is org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: http://solr-dashapramathi.rhcloud.com/dashapramathi
Caused by:
org.springframework.data.solr.UncategorizedSolrException: IOException occured when talking to server at: http://solr-dashapramathi.rhcloud.com/dashapramathi; nested exception is org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: http://solr-dashapramathi.rhcloud.com/dashapramathi
at org.springframework.data.solr.core.SolrTemplate.execute(SolrTemplate.java:136)
at org.springframework.data.solr.core.SolrTemplate.saveBean(SolrTemplate.java:175)
at org.springframework.data.solr.core.SolrTemplate.saveBean(SolrTemplate.java:169)
at org.springframework.data.solr.repository.support.SimpleSolrRepository.save(SimpleSolrRepository.java:149)
Caused by: org.apache.http.conn.ConnectTimeoutException: Connect to solr-dashapramathi.rhcloud.com:80 timed out
at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:129)
Could anyone please help me?
Judging by the documentation listed here http://docs.spring.io/spring-data/solr/docs/1.2.4.RELEASE/reference/html/solr.repositories.html It looks like it tries to connect through port 8993 which is why would would be receiving the timeout.
OpenShift only allows external connections to be made to 80,8080,443,8443. For inside the gear connections you can alter things to connect to more ports as per the following OpenShift Doc https://help.openshift.com/hc/en-us/articles/202185874.
I had the same problem, and I've managed to resolve it just by changing the timeout in the definition of the Solr server.
So, for your case it would be:
> <solr:solr-server id="solrServer"
> url="http://solr-dashapramathi.rhcloud.com/" timeout="1000"/>
or you can set a higher value for the timeout, depending on your connection.
In the documentation of the Spring Data Solr the 8993 port it is probably the port that the application server which hosts Solr runs on.
I am using jmeter jms point to point queue for load testing.
But I am getting the following error:
javax.naming.NamingException: Failed to create remoting connection [Root exception is java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed]
I am using jmeter 2.11 version
I add user name and password in jndi properties. But still it is not working. Here is the configuration i am using:
QueueConnectionFactory: RemoteConnectionFactory
initial context factory: org.jboss.naming.remote.client.InitialContextFactory
url : remote://localhost:4447
JNDI Prpperties:
username: ..............
password: ...........
Your Jndi properties seem wrong, check this:
http://docs.oracle.com/cd/E19182-01/820-7853/ghyco/index.html
Login / password props are :
java.naming.security.principal
The identity of the principal for authenticating the caller to the service. For more information, see the Java API documentation for javax.naming.Context.SECURITY_PRINCIPAL.
java.naming.security.credentials
The credentials of the principal for authenticating the caller to the service. For more information, see the Java API documentation for javax.naming.Context.SECURITY_CREDENTIALS.
I have encountered similar problem while using jmeter for solace, hope this help to someone having similar issue.
For solace jms testing need to use jndi properties since there is no place holder for VPN name. JNDI properties file will look something like this:
java.naming.factory.initial=com.solacesystems.jndi.SolJNDIInitialContextFactory
java.naming.provider.url=<IP:port><br>
Solace_JMS_VPN=<VPN Name><br>
java.naming.security.principal=<username><br>
java.naming.security.credentials=<password>
Here the jndi properties has to be packaged as a jar file and placed in the jmeter lib folder in order to be picked at runtime.
jar cvf my-jndi-properties.jar jndi.properties
Hope this helps.