[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
[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
[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