nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Where is the deployed website on localhost?

huima

I'm pretty much stumped after playing around with WCM bundle and the tutorial.

Preview works, so I have both teh alfresco server and the virtual server running.

However I just canÃƒÂ¤t figure out where the deployed 'LIVE' site should now be?

Alfresco says deployment was succesfull and there are no errors on catalina.out - but I can't see where the site should be now, and how to access it with a browser.

Please give me a pointe to the right direction.

Find more posts tagged with

Comments

kvc

If you are deploying to a local or remote Alfresco server, you are deploying to a new content repository (each sandbox is it's own Subversion repo, just some sandboxes share context via a Clearcase-like view mechanism called layered directories - you can read more about that on our wiki). That content repository is based on the name of your current webproject, appended with the word "live".

If you look in the node browser or in CIFS, you will see this live content repo. You can sync this live repo whether it runs on your same server machine or a remote server machine. In our upcoming 2.2 release (currently BETA), we allow you to specify the URL to your run-time site that is accessible and serving content from this live repo (our preview URLs are special-generated virtualization URLs). You can read more about this on our wiki page on Deployment.

If you are deploying to a remote file-system using our file-system receiver, you'll see all the contents of your staging snapshot on disk in whatever location you specified in your deployment config file. Of course, you'll have to have either an httpd server of some sort that maps an URL to some docroot that corresponds with this deployment target dir in order to actually see your website once deployed (once again, your httpd server and what your run-time URL is up to you).

For dynamic sites, you really need to deploy to both the file-system (deploy your code to a remote file-system, run an ant script to WAR up and deploy into whatever app server you choose) and remote repo (the live store you dynamic pages query and retrieve data from using either web scripts or our remote API). This is nice, because while we manage your entire website or web app, in the run-time, your code runs standalone on whatever app tier you what, and your Alfresco repo (unemcumbered by various authoring activities) runs as a lightweight, embedded repo services content requests from your own web app.

Let me know if more questions. And do take a look at our 2.2 deployment wiki page. Setting up and tracking these types of deployment scenarios is much simply with our new deployment config wizard.

Kevin

huima

Ah, thank you.

I had a problem in my CIFS: mount. Did not realize that I had to mount //localhost/AVM/ … to see the site and all the repositories.

I still have quite a few questions before I get my head around the WCM-concept and how to developer applications or design systems to use it on dynamic sites.

However I assume that it is better to ask them in separate post.

kvc

Simplest way to think about WCM and dynamic sites: your dynamic site (a web app) runs in your production env and it queries and sources data from a run-time content repository (Alfresco). You can run your web app in any app server on any number of servers.

In WCM, we provide a source code control env modeled on Subversion. You put your whole source tree here. You can make changes to code and content and preview them. When you deploy a known good build (a snapshot) you push your code to your remote app servers and your content to your remote repositories. What you call your web app, how you build - everything - is entirely up to you. We act as a production env to development and publish to your run-time. It's open and flexible (and, new in 2.2, also enables in-context preview via remote test servers for non-Java based sites (site we can't virtualize via a servlet engine with specialized virtualization class-loader logic).

Hope that helps a bit.

Kevin

kmadel

In our upcoming 2.2 release (currently BETA), we allow you to specify the URL to your run-time site that is accessible and serving content from this live repo (our preview URLs are special-generated virtualization URLs). You can read more about this on our wiki page on Deployment.

Kevin

I am really interested in this feature for the community edition. Do you know when it may become available for the community edition.