[Design of JBoss Portal] - WANTED: Input from administrators & developers
by thomas.heute@jboss.com
As part of our plans to improve on JBoss Portal administration, we would like to hear about your needs.
This is your chance to define the required features and prioritize our work at this early stage.
There are two main fields:
Metrics and provisioning. For infrastructure reasons, we will start by implementing the metrics part.
Metrics can be monitored and trigger alarms while provisioning help you manage your JBoss Portal instance.
Here is a list of things that i can think of:
Metrics:
- Availability: One need to know remotely if the portal is running fine. It means that all related services are up and running (CMS service if used, Database...)
- Size of the database tables/ Maximum size allowed -> trigger alarm when the table size is reaching the max
- Number of database hits per time unity
- Time to render portlets (min, max, average) -> Help figure out which portlets are slowing down the page rendering
- Time to render a page (min max, average)
- Consumed instances (WSRP)
- Produced instances (WSRP)
- Number of users
- Number of roles
- CMS availability
- CMS number of documents
- Min/Max/Time to get a content from the CMS
- Invalidate CMS cache (on a cluster)
- CMS cache utilization (on a cluster)
- List available portlets
Provisioning:
- Change datasource (copy data over)
- Pages definition export from database to XML (-objects.xml, -instances.xml)
- Migration from JBoss portal version to the other
- Secure a window/a page/a portal
- Invalidate portlet cache
Now this is open to discussion to add/remove/modify features from this list.
As most of you are probably developers, if you are working on a major project using portal please ping your administrators to get their input on what they will want/need to efficiently administrate and monitor JBoss Portal.
Thanks in advance !
Thomas.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971890#3971890
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971890
19 years, 6 months
[Design of JBoss/Tomcat Integration] - Re: Session Persistance
by mpunhani
Did you find a solution to this problem..I'm running into same problem with similar configuration. Error message is same as yours:
"The database connection is null or was found to be closed. Trying to re-open it"
and then it comes back with a NullPointerException.
Thanks
-Mukesh
"susantpatnaik" wrote : Hi All,
| i m again here.
| i m trying this configuration using mysql as database.
| i m gettting this message in JbossApp.Server while starting Application server and i m using jboss4.0.3sp1.
|
| | [[/test]] The database connection is null or was found to be closed. Trying to re-open it
| |
| but when ever i m shutting down application server it stores the session into database, and another problem i m facing is i m not getting all web application's session persistance.What could be the reason if any body will reply it will be highly Appriciatable.
|
|
| Many Thanks,
| Susanta Patnayak
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971848#3971848
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971848
19 years, 6 months
[Design of JBoss Remoting, Unified Invokers] - Wire Versioning at the Application-level Needed
by joe.marques@jboss.com
I feel that wire versioning IS a very important feature, because if people are using JBoss Remoting as the framework on which they are building distributed applications, then it will be of the utmost importance for many to be able to upgrade one node at a time to ensure zero downtime when upgrading the entire enterprise.
However, I think that only solves half of the problem. Wire versioning in 2.0.0 only addresses the infrastructure, but there will still be issues at the application-level. More precisely, regardless of whether the cooperating nodes' remoting capabilities can be upgraded independently, if the application code running on top of that infrastructure can't be updated in a similar "rolling" fashion, then much of the potential utility for wire versioning is being restrained.
That being said, let's take a look at some of the use cases this application level scheme needs to handle.
Essentially, if I have two participants sending and receiving the following definition for Person:
public class Person
| {
| private String name; // version 1 only has a name
|
| // appropriate getters/setters
| }
And one of the participants gets upgraded with a new definition, say:
public class Person
| {
| private String name;
| private int age; // version 2 also has age
|
| // appropriate getters/setters
| }
Then there needs to be a mechanism to handle the graceful conversion of this one class definition to the other, so that enterprises can upgrade each node's definition in a "rolling" fashion.
The semantics of specifically what happens should perhaps be flexible within each remoting node's configuration, but somethings need to be defined that will intercept the call and handle the graceful transformation.
For instance, mabye extra attributes from an inconsistent class definition are simply dropped. In the reverse scenario, missing attributes might get simply get type-defined default values.
This example assumed that the change in the newest version of the class was a simple addition. What happens in more complex cases? Let?s say from v2 to v3, Person had changes that looked like:
public class Person
| {
| private String fullName; // refactor name to fullName
| private Date birthday; // change age type: int->Date
|
| // appropriate getters/setters
| }
Is it possible to design this application-level wire versioning in a way so that it executes a translation when the object is being deserialized / unmarshalled on the receiving end, so that I can transform names into fullNames (and vice versa), and birthdates into ages and ages into (albeit not perfectly accurate) birthdates?
I'm thinking a solution might have to use something other than Java serialization because by default there would be serialization exceptions all over the place unless the exact same class definition existed on both ends. But maybe I'm mistaken here? Maybe someone knows some clever trick that we could use to implement this indirectly using Java serialization, such as pushing out some metadata in front of each serialized attribute, and inspecting that metadata on the receiving end by the intercepting transformer?
Another approach that might was something I saw while reading through the source code for some of the unmarshallers. It appears it's possible to use a remote classloader to instantiate the serialized object when the class definition doesn't exist on the receiving end. So maybe this could be adapted slightly to instantiate the object when the class definitions differ, and then use some clever tricks with reflection to "copy and paste" the data from the remote object type to the local one (e.g. something along the lines of local.setAttr(remote.getAttr)).
Keep in mind that an overarching concern here is performance. So, I want to keep that consideration clearly on the table as possible implementation strategies for this are discussed further.
-joseph
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971837#3971837
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971837
19 years, 6 months
[Design of JBoss Collaboration Server] - Re: Help, can not send email to hotmail.com?
by gohip@ichibancomputers.com
it sounds like your DNS is screwed up, or your network connection, it doesnt look like your even connecting to it at all
you should see, as you did with the other test emails you sent, a section of output, where the two servers are communicating the data. hot mails bad, it's feisty when it comes to junk mail, but not that feisty, you might try capturing your network packets, and see whats going on
are those two other .com's within your org, or outside it, i.e. are you just having trouble connecting to mail servers outside the organization?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971798#3971798
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971798
19 years, 6 months