I have checked out Googles code example for the Guestbook. It builds locally and I can deploy it to my local machine and it is working out ok.
When I try to deploy it to Google App Engine this happens in the log:
com.google.appengine.api.datastore.DatastoreNeedIndexException: no matching index found. recommended index is:
- kind: Greeting
ancestor: yes
properties:
- name: date
direction: desc
The suggested index for this query is:
<datastore-index kind="Greeting" ancestor="true" source="manual">
<property name="date" direction="desc"/>
</datastore-index>
at com.google.appengine.api.datastore.DatastoreApiHelper.translateError(DatastoreApiHelper.java:56)
After a bit of Googling I find people that suggest one of two things. 1) Do some editing in the YAML. 2) Manually modify the TARGET and add some index config.
I'd like to avoid both because 1) In the latest Guestbook code sample there is no YAML and 2) I prefer to automate my build than to manually hack it every time I want to deploy.
Is there any way to make this work when using mvn appengine:deploy ?
This is the guide I have been using : https://cloud.google.com/appengine/docs/standard/java/tools/using-maven
It's perfectly normal (sometimes even required) to manually modify the datastore index configuration file according to your app's specific usage. The reason for which such file may be missing from the sample code could be that it is typically auto-generated. From Cloud Datastore Indexes:
Important: For an in-depth discussion of indexes and querying, see the article Index Selection and Advanced Search.
App Engine predefines a simple index on each property of an entity. An
App Engine application can define further custom indexes in an index
configuration file named datastore-indexes.xml, which is
generated in your application's /war/WEB-INF/appengine-generated
directory . The development server automatically adds suggestions to
this file as it encounters queries that cannot be executed with the
existing indexes. You can tune indexes manually by editing the file
before uploading the application.
You should also note that the datastore index configuration is an app-level configuration, shared by all app's services/modules, even if they're not written in Java. Which is why you may see references to both datastore-indexes.xml (java-only, the suggested index format in your message is for this file) and index.yaml (all languages).
Another important note is that the index configuration can be deployed independently from the service/module code, including with maven. From App Engine Maven Plugin Goals and Parameters:
appengine:deployIndex
Deploys an index.yaml configuration file to App Engine.
So just use this target to update your datastore index configuration.
Related
I use JDBC and created h2 database called usaDB from sql script. Then I filled all tables with jdbc.
The problem is that after I connect to usaDB at localhost:8082 I cannot see on the left tree
my tables. There is only INFORMATION_SCHEMA database and rootUser which I specified creating usaDB.
How to view the content of tables in my h2 database?
I tried query SELECT * FROM INFORMATION_SCHEMA.TABLES.
But it returned many table names except those I created. My snapshot:
I had the same issue and the answer seems to be really stupid: when you type your database name you shouldn't add ".h2.db" suffix, for example, if you have db file "D:\somebase.h2.db" your connection string should be like "jdbc:h2:file:/D:/somebase". In other way jdbc creates new empty database file named "somebase.h2.db.h2.db" and you see what you see: only system tables.
You can use the SHOW command:
Using this command, you can lists the schemas, tables, or the columns of a table. e.g.:
SHOW TABLES
This problem drove me around the twist and besides this page I read many (many!) others until I solved it.
My Use Case was to see how a SpringBatch project created in STS using :: Spring Boot :: (v1.3.1.RELEASE) was going to behave with the H2 database; to do the latter, I needed to be able to get the H2 console running as well to query the DB results of the batch run.
This is what I did and found out:
Created an Web project in STS using Spring Boot:
Added the following to the pom.xml of the latter:
Added a Spring configuration file as follows to the project:
This solves the Web project deficiencies in STS. If you run the project now, you can access the H2 console as follows: http://localhost:8080/console
Now create a SpringBatch project in STS as follows (the alternative method creates a different template missing most of the classes for persisting data. This method creates 2 projects: one Complete, and the other an initial. Use the Complete in the following.):
The SpringBatch project created with STS uses an in memory H2 database that it CLOSES once the application run ends; once you run it, you can see this in the logging output.
So what we need is to create a new DataSource that overrides the default that ships with the project (if you are interested, just have a look at the log messages and you will see that it uses a default datasource...this is created from:
o.s.j.d.e.EmbeddedDatabaseFactory with the following parameters:
Starting embedded database: url='jdbc:hsqldb:mem:testdb', username='sa')
So, it starts an in memory, and then closes it. You have no chance of seeing the data with the H2 console; it has come and gone.
So, create a DataSource as follows:
You can of course use a properties file to map the parameters, and profiles for different DataSource instances...but I digress.
Now, make sure you set the bit that the red arrow in the picture is pointing to, to a location on your computer where a file can be persisted.
Running the SpringBatch (Complete project) you should now have a db file in that location after it runs (persisting Person data)
Run the Web project you configured previously in these steps, and you WILL :=) see your data, and all the Batch job and step run data (et voila!):
Painful but rewarding. Hope it helps you to really BOOTSTRAP :=)
I have met exactly this problem.
From what you describe, I suppose that you connect your jdbc with the "real" h2 server, but you are connecting on web application to database by the wrong mode (embedded-in-memory mode, aka h2mem). It means that h2 will create a new database in-memory, instead of using your true database stored elsewhere.
Please make sure that when you connect to this database, you use the mode Generic H2 (Server), NOTGeneric H2 (Embedded). You can refer to the picture below.
Version of jar file and installed h2 database should be same.
If in case you have created and populated H2 database table using maven dependency in spring boot, then please do change the JDBC URL as jdbc:h2:mem:testdb while connecting to H2 using web console.
It is an old question, but I came across the same problem. Eventually I found out that the default JDBC URL is pointing a test server rather than my application. After correcting it, I could access the right DB.
I tried with both Generic H2 (Embedded) and the Generic H2 (Server) options, both worked as long as the JDBC URL: is provided correctly.
In grails 4.0.1 the jdbc URL for development is jdbc:h2:mem:devDb. Check your application.yml file for the exact URL.
For the people who are using H2 in embedded(persistent mode) and want to "connect" to it from IntelliJ(other IDEs probably apply too).
Using for example jdbc url as follows: jdbc:h2:./database.h2
Note, that H2 does not allow implicit relative paths, and requires adding explicit ./
Relative paths are relative to current workdir
When you run your application, your workdir is most likely set to your project's root dir
On the other hand, IDE's workdir is most likely not your project's root
Hence, in IDE when "connecting" to your database you need to use absolute path like: jdbc:h2:/Users/me/projects/MyAwesomeProject/database.h2
For some reason IntelliJ by default also adds ;MV_STORE=false. It disables MVStore engine which in fact is currently used by default in H2.
So make sure that both your application and your IDE use the same store engine, as MVStore and PageStore have different file layouts.
Note that you cannot "connect" to your database if your application is using it because of locking. The other way around applies too.
In my case the issue was caused by the fact that I didn't set the h2 username, password in java. Unfortunatelly, Spring didn't display any errors to me, so it was not easy to figure out. Adding this lines to dataSource method helped me fix the issue:
dataSource.setUsername("sa");
dataSource.setPassword("");
Also, I should have specified the schema when creating tables in schema.sql
Selecting Generic H2 (Server) solved for me. We tempted to use default Generic H2 (Embedded) which is wrong.
I am looking for a configuration file in websphere 8.5.1 which holds all the server settings like datasources, buses, queues etc. I am aware of server.xml which is present for every server instance at cell level but it does not have all the settings.
Please help me with some suggestion. I am looking for this file as I want to configure a maven integration test with websphere8.5.1.
So, in order to run these tests I would need some file to get the configurations from.
Basically i am trying to replicate a maven integration test with glassfish where domain.xml was used in the maven integration script pom.xml to configure all the resources.
For WebSphere "full Profile" (as opposed to "Liberty Profile"), there is no single file. All that information is spread across many files.
The information on datasources will be in resource.xml. However, there is a resources.xml file at every scope ie at cell level , cluster level, node level and JVM level. So based on where datasource is defined the correct resource.xml can be used. Sib configuration will be created in the PROFILE_HOME/config/cells//buses
VG, opinions are my own and not those of my employer
There is a PropertiesBasedConfiguration command group from WAS 7 onwards which can let you extract your config to a single file but there are some limitations too.
You can check below links to get more info on same:
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=/com.ibm.websphere.base.doc/ae/rxml_7propbasedconfig.html
http://www.ibm.com/developerworks/websphere/techjournal/0904_chang/0904_chang.html
There is a team develops enterprise application with web interface: java, tomcat, struts, mysql, REST and LDAP calls to external services and so on.
All configuration is stored in context.xml --tomcat specific file that contains variables available via servlet context and object available via JNDI resources.
Developers have no access to production and QA platforms (as it should be) so context.xml is managed by support/sysadmin team.
Each release has config-notes.txt with instructions like:
please add "userLimit" variable to context.xml with value "123", rename "DB" resource to "fooDB" and add new database connection to our new server (you should know url and credentials) named "barDb"
That is not good.
Here is my idea how to solve it.
Each release has special config file with required variable names, descriptions and default values (if any): even web.xml could be used.
Here is pseudo example:
foo=bar
userLimit=123
barDb=SET_MANUAL(connection to our new server)
And there is a special tool that support team runs against deployment artifact.
Look at it (text after ">" is typed by support guy):
Config for version 123 of artifact "mySever".
Enter your config file location> /opt/tomcat/context/myServer.xml
+"foo" value "bar" -- already exists and would not be changed
+"userLimit" value "123" -- adding new
+"barDb"(connection to our new server) please type> jdbc:mysql:host/db
Saving your file as /opt/tomcat/context/myServer.xml
Your environment is not configured to run myServer-123.
That will give us ability to deploy application on any environment and update configuration if needed.
Do you like my idea? What do you use for environment configuration management? Does there is ready-to-use tools for that?
There are plenty of different strategies. All of them are good and depends on what suit you best.
Build a single artifact and deploy configs to a separate location. The artifact could have placeholder variables and, on deployment, the config could be read in. Have a look at Springs property placeholder. It works fantastically for webapps that use Spring and doesn't involve getting ops involved.
Have an externalised property config that lives outside of the webapp. Keep the location constant and always read from the property config. Update the config at any stage and a restart will be up the new values.
If you are modifying the environment (i.e. application server being used or user/group permissions) look at using the above methods with puppet or chef. Also have a look at managing your config files with these tools.
As for the whole should devs be given access to prod, it really depends on a per company basis. For smaller companies where the dev is called every time there is a problem, regardless of whether that problem is server or application related, then obviously devs require access to the box.
DevOps is not about giving devs access to the box, its about giving devs the ability to use infrastructure as a service, the ability to spawn new instances with application X with config Y and to push their applications into environments without ops. In a large company like ours, what it allows is the ability for devs to manage the application they put on a server. Operations shouldn't care what version is on their, thats our job, their job is all about keeping the server up and running.
I strongly disagree with your remark that devs shouldn't have access to prod or staging environments. It's this kind of attitude that leads to teams working against each other instead of with eath other.
But to answer your question: you are thinking about what is typically called continuous integration ( http://en.wikipedia.org/wiki/Continuous_integration ) and moving towards devops. Ideally you should aim for the magic "1 click automated deployment". The guys from Flickr wrote a lot of blogs (and books) about how they achieved that.
Anyhow .. there's a lot of tools around that sector. You may want to have a look a things like Hudson/Jenkins or Puppet/Chef.
I am working on single solr app. I downloded solr exampple code for net, which is working fine while running on jetty server.It is having data which are to be indexed in C:\apache-solr-1.4.0\example\exampledocs and the indexes are stored in C:\apache-solr-1.4.0\example\solr\data, using jetty server indexes are created using command java -jar post.jar *.xml. Now i want to know how can i achieve this using Tomcat. do i need to change the configuration to change the path for indexe storage and for xml files storage. how data will b indexed so that i would able to search it.
If I understand your question correctly, you'll want to use the -Durl flag when running post.jar, e.g.:
java -jar -Durl=http://localhost:8080/solr/update post.jar solr.xml monitor.xml
In solrconfig.xml you can mention the path that has to hold the index
<dataDir>${solr.data.dir:}</dataDir>
I think you just have to read more from SOLR documentation, and click through what you have in the package.
There is an tomcat deployment doc in solr wiki:
http://wiki.apache.org/solr/SolrTomcat
And the war file is in the dist folder you've downloaded.
How to search it? There is no simple answer. I suggest you read more on the solr wiki. Find out what is a handler, what is the difference between dismax handler and standard handler, how schema.xml defines the database.
I want to know if it is possible to use the same index file for an entity in two applications. Let me be more specific:
We have an online Application with a frondend for the users and an application for the backend tasks (= administrator interface). Both are running on the same JBOSS AS. Both Applications are using the same database, so they are using the same entities. Of course the package names are not the same in both applications for the entities.
So this is our usecase: A user should be able to search via the frondend. The user is only allowed to see results which are tagged with "visible". This tagging happens in our admin interface, so the index for the frontend should be updated every time an entity is tagged as "visible" in the backend.
Of course both applications do have the same index root folder. In my index folder there are 2 index files:
de.x.x.admin.model.Product
de.x.x.frondend.model.Product
How to "merge" this via Hibernate Search Configuration? I just did not get it via the documentation...
Thanks for any help!
Ok, it seems, that this is not possible...