July 2008 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Portal] - Re: Portlet Instance configuration with nice GUI

by julien＠jboss.com

Actually it is a good idea. There is a special mode called EDIT_DEFAULT as far as I recall that is used to edit the preferences shared by all users of a portlet and that is more appropriate than EDIT mode. It is possible to check if the portlet supports it by reading the mode declared by the portlet. Edition could be done using the JSF portlet component that is already used in the same application in order to display the EDIT_DEFAULT mode instead of the generic configurator if the portlets supports it. Thomas, what do you think ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163992#4163992 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163992

17 years, 9 months

1
0
0 / 0

[Design of JBoss Portal] - Portlet Instance configuration with nice GUI

by michaelchan

For portlet preferences at instance level, we could use the admin portlet to change the preferences. However, there is no custom GUI available, this creates a huge drawback because the preferences data are of a raw type. For example, if a "Category" portlet displays some products in a Category that is identified by a catID, and the catID is in portlet preferences, system admin MUST work out the catID in order to change the category to be displayed on the "Category" portlet. I know we could use EDIT mode to provide a nice GUI, but the preferences are not stored at an instance level, it is stored on a per user / per instance level. Is there anyway to overcome this? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163971#4163971 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163971

17 years, 9 months

1
0
0 / 0

[Design of POJO Server] - Re: [JBAS-5589] What to do with org.jboss.hibernate.cache.De

by pferraro

Gone! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163969#4163969 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163969

17 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: BeanMetaDataBuilder and deprecated KernelDeployment.setB

by alesj

I've added this two methods: | /** | * Get bean factory from underlying bean meta data. | * | * Note: this one includes all nested beans from | * underlying bean metadata. | * | * @return bean meta data factory | */ | public abstract BeanMetaDataFactory getBeanMetaDataFactory(); | | /** | * Get underlying bean as BeanMetaDataFactory. | * | * Note: this method doesn't include nested beans from | * underlying bean metadata. | * | * @return bean meta data factory | */ | public BeanMetaDataFactory asBeanMetaDataFactory() | { | return new BeanMetaDataFactory() | { | public List<BeanMetaData> getBeans() | { | return Collections.singletonList(getBeanMetaData()); | } | }; | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163960#4163960 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163960

17 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - BeanMetaDataBuilder and deprecated KernelDeployment.setBeans

by scott.stark＠jboss.org

There is a bit of a mismatch with the migration to the BeanMetaDataFactory as the preferred KernelDeployment approach to describing the beans in the deployment and BeanMetaDataBuilder only providing access to a BeanMetaData instance. One either has to test whether the resulting BeanMetaData is a BeanMetaDataFactory (and for the default BeanMetaDataBuilder which returns an AbstractBeanMetaData it is), or use the deprecated KernelDeployment.setBeans. Can we add a way to get hold of a BeanMetaDataFactory from the BeanMetaDataBuilder to avoid this? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163953#4163953 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163953

17 years, 9 months

1
0
0 / 0

[Design of POJO Server] - Re: [JBAS-5589] What to do with org.jboss.hibernate.cache.De

by bstansberry＠jboss.com

Going once... going twice... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163944#4163944 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163944

17 years, 9 months

1
0
0 / 0

[Design of POJO Server] - Re: Is profile-service.xml misnamed?

by scott.stark＠jboss.org

"PeterJ" wrote : Ales hinted that he doesn't have enough to do and that I should post this here. ;-) | | Are there any plans to provide a system property that can be used to decide whether to use bootstrap.xml or boostrap-repo.xml? Right now bootstrap.xml is hard-coded and I had to rename the files to use bootstrap-repo.xml. (Also, is it expected that when using boostrap-repo.xml that hot deployment does not work?) | Yes, we should have something, http://jira.jboss.org/jira/browse/JBAS-5760. Note that there already is a ServerConfig.BOOTSTRAP_URL = jboss.bootstrap.url that should be used. "PeterJ" wrote : | On a related note, why is profile-service.xml not called simply profile.xml? The extension -service.xml is usually associated with JMX, but in this case the file is used with the microcontainer. I know that file naming conventions (e.g., *-service.xml) apply only in the deploy directory, and not in conf, but it can be initially confusing. | Fair enough. The conventions apply to any deployments processed by the deployers, so its the deployers, deploy directories. We might as well be consistent in naming conventions. http://jira.jboss.org/jira/browse/JBAS-5761 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163941#4163941 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163941

17 years, 9 months

1
0
0 / 0

[Design of JBossCache] - Re: Custom data versions

by bstansberry＠jboss.com

Understood. OK, all other 2nd level caching gurus, time to speak up or forever hold your peace! ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163940#4163940 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163940

17 years, 9 months

1
0
0 / 0

[Design of POJO Server] - Re: Scoping of war/jar file embedded in sar service archives

by adinn

anonymous wrote : | At this point I just want to reproduce the issue in a unit test. If I can't tweak my current example I'll need to get your deployment to see what exactly is happening. | Ok, well I think you should be able to reproduce the behaviour I saw if you modify the example you cited earlier as follows: add a manifest file to staticarray-web1.war which refers to staticarray1.jar via a classpath entry add a manifest file to staticarray-web2.war which refers to staticarray2.jar via a classpath entry add a manifest file to staticarray2.jar which mentions staticarray1.jar via a classpath entry it may be possible to do it with a shorter route add a manifest file to staticarray-web1.war which refers to staticarray1.jar via a classpath entry add a manifest file to staticarray-web2.war which refers to staticarray2.jar and staticarray1.jar via a classpath entry if this fails to err . . . fail . . . and you need my code let me know View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163938#4163938 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163938

17 years, 9 months

1
0
0 / 0

[Design of JBossCache] - Re: Custom data versions

by manik.surtani＠jboss.com

Yup that pretty much sums it up. Concurrent updates will be dealt with exactly as they are dealt with right now. Regarding releasing, it is easier than you think: DataVersions were a strictly Optimistic-Locking feature. With MVCC, we never made any promises that DataVersions would apply. Just as we ignore custom data versions with Pessimistic Locking, I expect to do the same with MVCC. The problem with leaving versioning logic in MVCC is that it is pretty central. (Use VersionedNode instead of UnversionedNode, different write-skew check, different ways of handing custom data versions which may be unnecessary). I'd rather we leave this out (if the logic makes sense) and move on from a fragile and broken API. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163933#4163933 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163933

17 years, 9 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 July 2008