So i have installed Alfresco and have two web applications /alfresco and /share. Whats the difference and purposes of these applications? Can one application exist without the other?
/alfresco
This context points you to the Repository application. It's the "core" app, where the content is effectively stored and where all the magic happens. Back in the old times, it was the one and only application, so that when Alfresco introduced Share, it was the only place where to find a UI for some features. Now, Share is missing just a couple things.
Currently, the idea is that this JSF application should be a kind of Admin only interface, only to be accessed whenever Share is missing something. However, if you really love JSF (really?) you can still opt to use this interface to build your Alfresco implementation.
This application is mainly interesting for its features rather than for its UI: all the connections to external systems, like DB, CIFS or IMAP for example, happen from here.
On a side note, the "original" implementation of Alfresco WCM is built around this application. Anyway, because of several reasons this implementation of WCM is being phased out, with a new implementation built around Share and its concepts (e.g. Sites) that will grow quite a lot soon.
Don't expect new fancy development on this UI.
/share
This is usually intended the main UI for end users. No JSF here (thanks, God!), it's a Spring Surf frontend to Alfresco that focuses on providing a Collaborative environment. Here you will find the concepts of Sites, project/topic focussed containers for content, blogs and wikis.
As all the content is stored via the other application, Share is almost stateless: no DB connection is opened from here, everything is pulled and pushed to /alfresco via Alfresco REST API and CMIS.
As already mentioned, the new WCM is leveraged from here, as well as all the common ECM features of Alfresco such as workflows, versioning, document transformations, ACLs and so on. Plus, document previews and thumbnails, Blogs, Wikis, Data Lists, ...
This is most likely the UI Alfresco will continue to improve, adding all the whistles and bells they can come up with.
Adding some more information on latest version alfresco 5.0b.
Major changes in alfresco 5.0b is that Alfresco web client is removed from alfresco.So there wont be any JSF coding
Repository Architecture is still there, So if you want to deal with core app "/alfresco" is the location which will be used for creating webscript,workflows and other thing.
Conclusion
Share will be only used as frontend application.All core portion will
be on alfresco repository.
Alfresco:
By a developer point of view I would describe "alfresco" as the backend repository that sums up most of the functionality for which we use ACS. The services that share uses are defined in alfresco.
Share:
Share was introduced so that a person with not so much technical knowledge may be able to get as much as possible out of the ECM. If you are new to share you should look into model manager, smart folders and actions.
In 2020, think of /alfresco as the repository part of Alfresco and /share as the user interface. Keep in mind that Share is now deprecated and will be replaced more and more with something called Alfresco Digital Workspace. For now, they have most of the same functionality except that the old Share uses an older Javascript framework, called "Surf" that integrates with a much older version of Spring. The Alfresco Digital Workspace is created using Angular and is a client that can be run from its own WAR.
Related
I've started looking at osgi with the main purpose to achieve the task ahead of me. Basically i would be able to distribute an web based application and build specific features of the whole web app separately in such a way that i can deploy at A my web app with features a,b,c and deploy at B with features a,c,d.
A little like how one can install plugin in joomla. So for example when i want to add a different aspect of the web application, i would build a small war with all the html and its admin section and have this feature admin section available in the main admin panel.
Second question is about Spring DM. most likely i will be using Spring and it seem logical i see what Spring DM has to offer.After downloading Spring DM .1.2.1 i found out that its lib folder contains spring jars for version 2.5.6.SEC01 but i planned on using 3.1.2 so am a little confuse as how everything will play nice together.
Thanks for reading
I've just been doing such an exercise so I can shed some light how you do it without the overhead of Spring. I've made a clear division: all application code is in the browser, all data handling is in the server. With HTML5 the browser has grown up to an impressive, portable, and powerful application environment. One has multiprocessing, messaging, modularity, and amazing visuals. I am using angularjs as the framework in the browser.
Angular works with a central routing table mapping the hash part of the page url to "modules" in Javascript. This makes it very easy to define what modules are part of the application. The server can easily control this part.
On the server side I have bundles that carry the Javascript code, the html fragments and the data handling. I based this on the OSGi Http Server model since it is more flexible. However, I added proper support for static resources in bundles: caching, streaming, ranges, etc.
In the server I used DS and bndtools to develop the bundles. This is an impressive development experience since it works like Smalltalk. You change and it is immediately reflected in the server. Adding bundles, removing bundles, the server keeps on running. Server restarts are rare during development.
The disadvantage is that there are unfortunately very few components that leverage OSGi. Most components, with Spring being the archetypical example, rely heavily on class loading hacks to wire applications from a central point. This is fundamentally not modular. For this reason I had to develop many highly cohesive and uncoupled components that leverage the OSGi service model. Once I get time I will donate them to an open source project.
I'm not sure you need to be considering OSGi, at least not directly, to achieve your state requirements. You said:
Basically i would be able to distribute an web based application and
build specific features of the whole web app separately in such a way
that i can deploy at A my web app with features a,b,c and deploy at B
with features a,c,d.
If these are youre requirements, then you don't actually need to concern yourself with OSGi directly, but rather find a web app framework that supports modular extensions. Which most likely means that the framework itself uses OSGi. I'm not familiar with Spring, but I do know that Struts 2 ( a comparable web app framework ) has an OSGi based plugin meant to achieve your use case.
On the other hand, if your idea is to play with OSGi, then I suggest you pick a lower level task, such as writing a web application framework, rather than a web app itself.
I'm a newcomer to JSF and am still trying to follow examples to learn the basics of how it works, and that has now lead me to begin exploring ICEFaces.
I love the concept behind GWT that you can just write in pure Java and have it compile down to JS and HTML, but I have also heard that ICEFaces offers a lot of things that GWT doesn't.
That led me to start thinking: is there a way to combine the two in a project, and get the best of both worlds? Is it possible to get the AJAX-centricity, rich UIs and underlying capabilities of JSF, but then use GWT to handle all the client-side code generation?
I looked at something called ICEPush which may very well do just this, but without fully understanding the roles both technologies play in MVC web apps I wanted to take a moment and see what the SO community thought of such a hybrid solution.
Having said that, I was wondering if someone could break down - in quasi laymans terms - the intentional difference between these two frameworks, and to give argumentation as to why they can be - or shouldn't be - combined inside the same project.
Essentially I'm looking for an AJAX-friendly, rich UI Java webapp framework that is open source, has an active dev community, and comes loaded decent/good documentation.
Also, not that beggars can be choosers, but I'd appreciate it if answerers don't solicit other solutions besides ICEFaces or GWT. I'm very well aware that these are not the only two webapp frameworks out there, and this question isn't going to convince me to start using either of them; I'm simply interested if their strengths can be combined, or not.
Thanks in advance.
JSF in general makes heavy usage of javascript. JSF or bette the JSF frameworks provide lots of components. The Javascript is generated on the fly.
GWT compiles the Javascript upfront. It provides some components as well. GWT is doing AJAX calls to its interfaces.
I'm not aware of any bridge that allows you to integrate JSF with GWT. So there is no interface and those technologies don't work together.
Both come with good documentation and have an active community.
ICEpush can be used directly with GWT; you can find out more about the integration here:
http://www.icepush.org/product/icepush-GWT.html
ICEpush provides a simple API to "push" notifications to the browser. Essentially, users (or browser windows) are organized into groups. When something interesting happens (such as a new photo uploaded to a photo sharing application) you can invoke a push on the group users.
In the case of the ICEpush GWT integration, you receive a callback into your "Java" code and can respond to the notification (such as, display the new photo). A GWT application can potentially run offline, but that does introduce the risk of application code being subject to offline attack.
In the case of ICEfaces, the ICEpush integration is abstracted away: rather than a "push" to a group, you "render" a group. With ICEfaces you request that all relevant pages be rendered on the server and any necessary page updates are sent to the browser. This makes it particularly easy to add Ajax Push features to an ICEfaces application.
So, the choice is really whether you want to use JSF or GWT. With JSF you have a standard server-side framework that emphasizes pages built from declarative markup. It is the natural successor to JSP application development. With GWT you have a procedural client/server distributed framework that emphasizes events and pages that are built from "Java" objects. It is the natural successor to AWT/Swing on the web. Both are very popular, so it's more a question of the technique you prefer.
I'm working on a project which takes use of several technologies:
Java
JDBC Transaction Isolation Level
Java Service Wrapper
Log4j
Apache Tomcat Webserver
BIRT
Apache Version Numbering System
Apache ANT Build System
SOAP
The software supports well known databases, such as MSSQL, MySQL, Oracle and DB2. The environment is subdivided in modules:
A WebGUI to interact with the database
A service to interact with the database through HTTP (create own forms and get a plain of formatted output of the result)
A service to interact with the database though SOAP
Almost all services are offered in Tomcat via webapps. I'm pretty sure that we don't have the newest versions from those technologies.
But I still wonder, if we could achieve the same with less dependancies. Anything new that could make our productivity more efficient?----
The dependencies you have listed are fairly well-established and standard technologies that all solve different problems.
I don't think you should be trying to reduce the number of dependencies. Any reasonably complicated website will (and should) have this many dependencies, so that they can harness the expertise folks who specialized in each of those areas, and so kindly packed their knowledge into freely available libraries. By all means, use them!
Modern websites are already so complicated that no single person knows how to build one from scratch, the same way nobody knows how to make a pencil.
I have come up with a small project to help me learn Java EE, i'm unsure what technology best suites what I want to achieve however so i'm hoping someone can point me in the right direction.
What is essentially a gloried web crawler should be constantly running somewhere - maybe updating a database or not (the information will become out of date quickly so there might be no need to persist the information).
Clients can then view the up to date information when they log in, i presume a servlet is the best approach for this.
I'm not sure what technology is best for this kind of 'always running service'. I want the information always there regardless of whether a client is viewing it or not.
What approach would you take? While i realise it might not be the best solution using an application server for this, i'm doing this as a fun project for myself to help me learn.
have come up with a small project to help me learn Java EE, i'm unsure what technology best suites what I want to achieve however so i'm hoping someone can point me in the right direction..
Let's try. I'll base my answer on Java EE 6.
Clients can then view the up to date information when they log in, I presume a servlet is the best approach for this.
Or JSF 2.0 and Facelets (Facelets are the default view technology in JSF 2.0 and replace JSP as the view technology for pages)
I'm not sure what technology is best for this kind of 'always running service'. I want the information always there regardless of whether a client is viewing it or not.
It would be probably easier to run this in another VM but you could try with an #Asynchronous bean with EJB 3.1. See the links below.
See also
Part Three: New Features in EJB 3.1
News: Article: New features in EJB 3.1, Part III
TOTD #139: Asynchronous Request Processing using Servlets 3.0 and Java EE 6
TOTD #137: Asynchronous EJB, a light-weight JMS solution – Feature-rich Java EE 6
Ill address each point below:
1) Your concern over storing data in a db or not. The information should be stored in a database as your server will die from not having enough memory to keep everything available freely.
2) When clients log in yes you would want to use a servlet. To be more specific you would want a layer of abstraction between the model and the database. The Controller would speak with the model about its current state than proceed to paint the view (the web page) with the most recent data.
3) I wouldn't necessarily classify this as a service so to speak, but more so a portal of information. An application server is fine for this type of work as it provides a central point for clients to interface with the application.
I need help choosing a CMS product to suit an e-commerce application with some complex unique features. I'm considering using an existing CMS because I don't have the budget to build my own versions of:
copy editor
page layout tools
site map editor (optional)
I'd considered Spring.MVC and JBoss Seam as framework alternatives and JSP/JSTL and Facelets/JSF as view technologies before realising the CMS may drive this choice.
Since there are six customers to start with I was very keen on a multi-tenant architecture with branding applied to each tenants pages.
I see two architectural alternatives:
Build a bespoke multitenant site based directly on a web framework and "pull in" content via JCR.
Deploy a multi-tenant CMS and somehow add the unique functions.
The "unique functions" are an interactive designer to build exactly the product you want. Once built the product is added to your cart and there is then the normal payment and account set-up functions to consider. All still within a multi-tenant situation.
I am quite happy for the content editing functions to sit in a separate web app it would be sufficient for me to operate this on behalf of the six customers, but ideally they would also have access. There is no need for this to be branded at all.
Any suggestions?
If you are planning to develop custom functional requirements on top a cms, then I would recommend liferay portal. It's an open source portal comes with built in cms. It also comes with shopping cart portlets and many more built in portlets and themes. It can provide you a multi tenancy solution with strong user/role based permissioning mechanism. It can integrate with active directory and you can configure single sign on solutions easily. You can develop custom requirements as JSR168 or JSR286 compliant portlets and deploy them to liferay portal. Also you will have options to extend/customise liferay functionalities via hooks and extension environment capabilities.
Take a look at dotCMS, an open source CMS built on top of Liferay. It is a flexible java solution that makes running multiple sites within a single instance easy.
Sites can share content, assets and templates, or not share anything depending on how you set them up.
Users can have access to manage one site or many sites - their views into the management tool are limited by their permissions (as you'd expect).
Again, I am biased, but this is exactly the problem that dotCMS was designed to solve.