I'm looking for a web-based Java tool (preferably one that will run in both Weblogic and JBoss) that will allow controlled access to a particular database. I need to allow non-technical users to insert, update, and delete rows in a particular Oracle DB table. The rows will be of varying data type (some dates, some numbers). Ability to add dropdowns with specific values would be nice.
Also nice, but not necessary (since we can always use a reverse proxy) would be the ability to control read/write access using LDAP/AD groups.
Another developer on my team suggested Spring/Roo, but that may be too heavyweight for what we're looking to do. There's got to be something simpler out there... Oracle Apex is another option, if we get desperate.
Grails is a great cheap way to build a CRUD app like you're describing, and it integrates cleanly with Java applications. You can probably build your first prototype app in an hour or two to get a feel for it. Here's a decent starter tutorial: https://www.ibm.com/developerworks/java/library/j-grails01158/
Spring Roo is absolutely not an overkill for this task in my opinion. It actually supports database reverse engineering, so you can explicitly specify which tables you want to have a CRUD view for.
You will need a really simple script, something like this:
project --topLevelPackage org.whatever --projectName crud --java 6
persistence setup --provider HIBERNATE --database ORACLE
--> you will need to acquire ojdbc*.jar because it's not available from Maven
--> also you will need to adjust database.properties to suit your needs
database reverse engineer --schema my --includeTables "Table1 .." --package ~.domain
controller all --package ~.web
logging setup --level DEBUG --> OPTIONAL
security setup --> OPTIONAL
exit
That's it, you can run your application.
Just write a simple web application with a few JSP files if that is all that you need to do. You can package them into a WAR file and deploy them easily to either JBoss or Weblogic.
What you want is a java-based Web Framework that gives you automatic Create/Retrieve/Update/Delete (CRUD) screens. There are a huge number of frameworks available, each with different strengths and weaknesses. You don't give enough information to make a reasonable suggestion of which would be best, so I would recommend that you play around with different frameworks until you find the one best suited to your needs.
Spring Roo is one way to try out different frameworks, but I find that it has a lot of typing overhead to build the model you want. If you recorded a script you could perhaps replay it with different frameworks selected for generation, but that may be too complicated.
I would recommend you check out AppFuse, which is a meta-framework that allows you to play with different frameworks easily. See AppFuse QuickStart for information on getting started.
As for controlling access to the tables using LDAP, there are many possibilities available. Java provides direct control as shown here . Another option that many use is Spring Security.
Related
What is the best way to store parameters and data for an EE7 application. I have to provide the web applications with information like a member fee or similar data (which may/can be altered several times in a year). The owner of the application should also have a central place where these data are stored and an application to change them.
Thanks in advance for any input
Franz
This is one question we are currently struggling with as we re-architect some of our back-end systems here, and I do agree with the comment from #JB Nizet that it should be stored on the database, however I will try to add some additional considerations and options to help you make the decision that is right for you. The right option will depend on a few factors though.
If you are delivering source code and automation to build and deploy your software, the configuration can be stored in a source code repository (i.e. as YAML or XML) and bundled with your deployable during the build process. This is a bit archaic but certainly widely adopted practice and works well, for the most part.
If you are delivering deployable binaries, you have a couple of options.
First one is to have a predetermined place in the file system where your application will look for an "override" configuration file (i.e. home directory of the user used to run your application server). This way you can have your binary deployable file completely separate from your configuration, but you will still need to build some sort of automation and version control for that configuration file so that your customer can roll back versions if/when necessary. This can also be one or many configuration files (i.e. separate files for your app server, vs. the application itself).
The option we are contemplating currently is having a configuration database where all of our applications can query for their own configuration. This can either be a very simple or complex solution depending on your particular needs - for us these are internal applications and we manage the entire lifecycles ourselves, but we have a need to have a central repository since we have tens of services and applications running with a good number of common configuration keys, and updating these keys independently can be error prone.
We are looking at a few different solutions, but I would certainly not store the configuration in our main database as: 1) I don't think SQL is best repository for configuration, 2) I believe we can get better performance from NoSQL databases which can be critical if you need to load some of those configuration keys for every request.
MongoDB and CouchDB both come to mind as good candidates for storing the our configuration keys if you need clearly defined hierarchy for you options, whereas Redis or Memcached are great options if you just need a key-value storage for your configuration (faster than document based too). We will also likely build a small app to help up configure and version the configuration and push changes to existing/active servers, but we haven't spec'd out all the requirements for that.
There are also some OSS solutions that may work for you, although some of them add too much complexity for what we are trying to achieve at this point. If you are using springframework, take a look at the Spring Cloud Config Project, it is very interesting and worth looking into.
This is a very interesting discussion and I am very willing to continue it if you have more questions on how to achieve distributed configurations. Food for thought, here are some of my personal must haves and nice to haves for our new configuration architecture design:
Global configuration per environment (dev,staging,prod)
App specific configuration per environment (dev,staging,prod)
Auto-discovery (auto environment selection depending on requestor)
Access control and versioning
Ability to push updates live to different services
Roger,thanks a lot. Do you have an example for the version predetermined place in the file system"predetermined place in the file system"? Does it make sense to use a singleton which reads the configuration file (using Startup annotation) and provides then the configuration data? But this does not support a dynamic solution.kind regards Franz
We have an existing large Java Web Application that is clustered across many servers. We currently store our Word documents within our Oracle/BLOB and would like to move to a CMS solution like Liferay. Ideally we would like to present our users a view of their directory/file within one of the pages of our existing application and implement some workflow on top of Liferay within our application.
I've been reading the Liferay documentation to get a good feel to how best integrate into an existing Liferay/CMS server and from what I can tell the only way is via Portlets and or IFrames. So the integration happens in the GUI of the application.
We were hoping to integrate with Liferay within our Server calling SOAP/REST/JSON calls and then taking the results and displaying it within our application.
Could someone educate me on if this is feasible and if it is where I could get further information regarding this?
Yes, you can integrate just at "view side", but a good choice consists in usign Liferay ServiceBuilder.
It is a well documented Liferay's framework available for any custom portlet you want to write, allowing you to:
- automatically create a ready-to-use persistence layer (db DDL, ORM, cache configuration, transaction ecc...)
- expose local (in the same VM), remote (in the same VM, or by SOAP/REST/JS API/Mobile API) functionalities
You can surely combine both functionalities together, but you are free to use just one of them.
If it was a my choice, I would create a LR service wrapping the call to your external datasource.
In this way it will be able to partecipate in a distributed transaction (simply configuring a distributed transaction manager), to configure access to resource by using LR permissions framework, to be compliant with any kind of LR taglib (as SearchContainer: it should be very useful for showing a list of item)... and everything without the necessity to configure anything.
Several ways for achieving what I said are available... with a simple Google search I immediately fiund this guide.
Hope it helps.
Liferay allows you to write your own custom document store. You will need to implement few interfaces and configure LR to use it. That should do it. You can look at com.liferay.portlet.documentlibrary.store.BaseStore and com.liferay.portlet.documentlibrary.store.DBStore to understand how it can be done.
Thanks
We are about to create a Java standard project which is actually a batch process that executes at console.
Every "batch" uses only select statements on multiple tables from different DBs. But we'll be doing around thousands of selects.
I'm not really familiar with the "whole" of Hibernate but is it worth using it in this situation?
Have you taken a look at Spring Batch:
Spring Batch is a lightweight, comprehensive batch framework designed
to enable the development of robust batch applications vital for the
daily operations of enterprise systems. Spring Batch builds upon the
productivity, POJO-based development approach, and general ease of use
capabilities people have come to know from the Spring Framework, while
making it easy for developers to access and leverage more advanced
enterprise services when necessary.
Not necessary. As your description, your db operation is quite simple, so why not just use jdbc directly or some simple libs such as spring jdbc template (http://docs.spring.io/spring/docs/3.0.x/spring-framework-reference/html/jdbc.html)
There's no need to import a huge dependency like Hibernate in my opinion. The time of learning and configuring Hibernate is uncertain, so why not just focus on the main project requirements and make it simple at the first beginning.
If you will perform select on many different tables and/or need to manipulate the data, so the easiest way is retrieve rows from database as instances of objects i strongly recommend hibernate.
We have a web application that uses Spring/JPA/Hibernate. Currently we are using SolidBase for database change management, which works well in a managed deployment model - however we are now migrating to a non-managed deployment model where users will be able to download the web application. We are building an "Update-Center" type functionality for the web application and are trying to figure out how we should apply database changes.
Ideally, I would like the application to apply any pending database changes at application startup and I would like this to be something that we can code pro grammatically but I don't want to rewrite Hibernate's SchemaExport functionality to do it.
Does anyone have any recommendations, patterns, or best practices on how we can best implement this functionality in to our application?
Is there any update-center application libraries that will solve our problem (I haven't been able to find a single one)?
I discovered this article while researching this
http://www.infoq.com/news/upgrade-frameworks
This led me to this post
http://www.jroller.com/mrdon/entry/transparent_sql_schema_migration_with
Which ultimately led me to rolling my own solution to this problem using Apache DdlUtils and the BeanFactory solution offered in the jroller.com blog post.
This ultimately will be a component that can be dropped in to any application, legacy or new to implement update functionality into a web application. It will use XML to apply database updates and with the use of DDL it means that the package will work against any supported database. The updater will also support updates to filesystem resources and data itself (as opposed to schema)
I do not work for BitRock.
This may not be exactly what you are looking for, but I have used InstallBuilder from Bitrock to manage these types of updates for distributed applications. This is the same installer package that the PostgreSQL team uses. It was pretty straight forward to get this working, with minimal headaches. Especially when compared to other installer programs.
Ok, i wish to know the correct way to build forms in JSF. I have multidatabase app(user can switch databases during runtime, all databases are build on the same scheme) and now i want to build forms for data input.
I tried build functionalities in NetBeans, where i can generate entity classes from database, but, as far as i understood, this way correctly works only in case, i have one database. For my DB connections i use Hibernate. I already completed part, where i can switch between databases.
Maybe, there are some advices, how i can build forms for app? Preferable will be dynamic form build, it can be from XML file. Looking forward for your replies!
If your application is really divided into independent layers (DAO / Service / presentation for example, or MVC if you prefer), then the presentation layer, which is managed by the JSF framework, must not be impacted by the database connection.
You say that every database uses the same structure, so I don't really think that your JSF forms design and structures will be impacted by the database chosen by the user. This parameter will be taken into consideration in the deeper layers of your application, the ones managed by Hibernate in particular.
So to answer your question, I would say that you don't have to care about this specificity when designing your pages with JSF. So use the "default" best practices for JSF developments.
Have a look at how Seam does it with the Seam-gen tool. It will generate the entire application - including forms - from the database. It's based on Freemarker templates.
There is no such thing as "correct way" of building forms. It all depends on the functional requirements and what all is available.
If the forms are purely meant as kind of "database admin tool", then you need to build from the DB to the UI (bottom-up approach).
If the forms are purely meant to give the enduser some functionality (e.g. register form, order form, contact form, etc), then often a top-down approach (build from UI to DB) is preferred.
In your case it's likely the bottom-up approach. You're lucky, there are much more generators/tools for that available (as you probably already have found out). As long as you keep everything abstract, I don't forsee (re)usability and maintainability problems.
However, it is possible to "convert" some XML file to a JSF (XHTML) page with little help of XSL and a Filter.