November 2007 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: Embbedded - broken - some fixes - still not working

by steve.ebersole＠jboss.com

anonymous wrote : But like I said before, this doesn't really optimize it. e.g. at least in JBoss | we'll already have a cache of the annotations so there would be no | need for you to re-read them. e.g. you currently take the stream | and parse the byte code (we've already done that looking for other annotations) The idea is that whatever implementation of the EntityScanner contract was registered would be the one "finding" annotated classes. In your case, as you said, that work has already been done, so your impl could be quite optimized ;) anonymous wrote : Iterator Personally, I like this: | interface EntityProcessor { | void processAnnotatedClass(Class clazz); | ... | } | interface EntityScanner { | void findAnnotatedEntities(EntityProcessor processor); | } | But like I said, I'll leave this up to Emmanuel... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4109001#4109001 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4109001

16 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - Re: New persistence unit deployers

by scott.stark＠jboss.org

"wolfc" wrote : | Is the JBossAppMetaData attachment available for a jar inside the ear? Not the ear module deployment units, but they can walk up to the ear deployment unit using getParent(). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4109000#4109000 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4109000

16 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Hot Deployment -Object Cache

by galder.zamarreno＠jboss.com

In fact, your post is not even about JBoss Cache usage itself. Please visit the Sun's Java forums :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108998#4108998 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108998

16 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Hot Deployment -Object Cache

by galder.zamarreno＠jboss.com

And maybe, just maybe, you could stop using the Design forum to ask questions about usage of JBoss Cache :) This forum is used to discuss the design of JBoss Cache itself. Please, use the JBoss Cache User Forum instead. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108997#4108997 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108997

16 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Embbedded - broken - some fixes - still not working

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | URL[] is better than file. e.g. it could be a jar entry. | We'll actually Iterator<URL> will scale better when there are lots of classes. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108996#4108996 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108996

16 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Hot Deployment -Object Cache

by ekobir

Hi How can I develop a small cache without losing hot deployment functionality of JBOSS ? Ans suggestion will be appreciated. I'm planing to write code similar to following but it will not assure hot deployment will work properly.... (Example is written by me.. And I know it can written better :) ) import java.lang.ref.SoftReference; import java.util.concurrent.ConcurrentHashMap; abstract class BaseClass { public abstract String test(); } class AClass extends BaseClass{ public String test(){ return "A"; } } class BClass extends BaseClass { public String test(){ return "B"; } } public class SmallCache{ private static ConcurrentHashMap<Integer,SoftReference> testMap = new ConcurrentHashMap<Integer, SoftReference>(); public static BaseClass getInstance(int type){ SoftReference sf = testMap.get(type); if(sf == null) { switch(type) { case 1: testMap.put(type, new SoftReference(new AClass())); break; case 2: testMap.put(type, new SoftReference(new BClass())); break; default: System.out.println("Ignore it for now"); } } return sf.get(); } } View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108992#4108992 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108992

16 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Embbedded - broken - some fixes - still not working

by adrian＠jboss.org

"steve.ebersole(a)jboss.com" wrote : I guess it comes down to the definition of "correctness" I asked about before. I should have been more specific. Concretely I was thinking of URLConnection.getContentType(), and wondering what would get returned here for the vfs URL impl. But based on your answers I have to assume it is something non-useful like "vfs' or some-such. | Well it should return the underlying real answer. But that depends upon how good the protocol handler is. In this case, Bill wrote it, so its a NYI :-) I have not seen Emmanuel's code for this discovery, so I cannot give the best answer. But I would assume something like this registerable with the Hibernate Configuration. Probably even the discovery itself could get encapsulated into a registerable contract which you could then provide. A contact like: | public interface EntityScanner { | /** | * Note sure of the most appropriate return type here, but | * it seems best to stay away from URL on vfs ;) | */ | File[] getAnnotatedEntities(URL root); | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108991#4108991 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108991

16 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Embbedded - broken - some fixes - still not working

by steve.ebersole＠jboss.com

I guess it comes down to the definition of "correctness" I asked about before. I should have been more specific. Concretely I was thinking of URLConnection.getContentType(), and wondering what would get returned here for the vfs URL impl. But based on your answers I have to assume it is something non-useful like "vfs' or some-such. I have not seen Emmanuel's code for this discovery, so I cannot give the best answer. But I would assume something like this registerable with the Hibernate Configuration. Probably even the discovery itself could get encapsulated into a registerable contract which you could then provide. A contact like: | public interface EntityScanner { | /** | * Note sure of the most appropriate return type here, but | * it seems best to stay away from URL on vfs ;) | */ | File[] getAnnotatedEntities(URL root); | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108973#4108973 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108973

16 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Embbedded - broken - some fixes - still not working

by adrian＠jboss.org

"steve.ebersole(a)jboss.com" wrote : | You can, sure. But what about other app severs/environments... If the URLConnection/ContentHandler approach is more "correct" and the vfs stuff will really handle it correctly, then whats the issue with using that? Seems like a more universally applicable solution. But of course, I'm a dolt (^^) so please enlighten me ;) Where in the URL api does it have a listChildren(), etc.? :-) You have to use a specific api, e.g. java.io.File or java.util.jar.JarFile before you can look at structure. This adhoc processing (usually done wrong in multiple places :-) is one of the reasons we introduced the VFS, so we can do it correctly in one place and extend it. All I'm asking is for a way to plugin where currently hibernate takes a non-overriable decision. If other appservers want to plugin as well then ok. Even something as simple as: | package org.hiberante.vfs | | public interface URLLister | { | URL[] getChildren(URL parent); | } | would mean we could do: -Dorg.hibnerate.vfs.URLLister.vfs=org.jboss.hibernate.vfs.VFSURLLister i.e. a system/hibernate property org.hiberate.vfs.URLLister.{protocol} I'm sure you can come up with something better :-) I'd prefer something at a higher level. Mainly because we are already scanning classes for annotations for other reasons so we can optimize your search for those that are marked @Entity or whatever filtering you need. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108965#4108965 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108965

16 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Embbedded - broken - some fixes - still not working

by steve.ebersole＠jboss.com

"adrian(a)jboss.org" wrote : | Yes, but you don't use it. Your logic is something like: | if (fileURL()) then use java.io.File | else assume a jar file. | Yes, I understand that much; I am a dolt, not a *complete* dolt ;) The question is whether if we did use that approach the vfs URL would actually do TheRightThing... "adrian(a)jboss.org" wrote : | This is neither of those. You need to define your own simple VFS api | that we can plug into. In fact, you should really be defining something | more high level, since all you really want is a list of relevant annotated class URLs | (the real ones) which we can give you. | You can, sure. But what about other app severs/environments... If the URLConnection/ContentHandler approach is more "correct" and the vfs stuff will really handle it correctly, then whats the issue with using that? Seems like a more universally applicable solution. But of course, I'm a dolt (^^) so please enlighten me ;) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4108957#4108957 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4108957

16 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums November 2007