Re: [JBoss-dev] Handling of ejb-ref and ejb-local-ref
Jeremy Boynes wrote: Scott Stark wrote: There is no need for an ejb-local-ref in the JBoss specific descriptors as the ejb-link element handles this in the standard descriptor. There is no reason why the metadata needs to be expanded to allow for specifying the local home jndi name. There is, because ejb-link is optional: ^ --| and if it's not there you need to be able to specify the target's local-jndi-name. Jeremy I agree with Scott. Having a element be optional in the DTD doesn't mean it optional for a correct deployment. The intent is that a deployment descriptor may be written by a developer without the ejb-link. The link will be specified later by the deployer or integrator. --Victor
Re: [JBoss-dev] Verify primary key implements equals and hashCode
Dain Sundstrom wrote:
On Wednesday, March 26, 2003, at 09:29 PM, Victor Langelo wrote:
I haven't read Effective Java, but this won't work for us. We
intentionally create derived primary key classes for each entity.
These are derived from generic pk classes when the primary key data
is a simple primative type. The super class implements equals,
compareTo and hashCode. I don't see any reason these would need to be
reimplemented in each derived class.
The purpose of the derived classes is primarly for type safety.
I should have added that our client side framework depends on there
being different classes for each domain type. For instance if you double
click on a refund in a list of transactions we need to know to open the
form for editing/viewing a refund instead of one for editing payments.
I loaned my copy of Effective Java to a friend so I can't quote. The
basic idea is that if a.equals(b) is true b.equals(a) must also be
true. This means you must test for the exact type of the related
compare to object. You must have code that looks something like this.
public boolean equals(object o)
{
if(o instanceof MyType)
{
return value.equals((MyType).value);
}
return false;
}
The important part is the instance of check. I suppose you could do
this check with reflection... something like this
if(getClass() == o.getClass())
Agreed. We do something similar. Due to class loader issues, it isn't
always that simple :(
So I guess you are right, but we know that if one of the super classes
(other then Object) we know that the implementation is wrong.
I sorry, but I don't understand this statement at all.
public static boolean definesEquals(Class clazz)
{
Class[] params = new Class[] { Object.class };
while (clazz != null && !clazz.equals(Object.class)) {
try {
Method m = clazz.getDeclaredMethod("equals", params);
if (m.getReturnType() == Integer.TYPE)
return true;
} catch (NoSuchMethodException) {
}
clazz = clazz.getSuperclass();
}
return false;
}
That should work.
-dain
--Victor
---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Verify primary key implements equals and hashCode
Dain Sundstrom wrote:
After some email with Bill, it looks like we can use
Class.getDeclaredMethods to find which method the class implements
(you learn something new every day). It specifically excludes
inherited methods, so we can use it to verify if a primary key has
actually implemented hashCode and equals.
Class.getDeclaredMethod("equals", new Class[] { Object.class }) should
also do the trick and won't return inherited methods.
Since equals equals is not really inheritable (see Effective Java), I
think we should throw a verifier error if a pk does not directly
implement it.
I haven't read Effective Java, but this won't work for us. We
intentionally create derived primary key classes for each entity. These
are derived from generic pk classes when the primary key data is a
simple primative type. The super class implements equals, compareTo and
hashCode. I don't see any reason these would need to be reimplemented in
each derived class.
The purpose of the derived classes is primarly for type safety.
HashCode on the other hand can be inherited (and still be valid), so I
think we should only print a warning if they don't directly. We could
check the parents until we get to Object to see if they left the
default implementation.
Who maintains the verifier?
-dain
Here is the code I wrote in to test this:
public static boolean definesEquals(Class clazz)
{
Method[] method = clazz.getDeclaredMethods();
for(int i=0; i
{
if(method[i].getName().equals("equals") &&
method[i].getParameterTypes().length == 1 &&
method[i].getParameterTypes()[0] == Object.class &&
method[i].getReturnType() == Boolean.TYPE)
{
return true;
}
}
return false;
}
How about: (off the cuff and untested)
public static boolean definesEquals(Class clazz)
{
Class[] params = new Class[] { Object.class };
while (clazz != null && !clazz.equals(Object.class)) {
try {
Method m = clazz.getDeclaredMethod("equals", params);
if (m.getReturnType() == Integer.TYPE)
return true;
} catch (NoSuchMethodException) {
}
clazz = clazz.getSuperclass();
}
return false;
}
--Victor Langelo
---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] new PooledInvoker: speeds up invocations
Hiram Chirino wrote: Hiram Chirino wrote: > Anyways. JMS need bi-directional invocations (BADLY). Should this > become a requirement for the other invokers??I completely disagree. There is no reason server to clientcommunication has to go over the back channel of a client to server I might have said this before, but there is one reason it's a nice feature:This allows callback to clients that are sitting behind a firewall. Let me agree with Hiram. I would add it is essential to use the client connection if the client network is using NAT (network address translation). With the advent of new security measures, many of our clients are adding firewalls and NAT. The worst case is when the server has a public IP and the local LAN clients are on the otherside of a NAT router. --Victor
Re: [JBoss-dev] .DS_Store
Meta information saved by Mac OS X. Unless you're using Mac OS X you can delete these files. --Victor Peter Fagerlund wrote: What are these binary files ? ? jboss-head/varia/src/resources/services/binding/.DS_Store ? jboss-head/varia/src/resources/services/.DS_Store ? jboss-head/connector/src/etc/example-config/.DS_Store --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: AW: AW: [JBoss-dev] Just how hard is polymorphic cmp?
Title: Nachricht Hi Dr. Jung, Sorry to take so long to reply. I've been hoping for some time to review a previous project where we did encounter serious performance problems. Alas, that hasn't happened so I'll do the best I can from memory. See my comments inline. Jung , Dr. Christoph wrote: [EMAIL PROTECTED]"> The VBSF kernel maintains an extends relationship for every class. Italso builds various mappings which provide base class to derived class lookupwhen needed. This provides the ability to reference a base class and actuallyretrieve instances of sub classes. Yes,I forgot to mention that. But IMHO this does not add anything "new" to thekernel, because this information could be looked up by reflection atdeployment time and is there for convenience purposes. I've found that strictly mirroring the java class hierarchy in the persistence hierarchy works well for simple class structures. However, we maintain at least two independent views of any entity. One view is used mostly for reporting purposes and often flattens out relationships (providing summary info). In practice if is very helpful to have these different views use a common base class in java code but two independent hierarchies in the persistence mapping. The point being that reflection will give the wrong result. It is possible that the only reason we've adopted this pattern is that VBSF doesn't allow attributes mapped in a super class to be remapped in derived classes. Removing this restriction might mean we could easily use the same hierarchy in both java and persistence mapping. [EMAIL PROTECTED]"> When buildingpolymorphic structures in Queries and Relationsships as the default, withno need to look at the same entity from differently abstract "views",i.e., nodes in the class hierarchy, programmatic conversion would IMHOnot be necessary (e.g., we make no use of it), but that´s certainly notgeneralizable. I'm not sure how to parse this sentence. Are you saying that the implementation will restrict query conditions to attributes on the base classes, consequently there is no need for the query processor to lookup derived classes? That may be true. However, VBSF doesn't have such a limit and we exceed this limit frequently. [EMAIL PROTECTED]"> There is a performance problem with the queries on base classes. The brute force approach of firingtables x filters queries can kill performance with as little as three subclasses. This occurs mostly with queries involving non trivial joins. I don'thave a general solution, but it's something to keep in mind. Wehavn´t yet had any serious performance problem maybe because we did not havethese non-trivial joins? Could you give me an example of such a three-class constellation,please? My small mind can only think of issues where trying to besmarter than brute force, hence combining the queries for several classstructures into one would result in non-trivialstatements that confuse the database ... Firing a set of queries insteadshould give you just a constant overhead, shouldn´tit? Yes it would be a constant overhead given simple filters on table columns. Our problems came when the entity was a join of multiple tables. Some derived classes included not exists (difference) conditions. Others included outer joins. When executing queries on the base class, some conditions should have automatically eliminated queries on various sub classes. However the query optimizer did not handle this gracefully. It's not that the time for any query was different than if run independently. It's just that it the query would never have been done had we handled building the queries programmatically. To make things worse, most queries on this entity had conditions on attributes of referenced entities. This required additional joins which made the optimizer's job even harder. [EMAIL PROTECTED]"> Thereal issue could IMHO come due to a lacking indexing of the FILTER, because this attribute will be used quite frequently to clearlydiscriminate the separate result sets in this approach ... Agreed, but most databases need more than a simple index on the filter condition to optimize complex queries. This can lead to geometric growth of indices. [EMAIL PROTECTED]"> Dr. Jung alluded to mappings of a single object to multiple tables. Iagree that these are not difficult to implement. The join conditions need tobe added to any queries involving the class. The question of how
Re: AW: [JBoss-dev] Just how hard is polymorphic cmp?
We are also using VBSF as our persistence engine with JBoss. I choose to build a JCA adapter which exposes the Database facade as a connection. I then built a framework for BMP beans that uses the capabilities of VBSF. I've also added a few features to the VBSF engine (we have source license as well). I'd also be willing to help with implementing polymorphic entity beans. There are a couple of points I'd like to add relevant to supporting polymorphic mappings. The VBSF kernel maintains an extends relationship for every class. It also builds various mappings which provide base class to derived class lookup when needed. This provides the ability to reference a base class and actually retrieve instances of sub classes. There is a performance problem with the queries on base classes. The brute force approach of firing tables x filters queries can kill performance with as little as three sub classes. This occurs mostly with queries involving non trivial joins. I don't have a general solution, but it's something to keep in mind. Dr. Jung alluded to mappings of a single object to multiple tables. I agree that these are not difficult to implement. The join conditions need to be added to any queries involving the class. The question of how hard it would be is dependent on exactly what features are required. To implement all the features of a product like VBSF would be hard. If we limit it to just allowing inheritance, it would be manageable. I haven't studied the existing cmp code yet, so I probably cannot answer David's original question. --Victor Jung , Dr. Christoph wrote: [EMAIL PROTECTED]"> David, Dain, othersCurrently, we use a JCA/JDO adapter built around the OR-mapper VBSF(http://www.objectmatter.com) that supports such a thing. I must admit that our application programmers make extensiv use ofpolymorphism at this level. They do it not for accident, but for realmodelling advantages which will give us a lot of headaches when doing theplanned transition to EJB2.0. Hence before I say something technically, Ithink we would be willing of dedicating resources to help with this feature... Interestingly, VBSF´s kernel representations (we bought the source, too;-)are not polymorphism- or subclassing-aware. The only "advanced" things thatthe kernel is able to do is to A) spread the attributes of a class into several (id-linked) tables and jointhem correctly together andB) manage a "FILTER" attribute that fo r each entity determines the mostspecific java class that the entity is an instance of (via hashcode, plaintext, or other things).The polymorphism feature can then be added quite like decorators (orproxies, pattern terminology is hard these days) around the "monomorphism"implementation: 1) extent queries. Instead of querying a single "table", you want to queryall (tables x FILTER) combinations of the given class and the subclasses.Not hard to implement when doing it over separate statements except when itcomes to ordering (which must now be done partially in-memory andconsistently with the db ordering).2) relationships. Requires that the referenced super class has a dedicatedtable (hence is not "abstract" in the db sense). When navigating, firstcollect the (id´s x FILTER) of the referenced objects, then batch read thevalues for each class whose FILTER has been hit.3) queries over relationsships. Not sure here without looking at the codeagain, but should work fairly trivial because you just have to verify(id,FILTER) where FILTER is the description of a subclass of the declaredone ...This was just quickly written and may not make total sense, maybe I´mlacking something because I haven´t worked in the code for some month now,but I just wanted to keep the discussion alive ;-)CGJ-Ursprüngliche Nachricht-Von: David Jencks [mailto:[EMAIL PROTECTED]] Gesendet: Montag, 26. August 2002 22:24An: jboss-devBetreff: [JBoss-dev] Just how hard is polymorphic cmp?I was wondering if anyone knew of any discussions of how hard it would be toimplement a "beyond the spec" cmp2 engine that allowed for polymorphism inyour entity beans.I'm aware of Dan O'Connors article on ServerS ide, but that talks about usinga standard cmp2 engine. I'm wondering about changing the cmp2 engineitself.Starting such a discussion would be fine too.Thanksdavid "tired of jdo" jencks
Re: [JBoss-dev] [ jboss-Bugs-552157 ] Stateful session activation fails
I'm willing to work on this problem, since I've already spent some time studying the relevant code. However, my first attempt was not spec compliant. So I though it might be a good idea to bounce a couple of solutions off the general dev group. The general problem is that passivated stateful session beans are activated in the StatefulSessionInstanceInterceptor. The instance interceptor sits before the security interceptor in the interceptor chain. If the passivated bean has any references to other beans, the handles to those beans call the bean's remote method (create or findByPrimaryKey). Since the caller's principal hasn't been associated with the current context yet, the remote method fails due to an authentication exception. Simply changing the order of the interceptors is not spec compliant because legitimate security exceptions will not dispose of the session bean. I can think of two solutions. 1. Split the security interceptor into two. The first would check the caller's credentials. If verifiable, associate the principal with the current context. Otherwise, do nothing before calling the next interceptor. The second security interceptor would check the method permissions. 2. Add support for a special principal like the anybody principal to the security interceptor. Any call with this principal will always succeed. Then the StatefulSessionPersistenceManager can temporarily associate this principal during activateSession. I think the first solution is cleaner, and only marginally violates the EJB spec. The spec is concerned with checking the callers roles against the declared method permissions. It really isn't concerned with verifying the caller's credentials. Any thoughts before I attempt another patch? --Victor Langelo >Bugs item #552157, was opened at 2002-05-03 21:54 >You can respond by visiting: >http://sourceforge.net/tracker/?func=detail&atid=376685&aid=552157&group_id=22866 > >Category: JBossServer >Group: v2.4 (stable) >Status: Open >Resolution: None >Priority: 5 >Submitted By: Victor Langelo (vlangelo) >Assigned to: Nobody/Anonymous (nobody) >Summary: Stateful session activation fails > >Initial Comment: >JDK 1.3.1_03 >Windows NT and RedHat Linux 7.0 >JBoss version 2.4.5RC3+ (branch_2_4 checkout 5/3/02) >and in JBoss 2.4.4 > >This is really the same as bug 441165. When a stateful >session bean with referenced entity bean is >reactivated, there is no security context associated >with the thread. Hence an Authenication exception is >thrown by an attempt to call the entity bean's >findBy >PrimaryKey method. > >As shown in the following log excerpt, >AbstractInstanceCache.get is called before the security >interceptor has associated the caller principal with >the current context. > >[ClientEditBean,2002-05-03 22:29:45,672] ejbPassivate >called for >com.eclipseservices.adpro.customer.ClientEditBean@2b436d >[DBConnectionProvider,2002-05-03 22:29:58,711] Getting >data source from environment. >[DBConnectionProvider,2002-05-03 22:29:58,721] >getDBConnection: creating connection spec. >[SecurityInterceptor,2002-05-03 22:30:29,435] >Authentication exception, principal=null >[ClientEdit,2002-05-03 22:30:29,465] TRANSACTION >ROLLBACK EXCEPTION: >javax.transaction.TransactionRolledbackException: Could >not activate; nested exception is: > java.rmi.ServerException: Could not get EJBObject; >nested exception is: > java.lang.reflect.InvocationTargetException; nested >exception is: > java.rmi.NoSuchObjectException: Could no >t activate; >nested exception is: > java.rmi.ServerException: Could not get EJBObject; >nested exception is: > java.lang.reflect.InvocationTargetException >java.rmi.NoSuchObjectException: Could not activate; >nested exception is: > java.rmi.ServerException: Could not get EJBObject; >nested exception is: > java.lang.reflect.InvocationTargetException > at >org.jboss.ejb.plugins.AbstractInstanceCache.get(AbstractInstanceCache.java:182) > at >org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invoke(StatefulSessionInstanceInterceptor.java:194) > at >org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext(TxInterceptorCMT.java:138) > at >org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:347) > at >org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:100) > at >org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:170) > at >org.jboss.ejb.StatefulSessionContainer.invoke(Statefu >lSessionContainer.java:347) > at >org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMPContainerInvoker.java:412) > at java.l
Re: [JBoss-dev] [ jboss-Change Notes-551858 ] EJB container config override
Thank you, Thank you, Thank you :-) * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=14752 ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] What should we do about SQLExceptions in BMP (3.0/3.1)
David Jencks wrote: >My understanding of Dain's cmp code is that any SQLException will result in >the tx being set rollback only, and basically all work discarded. > >In the new local jdbc wrapper, I've done something about as drastic: if >there is any SQLException from any operation, the connection is discarded >and the connection handle you get is then useless (unless you hold onto it >over a method boundary, then it can get reassociated on the next call). > I had the same questions while writting an adapter for a third party O-R mapping library. The jca spec is rather vague about how exceptions should effect the transaction state. However the intro to section 12 "Exceptions" does state that a resource can throw both system exceptions (where the transaction is rolled back) and application exceptions. > > >My interpretation of the jca spec is that this is the expected behavior for >a jca adapter. However,... > >1. This breaks at least some code in the test suite, the cts bmp unit test >basically tests for the existence of its table by looking for an exception. > The solution is to always discard a connection handle after any exception. >How much user code is likely to break? Does anyone know what the j2ee spec >says about SQLExceptions (a reference would be great) If this makes JBoss >more spec compliant, do we care if it breaks preexisting code? > This would also break code that tests integrity constraints and handles violations as application exceptions. > > >2. I wrote the wrapper so it would be easy to write an extension for a >specific database that could look at the SQLException content and only >discard the connection if it was actually unusable. If we do this, what >happens to the original SQLException? Do we turn it into a warning? Maybe >this idea of db-specific exception handling won't work. Any opinions? > Why can you not just rethrow the SQLException. It might make sense to turn all exceptions that break the connection into a runtime exception. This would mean they will always be treated as system exceptions. I haven't look at your new code, but how about the following: 1. Each SQLException is passed through a custom exception handler that's added to the adapter in the configuration. 2. The handler indicates if the connection is still good (via a callback?) and returns an exception which is rethrown. > > >thanks >david jencks > > Victor Langelo ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] java.util.Date in PostgreSQL DB
David Budworth wrote: [EMAIL PROTECTED]"> Or does PostgreSQL DATE/TIMESTAMP exactly the same? I know oracle willdrop the time portion if the column type is DATE.-David Actually Oracle will not drop the time protion if the column type is DATE. The following is from the Oracle 8 manual. Oracle 7 says essentially the same thing. The DATE datatype stores date and time information. Although date and time information can be represented in both CHAR and NUMBER datatypes, the DATE datatype has special associated properties. For each DATE value, Oracle stores the following information: century, year, month, day, hour, minute, and second. You need to use TRUNC(date) in order to remove the time portion (or more accurately set it to 0). --Victor [EMAIL PROTECTED]">
Re: [JBoss-dev] JBOSS @ JAVAONE TSHIRT CONTEST
> > >JBoss: > > JBoss: the one to follow. JBoss: leads the pack. JBoss: not the pointy hair kind. or JBoss: .04ms and falling :-) --Victor ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] The RARDeployer classpath is broken
Scott, I've recently written a resouce adapter for an O-R mapping engine. All classes in .jar files are successfully loaded. However, .class files placed in the rar archive are not added to the classpath. It would be nice if other resources in the rar were also added to the classpath. For instance the O-R mapping engine derives it's mapping information from schema files which are typically placed in the classpath. I currently have to jar the schema file and place that jar in the rar. --Victor Langelo Scott M Stark wrote: > I'm looking at the behavior of the RARDeployer for the JBossCX chapter > of the JBoss book and I have found that the classes in the rar are not > included in the class loader classpath setup by the RARDeployer. The only > reason the example jbosspool-jdbc.rar and jms-ra.rar adapters deploy is > because the adapter classes also happen to be in lib/ext due to the fact > that > they are part of other core jars. I am going to fix this and remove the rar > classes from the core jars. > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] EJB/QL - JBoss extentions
Dave Smith wrote: > 3. Dynamic where clause > Prompting the user for a search criteria and returning a result set > based on those criteria. Also would be handy to have cursors/limit. > > [snip] > For 1,3,4 I would propose that we add a special jboss function into the > QL, something like jboss_sql_inline() and what is between the brackets > is just passed through to the sql engine. Arguments could be passed > through to parts of the code with ??1 etc, sort of an escaped argument. > So you could have > > select object(o) from foo o where o.id=?1 and > jboss_sql_inline(datefunc(datefield) = ??2) > > Comments? > Are you attempting to reuse parameterized statements here? If so, there's a better technique which is spec compliant. Have the persistence engine parse the query and generate a parameterized sql expression. Then compare this expression with existing parsed queries in the cache. Simple hashtable lookup will work here. If there's a match, use the existing statement. Otherwise generate a new statement and add it to the cache. --Victor Langelo ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] DTDs
The standard way of accessing a local dtd in SGML/XML is the following: if jboss.dtd is in the same directory as the xml file. Otherwise use relative or absolute paths. I don't know if this works with the crimson parser though. --Victor Aaron Mulder wrote: > My fault, I had the case wrong (JBoss <> JBOSS). BTW, it appears > that you must provide a URL - if I use something like: > > > > The parser refuses to accept it. In any case, is there some way > to avoid loaded the DTD at all when the validate flag is off? > > Aaron ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
