We are looking at our current Liferay deployment for improvement in the near future. We'd like to move to where we use instances more.
We currently have a few sites in the default instance. The model we'd like to follow in the future is to - use the default instance for super/global administrator use only. Then create instances with different domains for different audiences/users and that they can be administered by different administrators/groups separately.
Does anyone know how can we move our sites and its related data to another Liferay instance? Is this easy and doable? Are there clearly defined steps and options for this process? Are there any risks to moving the data?
Thanks for the insight.
instances mean that there's nothing shared between the sites. Well, there actually is something: As you're running on the same appserver, so you're sharing all the code, all plugins.
For this reason you might not be as isolated as you want to be. Administration typically is a bit more tricky, as every single instance needs its own virtual host and its own user database (or LDAP connection). The shared plugins might limit you as to what customization you can do with Liferay.
Quite a few times I've seen expectations to "restart" the instance, which seems legit, as a customer is the only one on that instance. However, this quickly leads to accumulated maintenance windows for all instances that are not clearly visible to other customers.
In general you can use site's import and export, e.g. export to a LAR file and import into a new site on a new server in a different instance. You'll find the Import/Export UI in the site administration UI, along with the page administration.
Related
We maintain our server once a week.
Sometimes, the customer wishes that we change some settings which is already cached in server.
My colleague always write some JSP code to change these settings which are stored in the memory.
Is it a good method to use this kind of methodology?
If our project is not a Web container, which tools can help me?
Usually, in my experience, the server configuration is not stored only in memory of server:
What happens that after a configuration change, the server has been restarted / just went down for some system reason?
What happens if you have more than one instance of the same server to work on (a cluster of servers in other words)?
So, usually, people opt for various "externalized configuration" options that can range from "file-based" configuration + redeploy the whole cluster upon each configuration change, to configuration management servers (like Consul, etc.d, etc). There are also some solutions that came from (and used in) a java world: Apache Zookeeper, Spring cloud config server to name a few, there are others. In addition, sometimes, it's convenient to store the configurations in a database.
Now to your question: If your project is not a web container and you don't care that configuration will "disappear" after a server restart and you're not running a distributed cluster of servers, then, using JSP indeed doesn't seem appropriate in this case.
Maybe you should take a look at JMX - Java management extensions, that have a built-in solution so that you probably will be able to get rid of a web container (which seems to be not used by your team anyway other than for JSP modifications that you've described).
You basically need in memory cache, there are multiple solutions found in answers which include creating your own implementation or using existing java library. You can also get data from database and add cache over the database layer.
Our framework is Grails. Say domain.com contains an application and currently used by some client. If we want to allow another client with the same functionality but providing a separation for the data of two clients, so that they can't mix both, how to do this? And whenever we want to add n clients to this application, what is the best method to be followed, so that with less / no configuration we can share the common war file for these clients by separating the db.
How the real time web development handle these type of situations?
And, one more point is how to provide client1.domain.com works for client1 and client2.domain.com works for client2. How to make the war file (in Java / Grails) to work like this? Otherwise we have to programmatically control the clients with in the project for every feature to be allowed or unnecessarily maintain separate war file for each client, which will be a waste of resources.
You're describing multitenancy - create one table for N 'tenants' instead of N identical (or nearly) tables, but partition it with a tenant_id column, and use that to filter results in SQL WHERE clauses.
For example the generated code for findByUsername would be something like select * from person where username='foo' and tenant_id=3' - the same code as a regular call but with the tenant_id column to restrict within that tenant's data.
Note that previously simple things like unique constraints are now harder because you would want to restrict uniqueness within a tenant, but allow a value to be reused across tenants. In this case changing the unique constraint to be on the combo of username and tenant_id works and does the heavy lifting in the database.
For a while there were several related plugins, but they relied on tweaking internal APIs and some features broke in newer Hibernate versions. But I believe that http://grails.org/plugin/multi-tenant-single-db is active; it was updated over a year ago, but it is being used. Contact the authors if it looks like it'll be what you need to be sure it's active. Note that this can only work with Hibernate 3.x.
Hibernate 4 added support for multitenancy, but I haven't heard much about its use in Grails (which is expected, since it's not that common a requirement). It's not well documented, but this bug report highlights some of the potential pitfalls and should still be a working example (the test app is still on GitHub): https://jira.grails.org/browse/GPHIB-6.
I'd like to ensure that this is working and continues to work, so please let me know via email if you have issues later. It's a great feature and having it in Hibernate core makes things a lot easier for us. But we need to make it easy to use and well-documented, and that will happen a lot faster when it's being used in a real project.
I am working a project that will require a custom "wizard" to help a non-technical user to install a custom database driven application. The main concern is to not set up a new database for the custom application if there is a suitable database engine already in place. So the question comes: how to programmatically detect the type and location of existing database engines?
The trick here is that the requirements for the installer are that the wizard assists a non technical user decide if a database engine exists on the local private network that is on the compatibility list. If so, assist the non technical user with forming a connection to the selected database engine. Otherwise the wizard is to install a database etc.
Would it be better to just install the preferred DBMS regardless of the existing database scene? The platform is a windows box, but platform independence is a goal of the project.
I don't know if I am just using the wrong search terms or if there is little to no real information to this effect, but finding out if this is even possible has been frustrating.
Any help, advice, links, code resources, etc. will be greatly appreciated.
EDIT The goal of detecting the location and type of existing databases is to provide a simple list that a user can select from, for the case of adding an additional instance of the application on a private network for the current version or as an upgrade of the version (to effect a "clean" install). The application is a bit distributed in that there are typically going to be many instances of the application (3 - 10) working as terminals to interact with the database, manipulating the information in different ways for different uses on different terminals. The I think the preferred DBMS has settled on PostgreSQL.
Steve
If you know what type of database you're trying to connect to, you should be able to ping the default port for that type of database to see whether it returns a response. Or alternatively, try to open an actual connection to the database and see whether you get a response.
Getting more complicated, if you can access the PC on the network, browse to the default installation directories for the database type to see if anything exists.
These 2 so far would require the database to be installed using default locations and ports.
Getting more complicated, if you can connect to the registry on the remove PC then you can probably locate the database in the registry tree - this is going to be fixed no matter where the user installs the database
My suggestion would probably be to completely avoid this though, as it adds a lot of complexity without much payback. If your application is for a non-technical end user, it'd probably be better to just assume that there isn't any databases available to them, and just install a new one as part of the installer. Non-technical users are only going to be confused if you present them with a whole list of database options that really don't mean anything to them.
It could also potentially take a long time to query your local network, depending on how many network shares exist, and how quick they are to respond. All this would take away from the responsiveness of the installer, so the end user might not know why the installer isn't doing anything.
If you really want to give the option of choosing an existing database, I'd make it a separate optional button which would take them to another screen where they can choose a network host to investigate - the only people who would get to this screen would be more technical people who would probably know where a database exists anyway.
The main concern is to not set up a new database for the custom application if there is a suitable database engine already in place.
I don't quite understand how a wizard can determine whether an existing database is suitable. Suppose it finds 3 Oracle and 4 MySQL instances on the network – how will it choose? Moreover, such an approach creates a dependency between the user's application and another machine on the network, without the user's even being aware of it. What will the user do when the database's unavailable tomorrow?
It seems to me that if the data needs to be shared among several users or several systems, then selection of the DB must be an explicit, conscious operation by the user. If, on the other hand, the database is just a place where the application stores some stuff, then it should install one – preferably a lightweight one like HSQLDB or SQLite.
I'm looking for a free (if possible) solution where:
You can 'record' all the kinds of objects created during normal (production-like) usage of a webapp on an EJB application server (like Weblogic).
Afterwards you can 'replay' each page separately on an non-EJB application server like Tomcat.
Moreover, it would be fantastic if:
One could easily create test-suites from all the recorded scenarios and replay them in different browsers (to test regressions).
One could modify or substitute single recorded objects (for example changing the fields of a map etc.) Changed objects can be saved and added into a test suite.
It would be possible to integrate the solution with an IDE, optimally Eclipse.
I've tried googling and I've found Replay Solutions . Their product seems to be pretty well-suited to my requirements but
unfortunately it is paid and they don't even put pricing directly on the webpage (it's available after contacting the company).
Does anybody know such a solution or am I demanding too much?
I have an administrative page in a web application that resets the cache, but it only resets the cache on the current JVM.
The web application is deployed as a cluster to two WAS servers.
Any way that I can elegantly have the "clear cache" button on each server trigger the method on both JVMs?
Edit:
The original developer just wrote a singleton holding a HashMap to be the cache in question. Lightweight and (previously) worked just fine for the requirements. It caches content pulled from six or seven web services for specified amounts of time.
Edit:
The entire application in question is three pages, so the elegant solution might well be the lightest solution.
Since the Cache is internal to your application you are going to need to provide an interface to clear it within your application. Quotidian says to use a JMS queue. That will not work because only one instance will pick up the message assuming you have clustered MQ Queues.
If you want to reuse the same implementation then the only way to do this is to write some JMX that you will be able to interact with at the instance level.
If not you can either use the built in WAS cache (which is JMX enabled) or use a distributed cache like ehcache.
in the past I have created a subclassed LinkedHashMap that was linked to all instances on the network using JBOSS JGroups. Of course reinventing the wheel is always painful.
I tend to use a JMS queue for doing exactly that.