The changes seems to be working fine, I have done it on the local system.
Can we put this in the head?
Also I am in process of investigating the deplorers folder of the test suite , it contains some of the sample ears which I feel could be used for preparing the junit test suite .
I may write a separate JUnit test cases class as JBAS2904EARDeploymentUnitTestCase.java.
Would this be ok?
Regards
Vicky
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961012#3961012
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961012
"dimitris(a)jboss.org" wrote : From the top of my head, I'm sure we have plenty of places in the code we create a proxy for a single call, and throw it away. It's a bad practise.
We will have to clean these references during undeployment, or to use SoftReferences testing for Null Object.
I think the JVM doesn't make any internal references to the created proxy, what means the Proxy will released if a GC happens.
On JBoss Serialization, I created a package called PersistentReference that encapsulates such thing. It's really simple.
If we want to cache proxies without having to worry on clearing references later maybe we should implement a similar idea.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961004#3961004
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961004
OK, I knew technically is not a leakage by definition, but in practice, in our tests, everything is pegged because of this.
These proxies are alive during the whole cycle of the test, and released at the end. We have seen OME sometimes also.
Also... Are you sure MBeanProxyExt would avoid a redeployment leakage?
The Class created will have a reference back to the fake classLoader, what will have a reference to the parent classLoader, what would hang the classLoader anyways.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961000#3961000
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961000
Hmmm, interesting.
Could you make a quick try with ehcache-1.2.1? As far as I can judge it based on their release note, there were bugs related disk persistence fixed.
(You just need to replace the JAR in the kosmos-server.war/WEB-INF/lib dir. Then launch the container, force the webapp to load the SVN repo info by opening the portlet, the shot the container and then launch the container, again.)
If you report that it was successful, I will update the trunk code. Thx a lot for your contribution.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3960984#3960984
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3960984
Hi,
I have downloaded Pentaho Portal ver 1.1.7 which uses JBOSS portal server. I would like to deploy some BIRT reports . Is there any documentation on this topic. I have gone through all the tutorials and they just show how to show different portlets on the page. I would like my portlet to show a BIRT -ECLIPSE report.
If anyone has done this or knows how to do it , it would be greatly appreciated.!
Thanks,
Shaleen
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3960977#3960977
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3960977
the thinking behind this was the following:
identity and jpdl are two separate independent sub projects.
it is the suite (previously called the starters-kit) that will combine the two components.
therefor i thought it would be best to remove the dependency that was introduced by adding the identity mappings to the default mappings as they are specified in the jpdl/jar project.
the mappings should be there in comments in the default hibernate configuration file. so that you can create an ant script with some replace tasks that uncomments the identity mappings.
does this make sense ?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3960955#3960955
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3960955
this is a tricky one.
currently, the cancel method indeed includes the call to end() on purpose. the desired behaviour in case one fo the task instances is cancelled depends on the process. it cannot be defined in a general manner.
in the current code, it would be the most logical to add the .cancel(Transition trans) and .cancel(String transName) methods
apart from that i have been thinking about abstracting the state machine inside of a task instance. states being: created, started, cancelled, suspended, and others are thinkable. i'm in doubt wether this justifies it's own statemachine (could be implemented in jpdl:-) or wether this just be a hard coded state machine.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3960949#3960949
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3960949