September 2006 - jboss-dev-forums

[Design of JBoss Portal] - Re: Virtual hosts and multiple portal server instances

by sverker

Moving a mail conversation with Julien back to the forum... anonymous wrote : Hi Sverker, | | I found good ideas in your patch, however there are things that | prevent it to be integrated as is : it requires too many | modifications in the codebase that make jboss portal depend on that | solution. | | What raise issues : | | 1/ retrieving metadata from the war file about the virtual host : | this is simply not portable and jboss portal is going to migrate to | environment agnosticity | 2/ modifications of the portal object tables (context path addition) : | 2.1/ make the solution depend on the environement (the fact that | there are context paths). | 2.2/ will require an extra migration step from users. | | I hope you can understand that. | | I think we should take our time and discuss now how we can better | integrate your idea while remaining compatible with the main | objectives of the portal (i.e not depend on a particular | customization) as I think that it is a good feature for the project. | All of this for the 2.6 timeframe. | Hi Julien, the purpose of those patches was not that they were a complete solution but to form examples of how to solve this isse and to get the discussion started. To answer on your specific remarks below: 1. There are no standard way how the containers handle virtual host configuration. However, there are several other things that are not standardized neither, e.g. how deployments are handled etc, or even if they are standardized not all containers follow that. I believe that most likely you'll need to have some code specific for each container/application server that you want to support, you are currently tied to jboss/tomcat and it wouldn't be possible to deploy on jboss/jetty without additional adapter code. To retrieve virtual-host information could be part of that container-specific code. Another approach could be to specify virtual-host as part of the *-object.xml file. While it's completely portable I find it a bit cumbersome to have to specify that information when it's already avalible in the container. Maybe the right approach is to use both, if the information can be retreived from container then use it otherwise use context information specified in *-object.xml file. 2. A major problem with JBoss Portal today is that it is an application and not an infrastructure component as it should be. It works fine for a single purpose such as e.g. the JBoss site where you have a number of sub-portals forming one site, but I can't use it for deploying a number of arbitrary portals. There are several reasons for that, one is the issue that we are discussing that virtual-host is not supported, another is that all portals run in the same security domain which is not generic, yet another (minor issue) is that you throw in a default portal which should instead be part of the portal-samples.war etc. Forturnatly it turned out to be quite easy to extend the model slightly to contain virtual-host/context-path information which is neccesary to be able to map a request to the correct portal. The reason why I see that it should be bound to context instead of a portal is because of isolation, the portal container needs to be able to isolate portals which does not belong together while it still must be possible to build a site made of sub-portals like jboss.org. Just as the EJB container isolates two ear-files rom eachothers context, so must the portal contaier be able to do. Another example is how a servlet container provides separate contexts and isolation for different war files. A benefit with this approach is that it gives the flexibility to both be able to have isolation between portals and to not have it (which is how it currently works). 2.1 I'm not sure I understand what you mean there. A web application always is bound to a context path, which is / for the root. It is either derived from the war name or specified in a jboss-web.xml (or application.xml of a enclosing ear). 2.2 What migration? The only thing needed is to create the table CONTEXT_PATH. Previous portals will continue to work just as before as they deploy to the default context and no old persisted data needs to be converted. That is btw something I consider a bit aqward in the current implementation, that you persist data from the deployments, which by nature is transient (which I assume is why you created the TransientPortalObjectContainer). The current implementation doesn't clean up neither so if I undeploy a portal component it's still in the ObjectNode tree. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973122#3973122 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973122

19 years, 6 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: does optimistic locking always work ?

by alex.guizar＠jboss.com

Hibernate does offer a way to load an object for update: Session.load(class, id, LockMode.UPGRADE) This is certainly not optmistic control but pessimistic locking. Tom's solution should do the trick for databases where optimistic control is the only viable approach (e.g. Hypersonic). My alternative aims at environments where optimistic control is unfavorable due to high probability of concurrent updates. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973111#3973111 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973111

19 years, 6 months

1
0
0 / 0

[Design of JBoss Admin Console] - Re: JBoss Admin console 1.1 snapshot

by charles.crouch＠jboss.com

Apologies, don't know where I got that URL from. https://svn.jboss.org/repos/jbossas/trunk/ is where you want to get stuff from and https://svn.jboss.org/repos/jbossas/tags/ is where the snapshot should go. Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973108#3973108 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973108

19 years, 6 months

1
0
0 / 0

[Design of JBossXB] - Re: java.lang.NoSuchMethodError: org.apache.xerces.impl.xs.X

by alex.loubyansky＠jboss.com

You are on the wrong forum. Try using the Xerces version from the 4.0.3. If it doesn't help, please, post to an appropriate user forum. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973098#3973098 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973098

19 years, 6 months

1
0
0 / 0

[Design of JBoss Admin Console] - Re: JBoss Admin console 1.1 snapshot

by chilin

anonymous wrote : Checkout svn.jboss.org/repos/common/trunk... Shouldn't it be from svn.jboss.org/repos/jbossas/trunk? I tried svn.jboss.org/repos/common/trunk, but it doesn't exist... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973097#3973097 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973097

19 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Re: SingletonStoreCacheLoader in 2.0

by galder.zamarreno＠jboss.com

Chill mate! :-), I just realised this on a flight back to Switzerland and I still haven't had the chance to sit down and look at the ramifications and extra possible benefits. This thread was intended to pitch the idea and get some feedback. The original thought, and therefore the main reason, was that both cache loaders share the same aspect which is, delegating the work on another cache loader as I already pointed out. The second point, and the one I found after realising the first one, regarding isCustomCacheLoaderConfigured() was just an example of the benefits. I haven't looked at this method in detail yet. I will indeed look at the exact similarities between the two and see which aspects can be abstracted to this upper layer. Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973095#3973095 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973095

19 years, 6 months

1
0
0 / 0

[Design of JBossXB] - Re: java.lang.NoSuchMethodError: org.apache.xerces.impl.xs.X

by mpipes

This problem seems to be fixed in 4.03. Any suggestion on how to get this to work in 4.0.1sp1. ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973094#3973094 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973094

19 years, 6 months

1
0
0 / 0

[Design of JBoss Admin Console] - JBoss Admin console 1.1 snapshot

by charles.crouch＠jboss.com

Now that we?ve come to a relatively stable place with respect to the current feature set I think it makes sense to tag trunk for a 1_1 version of the Admin Console. Following the versioning protocol (http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossProductVersioning) this will be a snapshot release since it will depend on the current trunk code. Peter/Chi, could one of you look at the following: -Checkout svn.jboss.org/repos/common/trunk, noting the revision number when you checkout. -Check everything is ship-shape and all expected tests are passing. -Tag the /trunk, i.e. svn copy -r XXXXX https://svn.jboss.org/repos/common/trunk https://svn.jboss.org/repos/common/tags/JBossAdminConsole_1_1_SNAPSHOT -m "Tagging a 1.1 snapshot release of the 'admin-console' project." Replacing XXXXX with the revision number from 1). Once we?ve got a tag we can see about releasing a binary. Cheers View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973092#3973092 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973092

19 years, 6 months

1
0
0 / 0

[Design of JBoss Admin Console] - Re: JBossMQ vs JBoss Messaging

by charles.crouch＠jboss.com

"scott.stark(a)jboss.org" wrote : JBoss Messaging will be the default in jboss5 Understood. Given there is currently no JMS provider in the default config in /trunk I was just talking about reinstating JBossMQ temporarily. Peter/Chi: If you can test the admin console with the 'all' configuration from /trunk sufficiently that we can tag it, then I'm fine with leaving everything as is. Once we've got a tag, we can look at the work needed to migrate to JBoss Messaging. Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973091#3973091 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973091

19 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Re: SingletonStoreCacheLoader in 2.0

by vblagojevic＠jboss.com

Whoever wrote CacheLoaderInterceptor.isCustomCacheLoaderConfigured() is a very creative person ! IMO you have to come up with more good reasons why you would do what you propose other than improving already a nicely written method:) Are you almost done SingletonStoreCacheLoader? Why not create AbstractDelegatingCacheloader class that combines things that are common to all future delegating cacheloaders. One of them is getCacheLoader method but I would implement all cacheloader methods in AbstractDelegatingCacheloader with delegates. Subclasses then just have to override specific methods. For example, I am looking at AsyncCacheLoader and it needs to override only half a dozen methods. What do you think? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973089#3973089 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973089

19 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums September 2006