Re: STILL TRYING: [JBoss-user] CMP: Iterate Collection Performance Killer
Frank, I'm assuming you're doing read-only operations? What we typically do is use SQL and just load data-objects ourselves for collections that size. hth dim - Original Message - From: "Frank Morton" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, April 24, 2002 1:44 PM Subject: Re: STILL TRYING: [JBoss-user] CMP: Iterate Collection Performance Killer > Maybe I should try a different tactic. > > Does anyone have an entity bean that has a method that > returns a Collection that performs well with ~200 elements > in the Collection? Reaching it through a session bean is > fine. If so, would you share the source? I'm beginning to > believe that no one actually has done this successfully. > > Still working on this without success. I have tried all > suggestions, including wrapping it with a UserTransaction, > but still didn't make any difference. > > Still wanting cmp to work.. > > > I think I'm close.Thanks to all who have given advice. If I get > > this going, I'll be glad to write up the results, which based on > > dain's comments, others are also asking about. Here are the > > details (using 3.0.0.RC1): > > > > I have two cmp entity beans: Container and Attribute. > > > > I also have a stateless session bean called ContainerControl. In this > > class, there is a method called findByPrimaryKeyMap. This method > > does a findByPrimaryKey on a Container. It also does a > > findByContainerId, which returns a Collection of ~ 200 elements > > on Attribute, causing the performance problem. The findByPrimaryKeyMap > > method returns what I call a ContainerMap, which encapsulates > > the two find results as well as build a lookup table of the Collection. > > > > I have a web application that does the following: > > > > ContainerControl containerControl = Factory.getContainerControl(); > > ContainerMap containerMap = > containerControl.findByPrimaryKeyMap(id,"name"); > > CollectionMap attributeMap = containerMap.getAttributeMap(); > > > > Basically looks up the session bean, does the find and gets the results > > out of the ContainerMap. When the ContainerMap is built, it iterates > > the Collection, taking over 100 ms per element. Based on that, each > > step must still think it is a transaction. > > > > Based on the ejb-jar below, I think the session bean ought to be a single > > transaction, but it isn't. The ContainerControl ejb-jar.xml files looks > > like: > > > > > > > > > > > > Container Session Beans > > Container Session Beans > > > > > > ContainerControl > > > > com.base2inc.bean.session.container.ContainerControlHome > > > > com.base2inc.bean.session.container.ContainerControl > > > > > com.base2inc.bean.session.container.ContainerControlBean > ss> > > Stateless > > Bean > > > > > > ContainerValue > > > com.base2inc.bean.session.container.ContainerValueHome > > > com.base2inc.bean.session.container.ContainerValue > > > > > com.base2inc.bean.session.container.ContainerValueBean > > > > Stateless > > Bean > > > > > > > > > > > > > > ContainerControl > > * > > > >Required > > > > > > > > > > Any idea will be tried. Thanks. > > > > > > > You must use a transaction for your unseen session bean that is > accessing > > > the entity beans. Otherwise, as Dain says, everytime you change a bean > in > > > the collection, it creates a transaction, reads ahead 1000 or so > > (depending > > > upon read-ahead limit) then when you edit the bean, it commits the > > > transaction, which loses all the read-ahead information. Then as you > edit > > > the next bean, it starts the whole process over again. > > > > > > If your session bean was called AttributeManager, you would use a > > > container-transaction like the following in the assembly-descriptor > > element. > > > This way, the transactions on the Attribute bean are encompassed by the > > > transaction on the session bean method that is iterating over the > > > collection. > > > > > > > > > > > > AttributeManager > > > * > > > > > > Required > > > > > > > > > Michael > > > > > > > -Original Message- > > > > From: Frank Morton [mailto:[EMAIL PROTECTED]] > > > > Sent: Tuesday, April 23, 2002 11:50 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: [JBoss-user] CMP: Iterate Collection Performance Killer > > > > > > > > > > > > > Use a transaction or turn off read ahead. You are basically reading > > > > > ahead data, tossing the read-ahead information out, and > > > > then repeating. > > > > > > > > > > -dain > > > > > > > > Thanks for your response. > > > > > > > > Sorry for my confusion, but I am. Your doc states to use > > > > with the on-load for this exact case,
Re: STILL TRYING: [JBoss-user] CMP: Iterate Collection Performance Killer
Have you looked at the server.log? What queries are being executed? Don't post the whole file. Give us a summary. -dain BTW: there is a difference between doesn't work and is not fast enough for me. Frank Morton wrote: > Maybe I should try a different tactic. > > Does anyone have an entity bean that has a method that > returns a Collection that performs well with ~200 elements > in the Collection? Reaching it through a session bean is > fine. If so, would you share the source? I'm beginning to > believe that no one actually has done this successfully. > > Still working on this without success. I have tried all > suggestions, including wrapping it with a UserTransaction, > but still didn't make any difference. > > Still wanting cmp to work.. > > >>I think I'm close.Thanks to all who have given advice. If I get >>this going, I'll be glad to write up the results, which based on >>dain's comments, others are also asking about. Here are the >>details (using 3.0.0.RC1): >> >>I have two cmp entity beans: Container and Attribute. >> >>I also have a stateless session bean called ContainerControl. In this >>class, there is a method called findByPrimaryKeyMap. This method >>does a findByPrimaryKey on a Container. It also does a >>findByContainerId, which returns a Collection of ~ 200 elements >>on Attribute, causing the performance problem. The findByPrimaryKeyMap >>method returns what I call a ContainerMap, which encapsulates >>the two find results as well as build a lookup table of the Collection. >> >>I have a web application that does the following: >> >>ContainerControl containerControl = Factory.getContainerControl(); >>ContainerMap containerMap = >> > containerControl.findByPrimaryKeyMap(id,"name"); > >>CollectionMap attributeMap = containerMap.getAttributeMap(); >> >>Basically looks up the session bean, does the find and gets the results >>out of the ContainerMap. When the ContainerMap is built, it iterates >>the Collection, taking over 100 ms per element. Based on that, each >>step must still think it is a transaction. >> >>Based on the ejb-jar below, I think the session bean ought to be a single >>transaction, but it isn't. The ContainerControl ejb-jar.xml files looks >>like: >> >> >> >> >> >> Container Session Beans >> Container Session Beans >> >> >> ContainerControl >> >>com.base2inc.bean.session.container.ContainerControlHome >> >>com.base2inc.bean.session.container.ContainerControl >> >> > com.base2inc.bean.session.container.ContainerControlBean >>ss> >> Stateless >> Bean >> >> >> ContainerValue >> > com.base2inc.bean.session.container.ContainerValueHome > > com.base2inc.bean.session.container.ContainerValue > >> > com.base2inc.bean.session.container.ContainerValueBean >> Stateless >> Bean >> >> >> >> >> >> >>ContainerControl >>* >> >> Required >> >> >> >> >>Any idea will be tried. Thanks. >> >> >> >>>You must use a transaction for your unseen session bean that is >>> > accessing > >>>the entity beans. Otherwise, as Dain says, everytime you change a bean >>> > in > >>>the collection, it creates a transaction, reads ahead 1000 or so >>> >>(depending >> >>>upon read-ahead limit) then when you edit the bean, it commits the >>>transaction, which loses all the read-ahead information. Then as you >>> > edit > >>>the next bean, it starts the whole process over again. >>> >>>If your session bean was called AttributeManager, you would use a >>>container-transaction like the following in the assembly-descriptor >>> >>element. >> >>>This way, the transactions on the Attribute bean are encompassed by the >>>transaction on the session bean method that is iterating over the >>>collection. >>> >>> >>> >>> AttributeManager >>> * >>> >>>Required >>> >>> >>>Michael >>> >>> -Original Message- From: Frank Morton [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 23, 2002 11:50 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] CMP: Iterate Collection Performance Killer >Use a transaction or turn off read ahead. You are basically reading >ahead data, tossing the read-ahead information out, and > then repeating. >-dain > Thanks for your response. Sorry for my confusion, but I am. Your doc states to use with the on-load for this exact case, but doesn't seem to make a difference at this point. You are saying strategy=none is the right thing to do? I tried that, too, which doesn't appear to make any difference. Please clarify this. There is a lot of contradictory info on the web about this. I also tried setting in standardjaws.xml to true and false, neither of which
Re: STILL TRYING: [JBoss-user] CMP: Iterate Collection Performance Killer
Maybe I should try a different tactic. Does anyone have an entity bean that has a method that returns a Collection that performs well with ~200 elements in the Collection? Reaching it through a session bean is fine. If so, would you share the source? I'm beginning to believe that no one actually has done this successfully. Still working on this without success. I have tried all suggestions, including wrapping it with a UserTransaction, but still didn't make any difference. Still wanting cmp to work.. > I think I'm close.Thanks to all who have given advice. If I get > this going, I'll be glad to write up the results, which based on > dain's comments, others are also asking about. Here are the > details (using 3.0.0.RC1): > > I have two cmp entity beans: Container and Attribute. > > I also have a stateless session bean called ContainerControl. In this > class, there is a method called findByPrimaryKeyMap. This method > does a findByPrimaryKey on a Container. It also does a > findByContainerId, which returns a Collection of ~ 200 elements > on Attribute, causing the performance problem. The findByPrimaryKeyMap > method returns what I call a ContainerMap, which encapsulates > the two find results as well as build a lookup table of the Collection. > > I have a web application that does the following: > > ContainerControl containerControl = Factory.getContainerControl(); > ContainerMap containerMap = containerControl.findByPrimaryKeyMap(id,"name"); > CollectionMap attributeMap = containerMap.getAttributeMap(); > > Basically looks up the session bean, does the find and gets the results > out of the ContainerMap. When the ContainerMap is built, it iterates > the Collection, taking over 100 ms per element. Based on that, each > step must still think it is a transaction. > > Based on the ejb-jar below, I think the session bean ought to be a single > transaction, but it isn't. The ContainerControl ejb-jar.xml files looks > like: > > > > > > Container Session Beans > Container Session Beans > > > ContainerControl > > com.base2inc.bean.session.container.ContainerControlHome > > com.base2inc.bean.session.container.ContainerControl > > com.base2inc.bean.session.container.ContainerControlBean ss> > Stateless > Bean > > > ContainerValue > com.base2inc.bean.session.container.ContainerValueHome > com.base2inc.bean.session.container.ContainerValue > > com.base2inc.bean.session.container.ContainerValueBean > > Stateless > Bean > > > > > > > ContainerControl > * > >Required > > > > > Any idea will be tried. Thanks. > > > > You must use a transaction for your unseen session bean that is accessing > > the entity beans. Otherwise, as Dain says, everytime you change a bean in > > the collection, it creates a transaction, reads ahead 1000 or so > (depending > > upon read-ahead limit) then when you edit the bean, it commits the > > transaction, which loses all the read-ahead information. Then as you edit > > the next bean, it starts the whole process over again. > > > > If your session bean was called AttributeManager, you would use a > > container-transaction like the following in the assembly-descriptor > element. > > This way, the transactions on the Attribute bean are encompassed by the > > transaction on the session bean method that is iterating over the > > collection. > > > > > > > > AttributeManager > > * > > > > Required > > > > > > Michael > > > > > -Original Message- > > > From: Frank Morton [mailto:[EMAIL PROTECTED]] > > > Sent: Tuesday, April 23, 2002 11:50 AM > > > To: [EMAIL PROTECTED] > > > Subject: Re: [JBoss-user] CMP: Iterate Collection Performance Killer > > > > > > > > > > Use a transaction or turn off read ahead. You are basically reading > > > > ahead data, tossing the read-ahead information out, and > > > then repeating. > > > > > > > > -dain > > > > > > Thanks for your response. > > > > > > Sorry for my confusion, but I am. Your doc states to use > > > with the on-load for this exact case, but doesn't > > > seem to make a difference at this point. You are saying strategy=none > > > is the right thing to do? I tried that, too, which doesn't > > > appear to make > > > any difference. Please clarify this. There is a lot of contradictory > > > info on the web about this. I also tried setting in > > > standardjaws.xml to true and false, neither of which seemed to > > > make any difference. Seems no matter what I do, I get the > > > same behavior, so I must be missing something. > > > > > > While I'm irritating you, can you explain exactly how or refer me to > > > someplace that explains exactly how to use a transaction to speed up > > > r
Re: [JBoss-user] create-table, jaws.xml and JBoss 3.0 beta2
On 2002.04.23 20:28:46 -0400 James Higginbotham wrote: > That may be the case. The entity bean isn't using CMP 2.0 standards > (abstract fields and such), but I noticed that if I changed the > datasource in the standardjbosscmp-jdbc.xml file, things worked better > (didn't use hsql by default - DefaultDS). > > So, do I use jbosscmp-jdbc.xml in place of jaws in my ejb.jar, yes or do I > deploy this file into the deploy directory like I would JMS > configurations (I assume in place of jaws.xml in my meta-inf)? > > Is the format of the enterprise-beans section the same as the older > jaws.xml format (allowing for override of field types, etc)? It allows much more, the format is similar, see the jbosscmp-jdbc_3_0.dtd in server/src/resource/metadata I think (I may have the exact name wrong). david jencks > > Thanks, > James > > > -Original Message- > > From: David Jencks [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, April 23, 2002 7:08 PM > > To: James Higginbotham > > Cc: [EMAIL PROTECTED] > > Subject: Re: [JBoss-user] create-table, jaws.xml and JBoss 3.0 beta2 > > > > > > Any chance you are using cmp2 in enough places so that > > jbosscmp-jdbc.xml would be the place to specify this? I > > think the pm (jaws/cmp2) is specified somewhere in the > > container configuration. > > > > david jencks > > > > On 2002.04.23 19:05:20 -0400 James Higginbotham wrote: > > > Can someone please tell me why the following entry in a > > jaws.xml file > > > inside my entity bean's jar continues to cause jboss to create the > > > table in mysql (named workflowstoragebean after the EJB) > > rather than > > > using the one specified in the jaws file (workflowejb)? When JBoss > > > creates the table, it creates a BLOB rather than LONGBLOB > > type for the > > > column and thus limits me to 65k bytes, which is not what I want. > > > Thus, I have defined the tablename for the CMP but jboss ignores it. > > > > > > > > > > > >WorkflowStorageBean > > >workflowejb > > >false > > >false > > > > > > workflowId > > > workflowId > > > VARCHAR > > > VARCHAR(64) > > > > > > > > > data > > > data > > >JAVA_OBJECT > > >BLOB > > > > > > > > > > > > > > > > > > Thanks, > > > James > > > > > > > > > Message > > > > > > > > > > size=2>Can someone > > > please > > > tell me why the following entry in a jaws.xml file inside my entity > > > bean's jar > > > continues to cause jboss to create the table in mysql (named > > > workflowstoragebean > > > after the EJB) rather than using the one specified in the jaws file > > > (workflowejb)? When JBoss creates the table, it creates a > > BLOB rather > > > than > > > LONGBLOB type for the column and thus limits me to 65k > > bytes, which is > > > not what > > > I want. Thus, I have defined the tablename for the CMP but > > jboss ignores > > > it. > > > > > > > > size=2> > > > > > > > size=2>> y> WorkflowStorageBean > > workf > > lowejb > e>false > e-table>false < > > ;cmp-field> wo > > rkflowId > umn-name>workflowId &nbs > > p; > > > > > > > > VARCHAR > > > > > > > > > > >VARCHAR(64) < > > > > > /cmp-field>& > > > > > nbsp; data &n > > > > > bsp;data & > > > nbsp; > > > > > > > >JAVA_OBJECT &n > > > bsp; > > > > > > > >BLOB > > > > eld> > s> > > > > > size=2> > > > > > size=2>Thanks, > > > > > size=2>James > > > > > > > ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] create-table, jaws.xml and JBoss 3.0 beta2
That may be the case. The entity bean isn't using CMP 2.0 standards (abstract fields and such), but I noticed that if I changed the datasource in the standardjbosscmp-jdbc.xml file, things worked better (didn't use hsql by default - DefaultDS). So, do I use jbosscmp-jdbc.xml in place of jaws in my ejb.jar, or do I deploy this file into the deploy directory like I would JMS configurations (I assume in place of jaws.xml in my meta-inf)? Is the format of the enterprise-beans section the same as the older jaws.xml format (allowing for override of field types, etc)? Thanks, James > -Original Message- > From: David Jencks [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, April 23, 2002 7:08 PM > To: James Higginbotham > Cc: [EMAIL PROTECTED] > Subject: Re: [JBoss-user] create-table, jaws.xml and JBoss 3.0 beta2 > > > Any chance you are using cmp2 in enough places so that > jbosscmp-jdbc.xml would be the place to specify this? I > think the pm (jaws/cmp2) is specified somewhere in the > container configuration. > > david jencks > > On 2002.04.23 19:05:20 -0400 James Higginbotham wrote: > > Can someone please tell me why the following entry in a > jaws.xml file > > inside my entity bean's jar continues to cause jboss to create the > > table in mysql (named workflowstoragebean after the EJB) > rather than > > using the one specified in the jaws file (workflowejb)? When JBoss > > creates the table, it creates a BLOB rather than LONGBLOB > type for the > > column and thus limits me to 65k bytes, which is not what I want. > > Thus, I have defined the tablename for the CMP but jboss ignores it. > > > > > > > >WorkflowStorageBean > >workflowejb > >false > >false > > > > workflowId > > workflowId > > VARCHAR > > VARCHAR(64) > > > > > > data > > data > >JAVA_OBJECT > >BLOB > > > > > > > > > > > > Thanks, > > James > > > > > > Message > > > > > > size=2>Can someone > > please > > tell me why the following entry in a jaws.xml file inside my entity > > bean's jar > > continues to cause jboss to create the table in mysql (named > > workflowstoragebean > > after the EJB) rather than using the one specified in the jaws file > > (workflowejb)? When JBoss creates the table, it creates a > BLOB rather > > than > > LONGBLOB type for the column and thus limits me to 65k > bytes, which is > > not what > > I want. Thus, I have defined the tablename for the CMP but > jboss ignores > > it. > > > > > size=2> > > > > size=2>y> WorkflowStorageBean > workf > lowejb e>false e-table>false < > ;cmp-field> wo > rkflowId umn-name>workflowId &nbs > p; > > > > > VARCHAR > > > > > > >VARCHAR(64) < > > > /cmp-field>& > > > nbsp; data &n > > > bsp;data & > > nbsp; > > > > >JAVA_OBJECT &n > > bsp; > > > > >BLOB > > eld> s> > > > size=2> > > > size=2>Thanks, > > > size=2>James > > > ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] create-table, jaws.xml and JBoss 3.0 beta2
Any chance you are using cmp2 in enough places so that jbosscmp-jdbc.xml would be the place to specify this? I think the pm (jaws/cmp2) is specified somewhere in the container configuration. david jencks On 2002.04.23 19:05:20 -0400 James Higginbotham wrote: > Can someone please tell me why the following entry in a jaws.xml file > inside my entity bean's jar continues to cause jboss to create the table > in mysql (named workflowstoragebean after the EJB) rather than using the > one specified in the jaws file (workflowejb)? When JBoss creates the > table, it creates a BLOB rather than LONGBLOB type for the column and > thus limits me to 65k bytes, which is not what I want. Thus, I have > defined the tablename for the CMP but jboss ignores it. > > > >WorkflowStorageBean >workflowejb >false >false > > workflowId > workflowId > VARCHAR > VARCHAR(64) > > > data > data >JAVA_OBJECT >BLOB > > > > > > Thanks, > James > > > Message > > > > Can someone > please > tell me why the following entry in a jaws.xml file inside my entity > bean's jar > continues to cause jboss to create the table in mysql (named > workflowstoragebean > after the EJB) rather than using the one specified in the jaws file > (workflowejb)? When JBoss creates the table, it creates a BLOB rather > than > LONGBLOB type for the column and thus limits me to 65k bytes, which is > not what > I want. Thus, I have defined the tablename for the CMP but jboss ignores > it. > > size=2> > >size=2>> size=2> > size=2>Thanks, > size=2>James > ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user WorkflowStorageBean workflowejb false false workflowId workflowId > >VARCHAR > > >VARCHAR(64) data data > > >JAVA_OBJECT > > >BLOB
[JBoss-user] create-table, jaws.xml and JBoss 3.0 beta2
Title: Message Can someone please tell me why the following entry in a jaws.xml file inside my entity bean's jar continues to cause jboss to create the table in mysql (named workflowstoragebean after the EJB) rather than using the one specified in the jaws file (workflowejb)? When JBoss creates the table, it creates a BLOB rather than LONGBLOB type for the column and thus limits me to 65k bytes, which is not what I want. Thus, I have defined the tablename for the CMP but jboss ignores it. WorkflowStorageBean workflowejb false false workflowIdworkflowId VARCHAR VARCHAR(64) datadata JAVA_OBJECT BLOB Thanks, James
Re: [JBoss-user] CMP: Iterate Collection Performance Killer
Marius Kotsbak wrote: > I remember from using jboss 2.4.x, that manual changes in the DB would > take some time to be reflected from CMP-beans (no new data even in a new > transaction after the change), probably because jboss was caching the > data, and not writing it to the DB at the same time the set-method was > called. No, it was because JBoss 2.4 used commit option A by default and in JBoss 3.0 we switched to B. If you want to know about commit options read the EJB spec. > With jboss 3.x, I don't see this behavior. What has happened, > what is the difference? Is there no write-cache now? Does it save one > and one property of the beans? What? Writes are delayed until the end of the transaction, if that is what you mean, but that is not really a cache. > There should be a doc of the CMP-engine to answer these FAQs, at least a > updated description of the settings in the DTD (the comments there > doesn't explain it very well) I am literally writing this chapter right now in another window. -dain ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] CMP: Iterate Collection Performance Killer
Dain Sundstrom wrote: > Marius Kotsbak wrote: > >> In that file, I find false. Is there >> a reason for that to be false as default? > > > > FK constraints are not supported by hypersonic, or more importantly I > couldn't get them to work. > > >> And since this one is there: >> >> on-load >> 1000 >> * >> >> 1000 >> >> , shouldn't most uses of CMPs be tuned OK (when using the same >> transaction!)? > > > > what? > > >> What does , and 300 mean? > > > > list cache max is the number of queries that the container will remember. > When a query is executed, JBossCMP remembers the order of the > results. When lazy loading the container will read-ahead the next n > entities from the list. > > time-out has been renamed to read-time-out, and specifies the amount > of time that a read-only field is considered valid (milliseconds). I remember from using jboss 2.4.x, that manual changes in the DB would take some time to be reflected from CMP-beans (no new data even in a new transaction after the change), probably because jboss was caching the data, and not writing it to the DB at the same time the set-method was called. With jboss 3.x, I don't see this behavior. What has happened, what is the difference? Is there no write-cache now? Does it save one and one property of the beans? There should be a doc of the CMP-engine to answer these FAQs, at least a updated description of the settings in the DTD (the comments there doesn't explain it very well) > > -dain > > > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: STILL TRYING: [JBoss-user] CMP: Iterate Collection PerformanceKiller
Frank Morton wrote: >>You have specified Bean. Then I think >> >> >you have to manually start and end the transaction. Do you do this? And I >think you should use container for this option instead, and Required in the >transaction-type of your methods. > >I am not starting/ending the transaction manually and >I haven't been able to find a description how to do it. >If you can point me at how to do that, I'd appreciate it. > >Thanks for your help. > > > somthing like this in your ejb-jar.xml: beanName * bean2name * Required I think required may be the default, or nothing? ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: STILL TRYING: [JBoss-user] CMP: Iterate Collection PerformanceKiller
Frank Morton wrote: >>You have specified Bean. Then I think >> >> >you have to manually start and end the transaction. Do you do this? And I >think you should use container for this option instead, and Required in the >transaction-type of your methods. > >I am not starting/ending the transaction manually and >I haven't been able to find a description how to do it. >If you can point me at how to do that, I'd appreciate it. > >Thanks for your help. > > > Take a look in a EJB-book under transactions (you should really have one when using EJB) or maybe the jboss-book (in paper or online for 10$), but you probably don't need it. Just change to Container and in the transaction set methods=* type=required, possibly with the help of xdoclet. ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] CMP: Iterate Collection Performance Killer
Marius Kotsbak wrote: > In that file, I find false. Is there a > reason for that to be false as default? FK constraints are not supported by hypersonic, or more importantly I couldn't get them to work. > And since this one is there: > > on-load > 1000 > * > > 1000 > > , shouldn't most uses of CMPs be tuned OK (when using the same > transaction!)? what? > What does , and 300 mean? list cache max is the number of queries that the container will remember. When a query is executed, JBossCMP remembers the order of the results. When lazy loading the container will read-ahead the next n entities from the list. time-out has been renamed to read-time-out, and specifies the amount of time that a read-only field is considered valid (milliseconds). -dain ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: STILL TRYING: [JBoss-user] CMP: Iterate Collection PerformanceKiller
You have specified Bean. Then I think you have to manually start and end the transaction. Do you do this? And I think you should use container for this option instead, and Required in the transaction-type of your methods. Frank Morton wrote: >I think I'm close.Thanks to all who have given advice. If I get >this going, I'll be glad to write up the results, which based on >dain's comments, others are also asking about. Here are the >details (using 3.0.0.RC1): > >I have two cmp entity beans: Container and Attribute. > >I also have a stateless session bean called ContainerControl. In this >class, there is a method called findByPrimaryKeyMap. This method >does a findByPrimaryKey on a Container. It also does a >findByContainerId, which returns a Collection of ~ 200 elements >on Attribute, causing the performance problem. The findByPrimaryKeyMap >method returns what I call a ContainerMap, which encapsulates >the two find results as well as build a lookup table of the Collection. > >I have a web application that does the following: > >ContainerControl containerControl = Factory.getContainerControl(); >ContainerMap containerMap = containerControl.findByPrimaryKeyMap(id,"name"); >CollectionMap attributeMap = containerMap.getAttributeMap(); > >Basically looks up the session bean, does the find and gets the results >out of the ContainerMap. When the ContainerMap is built, it iterates >the Collection, taking over 100 ms per element. Based on that, each >step must still think it is a transaction. > >Based on the ejb-jar below, I think the session bean ought to be a single >transaction, but it isn't. The ContainerControl ejb-jar.xml files looks >like: > > > > > > Container Session Beans > Container Session Beans > > > ContainerControl > >com.base2inc.bean.session.container.ContainerControlHome > >com.base2inc.bean.session.container.ContainerControl > >com.base2inc.bean.session.container.ContainerControlBeanss> > Stateless > Bean > > > ContainerValue > com.base2inc.bean.session.container.ContainerValueHome > com.base2inc.bean.session.container.ContainerValue > >com.base2inc.bean.session.container.ContainerValueBean > > Stateless > Bean > > > > > > >ContainerControl >* > > Required > > > > >Any idea will be tried. Thanks. > > > > >>You must use a transaction for your unseen session bean that is accessing >>the entity beans. Otherwise, as Dain says, everytime you change a bean in >>the collection, it creates a transaction, reads ahead 1000 or so >> >> >(depending > > >>upon read-ahead limit) then when you edit the bean, it commits the >>transaction, which loses all the read-ahead information. Then as you edit >>the next bean, it starts the whole process over again. >> >>If your session bean was called AttributeManager, you would use a >>container-transaction like the following in the assembly-descriptor >> >> >element. > > >>This way, the transactions on the Attribute bean are encompassed by the >>transaction on the session bean method that is iterating over the >>collection. >> >> >> >> AttributeManager >> * >> >>Required >> >> >>Michael >> >> >> >>>-Original Message- >>>From: Frank Morton [mailto:[EMAIL PROTECTED]] >>>Sent: Tuesday, April 23, 2002 11:50 AM >>>To: [EMAIL PROTECTED] >>>Subject: Re: [JBoss-user] CMP: Iterate Collection Performance Killer >>> >>> >>> >>> Use a transaction or turn off read ahead. You are basically reading ahead data, tossing the read-ahead information out, and >>>then repeating. >>> >>> -dain >>>Thanks for your response. >>> >>>Sorry for my confusion, but I am. Your doc states to use >>>with the on-load for this exact case, but doesn't >>>seem to make a difference at this point. You are saying strategy=none >>>is the right thing to do? I tried that, too, which doesn't >>>appear to make >>>any difference. Please clarify this. There is a lot of contradictory >>>info on the web about this. I also tried setting in >>>standardjaws.xml to true and false, neither of which seemed to >>>make any difference. Seems no matter what I do, I get the >>>same behavior, so I must be missing something. >>> >>>While I'm irritating you, can you explain exactly how or refer me to >>>someplace that explains exactly how to use a transaction to speed up >>>reading Collections. >>> >>>Thanks. I'm guessing I'm not the only one that needs to know >>>about this. >>> >>>Frank >>> >>>Here is my ejb-jar.xml file in case it is of use to you: >>> >>> >>> >>> >>> Attribute Management >>> Attribute Management >>> >>> >>> >>> Attribute >>> Attribute >>
Re: [JBoss-user] CMP: Iterate Collection Performance Killer
Dain Sundstrom wrote: > danch wrote: > >> Dain Sundstrom wrote: >> >>> Frank Morton wrote:> >>> I tried that, too, which doesn't appear to make any difference. Please clarify this. There is a lot of contradictory info on the web about this. I also tried setting in standardjaws.xml to true and false, neither of which seemed to make any difference. >>> >>> >>> >>> >>> >>> That won't work. It shouldn't even boot. Check the dtd. >> >> >> >> >> ? standardjaws.xml is just ignored in jboss3, i'n'it? >> > > > Ya, didn't read to close. > > Change standardjbosscmp-jdbc.xml instead. > > -dain > > > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user In that file, I find false. Is there a reason for that to be false as default? And since this one is there: on-load 1000 * 1000 , shouldn't most uses of CMPs be tuned OK (when using the same transaction!)? What does , and 300 mean? Marius K Boostcom.no ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
STILL TRYING: [JBoss-user] CMP: Iterate Collection Performance Killer
I think I'm close.Thanks to all who have given advice. If I get this going, I'll be glad to write up the results, which based on dain's comments, others are also asking about. Here are the details (using 3.0.0.RC1): I have two cmp entity beans: Container and Attribute. I also have a stateless session bean called ContainerControl. In this class, there is a method called findByPrimaryKeyMap. This method does a findByPrimaryKey on a Container. It also does a findByContainerId, which returns a Collection of ~ 200 elements on Attribute, causing the performance problem. The findByPrimaryKeyMap method returns what I call a ContainerMap, which encapsulates the two find results as well as build a lookup table of the Collection. I have a web application that does the following: ContainerControl containerControl = Factory.getContainerControl(); ContainerMap containerMap = containerControl.findByPrimaryKeyMap(id,"name"); CollectionMap attributeMap = containerMap.getAttributeMap(); Basically looks up the session bean, does the find and gets the results out of the ContainerMap. When the ContainerMap is built, it iterates the Collection, taking over 100 ms per element. Based on that, each step must still think it is a transaction. Based on the ejb-jar below, I think the session bean ought to be a single transaction, but it isn't. The ContainerControl ejb-jar.xml files looks like: Container Session Beans Container Session Beans ContainerControl com.base2inc.bean.session.container.ContainerControlHome com.base2inc.bean.session.container.ContainerControl com.base2inc.bean.session.container.ContainerControlBean Stateless Bean ContainerValue com.base2inc.bean.session.container.ContainerValueHome com.base2inc.bean.session.container.ContainerValue com.base2inc.bean.session.container.ContainerValueBean Stateless Bean ContainerControl * Required Any idea will be tried. Thanks. > You must use a transaction for your unseen session bean that is accessing > the entity beans. Otherwise, as Dain says, everytime you change a bean in > the collection, it creates a transaction, reads ahead 1000 or so (depending > upon read-ahead limit) then when you edit the bean, it commits the > transaction, which loses all the read-ahead information. Then as you edit > the next bean, it starts the whole process over again. > > If your session bean was called AttributeManager, you would use a > container-transaction like the following in the assembly-descriptor element. > This way, the transactions on the Attribute bean are encompassed by the > transaction on the session bean method that is iterating over the > collection. > > > > AttributeManager > * > > Required > > > Michael > > > -Original Message- > > From: Frank Morton [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, April 23, 2002 11:50 AM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-user] CMP: Iterate Collection Performance Killer > > > > > > > Use a transaction or turn off read ahead. You are basically reading > > > ahead data, tossing the read-ahead information out, and > > then repeating. > > > > > > -dain > > > > Thanks for your response. > > > > Sorry for my confusion, but I am. Your doc states to use > > with the on-load for this exact case, but doesn't > > seem to make a difference at this point. You are saying strategy=none > > is the right thing to do? I tried that, too, which doesn't > > appear to make > > any difference. Please clarify this. There is a lot of contradictory > > info on the web about this. I also tried setting in > > standardjaws.xml to true and false, neither of which seemed to > > make any difference. Seems no matter what I do, I get the > > same behavior, so I must be missing something. > > > > While I'm irritating you, can you explain exactly how or refer me to > > someplace that explains exactly how to use a transaction to speed up > > reading Collections. > > > > Thanks. I'm guessing I'm not the only one that needs to know > > about this. > > > > Frank > > > > Here is my ejb-jar.xml file in case it is of use to you: > > > > > > > > > > Attribute Management > > Attribute Management > > > > > > > >Attribute > >Attribute > > > > com.base2inc.bean.entity.attribute.AttributeHome local-home> > > > > com.base2inc.bean.entity.attribute.Attribute > > > > com.base2inc.bean.entity.attribute.AttributeBean > jb-class> > >Container > >java.lang.Long > >False > >2.x > > > > idBIGINT > type> > ld> > > > > containerIdBIGI > > NT > > > > > > containerType > >
[JBoss-user] Roadmap?
I am new to the list so I am not real familiar with the release cycles. So I went looking around the site for a road-map but was unable to find one. I am trying to find out when (approximately) when JBoss 3.0 will be released. If it's soon and will beat my product I be able say my application works with "JBoss 3.0" otherwise I have to say "JBoss 3.0 beta". Obviously leaving off the "beta" would be preferred... So, is there a road-map someplace and I just missed it? If not can someone give me some approximation on when there will be 3.0 full release? Thanks, /mike ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] EJB deployment warnings
> And in SectionLocalHome I have: public void remove() throws > javax.ejb.RemoveException; Remove remove() from the home interface. -- Eric Jain ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] RE: [JBoss-dev] 414 Votes for the RFE 4670071 ... We are in the Top25! ... Go ah ead ...
Title: Message problem is, sun doesn't think it's a bug in the first place, so if it's classified as a bug it will never get fixed -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt HumphreySent: Tuesday, April 23, 2002 1:29 PMTo: 'Jung , Dr. Christoph'; [EMAIL PROTECTED]; 'Jboss-Development'Subject: [JBoss-user] RE: [JBoss-dev] 414 Votes for the RFE 4670071 ... We are in the Top25! ... Go ah ead ... I wonder if issues classified as RFE's are less likely to be fixed/implemented than issues classified as bugs. It seems like those RFE's at the top of that list have been there a LONG time. -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jung , Dr. ChristophSent: Tuesday, April 23, 2002 8:13 AMTo: '[EMAIL PROTECTED]'; Jboss-Development ([EMAIL PROTECTED])Subject: [JBoss-dev] 414 Votes for the RFE 4670071 ... We are in the Top25! ... Go ah ead ... I let it be recatecorized under RFE. Now we are in the Top25! The shown ranking is slightly behind the actual votes (414!). We should be 6th place now. http://developer.java.sun.com/developer/bugParade/top25rfes.html You are a great bunch of Java connaisseurs ;-) Go ahead, tell your grandma to give her three votes! http://developer.java.sun.com/developer/bugParade/bugs/4670071.html CGJ
[JBoss-user] RE: [JBoss-dev] 414 Votes for the RFE 4670071 ... We are in the Top25! ... Go ah ead ...
Title: Message I wonder if issues classified as RFE's are less likely to be fixed/implemented than issues classified as bugs. It seems like those RFE's at the top of that list have been there a LONG time. -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jung , Dr. ChristophSent: Tuesday, April 23, 2002 8:13 AMTo: '[EMAIL PROTECTED]'; Jboss-Development ([EMAIL PROTECTED])Subject: [JBoss-dev] 414 Votes for the RFE 4670071 ... We are in the Top25! ... Go ah ead ... I let it be recatecorized under RFE. Now we are in the Top25! The shown ranking is slightly behind the actual votes (414!). We should be 6th place now. http://developer.java.sun.com/developer/bugParade/top25rfes.html You are a great bunch of Java connaisseurs ;-) Go ahead, tell your grandma to give her three votes! http://developer.java.sun.com/developer/bugParade/bugs/4670071.html CGJ
Re: [JBoss-user] CMP: Iterate Collection Performance Killer
danch wrote: > Dain Sundstrom wrote: > >> Frank Morton wrote:> >> >>> I tried that, too, which doesn't appear to make >>> any difference. Please clarify this. There is a lot of contradictory >>> info on the web about this. I also tried setting in >>> standardjaws.xml to true and false, neither of which seemed to >>> make any difference. >> >> >> >> >> That won't work. It shouldn't even boot. Check the dtd. > > > > ? standardjaws.xml is just ignored in jboss3, i'n'it? > Ya, didn't read to close. Change standardjbosscmp-jdbc.xml instead. -dain ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] CMP: Iterate Collection Performance Killer
Dain Sundstrom wrote: > Frank Morton wrote:> >> I tried that, too, which doesn't appear to make >> any difference. Please clarify this. There is a lot of contradictory >> info on the web about this. I also tried setting in >> standardjaws.xml to true and false, neither of which seemed to >> make any difference. > > > > That won't work. It shouldn't even boot. Check the dtd. ? standardjaws.xml is just ignored in jboss3, i'n'it? -danch ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] CMP: Iterate Collection Performance Killer
Frank Morton wrote: >>Use a transaction or turn off read ahead. You are basically reading >>ahead data, tossing the read-ahead information out, and then repeating. >> >>-dain >> > > Thanks for your response. > > Sorry for my confusion, but I am. Your doc states to use > with the on-load for this exact case, but doesn't > seem to make a difference at this point. You are saying strategy=none > is the right thing to do? No, it is just one of the two (good) options. > I tried that, too, which doesn't appear to make > any difference. Please clarify this. There is a lot of contradictory > info on the web about this. I also tried setting in > standardjaws.xml to true and false, neither of which seemed to > make any difference. That won't work. It shouldn't even boot. Check the dtd. > Seems no matter what I do, I get the > same behavior, so I must be missing something. Start a transaction, do your work, commit the transaction. > While I'm irritating you, can you explain exactly how or refer me to > someplace that explains exactly how to use a transaction to speed up > reading Collections. Depends where this code is. If it is in an EJB, just set the method to Required. If it is in a web app, lookup the user transaction in jndi, start it, and commit it. Try the book at theserverside.com, or search google for "ejb user transaction". > Thanks. I'm guessing I'm not the only one that needs to know about this. You are about the 10th this week. We need a FAQ, but I'm to busy to write it, so I'm not allowed to complain. -dain ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] CMP: Iterate Collection Performance Killer
> Use a transaction or turn off read ahead. You are basically reading > ahead data, tossing the read-ahead information out, and then repeating. > > -dain Thanks for your response. Sorry for my confusion, but I am. Your doc states to use with the on-load for this exact case, but doesn't seem to make a difference at this point. You are saying strategy=none is the right thing to do? I tried that, too, which doesn't appear to make any difference. Please clarify this. There is a lot of contradictory info on the web about this. I also tried setting in standardjaws.xml to true and false, neither of which seemed to make any difference. Seems no matter what I do, I get the same behavior, so I must be missing something. While I'm irritating you, can you explain exactly how or refer me to someplace that explains exactly how to use a transaction to speed up reading Collections. Thanks. I'm guessing I'm not the only one that needs to know about this. Frank Here is my ejb-jar.xml file in case it is of use to you: Attribute Management Attribute Management Attribute Attribute com.base2inc.bean.entity.attribute.AttributeHome com.base2inc.bean.entity.attribute.Attribute com.base2inc.bean.entity.attribute.AttributeBean Container java.lang.Long False 2.x idBIGINT containerIdBIGINT containerType name value id on-load 255 1000 Attribute * Required Frank Morton wrote: > > > Using 3.0.0RC1 with PostgreSQL underneath. Just converted > > to using a Local Interface, but didn't make as much performance > > difference as I hoped. > > > > I have a case where I need to iterate a Collection resulting from > > a finder method with an entity bean. Since the collection might have > > 200 items, performance is very bad iterating the Collection. > > (I do have an index on the field used for finding). > > > > Using a Collection in the first place is what I would like to do > > since some of the elements require an update. But, since I > > know I will be looking at each item in the Collection, is there > > some way to fetch the content of the collection as a group > > prior to iterating instead of getting killed by the performance > > of fetching one at a time? > > > > TIA. > > > > > > ___ > > JBoss-user mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] JBoss and jbunit
Hi, I don't know if anyone here has used jbunit (http://dbunit.sourceforge.net/) with JBoss but if anyone has I'd appreciate some help. I am trying a simple operation to populate the database with data from the jbunit dataset from within a testcase (running within jboss, using cactus). Initially I found that it would run but no data would appear in the DB. Looking at the DB logs I saw that all the operations were being roled back, but no errors were appearing from my testcase. I was using a DB connection from the Jboss pool (PostgresDS). I then tried it again but this time making a database connection manually. This worked okay. I have since tried several different methods and have found the following: - It'll work fine when using a database connection manually created. - It'll fail when trying to use a DB connection from JBoss's Postgres datasource pool. Has anyone used jbunit before and would they have any advice? I am assuming it's a problem caused by the fact that an "external" (if you could call it that) entity is trying to use JBoss DB connections. More information can be found from my post to the jbunit mailing list: http://www.geocrawler.com/lists/3/SourceForge/20449/0/8463589/ and a follow up at: http://www.geocrawler.com/lists/3/SourceForge/20449/0/8471840/ I am currently trying to change the current commit option used by JBoss but this is the first time I have really looked at this, so it'll take me a little while to figure it out. Any ideas, advice would be appreciated! All the best, Tim msg15493/bin0.bin Description: application/ms-tnef
Re: [JBoss-user] CMP: Iterate Collection Performance Killer
Use a transaction or turn off read ahead. You are basically reading ahead data, tossing the read-ahead information out, and then repeating. -dain Frank Morton wrote: > Using 3.0.0RC1 with PostgreSQL underneath. Just converted > to using a Local Interface, but didn't make as much performance > difference as I hoped. > > I have a case where I need to iterate a Collection resulting from > a finder method with an entity bean. Since the collection might have > 200 items, performance is very bad iterating the Collection. > (I do have an index on the field used for finding). > > Using a Collection in the first place is what I would like to do > since some of the elements require an update. But, since I > know I will be looking at each item in the Collection, is there > some way to fetch the content of the collection as a group > prior to iterating instead of getting killed by the performance > of fetching one at a time? > > TIA. > > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user > ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] CMP: Iterate Collection Performance Killer
I'm not sure of all the details, but you want to use cmp2 and investigate the read-ahead stuff Dain implemented. Also you need to make sure your transactions are large enough to include all the access to the whole collection. david jencks On 2002.04.23 11:08:10 -0400 Frank Morton wrote: > Using 3.0.0RC1 with PostgreSQL underneath. Just converted > to using a Local Interface, but didn't make as much performance > difference as I hoped. > > I have a case where I need to iterate a Collection resulting from > a finder method with an entity bean. Since the collection might have > 200 items, performance is very bad iterating the Collection. > (I do have an index on the field used for finding). > > Using a Collection in the first place is what I would like to do > since some of the elements require an update. But, since I > know I will be looking at each item in the Collection, is there > some way to fetch the content of the collection as a group > prior to iterating instead of getting killed by the performance > of fetching one at a time? > > TIA. > > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user > > ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] CMP: Iterate Collection Performance Killer
Using 3.0.0RC1 with PostgreSQL underneath. Just converted to using a Local Interface, but didn't make as much performance difference as I hoped. I have a case where I need to iterate a Collection resulting from a finder method with an entity bean. Since the collection might have 200 items, performance is very bad iterating the Collection. (I do have an index on the field used for finding). Using a Collection in the first place is what I would like to do since some of the elements require an update. But, since I know I will be looking at each item in the Collection, is there some way to fetch the content of the collection as a group prior to iterating instead of getting killed by the performance of fetching one at a time? TIA. ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] RE: log4j
Eric, I have seen this problem with WebLogic, but not with JBoss, so I didn't want to lead you off in the wrong direction. Also note that I have not used a 2.x version in quite some time so I don't know how relevant this information will be to that version. As far as I know there are two ways to include third-party jars or classes in your EJB jar. One is to unpack all the classes from the original jar and include them the EJB jar. (Personally, I always hated having to do this because it felt kludgy.) The other way is to package everything in a EAR and include the third party jars in the EAR off the root or in a lib/ directory. In this case I believe you have to specify them in the Class-Path element of the jars manifest file (i.e. "Class-Path: lib/log4j.jar"). I'm sure you already knew both of those but I wanted to go over it just to make sure. The problem I ran into with WebLogic was that the class I had which was using Log4j was being packaged in the EJB jar (and thereby loaded by the EJB's class loader) and being used in the webapp. Since I was packaging the log4j.jar in the WEB-INF/lib directory the EJB class didn't have access to it. I solved this by fixing my build script to only include the absolute essential classes in the EJB jar. However, since it sounds like you need to have access to the log4j classes in the EJB jar and webapp the best (and I think only) way you can solve this is by packaging Log4j in the EAR jar rather than the EJB jar. I have no idea if this helped at all, but maybe it sparked some thoughts in you head that may lead to a solution... /mike On Tue, 2002-04-23 at 06:46, Eric Kaplan wrote: > ok, now i feel like i'm being ignored. is this is a difficult question? i > see other people encountered this same problem, > but have tried various things and nothing seems to fix this. can someone > please tell me, this is critical for the work > we're doing. if you can't use log4j with jboss without great pain, it's a > problem. > > > -Original Message- > > From: Eric Kaplan [mailto:[EMAIL PROTECTED]] > > Sent: Monday, April 22, 2002 2:12 PM > > To: [EMAIL PROTECTED] > > Subject:log4j > > > > I had posed this question a while ago and never actually got an answer > > that worked. If I instantiate a static > > Category in one of my beans, I get the following error upon loading. This > > is jboss 2.4.1. Yes, I'm behind a bit, > > but that's because when I tried to upgrade to 2.4.4 I got some errors > > which I have not had time to resolve. > > What needs to happen here? > > > > Thanks > > > > Eric > > > > [Verifier] java.lang.NoClassDefFoundError: org/apache/log4j/Category > > [Verifier] at > > com.armanta.ejb.coldefs.ColdefsMasterBean.(ColdefsMas > > terBean.java:103) > > [Verifier] at java.lang.Class.newInstance0(Native Method) > > [Verifier] at java.lang.Class.newInstance(Class.java:237) > > [Verifier] at > > org.jboss.verifier.strategy.AbstractVerifier.hasDefaultConstr > > uctor(AbstractVerifier.java:356) > > [Verifier] at > > org.jboss.verifier.strategy.EJBVerifier11.verifySessionBean(E > > JBVerifier11.java:630) > > [Verifier] at > > org.jboss.verifier.strategy.EJBVerifier11.checkSession(EJBVer > > ifier11.java:93) > > [Verifier] at > > org.jboss.verifier.BeanVerifier.verify(BeanVerifier.java:134) > > > > [Verifier] at > > org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:4 > > 67) > > [Verifier] at > > org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:3 > > 69) > > [Verifier] at > > org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:3 > > 04) > > [Verifier] at java.lang.reflect.Method.invoke(Native Method) > > [Verifier] at > > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl > > .java:1628) > > [Verifier] at > > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl > > .java:1523) > > [Verifier] at > > org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.j > > ava:494) > > [Verifier] at > > org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeploy > > er.java:468) > > [Verifier] at > > org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:20 > > 8) > > [Verifier] at java.lang.reflect.Method.invoke(Native Method) > > [Verifier] at > > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl > > .java:1628) > > [Verifier] at > > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl > > .java:1523) > > [Verifier] at > > org.jboss.ejb.AutoDeployer.deploy(AutoDeployer.java:379) > > [Verifier] at org.jboss.ejb.AutoDeployer.run(AutoDeployer.java:217) > > [Verifier] at > > org.jboss.ejb.AutoDeployer.startService(AutoDeployer.java:353 > > ) > > [Verifier] at > > org.jboss.util.ServiceMBeanSupport.start(ServiceMBeanSupport. > > java:107) > > [Verifier] at java.lang.reflect.Method.invoke(Native Method) > > [Verifier] at > > com.sun.management.jmx.
RE: [JBoss-user] RE: log4j
Title: RE: [JBoss-user] RE: log4j
I'll throw this out, though it may not directly relate to your problem..
We encountered a VerifyError when trying to call the Logger, part of log4j 1.2 beta, that isn't part of log4j1.1.3 that is distributed with Jboss 3 (not sure about 2.4). I simply removed references to Logger and used Category.getInstance("foo") and was able to get everything to work. It seems that the jboss custom classloaders obey the Java way of doing things and prefer their log4j rather than one packaged within your own ear or war. So, you will have to use 1.1.3 log4j. As for your class not found, I'm not sure of the exact problem, other than possibly the need for an entry in your ejb's manifest such as:
Classpath: log4j.jar (or maybe lib/log4j.jar)
HTH,
James
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Eric Kaplan
Sent: Tuesday, April 23, 2002 8:46 AM
To: Eric Kaplan; [EMAIL PROTECTED]
Subject: [JBoss-user] RE: log4j
ok, now i feel like i'm being ignored. is this is a difficult question? i see other people encountered this same problem,
but have tried various things and nothing seems to fix this. can someone please tell me, this is critical for the work
we're doing. if you can't use log4j with jboss without great pain, it's a problem.
-Original Message-
From: Eric Kaplan [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 22, 2002 2:12 PM
To: [EMAIL PROTECTED]
Subject: log4j
I had posed this question a while ago and never actually got an answer that worked. If I instantiate a static
Category in one of my beans, I get the following error upon loading. This is jboss 2.4.1. Yes, I'm behind a bit,
but that's because when I tried to upgrade to 2.4.4 I got some errors which I have not had time to resolve.
What needs to happen here?
Thanks
Eric
[Verifier] java.lang.NoClassDefFoundError: org/apache/log4j/Category
[Verifier] at com.armanta.ejb.coldefs.ColdefsMasterBean.(ColdefsMas
terBean.java:103)
[Verifier] at java.lang.Class.newInstance0(Native Method)
[Verifier] at java.lang.Class.newInstance(Class.java:237)
[Verifier] at org.jboss.verifier.strategy.AbstractVerifier.hasDefaultConstr
uctor(AbstractVerifier.java:356)
[Verifier] at org.jboss.verifier.strategy.EJBVerifier11.verifySessionBean(E
JBVerifier11.java:630)
[Verifier] at org.jboss.verifier.strategy.EJBVerifier11.checkSession(EJBVer
ifier11.java:93)
[Verifier] at org.jboss.verifier.BeanVerifier.verify(BeanVerifier.java:134)
[Verifier] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:4
67)
[Verifier] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:3
69)
[Verifier] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:3
04)
[Verifier] at java.lang.reflect.Method.invoke(Native Method)
[Verifier] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl
.java:1628)
[Verifier] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl
.java:1523)
[Verifier] at org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.j
ava:494)
[Verifier] at org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeploy
er.java:468)
[Verifier] at org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:20
8)
[Verifier] at java.lang.reflect.Method.invoke(Native Method)
[Verifier] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl
.java:1628)
[Verifier] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl
.java:1523)
[Verifier] at org.jboss.ejb.AutoDeployer.deploy(AutoDeployer.java:379)
[Verifier] at org.jboss.ejb.AutoDeployer.run(AutoDeployer.java:217)
[Verifier] at org.jboss.ejb.AutoDeployer.startService(AutoDeployer.java:353
)
[Verifier] at org.jboss.util.ServiceMBeanSupport.start(ServiceMBeanSupport.
java:107)
[Verifier] at java.lang.reflect.Method.invoke(Native Method)
[Verifier] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl
.java:1628)
[Verifier] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl
.java:1523)
[Verifier] at org.jboss.configuration.ConfigurationService$ServiceProxy.inv
oke(ConfigurationService.java:836)
[Verifier] at $Proxy0.start(Unknown Source)
[Verifier] at org.jboss.util.ServiceControl.start(ServiceControl.java:81)
[Verifier] at java.lang.reflect.Method.invoke(Native Method)
[Verifier] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl
.java:1628)
[Verifier] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl
.java:1523)
[Verifier] at org.jboss.Main.(Main.java:210)
[Verifier] at org.jboss.Main$1.run(Main.java:116)
[Verifier] at java.security.AccessController.doPrivileged(Native Method)
[Verifier] at org.jboss.Main.main(Main.java:112)
Eric Kaplan
Re: [JBoss-user] RE: log4j
Just a quick idea - you aren't including log4j.jar in any of your application deployment units are you? Just use the one that is already in the jboss classpath. If I'm way off, feel free to ignore me but just thought I'd check. David -- Eric Kaplan wrote: > ok, now i feel like i'm being ignored. is this is a difficult question? i > see other people encountered this same problem, > but have tried various things and nothing seems to fix this. can someone > please tell me, this is critical for the work > we're doing. if you can't use log4j with jboss without great pain, it's a > problem. > > >> -Original Message- >>From: Eric Kaplan [mailto:[EMAIL PROTECTED]] >>Sent: Monday, April 22, 2002 2:12 PM >>To: [EMAIL PROTECTED] >>Subject: log4j >> >>I had posed this question a while ago and never actually got an answer >>that worked. If I instantiate a static >>Category in one of my beans, I get the following error upon loading. This >>is jboss 2.4.1. Yes, I'm behind a bit, >>but that's because when I tried to upgrade to 2.4.4 I got some errors >>which I have not had time to resolve. >>What needs to happen here? >> >>Thanks >> >>Eric >> >>[Verifier] java.lang.NoClassDefFoundError: org/apache/log4j/Category >>[Verifier] at >>com.armanta.ejb.coldefs.ColdefsMasterBean.(ColdefsMas >>terBean.java:103) >>[Verifier] at java.lang.Class.newInstance0(Native Method) >>[Verifier] at java.lang.Class.newInstance(Class.java:237) >>[Verifier] at >>org.jboss.verifier.strategy.AbstractVerifier.hasDefaultConstr >>uctor(AbstractVerifier.java:356) >>[Verifier] at >>org.jboss.verifier.strategy.EJBVerifier11.verifySessionBean(E >>JBVerifier11.java:630) >>[Verifier] at >>org.jboss.verifier.strategy.EJBVerifier11.checkSession(EJBVer >>ifier11.java:93) >>[Verifier] at >>org.jboss.verifier.BeanVerifier.verify(BeanVerifier.java:134) >> >>[Verifier] at >>org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:4 >>67) >>[Verifier] at >>org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:3 >>69) >>[Verifier] at >>org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:3 >>04) >>[Verifier] at java.lang.reflect.Method.invoke(Native Method) >>[Verifier] at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl >>.java:1628) >>[Verifier] at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl >>.java:1523) >>[Verifier] at >>org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.j >>ava:494) >>[Verifier] at >>org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeploy >>er.java:468) >>[Verifier] at >>org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:20 >>8) >>[Verifier] at java.lang.reflect.Method.invoke(Native Method) >>[Verifier] at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl >>.java:1628) >>[Verifier] at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl >>.java:1523) >>[Verifier] at >>org.jboss.ejb.AutoDeployer.deploy(AutoDeployer.java:379) >>[Verifier] at org.jboss.ejb.AutoDeployer.run(AutoDeployer.java:217) >>[Verifier] at >>org.jboss.ejb.AutoDeployer.startService(AutoDeployer.java:353 >>) >>[Verifier] at >>org.jboss.util.ServiceMBeanSupport.start(ServiceMBeanSupport. >>java:107) >>[Verifier] at java.lang.reflect.Method.invoke(Native Method) >>[Verifier] at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl >>.java:1628) >>[Verifier] at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl >>.java:1523) >>[Verifier] at >>org.jboss.configuration.ConfigurationService$ServiceProxy.inv >>oke(ConfigurationService.java:836) >>[Verifier] at $Proxy0.start(Unknown Source) >>[Verifier] at >>org.jboss.util.ServiceControl.start(ServiceControl.java:81) >>[Verifier] at java.lang.reflect.Method.invoke(Native Method) >>[Verifier] at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl >>.java:1628) >>[Verifier] at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl >>.java:1523) >>[Verifier] at org.jboss.Main.(Main.java:210) >>[Verifier] at org.jboss.Main$1.run(Main.java:116) >>[Verifier] at java.security.AccessController.doPrivileged(Native >>Method) >>[Verifier] at org.jboss.Main.main(Main.java:112) >>Eric Kaplan >>Armanta, Inc. >>55 Madison Ave. >>Morristown, NJ 07960 >>Phone: (973) 326-9600 >> > -- - David Ward [EMAIL PROTECTED] http://www.dotech.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] RE: log4j
ok, now i feel like i'm being ignored. is this is a difficult question? i see other people encountered this same problem, but have tried various things and nothing seems to fix this. can someone please tell me, this is critical for the work we're doing. if you can't use log4j with jboss without great pain, it's a problem. > -Original Message- > From: Eric Kaplan [mailto:[EMAIL PROTECTED]] > Sent: Monday, April 22, 2002 2:12 PM > To: [EMAIL PROTECTED] > Subject: log4j > > I had posed this question a while ago and never actually got an answer > that worked. If I instantiate a static > Category in one of my beans, I get the following error upon loading. This > is jboss 2.4.1. Yes, I'm behind a bit, > but that's because when I tried to upgrade to 2.4.4 I got some errors > which I have not had time to resolve. > What needs to happen here? > > Thanks > > Eric > > [Verifier] java.lang.NoClassDefFoundError: org/apache/log4j/Category > [Verifier] at > com.armanta.ejb.coldefs.ColdefsMasterBean.(ColdefsMas > terBean.java:103) > [Verifier] at java.lang.Class.newInstance0(Native Method) > [Verifier] at java.lang.Class.newInstance(Class.java:237) > [Verifier] at > org.jboss.verifier.strategy.AbstractVerifier.hasDefaultConstr > uctor(AbstractVerifier.java:356) > [Verifier] at > org.jboss.verifier.strategy.EJBVerifier11.verifySessionBean(E > JBVerifier11.java:630) > [Verifier] at > org.jboss.verifier.strategy.EJBVerifier11.checkSession(EJBVer > ifier11.java:93) > [Verifier] at > org.jboss.verifier.BeanVerifier.verify(BeanVerifier.java:134) > > [Verifier] at > org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:4 > 67) > [Verifier] at > org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:3 > 69) > [Verifier] at > org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:3 > 04) > [Verifier] at java.lang.reflect.Method.invoke(Native Method) > [Verifier] at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl > .java:1628) > [Verifier] at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl > .java:1523) > [Verifier] at > org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.j > ava:494) > [Verifier] at > org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeploy > er.java:468) > [Verifier] at > org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:20 > 8) > [Verifier] at java.lang.reflect.Method.invoke(Native Method) > [Verifier] at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl > .java:1628) > [Verifier] at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl > .java:1523) > [Verifier] at > org.jboss.ejb.AutoDeployer.deploy(AutoDeployer.java:379) > [Verifier] at org.jboss.ejb.AutoDeployer.run(AutoDeployer.java:217) > [Verifier] at > org.jboss.ejb.AutoDeployer.startService(AutoDeployer.java:353 > ) > [Verifier] at > org.jboss.util.ServiceMBeanSupport.start(ServiceMBeanSupport. > java:107) > [Verifier] at java.lang.reflect.Method.invoke(Native Method) > [Verifier] at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl > .java:1628) > [Verifier] at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl > .java:1523) > [Verifier] at > org.jboss.configuration.ConfigurationService$ServiceProxy.inv > oke(ConfigurationService.java:836) > [Verifier] at $Proxy0.start(Unknown Source) > [Verifier] at > org.jboss.util.ServiceControl.start(ServiceControl.java:81) > [Verifier] at java.lang.reflect.Method.invoke(Native Method) > [Verifier] at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl > .java:1628) > [Verifier] at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl > .java:1523) > [Verifier] at org.jboss.Main.(Main.java:210) > [Verifier] at org.jboss.Main$1.run(Main.java:116) > [Verifier] at java.security.AccessController.doPrivileged(Native > Method) > [Verifier] at org.jboss.Main.main(Main.java:112) > Eric Kaplan > Armanta, Inc. > 55 Madison Ave. > Morristown, NJ 07960 > Phone: (973) 326-9600 > winmail.dat Description: application/ms-tnef
[JBoss-user] different transaction context ?
Does anyone know what could cause this exception ? It happens when I do sessionContext.setRollbackOnly(); in my stateful session bean. In the same method SFSB called SLSB. SFSB has Required, SLSB has Mandatory TX attribute on all methods. Maris Orbidans [ERROR,DataAccess] TRANSACTION ROLLBACK EXCEPTION: javax.transaction.TransactionRolledbackException: Application Error: tried to enter Stateful bean with different transaction context; nested exception is: java.rmi.RemoteException: Application Error: tried to enter Stateful bean with different tra nsaction context java.rmi.RemoteException: Application Error: tried to enter Stateful bean with different transaction context at org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invoke(Compiled Code)@f850ba0 at org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext(Compiled Code)@f659720 at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(Compiled Code)@f6572a0 at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(Compiled Code)@f850b10 at org.jboss.ejb.plugins.LogInterceptor.invoke(Compiled Code)@f850780 at org.jboss.ejb.StatefulSessionContainer.invoke(Compiled Code)@f850730 at org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(Compiled Code)@f850540 at java.lang.reflect.Method.invoke(Native Method)@d6f5c3e at sun.rmi.server.UnicastServerRef.dispatch(Compiled Code)@f6e0fb0 at sun.rmi.transport.Transport$1.run(Compiled Code)@f6e0e30 at java.security.AccessController.doPrivileged(Native Method)@d1f436c at sun.rmi.transport.Transport.serviceCall(Compiled Code)@f6e0700 at sun.rmi.transport.tcp.TCPTransport.handleMessages(Compiled Code)@f42f890 at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Compiled Code)@f42eb50 at java.lang.Thread.run(Compiled Code)@d133880 at java.lang.Thread.startThreadFromVM(Compiled Code)@d133720 --- End of stack trace ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] App development with JBoss 3
Hello, I have not tried with JBoss 3, thouth what I do with JBoss2.4.4 is: Assume you have an expanded ejb-jar like this: c:/someear/someEJB.jar/META-INF/ejb-jar.xml c:/someear/someEJB.jar/ c:/someear/META-INF/application.xml 1. specify deploy directories in jboss.conf. At "Auto deployment", there's a tag whose attribute is "URLs". Specifiy directories as an element. ../deploy,../deploy/lib,c:/someear 2. redeploy ejb. Touch the application.xml 3. Note. a)With JDK1.4, you don't even need redeployment if your modifications are hot-swappable( like modifing codes in a method. ). As for JSP/Servlet, I use another JVM and run tomcat. Put ejb-jars in WEB-INF/lib. And for the "EAR" option, I just write an ANT target which combines WARs and EJB-JARs. Hope this helps. Regards, Shunsuke Masuda - Original Message - From: "Simon Stewart" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, April 23, 2002 2:42 AM Subject: [JBoss-user] App development with JBoss 3 > I'm currently developing my app heavily, and there are many small, > incremental changes that I make to one file at a time (for example, > tweaking the HTML in a JSP) It would be extremely useful if I didn't > need to prepare an EAR file every time I make a change. Is there any > way to persuade JBoss to let me work on "live" files? > > I know that Orion offers a feature like this via its "development > mode", and Tomcat has something similar too. Tomcat on its own isn't > up to the task, because I want to use EJBs, etc hosted in JBoss, and > at the end of the day, I do want to have the option of shipping an EAR > file with the servlets and JSPs within a WAR. > > Any help on this would be appreciated. > > Regards, > > Simon > > -- > Darn it, who spiked my coffee with water?! > -- Larry Wall in <[EMAIL PROTECTED]> > > > ___ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] 414 Votes for the RFE 4670071 ... We are in the Top25! ... Go ahead ...
Title: Nachricht I let it be recatecorized under RFE. Now we are in the Top25! The shown ranking is slightly behind the actual votes (414!). We should be 6th place now. http://developer.java.sun.com/developer/bugParade/top25rfes.html You are a great bunch of Java connaisseurs ;-) Go ahead, tell your grandma to give her three votes! http://developer.java.sun.com/developer/bugParade/bugs/4670071.html CGJ
[JBoss-user] EJB deployment warnings
Deploying entity beans with local interfaces I see these warnings:
INFO [EJBDeployer]
Bean : Section
Method : public abstract void remove() throws RemoveException
Section: 12.2.1
Warning: Each local home method must match a method defined in the entity
bean class.
In SectionEJB I have: public void ejbRemove() throws RemoveException { }
And in SectionLocalHome I have: public void remove() throws
javax.ejb.RemoveException;
What does this warning mean?
And this follows the preceding:
INFO [EJBDeployer]
Bean : Section
Section: 12.2.1
Warning: null
alex
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] App development with JBoss 3
On Mon, Apr 22, 2002 at 06:42:53PM +0100, Simon Stewart wrote:
> I'm currently developing my app heavily, and there are many small,
> incremental changes that I make to one file at a time (for example,
> tweaking the HTML in a JSP) It would be extremely useful if I didn't
> need to prepare an EAR file every time I make a change. Is there any
> way to persuade JBoss to let me work on "live" files?
Answering my own question, so I hope none of you mind. Turns out that
all you need to do is to recreate your EAR's structure as a directory
tree in your server's deploy directory.
For example:
sms@lauren:~$ jar tvf foo.ear
0 Mon Apr 22 18:54:38 BST 2002 META-INF/
45 Mon Apr 22 18:54:38 BST 2002 META-INF/MANIFEST.MF
0 Thu Apr 18 15:29:50 BST 2002 META-INF/lib/
14745 Thu Apr 18 15:29:58 BST 2002 ejb.jar
573 Mon Apr 22 18:54:38 BST 2002 META-INF/application.xml
196991 Thu Apr 18 15:30:00 BST 2002 oscore.jar
184956 Thu Apr 18 15:30:00 BST 2002 log4j.jar
14516 Thu Apr 18 17:00:12 BST 2002 web.war
105977 Thu Apr 18 15:30:00 BST 2002 osuser.jar
becomes:
sms@lauren:~/jboss-live$ ls -F ${JBOSS_HOME}/server/default/deploy/foo.ear/
ejb.jar log4j.jar META-INF/ oscore.jar osuser.jar web.war/
sms@lauren:~/jboss-live$ ls -F ${JBOSS_HOME}/server/default/deploy/foo.ear/web.war/
cms/ index.html jsp/ META-INF/ _standard.css WEB-INF/
I hope that's been explained clearly enough. I can explain a bit more
if anyone wants, but I need to have a play with it. Certainly seems to
pick up changes in JSPs and maybe servlets, but I'm not sure if it'll
redeploy EJBs yet.
Cheers,
Simon
--
"That time in Seattle... was a nightmare. I came out of it dead broke,
without a house, without anything except a girlfriend and a knowledge of
UNIX." "Well, that's something," Avi says. "Normally those two are
mutually exclusive."--Neal Stephenson, "Cryptonomicon"
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] App development with JBoss 3
Simon, With XDoclet and Ant you can automate building and deploying an EAR file. Works for me. Only you still end up with the deploy time of your app and compile time of your jsp before you can check your page. Success, Frank Groot MORSE B.V. www.morse.nl -Original Message- From: Simon Stewart [mailto:[EMAIL PROTECTED]] Sent: Monday, April 22, 2002 19:43 To: [EMAIL PROTECTED] Subject: [JBoss-user] App development with JBoss 3 I'm currently developing my app heavily, and there are many small, incremental changes that I make to one file at a time (for example, tweaking the HTML in a JSP) It would be extremely useful if I didn't need to prepare an EAR file every time I make a change. Is there any way to persuade JBoss to let me work on "live" files? I know that Orion offers a feature like this via its "development mode", and Tomcat has something similar too. Tomcat on its own isn't up to the task, because I want to use EJBs, etc hosted in JBoss, and at the end of the day, I do want to have the option of shipping an EAR file with the servlets and JSPs within a WAR. Any help on this would be appreciated. Regards, Simon -- Darn it, who spiked my coffee with water?! -- Larry Wall in <[EMAIL PROTECTED]> ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Timer MBean
> One more question is: I use JBoss 2.4.4, will it work? > If no, is there as similar way for JBoss 2.4.4? Can't help you there; jboss-service.xml will certainly be different. -- Eric Jain ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Timer MBean
I really thank you! :D One more question is: I use JBoss 2.4.4, will it work? If no, is there as similar way for JBoss 2.4.4? TIA, Loic -Message d'origine- De : Eric Jain [mailto:[EMAIL PROTECTED]] Envoyé : lundi 22 avril 2002 18:54 À : JBoss User Mailing List Cc : Loïc Lefèvre Objet : RE: [JBoss-user] Timer MBean > How can I do to start the session bean > initialization just after the deployment of my > ear? Create a .sar file containing a simple class that implements org.jboss.varia.scheduler.Schedulable and calls your session bean from its perform method. Create a jboss-service.xml file containing the following in the .sar's META-INF directory: true MyScheduler 0 6 -1 jboss.j2ee:service=EJB,jndiName=SomeBeanEJB Finally, add the .sar to the .ear. -- Eric Jain ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
