October 2006 - jboss-dev-forums - Jboss List Archives

[Other JBoss Development Design] - Re: run.sh to launch JBoss in background

by scott.stark＠jboss.org

I guess I would ask why even keep the loop. As far as I know its useless as when does an exit code of 10 show up? Certainly no problem with this change, but why not make the only change whether or not the command in run in the background? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976393#3976393 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976393

19 years, 6 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Dashboard & Personalization proposal

by julien＠jboss.com

"roy.russo(a)jboss.com" wrote : I need for page information to exposed so the nav portlet can read it. For example, I need to know all private pages a user "owns" and render their names/ids in the tabs. It will be a portal object as usual. The user context (the object under user:xyz) will be probably an instance of Portal, or at least smth extending PageContainer that allows to manipulate pages, so it is pretty much similar to what we have today. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976391#3976391 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976391

19 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Re: PojoCache physical POJO field mapping and region

by genman

Why couldn't you create a node wrapper and hang your meta data from it? | class DelegatingNode implements Node { | Node delegate; | ... | } | | class PojoNode extends DelegatingNode { | Object secretData; | } | Or... There's a couple of internal cache fields, such as TreeCache.UNINITALIZED, etc. Rather than be strings, perhaps they could be typed using an interface and hidden from the user. Maybe create a partitioning map wrapper that delegates to the ConcurrentHashMap or whatever, and has "secret" storage for internal data. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976388#3976388 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976388

19 years, 6 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Dashboard & Personalization proposal

by roy.russo＠jboss.com

I need for page information to exposed so the nav portlet can read it. For example, I need to know all private pages a user "owns" and render their names/ids in the tabs. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976387#3976387 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976387

19 years, 6 months

1
0
0 / 0

[Other JBoss Development Design] - run.sh to launch JBoss in background

by mazz＠jboss.com

I want to write an init.d script with the typical start - stop options to start JBossAS. I want to use the method of writing a pid file when started and killing the pid found in the file when stopping. I do not want to use the "normal" shutdown mechanism to stop it because that assumes the JBoss instance has exposed its remote MBean interface (and I do not want to assume that). Plus, I want to ensure it is killed, and using the "kill" command is as fool-proof as I need it to be. I also want to be able to use run.sh to start the instance (I do not want to have to do all the work run.sh does - setting up the JVM, passing in arguments, worrying about all the cygwin - darwin things, etc. etc.). But, if my init.d script starts run.sh, I cannot use $! in my init.d script as the pid file contents because $! is the pid of run.sh script process. It is NOT the pid of the JBoss JVM instance itself. If I then go to kill the run.sh process, it dies, but the JVM process does not. Therefore, the init.d stop option does not work - it cannot stop the JBoss VM. I would like to propose to make the following change to run.sh that would facilitate this. This change is backwards compatible. What this change does is - if I set the environment variable "LAUNCH_JBOSS_IN_BACKGROUND" and source run.sh, run.sh will export JBOSS_PID as the pid value of the JVM process. My init.d script (the thing that sources run.sh) will be able to write JBOSS_PID anywhere I want and thus later be able to use it to kill the JBoss VM. Here is the change I propose (it only changes the bottom - I wrap the existing loop in an if-statement with the else clause running the VM in background): | if [ "x$LAUNCH_JBOSS_IN_BACKGROUND" = "x" ]; then | ### START - BELOW IS WHAT ALREADY EXISTS IN run.sh | STATUS=10 | while [ $STATUS -eq 10 ] | do | # Execute the JVM | "$JAVA" $JAVA_OPTS \ | -Djava.endorsed.dirs="$JBOSS_ENDORSED_DIRS" \ | -classpath "$JBOSS_CLASSPATH" \ | org.jboss.Main "$@" | STATUS=$? | # if it doesn't work, you may want to take a look at this: | # http://developer.java.sun.com/developer/bugParade/bugs/4465334.html | done | ### END - ABOVE IS WHAT ALREADY EXISTS IN run.sh | else | "$JAVA" $JAVA_OPTS \ | -Djava.endorsed.dirs="$JBOSS_ENDORSED_DIRS" \ | -classpath "$JBOSS_CLASSPATH" \ | org.jboss.Main "$@" & | JBOSS_PID=$! | export JBOSS_PID | fi | Its important to note that if you use this LAUNCH_JBOSS_IN_BACKGROUND feature, you have to "source" run.sh (you can't execute it from your init.d process because environment variables do not export up to a parent process - you have to ". run.sh" in order to get that exported environment variable into the shell that sourced run.sh). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976386#3976386 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976386

19 years, 6 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Dashboard & Personalization proposal

by julien＠jboss.com

for the portal object stuff, you can consider the namespacing to distinguish between the different scopes and lifecycle of the contained object trees. - for webapp, lifecycle is the .war file deployment - for shared, it is specified by the administrator - for dashboard it is the user context View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976385#3976385 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976385

19 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Pass event type to EvictionPolicy.canIgnoreEvents

by bstansberry＠jboss.com

When we moved to EvictionInterceptor from a TreeCacheListener-based approach, one thing we lost is the ability for custom policies to prevent certain kinds of events going into the eviction queue. For example, a customer wants to prevent node modifications and visits from going in the queue as they are far too numerous for his app; he just wants adds (and maybe removes) so he can evict solely based on maxNodeAge. Currently the only hook we provide to prevent an event going into the queue is EvictionPolicy.canIgnoreEvent(Fqn). But, when this call is made, we know the event type and even have a bunch of int constants identifying the valid types. So, for 2.0 I propose 1) create a proper JDK5 Enum of the event types, and 2) change the EvictionPolicy interface to: boolean canIgnoreEvent(Fqn fqn, NodeEventType eventType) The existing policies would just ignore the second parameter. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976378#3976378 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976378

19 years, 6 months

1
0
0 / 0

[Design of JBoss Portal] - Dashboard & Personalization proposal

by julien＠jboss.com

Up to 2.4 versions JBoss Portal focused on shared objects, such as shared pages and portlet instances. Note that it does not mean that users are not able to personalize one instance of a portlet, it means that there is a one to one state relationship between a user and an instance. For example, the administrator creates and configures an instance XYZ of a portlet, then any (authenticated) user is able to use that portlet instance and further customize it. ---Portlets, instances and customizations The main use case we want to add is to give the possibility to users to create private pages (dashboard) and multiple customizations of pre-configured portlets. The minimum requirements are : - the portal can create on behalf of the user as many customization as they need - the portal needs to keep as minimal as possible the number of customizations - the portal keep tracks of the customizations in order to facilitate the management of the lifecycle of the state - the portal provide private pages Instance container modifications: - instead of making it implicit that a user has a customized version of an instance, make it explicit. It allows to not restrict the customization id to only the user id. The customization id can be assembled by the portal to combine the user id and any contextual information like a page id or a window id. - make the distinction between two kinds of instances which are shared and non shared (thus using the explicit customization id) - add new security permissions | // An instance of a portlet | public interface Instance | { | String getId(); | Portlet getPortlet(); | void setProperties(PropertyChange[] changes); | PropertyMap getProperties(); | void invoke(PortletInvocation invocation) | ... | } | | // A shared instance that defines a scope under which customizations can be created | public interface InstanceDefinition extends Instance | { | InstanceCustomization getCustomization(String customizationId); | } | | // An instance customized and referenced by its customization id | public interface InstanceCustomization extends Instance | { | InstanceDefinition getDefinition(); | } | The getCustomization(String customizationId) returns a lazy customization which means that no persistent state is created until the instance gets really customized. When state creation occurs on the producer side it triggers the insertion on the consumer side. examples of usage : 1. in a shared page | String instanceId = window.getInstanceRef(); // We have a shared page, get the instance definition | InstanceDefinition instanceDef = instanceContainer.getInstanceDefinition(instanceId); | Instance instance = null; | if (userId != null) | { | instance = intanceDef.getCustomization(userId); | } | else | { | instance = instanceDef; | } | 2. on a private page it is the same scenario except that the user id is an assembly of contextual information with the proper encoding | String userId = userId + "." + window.getId(); | InstanceDefinition and InstanceCustomization have a relationship in order to keep track of all customizations for a given definitions, they also have the same life cycle. When an instance is destroyed then all the customizations are in order to cleanup resources properly. In the future we will add time based expirations when our framework will support that WSRP 2.0 feature. ---Dashboard The dashboard is a private page for a specific user. At the moment we have the concept of a shared persistent tree. Dashboarding can be added by namespacing conveniently object trees (à la JNDI). examples of usage : 1. default.default points to the default page of the default portal in the default namespace which is the shared namespace 2. user:xyz.default points to the default page of the user xyz 3. webapp:foo.default.default points to the default page of the default portal of portal defined in -object.xml of foo.war Portal object modifications: - add a namespace to make the clean distinction between intended usage of objects - update the war file -object.xml mechanism to store the data tree in a specific storage (in memory) based on the web application - add new URL mappings to expose objects in a friendly manner - update security permissions - add copy / move operations between namespaces View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976377#3976377 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976377

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: AbstractDeploymentUnit.getMetaDataFiles()

by scott.stark＠jboss.org

A JarEntryHandler cannot represent a filesystem directory. An unpacked archive should be handled by the file context implementation rather than the jar context implementation. Something must be getting confused. Can you update one of the org.jboss.test.virtual.test.* tests in the mc container project to illustrate the problem? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976367#3976367 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976367

19 years, 6 months

1
0
0 / 0

[Design of JBoss Collaboration Server] - Re: MailListener api

by mikezzz

The Mail Server APIs have grown a bit organically over time and Message Interface could do with some work. The simplest solution would probably be to add relevant method signatures from the Mail class, to the Message interface. Patches are welcome... Mike. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976361#3976361 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976361

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 October 2006