[JBoss AOP Development] New message: "Re: ClassPool Refactoring"
by Kabir Khan
User development,
A new message was posted in the thread "ClassPool Refactoring":
http://community.jboss.org/message/522340#522340
Author : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com
Message:
--------------------------------------------------------------
> mailto:flavia.rainone@jboss.com wrote:
> - why is it that calling get on the default domain returns a different version of the same class? This needs further investigation because it is clearly a bug
Yes, this definitely needs fixing. But I thought we had tests for this already? e.g. this from SimpleDelegatingClassPoolTestCase. I added a few extra checks as indicated to make double sure
public void testOnePoolPerClassLoadedByA() throws Exception
{
ClassPoolDomain domain = createClassPoolDomain("SIMPLE", null, false);
ClassPool poolA = createDelegatingClassPool(domain, JAR_A_URL);
ClassPool poolB = createDelegatingClassPool(domain, JAR_B_URL);
//The first time we access the pool it will create the classes, second time will use the cache
accessOnePoolPerClassLoadedByA(poolA, poolB);
accessOnePoolPerClassLoadedByA(poolA, poolB);
}
private void accessOnePoolPerClassLoadedByA(ClassPool poolA, ClassPool poolB) throws Exception
{
CtClass a = poolA.get(CLASS_A);
assertEquals(a, poolA.get(CLASS_A));
assertEquals(a, poolB.get(CLASS_A));
CtClass b = poolA.get(CLASS_B);
assertEquals(b, poolA.get(CLASS_B));
assertEquals(b, poolB.get(CLASS_B));
assertNotSame(a.getClassPool(), b.getClassPool());
assertEquals(poolA, a.getClassPool());
assertEquals(poolB, b.getClassPool());
}
> mailto:flavia.rainone@jboss.com wrote:
>
> - why wasn't the classes cache being used by BaseClassPool.get before? Any reason for this? This has been copied from previous versions, I think that it definetly causes some overhead (the above should work, but it would be faster if the classpool finds out it has already created the class and returns the same class instead of delegating to the domain first).
I can't see anything in BaseClassPool.get() or get0() regarding this? I think you mean DelegatingClassPool.get0()? I don't see the ClassPool.classes cache being used there either, so maybe I am looking in the wrong place. If I am in the right place, it might be an idea to try to load it locally in the initiating classpool first before hitting the domain if the cachedLookups == null.
//TODO KABIR was synchronized - I don't see why apart from that the standard javassist.ClassPool implementation was synchronized?
public final CtClass get0(String classname, boolean useCache) throws NotFoundException
{
//KABIR Made final just to make sure that cached lookups are only handled in one place.
if (cachedLookups != null)
{
CtClass cachedLookup = cachedLookups.get(classname, domain.getModCount());
if (cachedLookup != null)
{
logger.trace(classname + " was found in the cache of " + this);
return cachedLookup;
}
}
else
{
CtClass cached = getCachedLocally(classname);
if (cached != null)
return cached;
}
...
}
> mailto:flavia.rainone@jboss.com wrote:
> - if the cache starts being used as a first step of BaseClassPool.get, as it is in my local fix (not committed yet), is there need for a second level cache as Kabir wrote?
Yes. It caches all CtClasses looked up by that classpool, and they might come from any classpool in the domain. The cacheLookups of all the classpools in the domain are invalidated when a classpool is added/removed to the domain or its parent domain. Basically, it means that if we look something up in a classpool, we don't need to do all the work in the domain.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/522340#522340
16 years, 2 months
[JBoss Portal Development] New message: "[portlet container] actionURL generated too long because of large render parameter?"
by Chen Wang
User development,
A new message was posted in the thread "[portlet container] actionURL generated too long because of large render parameter?":
http://community.jboss.org/message/522334#522334
Author : Chen Wang
Profile : http://community.jboss.org/people/chenwang
Message:
--------------------------------------------------------------
Hello,
As I mentioned in my earlier posts in this form I'm in the process of developing an in-house portal on top of gatein portlet container. So far I've been very pleased with the container but running some user acceptance tests revealed one particular problem around portlet actionurl generation when there are large render parameter put into ActionResponse in processAction stage. The action url generated by calling RenderResponse.createActionUrl() in doView stage is too long, sometimes the browser/server just complains and refuses to proceed. I had a look at source code (as I always like to do), it seems that render parameters are being serialised as part of navigational state, I wonder if it can be done slightly better? My impression is that current solution relies on client-side url to keep the state which offloads burden on server-side but the length of url is easily out of control; would a session-like solution be more suitable here, say a unqiue id is sent to client instead of actual serialised data?
My workaround is to put data to be transfered between processAction and doView stages to portlet session instead of as render parameter. It's working but not perfect.
Thanks,
Chen
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/522334#522334
16 years, 2 months
[JBoss Messaging] New message: "Re: long live consumer stops working"
by Simo Nikula
User development,
A new message was posted in the thread "long live consumer stops working":
http://community.jboss.org/message/522325#522325
Author : Simo Nikula
Profile : http://community.jboss.org/people/simo.nikula@capgemini.com
Message:
--------------------------------------------------------------
Hi
I've been studing quite similar issue and there are many things to consider.
If you have firewall this may be helpful
http://blog.akquinet.de/2009/09/30/using-jboss-messaging-in-a-firewalled-...
I'm also facing network problems that cannot be fixed as temporary problems are typical nature of those networks.
In those cases few messages are left in queue every now and then. I'm still searching for proper solution but so far I've analyzed that those
problems come like this:
- client ping fails (also close fails with message cannot write CLOSING byte)
- server sends message without knowledge that client is no more alive
- after while server detects that client has not pinged it and logs error message and tries to close socket. These sockets can be detected by e.g. netstat and I run watchdog that restarts server after some amount of those CLOSE_WAIT (>5) sockets are found.
Message are delivered after server restart and FailoverCompleteTimeout.
Basically state is quite manageable but it is not nice to admit that we are restarting both our jboss servers for this cluster about 10 times per day.
Currently I'm testing socket.check_connection true in remoting-bisocket-service.
Having slow connection (512 kb) between client and servers makes testing easier than at redhat where this problem has not been able to be reproduced. client.FailoverCommandCenter can be usually activated by doing 2MB upload.
Simo
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/522325#522325
16 years, 2 months
[EJB 3.0] New message: "EJB 3.0 - Injection via annotation into a servlet"
by Riccardo Blumenthal
User development,
A new message was posted in the thread "EJB 3.0 - Injection via annotation into a servlet":
http://community.jboss.org/message/522316#522316
Author : Riccardo Blumenthal
Profile : http://community.jboss.org/people/neron17
Message:
--------------------------------------------------------------
Hello Community,
I am trying to get a web application working. Therefore I made a servlet, a stateless session bean and an interface for that bean. Now I am trying to get my bean injected (I think that is the correct expression?) into the servlet to call a function. I activate the servlet via a url - that is working. But as soon as I enter the code for the injection my JBoss throws an error on deploying.
I have tried numerous ways but nothing helped. I have spent 3 days on this now and it would be really helpful if there is any advice for what I am doing wong.
Ok, lets get a bit more precise.
I am using Eclipse 3.5 (also to generate the EAR file for the JBoss) and JBoss 5.0.1.GA
My servlet code looks as follows:
package com;
import java.io.IOException;
import javax.ejb.EJB;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.log4j.Logger;
import com.session.PersonControllerEJBemote;
public class SnoopServlet extends HttpServlet
{
Logger logger = Logger.getLogger(SnoopServlet.class);
@EJB
PersonControllerEJBRemote personControllerEJB;
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException
{
logger.info("doGet()");
personControllerEJB.addPerson();
}
}
Stateless Session Bean:
package com.session;
import java.io.Serializable;
import java.util.Date;
import javax.ejb.Local;
import javax.ejb.Stateless;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;
import org.apache.log4j.Logger;
import org.apache.ws.scout.registry.infomodel.PersonNameImpl;
@Local({PersonControllerEJBLocal.class})
@Stateless(name="personController")
public class PersonControllerEJBImpl implements PersonControllerEJBLocal, Serializable
{
@PersistenceContext(unitName="PersonControllerEJBImpl")
private EntityManager em;
private Logger logger = Logger.getLogger(PersonNameImpl.class);
public void addPerson()
{
logger.info("addPerson()");
System.out.println("Person added!");
}
public String findPerson(int personId)
{
return;
}
}
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/522316#522316
16 years, 2 months
[JBoss Cache] New message: "Re: Calrification required regarding version of Core Cache"
by Taran Sodhi
User development,
A new message was posted in the thread "Calrification required regarding version of Core Cache":
http://community.jboss.org/message/522310#522310
Author : Taran Sodhi
Profile : http://community.jboss.org/people/dony908
Message:
--------------------------------------------------------------
Thanks http://community.jboss.org/people/mircea.markus ,
I can certainly do that, but what I'm trying to undestand here is, *what is the differnce between Cayenene and Malagueta?* I can see that there is a subtle difference b/w the two in terms of building the cache and the methods available. So I'm not sure if Cayenene can be upgraded to Malagueta without changing the classes being used from the jars in my application to create, configure cache etc, which I feel is not a small job.
Also, my cache project is outside the JBoss EAP and the jars being used are downloaded seperately from jboss site (caynene 1.4 in my case.)dvance
I have tried looking over the place to find this deffernce but couldn't get much info. Any pointers would be highly apprecaited
Thanks in advance,
TS.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/522310#522310
16 years, 2 months