[JBoss-dev] CVS update: jboss/src/main/org/jboss/metadata ConfigurationMetaData.java
User: patriot1burke Date: 01/09/01 20:25:26 Modified:src/main/org/jboss/metadata ConfigurationMetaData.java Log: changed default from simple to queued locking policy Revision ChangesPath 1.19 +2 -2 jboss/src/main/org/jboss/metadata/ConfigurationMetaData.java Index: ConfigurationMetaData.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/metadata/ConfigurationMetaData.java,v retrieving revision 1.18 retrieving revision 1.19 diff -u -r1.18 -r1.19 --- ConfigurationMetaData.java2001/08/03 17:15:54 1.18 +++ ConfigurationMetaData.java2001/09/02 03:25:26 1.19 @@ -13,7 +13,7 @@ /** The configuration information for an EJB container. * @author mailto:[EMAIL PROTECTED]";>Sebastien Alborini * @author mailto:[EMAIL PROTECTED]";>Scott Stark - * @version $Revision: 1.18 $ + * @version $Revision: 1.19 $ * * Revisions: * 2001/08/02: marcf @@ -54,7 +54,7 @@ // This is to provide backward compatibility with 2.4 series jboss.xml // but it should come from standardjboss alone // marcf:FIXME deprecate the "hardcoded string" - private String lockClass = "org.jboss.ejb.plugins.lock.SimplePessimisticEJBLock"; + private String lockClass = "org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock"; private byte commitOption; private long optionDRefreshRate = 3; private boolean callLogging; ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: [jetty-discuss] Re: Persistant HttpSession
I like the idea of teaming up with the paperclips. If they have something in the works already, and it will support Servlet 2.3 lifecycle and events, as well as pluggable session management, perhaps it would be best if we worked with them for Jetty as well, so we have a similar if not the same thing? Any objections to this? If not, I'll join their list as well and start discussing it with them. -Original Message-From: Greg Wilkins [mailto:[EMAIL PROTECTED]]Sent: Saturday, September 01, 2001 5:51 PMTo: [EMAIL PROTECTED]Cc: Julian Gosnell; [EMAIL PROTECTED]; Bill BurkeSubject: Re: [jetty-discuss] Re: Persistant HttpSessionGuys,I think it is valuable to consider many different implementations ofsession - even bad ones, so we get a good flexible session managerimplementation.Remember that when we look at session persistance and session distributionmechanism - lots of class loader issues will start cropping up. So evenif a EJB based persistent session proves to be horribly inefficient - itwould be a good test of the session classloading to share the classloaderof JBoss etc.But when it comes to production quality session management - I don't thinkwe want to invent the whole wheel ourselves and we should build onthe work of others.A few other things of note here - so we get the abstract model of asession manager right - we should have a good look at other containers.Gnu-paperclips for one is working towards pluggable session managers andI have talked to them before about sharing session managers betweenjetty and paperclips. So it would be good if we had a very very similarAPI so we could just borrow (and donate) session managers. Thus itwould be worthwhile for folks to have a look at what they have done.Secondly, the 2.3 servlet API has lots of session lefecycle and eventsupport in it. So when we abstract the session manager - we shouldbuild in support for those lifecycles. Thus a quick read of the2.3 servlet spec is in order.I'm a little head down bum up at the moment to think about all thisin detail. What I plan is to concentrate on getting a 3.1.0 outin the next week or two. Then immediately start a 3.2.A0 stream inwhich we can break out the session manager and start playing with thisstuff.cheers-- Greg Wilkins<[EMAIL PROTECTED]> GB Phone: +44-(0)7092063462Mort Bay Consulting Australia and UK. Mbl Phone: +61-(0)4 17786631http://www.mortbay.com AU Phone: +61-(0)2 98107029 Yahoo! Groups Sponsor ADVERTISEMENT You can, too! Start here...Height: 345678 ft 01234567891011inWeight:lbs. kg. For the latest information about Jetty, please see http://jetty.mortbay. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
RE: [JBoss-dev] RE: Persistant HttpSession
Dain, I can only speak for our application, but our bottleneck has always been the database, the database, the database. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Dain > Sundstrom > Sent: Saturday, September 01, 2001 4:08 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] RE: Persistant HttpSession > > > For some reason this thread is not repling to the list correctly. > > I think that no matter what you do, if you want a persistent session you > need to send the data off server and the off server location, and > this means > serialization and network traffic (unavoidable in all cases). As for > waiting for the db (which is just a file system in the basic > case), this is > avoidable if you use a multicast system. The tradeoff is that each server > listening to the multicast must process the messages. In a crapy > implementation you get an n-to-the-n star network problem (you > don't get n^n > connections but each server has to process the messages from the n other > servers). > > The real answear the marc presented stands. There a billion possible > solutions and each one has different performance problems. What we in the > jboss group must do is define an interface to allow most (if not all) > implementaions. > > Is there an interface for HttpSession persistence in the web container > layer? > > -dain > > > -Original Message- > > From: Andreas Schaefer [mailto:[EMAIL PROTECTED]] > > Sent: Saturday, September 01, 2001 2:50 PM > > To: Dain Sundstrom > > Subject: Re: [JBoss-dev] RE: Persistant HttpSession > > > > > > Just as IBM WebSphere is doing. But the problem is that > > you introduce the latency of the network and DB for a regular > > simple task. > > On the other side your fail-over and clustering is reduced > > to the one of the DB which can not become the bottleneck. > > > > Andy > > > > - Original Message - > > From: "Dain Sundstrom" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Saturday, September 01, 2001 12:19 PM > > Subject: FW: [JBoss-dev] RE: Persistant HttpSession > > > > > > > I ment to send this to the list, but hit the wrong button. > > > > > > -Original Message- > > > From: Dain Sundstrom > > > Sent: Saturday, September 01, 2001 10:20 AM > > > To: 'Julian Gosnell' > > > Subject: RE: [JBoss-dev] RE: Persistant HttpSession > > > > > > > > > I saw a presentation at JavaOne from HP on thier highly scaleable > > > architecture and they were storing the http sessions into a > > db after each > > > request. The trick was they used a seperate database just > > for storing the > > > http session and this db was highly tuned for this type of > > use. With this > > > type of architecture you could tune the system to have a > > minimal impact > > from > > > the session storage. (As a side note if you know the > > structure of the http > > > session you could make is very fast). > > > > > > -dain > > > > > > > -Original Message- > > > > From: Julian Gosnell [mailto:[EMAIL PROTECTED]] > > > > Sent: Saturday, September 01, 2001 9:47 AM > > > > To: Bill Burke > > > > Cc: Kevin Duffey; Greg Wilkins; > > > > [EMAIL PROTECTED]; > > > > [EMAIL PROTECTED] > > > > Subject: Re: [JBoss-dev] RE: Persistant HttpSession > > > > > > > > > > > > > > > > I understand what you are saying, Bill. > > > > > > > > I am not proposing this as an enterprise level solution. > > > > I am proposing it as a full-featured (distributed/persistant) > > > > but trivial > > > > implementation. > > > > This means we can get it done quickly. More quickly than > > > > perhaps Kevin might > > > > get his solution implemented or a JavaGroups solution > > might get done. > > > > > > > > Because it is very simple, it is unlikely to be buggy. > > > > > > > > Once we have a rock-solid implementation, we can turn around > > > > and look at better > > > > solutions. If you want to write a JavaGroups solution you are > > > > very welcome to. > > > > I don't see anything on your website about persistance, which > > > > I assume is the > > > > reason why your proposed solution would be faster. However I > > > > would be surprised > > > > if it was actually simpler and required less additional > > > > infrastructure (over > > > > and above JBoss, because that is the perspective from which I > > > > am working) than > > > > a CMP solution. > > > > > > > > Besides DB access will only be necessary if a Servlet/JSP > > > > needs to read/write > > > > state. This is not the case with every click on a website. If > > > > the Servlet is > > > > reading/writing state, then is is probably accessing EJBs > > too (JBoss > > > > perspective again), so the cost of one more access may not be > > > > so unpalatable. > > > > > > > > I fully expect CMP to be the slowest solution, but I am not > > > > going to launch > > > > myself into a new problem space without a little recce trip > > > > and that is what my > > > > CMP HttpSession (If I actually wr
RE: [JBoss-dev] RE: Persistant HttpSession
Yes, JavaGroups looks very cool. Sacha Labourey turned me on to this in his first iteration of HA SLSB. I have yet to see a saturation of a 100M switched ethernet so I'm skeptical about all the academics screaming about multicast performance. Would all those Slim Shadys who actually experienced performance problems with multicast, Please stand up, Please stand up, please stand up. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Kevin > Duffey > Sent: Saturday, September 01, 2001 1:23 PM > To: Bill Burke; marc fleury; Julian Gosnell > Cc: Greg Wilkins; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] RE: Persistant HttpSession > > > Bill, > > Looking at JavaGroups it sounds like it would possibly allow a good > mechanism for the HttpSession replication as well. My experience is mostly > with Orion so I have to take my example from what they do. They use > multicast for HttpSession fail-over, so when I clicked on that link and > started reading, it sounded like this may be a possible way for > HttpSession > replication as well. What do you think? I read a few posts on the Orion > lists saying that using multicast can hinder network bandwidth > but I wasn't > sure why this would be. If you set up x number of servers in a cluster to > listen on a specific port for replication messages, wouldn't that only use > one port? I'll have to read up more on multicast. I understand that it > broadcasts out to potentially x number of listeners, but just not > sure about > the semantics of how it works. > > > > -Original Message- > > From: Bill Burke [mailto:[EMAIL PROTECTED]] > > Sent: Saturday, September 01, 2001 10:11 AM > > To: marc fleury; Julian Gosnell > > Cc: Kevin Duffey; Greg Wilkins; [EMAIL PROTECTED]; > > [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] RE: Persistant HttpSession > > > > > > Hey Julian/Marc, > > > > I hope didn't sound rude before. I was just pointing out what I > > think is a > > serious problem in using CMP. > > > > Julian, seriously, take a look at JavaGroups.DistributedHashtable > > http://www.javagroups.com It is really easy to use, and I think > > you'll find > > it really cool. > > > > Marc, the inVM thingy you were talking about before is a > cluster SFSB. I > > agree that using EJB is a good abstration for this. I know jack > > squat about > > Message Driven Beans, but would that be a possibility as well? > > > > Regards, > > > > Bill > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On > Behalf Of marc > > > fleury > > > Sent: Saturday, September 01, 2001 11:47 AM > > > To: Julian Gosnell; Bill Burke > > > Cc: Kevin Duffey; Greg Wilkins; > [EMAIL PROTECTED]; > > > [EMAIL PROTECTED] > > > Subject: RE: [JBoss-dev] RE: Persistant HttpSession > > > > > > > > > reading this reply I feel I should say what is on my mind > > > technologically-wise. > > > > > > It seems to me that you are asking for a EJB semantic and we > > are answering > > > with "persistence" issues. I think it is symptomatic and goes > > back to the > > > larger EJB discussions and particularly the Entity bashing that seems > > > popular these days. > > > > > > They are largely orthogonal issues. You can replace the > > > persistence engine > > > in JBoss. We allow for this, if you want A IN VM STORE WITH > > > REPLICATED JAVA > > > GROUPS as opposed to database access, WHAT PREVENTS US FROM > > DOING IT? (JMX > > > multinode batches of mods :) > > > > > > Julian is saying "I can get to work, manhana on this if I use the EJB > > > patterns". We as JBoss can get to work on this manhana if we > > isolate the > > > store work. Isolation. We have divided the work and the > > implementation of > > > the store is "irrelevant" from Julian's point of view. > > > > > > Bill, you are right, a database solution is probably the worst, but it > > > should not stop Julian from working until WE come up with a > great store. > > > And what really gets me excited is the fact that EJB semantic is > > > natural and > > > the implementation is orthogonal... its the trend... > > > > > > Another example is the Jive forums... they use direct JDBC because the > > > persistence blabla and the replication bla bla bla... Same category of > > > problems the solution is in our camp. > > > > > > marcf > > > > > > |-Original Message- > > > |From: [EMAIL PROTECTED] > > > |[mailto:[EMAIL PROTECTED]]On Behalf Of > > > |Julian Gosnell > > > |Sent: Saturday, September 01, 2001 10:47 AM > > > |To: Bill Burke > > > |Cc: Kevin Duffey; Greg Wilkins; > > [EMAIL PROTECTED]; > > > |[EMAIL PROTECTED] > > > |Subject: Re: [JBoss-dev] RE: Persistant HttpSession > > > | > > > | > > > | > > > |I understand what you are saying, Bill. > > > | > > > |I am not proposing this as an enterprise level solution. > > > |I am proposing it as a full-featured (distributed/persistant) > > but trivial > > > |implementation. > > > |Thi
RE: [JBoss-dev] RE: Persistant HttpSession
Hey, Is Jetty going to become a part of JBoss? Just asking. That would be very cool and make JBoss a true J2ee impl. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Dain > Sundstrom > Sent: Saturday, September 01, 2001 4:08 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] RE: Persistant HttpSession > > > For some reason this thread is not repling to the list correctly. > > I think that no matter what you do, if you want a persistent session you > need to send the data off server and the off server location, and > this means > serialization and network traffic (unavoidable in all cases). As for > waiting for the db (which is just a file system in the basic > case), this is > avoidable if you use a multicast system. The tradeoff is that each server > listening to the multicast must process the messages. In a crapy > implementation you get an n-to-the-n star network problem (you > don't get n^n > connections but each server has to process the messages from the n other > servers). > > The real answear the marc presented stands. There a billion possible > solutions and each one has different performance problems. What we in the > jboss group must do is define an interface to allow most (if not all) > implementaions. > > Is there an interface for HttpSession persistence in the web container > layer? > > -dain > > > -Original Message- > > From: Andreas Schaefer [mailto:[EMAIL PROTECTED]] > > Sent: Saturday, September 01, 2001 2:50 PM > > To: Dain Sundstrom > > Subject: Re: [JBoss-dev] RE: Persistant HttpSession > > > > > > Just as IBM WebSphere is doing. But the problem is that > > you introduce the latency of the network and DB for a regular > > simple task. > > On the other side your fail-over and clustering is reduced > > to the one of the DB which can not become the bottleneck. > > > > Andy > > > > - Original Message - > > From: "Dain Sundstrom" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Saturday, September 01, 2001 12:19 PM > > Subject: FW: [JBoss-dev] RE: Persistant HttpSession > > > > > > > I ment to send this to the list, but hit the wrong button. > > > > > > -Original Message- > > > From: Dain Sundstrom > > > Sent: Saturday, September 01, 2001 10:20 AM > > > To: 'Julian Gosnell' > > > Subject: RE: [JBoss-dev] RE: Persistant HttpSession > > > > > > > > > I saw a presentation at JavaOne from HP on thier highly scaleable > > > architecture and they were storing the http sessions into a > > db after each > > > request. The trick was they used a seperate database just > > for storing the > > > http session and this db was highly tuned for this type of > > use. With this > > > type of architecture you could tune the system to have a > > minimal impact > > from > > > the session storage. (As a side note if you know the > > structure of the http > > > session you could make is very fast). > > > > > > -dain > > > > > > > -Original Message- > > > > From: Julian Gosnell [mailto:[EMAIL PROTECTED]] > > > > Sent: Saturday, September 01, 2001 9:47 AM > > > > To: Bill Burke > > > > Cc: Kevin Duffey; Greg Wilkins; > > > > [EMAIL PROTECTED]; > > > > [EMAIL PROTECTED] > > > > Subject: Re: [JBoss-dev] RE: Persistant HttpSession > > > > > > > > > > > > > > > > I understand what you are saying, Bill. > > > > > > > > I am not proposing this as an enterprise level solution. > > > > I am proposing it as a full-featured (distributed/persistant) > > > > but trivial > > > > implementation. > > > > This means we can get it done quickly. More quickly than > > > > perhaps Kevin might > > > > get his solution implemented or a JavaGroups solution > > might get done. > > > > > > > > Because it is very simple, it is unlikely to be buggy. > > > > > > > > Once we have a rock-solid implementation, we can turn around > > > > and look at better > > > > solutions. If you want to write a JavaGroups solution you are > > > > very welcome to. > > > > I don't see anything on your website about persistance, which > > > > I assume is the > > > > reason why your proposed solution would be faster. However I > > > > would be surprised > > > > if it was actually simpler and required less additional > > > > infrastructure (over > > > > and above JBoss, because that is the perspective from which I > > > > am working) than > > > > a CMP solution. > > > > > > > > Besides DB access will only be necessary if a Servlet/JSP > > > > needs to read/write > > > > state. This is not the case with every click on a website. If > > > > the Servlet is > > > > reading/writing state, then is is probably accessing EJBs > > too (JBoss > > > > perspective again), so the cost of one more access may not be > > > > so unpalatable. > > > > > > > > I fully expect CMP to be the slowest solution, but I am not > > > > going to launch > > > > myself into a new problem space without a little recce trip > > > > and that is what my > > > > CMP HttpSession (If I actually writ
[JBoss-dev] [ jboss-Feature Requests-457650 ] JDO Support
Feature Requests item #457650, was opened at 2001-09-01 18:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376688&aid=457650&group_id=22866 Category: None Group: None Status: Open Priority: 5 Submitted By: Simon Harris (haruki_zaemon) Assigned to: Nobody/Anonymous (nobody) Summary: JDO Support Initial Comment: Now that the JDO spec is "nearly" final, I see a need within the community for an opensource implementation. It would seem to me that the underlying implementation of CMP 2.0 for JBOSS could be readily adapted to support JDO persistence as well. It (jbossjdbc) seems to be a large part of the way there in terms of functionality. I would be more than happy to help. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376688&aid=457650&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: [jetty-discuss] Re: Persistant HttpSession
Guys, I think it is valuable to consider many different implementations of session - even bad ones, so we get a good flexible session manager implementation. Remember that when we look at session persistance and session distribution mechanism - lots of class loader issues will start cropping up. So even if a EJB based persistent session proves to be horribly inefficient - it would be a good test of the session classloading to share the classloader of JBoss etc. But when it comes to production quality session management - I don't think we want to invent the whole wheel ourselves and we should build on the work of others. A few other things of note here - so we get the abstract model of a session manager right - we should have a good look at other containers. Gnu-paperclips for one is working towards pluggable session managers and I have talked to them before about sharing session managers between jetty and paperclips. So it would be good if we had a very very similar API so we could just borrow (and donate) session managers. Thus it would be worthwhile for folks to have a look at what they have done. Secondly, the 2.3 servlet API has lots of session lefecycle and event support in it. So when we abstract the session manager - we should build in support for those lifecycles. Thus a quick read of the 2.3 servlet spec is in order. I'm a little head down bum up at the moment to think about all this in detail. What I plan is to concentrate on getting a 3.1.0 out in the next week or two. Then immediately start a 3.2.A0 stream in which we can break out the session manager and start playing with this stuff. cheers -- Greg Wilkins<[EMAIL PROTECTED]> GB Phone: +44-(0)7092063462 Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631 http://www.mortbay.com AU Phone: +61-(0)2 98107029 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] requirements for build
> For what it's worth, a novice jboss builder's impression: I allocated > half a day to work through the usual incompatibilities, fired off the > build, found and fixed the ANT_HOME problem in 1 minute, reran and...it > worked! Amazing. Congrats to whoever set it up. Great. > I did what I'm sure others encountering the problem will do--changed > build.bat to unset ANT_HOME. It would be convenient for others if this > was always done, as suggested. I think this has been resolved, or at least will be shortly. Thanks for the feedback. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/cmp ActivateEntityCommand.java CMPStoreManager.java CommandFactory.java CreateEntityCommand.java DestroyCommand.java FindEntitiesCommand.java FindEntityCommand.java InitCommand.java InitEntityCommand.java LoadEntitiesCommand.java LoadEntityCommand.java PassivateEntityCommand.java RemoveEntityCommand.java StartCommand.java StopCommand.java StoreEntityCommand.java
User: olegnitz
Date: 01/09/01 15:03:14
Modified:src/main/org/jboss/ejb/plugins/cmp
ActivateEntityCommand.java CMPStoreManager.java
CommandFactory.java CreateEntityCommand.java
DestroyCommand.java FindEntitiesCommand.java
FindEntityCommand.java InitCommand.java
InitEntityCommand.java LoadEntitiesCommand.java
LoadEntityCommand.java PassivateEntityCommand.java
RemoveEntityCommand.java StartCommand.java
StopCommand.java StoreEntityCommand.java
Log:
converted tabs to spaces
Revision ChangesPath
1.3 +4 -4
jboss/src/main/org/jboss/ejb/plugins/cmp/ActivateEntityCommand.java
Index: ActivateEntityCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/ActivateEntityCommand.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ActivateEntityCommand.java2001/08/03 17:15:45 1.2
+++ ActivateEntityCommand.java2001/09/01 22:03:14 1.3
@@ -18,14 +18,14 @@
* initialize the "PersistenceContext" maintianed in the context.
*
* Life-cycle:
- * Tied to CMPStoreManager.
+ * Tied to CMPStoreManager.
*
- * Multiplicity:
- * One per CMPStore.
+ * Multiplicity:
+ * One per CMPStore.
*
* @author mailto:[EMAIL PROTECTED]";>Dain Sundstrom
* @author mailto:[EMAIL PROTECTED]";>Justin Forder
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.3 $
*/
public interface ActivateEntityCommand
{
1.5 +13 -13jboss/src/main/org/jboss/ejb/plugins/cmp/CMPStoreManager.java
Index: CMPStoreManager.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/CMPStoreManager.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- CMPStoreManager.java 2001/08/03 17:15:45 1.4
+++ CMPStoreManager.java 2001/09/01 22:03:14 1.5
@@ -42,17 +42,17 @@
* are the classic EntityBean messages (e.g., activate, passivate...).
*
* Dependency:
- * In general, this package depends as little as possible on other
packages.
+ * In general, this package depends as little as possible on other packages.
* Specifically it depends on container information from org.jboss.ejb, such as
* EntityEnterpriseContext. Additionally, implementations of this class, will
* depend on org.jboss.metadata to aquire information about the entity.
*
* Life-cycle:
- * Tied to the life-cycle of the entity container.
+ * Tied to the life-cycle of the entity container.
*
- * Multiplicity:
- * One per cmp entity bean. This could be less if another implementaion
of
- * EntityPersistenceStore is created and thoes beans use the implementation
+ * Multiplicity:
+ * One per cmp entity bean. This could be less if another implementaion of
+ * EntityPersistenceStore is created and thoes beans use the implementation
*
* @author mailto:[EMAIL PROTECTED]";>Dain Sundstrom
* @author mailto:[EMAIL PROTECTED]";>danch (Dan Christopherson)
@@ -61,7 +61,7 @@
* @author mailto:[EMAIL PROTECTED]";>Joe Shevland
* @author mailto:[EMAIL PROTECTED]";>Justin Forder
* @see org.jboss.ejb.EntityPersistenceStore
- * @version $Revision: 1.4 $
+ * @version $Revision: 1.5 $
*/
public abstract class CMPStoreManager
implements EntityPersistenceStore2
@@ -99,13 +99,13 @@
public void setContainer(Container container) {
this.container = (EntityContainer)container;
}
-
- public Log getLog() {
- return log;
- }
+
+ public Log getLog() {
+ return log;
+ }
- protected abstract CommandFactory createCommandFactory() throws Exception ;
-
+ protected abstract CommandFactory createCommandFactory() throws Exception ;
+
// Container Life cycle commands -
public void init() throws Exception {
@@ -226,7 +226,7 @@
// This class supports tuned updates and read-only entities
public static class PersistenceContext {
- public Map fieldState = new HashMap();
+ public Map fieldState = new HashMap();
}
}
1.3 +4 -4 jboss/src/main/org/jboss/ejb/plugins/cmp/CommandFactory.java
Index: CommandFactory.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/CommandFactory.java,v
retrieving revision 1.2
retrieving
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/cmp/bmp CustomFindByEntitiesCommand.java
User: olegnitz
Date: 01/09/01 15:03:14
Modified:src/main/org/jboss/ejb/plugins/cmp/bmp
CustomFindByEntitiesCommand.java
Log:
converted tabs to spaces
Revision ChangesPath
1.5 +49 -49
jboss/src/main/org/jboss/ejb/plugins/cmp/bmp/CustomFindByEntitiesCommand.java
Index: CustomFindByEntitiesCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/bmp/CustomFindByEntitiesCommand.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- CustomFindByEntitiesCommand.java 2001/09/01 19:50:30 1.4
+++ CustomFindByEntitiesCommand.java 2001/09/01 22:03:14 1.5
@@ -34,57 +34,57 @@
*
* @see org.jboss.ejb.plugins.cmp.jdbc.JDBCFindEntitiesCommand
* @author mailto:[EMAIL PROTECTED]";>Michel de Groot
- * @version $Revision: 1.4 $
+ * @version $Revision: 1.5 $
*/
public class CustomFindByEntitiesCommand implements FindEntitiesCommand {
-// Attributes
+ // Attributes
-/**
- * method that implements the finder
- */
-protected Method finderImplMethod;
-
-// Constructors --
-
-/**
- * Constructs a command which can handle multiple entity finders
- * that are BMP implemented.
- * @param finderMethod the EJB finder method implementation
- */
-public CustomFindByEntitiesCommand(Method finderMethod) {
-finderImplMethod = finderMethod;
-
-Logger.debug("Finder: Custom finder " + finderMethod.getName());
-}
-
-// FindEntitiesCommand implementation -
-
-public FinderResults execute(Method finderMethod,
-Object[] args,
-EntityEnterpriseContext ctx)
-throws Exception
-{
-try {
-// invoke implementation method on ejb instance
-Object result = finderImplMethod.invoke(ctx.getInstance(), args);
-
-// if expected return type is Collection, return as is
-// if expected return type is not Collection, wrap result in Collection
-if(!(result instanceof Collection)) {
-result = Collections.singleton(result);
-}
-return new FinderResults((Collection)result, null, null, null);
-} catch (IllegalAccessException e) {
-throw new FinderException("Unable to access finder implementation: " +
finderImplMethod.getName());
-} catch (IllegalArgumentException e) {
-throw new FinderException("Illegal arguments for finder implementation:
" + finderImplMethod.getName());
-} catch (InvocationTargetException e) {
-Throwable target = e.getTargetException();
-if(target instanceof Exception) {
-throw (Exception)target;
-}
-throw new FinderException("Unable to initialize finder implementation:
" + finderImplMethod.getName());
-}
-}
+ /**
+* method that implements the finder
+*/
+ protected Method finderImplMethod;
+
+ // Constructors --
+
+ /**
+* Constructs a command which can handle multiple entity finders
+* that are BMP implemented.
+* @param finderMethod the EJB finder method implementation
+*/
+ public CustomFindByEntitiesCommand(Method finderMethod) {
+ finderImplMethod = finderMethod;
+
+ Logger.debug("Finder: Custom finder " + finderMethod.getName());
+ }
+
+ // FindEntitiesCommand implementation -
+
+ public FinderResults execute(Method finderMethod,
+ Object[] args,
+ EntityEnterpriseContext ctx)
+ throws Exception
+ {
+ try {
+ // invoke implementation method on ejb instance
+ Object result = finderImplMethod.invoke(ctx.getInstance(), args);
+
+ // if expected return type is Collection, return as is
+ // if expected return type is not Collection, wrap result in Collection
+ if(!(result instanceof Collection)) {
+ result = Collections.singleton(result);
+ }
+ return new FinderResults((Collection)result, null, null, null);
+ } catch (IllegalAccessException e) {
+ throw new FinderException("Unable to access finder implementation: " +
finderImplMethod.getName());
+ } catch (IllegalArgumentException e) {
+ throw new FinderException("Illegal arguments for finder implementation: "
+ finderImplMethod.getName());
+ } catch (InvocationTargetException e) {
+ Throwable tar
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/cmp/bridge CMPFieldBridge.java CMRFieldBridge.java EntityBridge.java EntityBridgeInvocationHandler.java SelectorBridge.java
User: olegnitz
Date: 01/09/01 15:03:15
Modified:src/main/org/jboss/ejb/plugins/cmp/bridge
CMPFieldBridge.java CMRFieldBridge.java
EntityBridge.java
EntityBridgeInvocationHandler.java
SelectorBridge.java
Log:
converted tabs to spaces
Revision ChangesPath
1.4 +23 -23
jboss/src/main/org/jboss/ejb/plugins/cmp/bridge/CMPFieldBridge.java
Index: CMPFieldBridge.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/bridge/CMPFieldBridge.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- CMPFieldBridge.java 2001/08/03 17:15:45 1.3
+++ CMPFieldBridge.java 2001/09/01 22:03:14 1.4
@@ -13,38 +13,38 @@
* CMPFieldBridge represents one cmp field for one entity.
*
* Life-cycle:
- * Tied to the EntityBridge.
+ * Tied to the EntityBridge.
*
- * Multiplicity:
- * One for each entity bean cmp field.
+ * Multiplicity:
+ * One for each entity bean cmp field.
*
* @author mailto:[EMAIL PROTECTED]";>Dain Sundstrom
- * @version $Revision: 1.3 $
+ * @version $Revision: 1.4 $
*/
public interface CMPFieldBridge {
- public String getFieldName();
- public Class getFieldType();
- public boolean isPrimaryKeyMember();
- public boolean isReadOnly();
-
- public Object getInstanceValue(EntityEnterpriseContext ctx);
+ public String getFieldName();
+ public Class getFieldType();
+ public boolean isPrimaryKeyMember();
+ public boolean isReadOnly();
+
+ public Object getInstanceValue(EntityEnterpriseContext ctx);
public void setInstanceValue(EntityEnterpriseContext ctx, Object value);
- public Object getPrimaryKeyValue(Object primaryKey) throws
IllegalArgumentException;
+ public Object getPrimaryKeyValue(Object primaryKey) throws
IllegalArgumentException;
public Object setPrimaryKeyValue(Object primaryKey, Object value) throws
IllegalArgumentException;
- /**
- * Set CMPFieldValue to Java default value (i.e., 0 or null).
- */
- public void initInstance(EntityEnterpriseContext ctx);
+ /**
+ * Set CMPFieldValue to Java default value (i.e., 0 or null).
+ */
+ public void initInstance(EntityEnterpriseContext ctx);
- /**
- * Has the value of this field changes since the last time clean was called.
- */
- public boolean isDirty(EntityEnterpriseContext ctx);
+ /**
+ * Has the value of this field changes since the last time clean was called.
+ */
+ public boolean isDirty(EntityEnterpriseContext ctx);
- /**
- * Mark this field as clean.
- */
- public void setClean(EntityEnterpriseContext ctx);
+ /**
+ * Mark this field as clean.
+ */
+ public void setClean(EntityEnterpriseContext ctx);
}
1.4 +9 -9
jboss/src/main/org/jboss/ejb/plugins/cmp/bridge/CMRFieldBridge.java
Index: CMRFieldBridge.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/bridge/CMRFieldBridge.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- CMRFieldBridge.java 2001/08/03 17:15:45 1.3
+++ CMRFieldBridge.java 2001/09/01 22:03:14 1.4
@@ -13,19 +13,19 @@
* CMRFieldBridge a bean relationship.
*
* Life-cycle:
- * Haven't decided yet.
+ * Haven't decided yet.
*
- * Multiplicity:
- * Haven't decided yet. Will be either one per bean relationship role, or
- * one per relationship (shared between two beans).
+ * Multiplicity:
+ * Haven't decided yet. Will be either one per bean relationship role, or
+ * one per relationship (shared between two beans).
*
* @author mailto:[EMAIL PROTECTED]";>Dain Sundstrom
- * @version $Revision: 1.3 $
+ * @version $Revision: 1.4 $
*/
public interface CMRFieldBridge {
- public String getFieldName();
-// public Class getFieldType();
-
- public Object getValue(EntityEnterpriseContext ctx);
+ public String getFieldName();
+// public Class getFieldType();
+
+ public Object getValue(EntityEnterpriseContext ctx);
public void setValue(EntityEnterpriseContext ctx, Object value);
}
1.3 +22 -22
jboss/src/main/org/jboss/ejb/plugins/cmp/bridge/EntityBridge.java
Index: EntityBridge.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/bridge/Entity
Re: [JBoss-dev] requirements for build
For what it's worth, a novice jboss builder's impression: I allocated half a day to work through the usual incompatibilities, fired off the build, found and fixed the ANT_HOME problem in 1 minute, reran and...it worked! Amazing. Congrats to whoever set it up. I did what I'm sure others encountering the problem will do--changed build.bat to unset ANT_HOME. It would be convenient for others if this was always done, as suggested. I suppose it would be handy to do a dependency check like Red Hat rpm or provide a way to selectively override the build jars, but I doubt that it's worth the bother. - Original Message - From: "Jason Dillon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Dan - Blue Lotus Software" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Saturday, September 01, 2001 4:06 AM Subject: RE: [JBoss-dev] requirements for build Trying to support everyone's different environment is really not possible. There are currently 15 non-standard libraries used by some part of the build system, which means that every user who wants to use their own ANT_HOME, would have to have the exact same version for complete compatiblity. It is not just about the buildmagic stuff, there are required xslt jars for the testsuite & manual, junit to actually run the tests and so on. It might be possible with future versions of ant to support this, but for now there are better things to work on. Right now using the build.sh & build.bat scripts (or the ant scripts from tools/bin) are the only methods for building the system which are directly supported. If you would like to build from something else, I can probably help you set it up. There is a better way to deal with all of these support jars, I just haven't figure out what it is yet. --jason On Sat, 1 Sep 2001, Vincent Harcq wrote: > Hi, > I thought the idea was to permit the use of external ANT_HOME. > idea: JBoss build stops if it does not find build-magic.jar in ANT_HOME/lib > Also stops if ANT is not 1.4 version > Maybe other... > (with a 3 pages explanation if necessary)µ > Vincent > > > -Message d'origine- > > De : [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]De la part de > > Jason Dillon > > Envoyé : samedi 1 septembre 2001 8:51 > > À : Dan - Blue Lotus Software > > Cc : [EMAIL PROTECTED] > > Objet : RE: [JBoss-dev] requirements for build > > > > > > I will add that to my list of things todo. > > > > Thanks, > > > > --jason > > > > > > On Sat, 1 Sep 2001, Dan - Blue Lotus Software wrote: > > > > > Like I said, simply unsetting the environment variable ANT_HOME > > in the build > > > script should take care of this. > > > > > > I use Ant on many other non-JBoss related projects. I need > > ANT_HOME to be > > > set for these other projects. I assume others will have the > > same problem. > > > Because I was not aware JBoss included a fully functional Ant in the > > > distribution, I was thrown off by this. Simply unsetting ANT_HOME in > > > build.bat (and I suspect build.sh, as this is probably a > > problem for both > > > sides) would have fixed this. > > > > > > -dan > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On Behalf Of Jason > > > Dillon > > > Sent: Friday, August 31, 2001 11:49 PM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [JBoss-dev] requirements for build > > > > > > > > > Perhaps we should ignore any user set ANT_HOME, or warn the > > user if it is > > > set. > > > > > > --jason > > > > > > > > > On Fri, 31 Aug 2001, Dan - Blue Lotus Software wrote: > > > > > > > Yes, this was it. I suggest we unset ANT_HOME in the build script. > > > > > > > > -dan > > > > > > > > -Original Message- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED]]On Behalf Of > > > > Vincent Harcq > > > > Sent: Friday, August 31, 2001 7:50 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: RE: [JBoss-dev] requirements for build > > > > > > > > > > > > Hi, > > > > Is ANT_HOME env property set ? Unset it and it will run by > > finding ant > > > from > > > > tools/ > > > > Vincent. > > > > > > > > > -Message d'origine- > > > > > De : [EMAIL PROTECTED] > > > > > [mailto:[EMAIL PROTECTED]]De la > > part de Dan > > > > > - Blue Lotus Software > > > > > Envoyé : vendredi 31 août 2001 11:21 > > > > > À : JBoss Dev > > > > > Objet : [JBoss-dev] requirements for build > > > > > > > > > > > > > > > Well, I downloaded and compiled the Rabbit Hole release of > > JBoss today. > > > > > It's the first time I've built JBoss from scratch in about 6 > > > > > months. At any > > > > > rate, I thought I'd reflect a little on a couple of things, > > so that I > > > can > > > > > save people the 30 minutes I spent figuring it out. > > > > > > > > > > -You need v1.4beta of Ant. The current release is v1.4beta2. > > > > > -Copy the jar file from > > "/tools/buildmagic-tasks.jar" > > > into > > > > > the "lib" directory under Ant. > > > > > > > > > > Once that's done, you can cd int
RE: [JBoss-dev] RE: Persistant HttpSession
For some reason this thread is not repling to the list correctly. I think that no matter what you do, if you want a persistent session you need to send the data off server and the off server location, and this means serialization and network traffic (unavoidable in all cases). As for waiting for the db (which is just a file system in the basic case), this is avoidable if you use a multicast system. The tradeoff is that each server listening to the multicast must process the messages. In a crapy implementation you get an n-to-the-n star network problem (you don't get n^n connections but each server has to process the messages from the n other servers). The real answear the marc presented stands. There a billion possible solutions and each one has different performance problems. What we in the jboss group must do is define an interface to allow most (if not all) implementaions. Is there an interface for HttpSession persistence in the web container layer? -dain > -Original Message- > From: Andreas Schaefer [mailto:[EMAIL PROTECTED]] > Sent: Saturday, September 01, 2001 2:50 PM > To: Dain Sundstrom > Subject: Re: [JBoss-dev] RE: Persistant HttpSession > > > Just as IBM WebSphere is doing. But the problem is that > you introduce the latency of the network and DB for a regular > simple task. > On the other side your fail-over and clustering is reduced > to the one of the DB which can not become the bottleneck. > > Andy > > - Original Message - > From: "Dain Sundstrom" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, September 01, 2001 12:19 PM > Subject: FW: [JBoss-dev] RE: Persistant HttpSession > > > > I ment to send this to the list, but hit the wrong button. > > > > -Original Message- > > From: Dain Sundstrom > > Sent: Saturday, September 01, 2001 10:20 AM > > To: 'Julian Gosnell' > > Subject: RE: [JBoss-dev] RE: Persistant HttpSession > > > > > > I saw a presentation at JavaOne from HP on thier highly scaleable > > architecture and they were storing the http sessions into a > db after each > > request. The trick was they used a seperate database just > for storing the > > http session and this db was highly tuned for this type of > use. With this > > type of architecture you could tune the system to have a > minimal impact > from > > the session storage. (As a side note if you know the > structure of the http > > session you could make is very fast). > > > > -dain > > > > > -Original Message- > > > From: Julian Gosnell [mailto:[EMAIL PROTECTED]] > > > Sent: Saturday, September 01, 2001 9:47 AM > > > To: Bill Burke > > > Cc: Kevin Duffey; Greg Wilkins; > > > [EMAIL PROTECTED]; > > > [EMAIL PROTECTED] > > > Subject: Re: [JBoss-dev] RE: Persistant HttpSession > > > > > > > > > > > > I understand what you are saying, Bill. > > > > > > I am not proposing this as an enterprise level solution. > > > I am proposing it as a full-featured (distributed/persistant) > > > but trivial > > > implementation. > > > This means we can get it done quickly. More quickly than > > > perhaps Kevin might > > > get his solution implemented or a JavaGroups solution > might get done. > > > > > > Because it is very simple, it is unlikely to be buggy. > > > > > > Once we have a rock-solid implementation, we can turn around > > > and look at better > > > solutions. If you want to write a JavaGroups solution you are > > > very welcome to. > > > I don't see anything on your website about persistance, which > > > I assume is the > > > reason why your proposed solution would be faster. However I > > > would be surprised > > > if it was actually simpler and required less additional > > > infrastructure (over > > > and above JBoss, because that is the perspective from which I > > > am working) than > > > a CMP solution. > > > > > > Besides DB access will only be necessary if a Servlet/JSP > > > needs to read/write > > > state. This is not the case with every click on a website. If > > > the Servlet is > > > reading/writing state, then is is probably accessing EJBs > too (JBoss > > > perspective again), so the cost of one more access may not be > > > so unpalatable. > > > > > > I fully expect CMP to be the slowest solution, but I am not > > > going to launch > > > myself into a new problem space without a little recce trip > > > and that is what my > > > CMP HttpSession (If I actually write it) was intended to be - > > > sorry if this was > > > not made clear. > > > > > > Distribution may actually be a good enough solution, without > > > persistance, > > > provided that as new nodes come up they can update themselves > > > simply from the > > > rest of the cluster. Provided that the whole cluster does not > > > go down at once. > > > > > > With 2 or 3 solutions to the problem we will all be in a > > > better situation to > > > choose the one that best suits us. It's horses for courses. > > > > > > > > > Cheers, > > > > > > > > > > > > Jules > > > > > > > > > Bill Burke wro
[JBoss-dev] CVS update: jboss/src/main/org/jboss/web ThreadPool.java
User: kimptoc
Date: 01/09/01 12:50:33
Modified:src/main/org/jboss/web ThreadPool.java
Log:
remove deprecated logging import, where possible, otherwise comment as needing
replacement with log4j must find out how it is use would be good if the
deprecation message pointed to an example to use...
Revision ChangesPath
1.8 +9 -10 jboss/src/main/org/jboss/web/ThreadPool.java
Index: ThreadPool.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/web/ThreadPool.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- ThreadPool.java 2001/08/03 17:15:58 1.7
+++ ThreadPool.java 2001/09/01 19:50:33 1.8
@@ -4,22 +4,21 @@
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
-
+
package org.jboss.web;
import java.util.Stack;
-import org.jboss.logging.Logger;
/**
* A simple thread pool.
- *
+ *
* mailto:[EMAIL PROTECTED]";>Rickard Öberg
- * @version $Revision: 1.7 $
+ * @version $Revision: 1.8 $
*/
public class ThreadPool
{
// Constants -
-
+
// Attributes
/**
@@ -42,7 +41,7 @@
public ThreadPool()
{
}
-
+
// Public
/**
@@ -79,7 +78,7 @@
if (pool.size() < maxSize)
pool.push(w);
else
- w.die();
+ w.die();
}
// Inner classes -
@@ -145,7 +144,7 @@
// Clear work
work = null;
}
-
+
// Return to pool of cached idle threads
returnWorker(this);
@@ -157,8 +156,8 @@
} catch (InterruptedException e) {
// Ignore
}
- }
-}
+ }
+}
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/util CounterInterceptor.java Scheduler.java
User: kimptoc Date: 01/09/01 12:50:33 Modified:src/main/org/jboss/util CounterInterceptor.java Scheduler.java Log: remove deprecated logging import, where possible, otherwise comment as needing replacement with log4j must find out how it is use would be good if the deprecation message pointed to an example to use... Revision ChangesPath 1.4 +12 -9 jboss/src/main/org/jboss/util/CounterInterceptor.java Index: CounterInterceptor.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/util/CounterInterceptor.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- CounterInterceptor.java 2001/08/30 03:50:12 1.3 +++ CounterInterceptor.java 2001/09/01 19:50:33 1.4 @@ -7,12 +7,15 @@ import org.jboss.ejb.MethodInvocation; import org.jboss.ejb.Container; import org.jboss.ejb.plugins.*; + +// TODO this needs to be replaced with the log4j logging import org.jboss.logging.Logger; + import org.jboss.util.CounterService; /** * Interceptor that uses the CounterService MBean to record the length of time - * spent in 'lower' interceptors (below it in the stack). + * spent in 'lower' interceptors (below it in the stack). * How to use: * First, the CounterService MBean must be installed in JBoss. To do this, * place the following in your JBoss.jcml file, near the very end. @@ -22,8 +25,8 @@ * This will start up and enable the centralized counter in your JBoss server * instance. * Next, you need to configure this interceptor into the interceptor stacks - * of any beans you wish to monitor. This can be done either globally for a - * container-config in standardjboss.xml, or on a per-bean basis in a jar's + * of any beans you wish to monitor. This can be done either globally for a + * container-config in standardjboss.xml, or on a per-bean basis in a jar's * jboss.jcml. Just insert the following at the top of the* section. If you're overriding this for a bean in jboss.xml, you'll need to * override the entire container-interceptors section. @@ -31,7 +34,7 @@ * org.jboss.util.CounterInterceptor * * This can go anywhere in the container-interceptors section, but either - * the top or the bottom will probably be best for gathering application + * the top or the bottom will probably be best for gathering application * statistics. * @author mailto:[EMAIL PROTECTED]";>Dan Christopherson */ @@ -42,7 +45,7 @@ boolean loggedNoCounter = false; StringBuffer baseCounterName = null; int baseNameLength = 0; - + public CounterInterceptor() { } public void setContainer(Container container) { @@ -53,7 +56,7 @@ public Container getContainer() { return container; } - + public Object invokeHome(MethodInvocation mi) throws Exception { long startTime=System.currentTimeMillis(); try { @@ -68,7 +71,7 @@ } } } - + public Object invoke(MethodInvocation mi) throws Exception { long startTime=System.currentTimeMillis(); try { @@ -83,12 +86,12 @@ } } } - + public void init() throws java.lang.Exception { //get a reference to the CounterService from JNDI Logger.debug("CounterInterceptor initializing"); } - + private CounterService getCounter() { if (counter == null) { try { 1.9 +26 -27jboss/src/main/org/jboss/util/Scheduler.java Index: Scheduler.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/util/Scheduler.java,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- Scheduler.java2001/08/30 03:50:12 1.8 +++ Scheduler.java2001/09/01 19:50:33 1.9 @@ -32,7 +32,6 @@ import javax.naming.Reference; import javax.naming.StringRefAddr; -import org.jboss.logging.Log; import org.jboss.naming.NonSerializableFactory; import org.jboss.system.ServiceMBeanSupport; @@ -565,50 +564,50 @@ // Helper methods to bind/unbind the Management class // - - private void bind( Scheduler pScheduler ) +private void bind( Scheduler pScheduler ) throws NamingException { - Context lContext = new InitialContext(); - String lJNDIName = getJNDIName(); +Context lContext = new InitialContext(); +String lJNDIName = getJNDIName(); - // Ah ! JBoss Server isn't serializable, so we use a helper class - NonSeria
[JBoss-dev] CVS update: jboss/src/main/org/jboss/metadata XmlFileLoader.java
User: kimptoc
Date: 01/09/01 12:50:32
Modified:src/main/org/jboss/metadata XmlFileLoader.java
Log:
remove deprecated logging import, where possible, otherwise comment as needing
replacement with log4j must find out how it is use would be good if the
deprecation message pointed to an example to use...
Revision ChangesPath
1.20 +99 -97jboss/src/main/org/jboss/metadata/XmlFileLoader.java
Index: XmlFileLoader.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/metadata/XmlFileLoader.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- XmlFileLoader.java2001/08/15 12:15:28 1.19
+++ XmlFileLoader.java2001/09/01 19:50:32 1.20
@@ -25,6 +25,8 @@
import org.xml.sax.SAXParseException;
import org.jboss.ejb.DeploymentException;
+
+// TODO this needs to be replaced with the log4j logging
import org.jboss.logging.Logger;
/**
@@ -37,7 +39,7 @@
* @author mailto:[EMAIL PROTECTED]";>Wolfgang Werner
* @author mailto:[EMAIL PROTECTED]";>Darius Davidavicius
* @author mailto:[EMAIL PROTECTED]";>Scott Stark
- * @version $Revision: 1.19 $
+ * @version $Revision: 1.20 $
*
* Revisions:
* 20010620 Bill Burke: Print an error message when failing to load
standardjboss.xml
@@ -45,15 +47,15 @@
*syntax error.
*/
public class XmlFileLoader {
- // Constants -
+// Constants -
- // Attributes
+// Attributes
private static boolean defaultValidateDTDs = false;
- private ClassLoader classLoader;
- private ApplicationMetaData metaData;
+private ClassLoader classLoader;
+private ApplicationMetaData metaData;
private boolean validateDTDs;
- // Static
+// Static
public static boolean getDefaultValidateDTDs()
{
return defaultValidateDTDs;
@@ -63,36 +65,36 @@
defaultValidateDTDs = validate;
}
- // Constructors --
- public XmlFileLoader()
+// Constructors --
+public XmlFileLoader()
{
this(defaultValidateDTDs);
- }
+}
public XmlFileLoader(boolean validateDTDs)
{
this.validateDTDs = validateDTDs;
}
- // Public
- public ApplicationMetaData getMetaData() {
- return metaData;
+// Public
+public ApplicationMetaData getMetaData() {
+return metaData;
}
/**
Set the class loader
@param ClassLoader cl - class loader
*/
- public void setClassLoader(ClassLoader cl) {
- classLoader = cl;
- }
+public void setClassLoader(ClassLoader cl) {
+classLoader = cl;
+}
/**
Gets the class loader
@return ClassLoader - the class loader
*/
public ClassLoader getClassLoader() {
- return classLoader;
- }
+return classLoader;
+}
/** Get the flag indicating that ejb-jar.dtd, jboss.dtd &
jboss-web.dtd conforming documents should be validated
@@ -111,80 +113,80 @@
this.validateDTDs = validate;
}
- /**
- * load()
- *
- * This method creates the ApplicationMetaData.
- * The configuration files are found in the classLoader.
- * The default jboss.xml and jaws.xml files are always read first, then we
override
- * the defaults if the user provides them
- *
- */
- public ApplicationMetaData load() throws Exception {
- // create the metadata
- metaData = new ApplicationMetaData();
-
- // Load ejb-jar.xml
-
- // we can always find the files in the classloader
- URL ejbjarUrl = getClassLoader().getResource("META-INF/ejb-jar.xml");
-
- if (ejbjarUrl == null) {
- throw new DeploymentException("no ejb-jar.xml found");
- }
-
- Document ejbjarDocument = getDocumentFromURL(ejbjarUrl);
-
- // the url may be used to report errors
- metaData.setUrl(ejbjarUrl);
- metaData.importEjbJarXml(ejbjarDocument.getDocumentElement());
+/**
+* load()
+*
+* This method creates the A
[JBoss-dev] CVS update: jboss/src/main/org/jboss/logging Log.java Logger.java
User: kimptoc
Date: 01/09/01 12:50:32
Modified:src/main/org/jboss/logging Log.java Logger.java
Log:
remove deprecated logging import, where possible, otherwise comment as needing
replacement with log4j must find out how it is use would be good if the
deprecation message pointed to an example to use...
Revision ChangesPath
1.15 +47 -47jboss/src/main/org/jboss/logging/Log.java
Index: Log.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/logging/Log.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- Log.java 2001/08/03 17:15:53 1.14
+++ Log.java 2001/09/01 19:50:32 1.15
@@ -16,10 +16,10 @@
import org.apache.log4j.NDC;
/** The legacy JBoss logging framework base class.
- * @deprecated, As of JBoss 2.3, replaced by the org.apache.log4j framework
+ * @deprecated, As of JBoss 2.3, replaced by the org.apache.log4j framework. TODO
Example of how to use log4j
* @author mailto:[EMAIL PROTECTED]";>Rickard Öberg
* @author mailto:[EMAIL PROTECTED]";>Scott Stark.
- * @version $Revision: 1.14 $
+ * @version $Revision: 1.15 $
*/
public abstract class Log
{
@@ -41,17 +41,17 @@
static ThreadLocal currentLog = new InheritableThreadLocal()
{
- // Child threads should get same stack, but only a copy of it
- public Object childValue(Object obj)
- {
- if (obj != null)
- return ((Stack)obj).clone();
- else
- return null;
- }
+// Child threads should get same stack, but only a copy of it
+public Object childValue(Object obj)
+{
+if (obj != null)
+return ((Stack)obj).clone();
+else
+return null;
+}
};
- protected static Log defaultLog;
+ protected static Log defaultLog;
public static void setLog(Log log)
{
@@ -83,33 +83,33 @@
public static Log getLog()
{
Stack s = (Stack)currentLog.get();
- if( s == null ) {
- if( defaultLog == null ) {
- defaultLog = createLog( "Default" );
- }
- return defaultLog;
- }
- else {
- return (Log)s.peek();
- }
+if( s == null ) {
+if( defaultLog == null ) {
+defaultLog = createLog( "Default" );
+}
+return defaultLog;
+}
+else {
+return (Log)s.peek();
+}
}
- public static Log createLog( Object pSource ) {
- Log lReturn;
- try {
+ public static Log createLog( Object pSource ) {
+ Log lReturn;
+try {
final String logClass = System.getProperty("JBOSS_LOG_CLASS",
"org.jboss.logging.LogToCategory");
- Class lLog =
Thread.currentThread().getContextClassLoader().loadClass( logClass );
-//AS Class lLog = Class.forName( "org.jboss.logging.DefaultLog" );
- lReturn = (Log) lLog.getConstructor( new Class[] {
Object.class } ).newInstance(
- new Object[] { pSource }
- );
- }
- catch( Exception e ) {
- lReturn = new Log.NoLog( pSource );
- }
- return lReturn;
- }
+Class lLog = Thread.currentThread().getContextClassLoader().loadClass(
logClass );
+//ASClass lLog = Class.forName( "org.jboss.logging.DefaultLog" );
+lReturn = (Log) lLog.getConstructor( new Class[] { Object.class }
).newInstance(
+new Object[] { pSource }
+);
+}
+catch( Exception e ) {
+lReturn = new Log.NoLog( pSource );
+}
+return lReturn;
+ }
// Constructors --
public Log()
@@ -194,18 +194,18 @@
return count++;
}
- public static class NoLog extends Log {
- public NoLog() {
- super();
- }
- public NoLog( Object pSource ) {
- super( pSource );
- }
- public Log getDefault() {
- return new NoLog();
- }
- public synchronized void log( String pType, String pMessage ) {
- }
- }
+ public static class NoLog exten
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata JDBCApplicationMetaData.java JDBCMappingMetaData.java
User: kimptoc
Date: 01/09/01 12:50:31
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata
JDBCApplicationMetaData.java
JDBCMappingMetaData.java
Log:
remove deprecated logging import, where possible, otherwise comment as needing
replacement with log4j must find out how it is use would be good if the
deprecation message pointed to an example to use...
Revision ChangesPath
1.9 +282 -279
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata/JDBCApplicationMetaData.java
Index: JDBCApplicationMetaData.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata/JDBCApplicationMetaData.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- JDBCApplicationMetaData.java 2001/08/18 16:08:47 1.8
+++ JDBCApplicationMetaData.java 2001/09/01 19:50:31 1.9
@@ -16,7 +16,10 @@
import javax.naming.NamingException;
import javax.sql.DataSource;
import org.jboss.ejb.DeploymentException;
+
+// TODO this needs to be replaced with the log4j logging
import org.jboss.logging.Logger;
+
import org.jboss.metadata.ApplicationMetaData;
import org.jboss.metadata.BeanMetaData;
import org.jboss.metadata.EntityMetaData;
@@ -25,290 +28,290 @@
import org.jboss.metadata.XmlLoadable;
import org.w3c.dom.Element;
-/**
- * This immutable class contains information about the application
- *
+/**
+ * This immutable class contains information about the application
+ *
* @author mailto:[EMAIL PROTECTED]";>Dain Sundstrom
- * @author Sebastien Alborini
- * @version $Revision: 1.8 $
+ * @author Sebastien Alborini
+ * @version $Revision: 1.9 $
*/
public final class JDBCApplicationMetaData {
- public final static String JDBC_PM =
"org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager";
-
- /**
+public final static String JDBC_PM =
"org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager";
+
+/**
* The class loader for this application. The class loader is used to load all
classes
- * used by this application.
- */
- private final ClassLoader classLoader;
-
- /**
-* Application metadata loaded from the ejb-jar.xml file
- */
- private final ApplicationMetaData applicationMetaData;
-
- /**
+ * used by this application.
+ */
+private final ClassLoader classLoader;
+
+/**
+* Application metadata loaded from the ejb-jar.xml file
+ */
+private final ApplicationMetaData applicationMetaData;
+
+/**
* Map of the type mappings by name.
- */
- private final Map typeMappings = new HashMap();
-
- /**
- * Map of the entities managed by jbosscmp-jdbc by bean name.
- */
- private final Map entities = new HashMap();
-
- /**
- * Map of relations in this application by name.
- * Items are instance of JDBCRelationMetaData.
- */
- private final Map relationships = new HashMap();
-
- /**
- * Map of the relationship roles for an entity by entity object.
- */
- private final Map entityRoles = new HashMap();
+ */
+private final Map typeMappings = new HashMap();
+
+/**
+ * Map of the entities managed by jbosscmp-jdbc by bean name.
+ */
+private final Map entities = new HashMap();
+
+/**
+ * Map of relations in this application by name.
+ * Items are instance of JDBCRelationMetaData.
+ */
+private final Map relationships = new HashMap();
+
+/**
+ * Map of the relationship roles for an entity by entity object.
+ */
+private final Map entityRoles = new HashMap();
- /**
+/**
* Map of the dependent value classes by java class type.
- */
- private final Map valueClasses = new HashMap();
-
- /**
- * Map from abstract schema name to entity name
- */
- private final Map entitiesByAbstractSchemaName = new HashMap();
-
- /**
- * Constructs jdbc application meta data with the data from the
applicationMetaData.
- *
- * @param applicationMetaData the application data loaded from the ejb-jar.xml
file
- * @param classLoader the ClassLoader used to load the classes of the
application
- * @throws DeploymentException if an problem occures while loading the classes
or if
- * data in the ejb-jar.xml is inconsistent with data from
jbosscmp-jdbc.xml file
- */
- public JDBCApplicationMetaData(ApplicationMetaData applicationMetaData,
ClassLoader classLoader) throws DeploymentException {
- // the classloade
[JBoss-dev] CVS update: jboss/src/main/org/jboss/util/timeout TimeoutFactory.java
User: kimptoc
Date: 01/09/01 12:50:33
Modified:src/main/org/jboss/util/timeout TimeoutFactory.java
Log:
remove deprecated logging import, where possible, otherwise comment as needing
replacement with log4j must find out how it is use would be good if the
deprecation message pointed to an example to use...
Revision ChangesPath
1.7 +8 -7 jboss/src/main/org/jboss/util/timeout/TimeoutFactory.java
Index: TimeoutFactory.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/util/timeout/TimeoutFactory.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- TimeoutFactory.java 2001/08/03 17:15:58 1.6
+++ TimeoutFactory.java 2001/09/01 19:50:33 1.7
@@ -6,6 +6,7 @@
*/
package org.jboss.util.timeout;
+// TODO this needs to be replaced with the log4j logging
import org.jboss.logging.Logger;
@@ -20,9 +21,9 @@
* timeout is saved to be reused for another timeout. This means that if
* no timeouts are fired, this class will eventually operate without
* allocating anything on the heap.
- *
+ *
* @author Ole Husgaard
- * @version $Revision: 1.6 $
+ * @version $Revision: 1.7 $
*/
public class TimeoutFactory {
@@ -64,7 +65,7 @@
static final int DONE= -1; // done, may be finalized or reused
static final int TIMEOUT = -2; // target being called
static final int CWAIT = -3; // target being called and cancel waiting
-
+
int index; // index in queue, or one of constants above.
long time; // time to fire
TimeoutTarget target; // target to fire at
@@ -80,7 +81,7 @@
*/
private static class TimeoutWorker extends Thread {
private TimeoutImpl work;
-
+
/**
* Create a new instance.
*
@@ -90,7 +91,7 @@
this.work = work;
setDaemon(false);
}
-
+
/**
* Override to fire the timeout.
*/
@@ -168,7 +169,7 @@
*
* The invariant may be temporarily broken while executing synchronized
* on this instance, but is always reestablished before
- * leaving the synchronized code.
+ * leaving the synchronized code.
*
* The node at index 1 is always the first node to timeout,
* as can be deduced from the invariant.
@@ -562,4 +563,4 @@
}
}
-
+
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/tm/usertx/server UserTransactionSessionImpl.java
User: kimptoc Date: 01/09/01 12:50:33 Modified:src/main/org/jboss/tm/usertx/server UserTransactionSessionImpl.java Log: remove deprecated logging import, where possible, otherwise comment as needing replacement with log4j must find out how it is use would be good if the deprecation message pointed to an example to use... Revision ChangesPath 1.4 +2 -1 jboss/src/main/org/jboss/tm/usertx/server/UserTransactionSessionImpl.java Index: UserTransactionSessionImpl.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/tm/usertx/server/UserTransactionSessionImpl.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- UserTransactionSessionImpl.java 2001/08/03 17:15:57 1.3 +++ UserTransactionSessionImpl.java 2001/09/01 19:50:32 1.4 @@ -32,6 +32,7 @@ import org.jboss.tm.TransactionPropagationContextFactory; +//this needs to be replaced with the log4j logging TODO import org.jboss.logging.Logger; import org.jboss.tm.usertx.interfaces.UserTransactionSession; @@ -209,7 +210,7 @@ tx.setRollbackOnly(); } - + /** * Return status of the transaction. * ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/proxy Proxies.java ProxyProxy.java
User: kimptoc
Date: 01/09/01 12:50:32
Modified:src/main/org/jboss/proxy Proxies.java ProxyProxy.java
Log:
remove deprecated logging import, where possible, otherwise comment as needing
replacement with log4j must find out how it is use would be good if the
deprecation message pointed to an example to use...
Revision ChangesPath
1.5 +69 -68jboss/src/main/org/jboss/proxy/Proxies.java
Index: Proxies.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/proxy/Proxies.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- Proxies.java 2001/08/03 17:15:55 1.4
+++ Proxies.java 2001/09/01 19:50:32 1.5
@@ -10,6 +10,7 @@
import java.io.*;
import java.util.Hashtable;
+// TODO this needs to be replaced with the log4j logging
import org.jboss.logging.Logger;
/**
@@ -19,27 +20,27 @@
public final class Proxies
{
private Proxies() {}
-
+
/**
* Create a new target object x which is a proxy for
* the given InvocationHandler disp. The new object will be
* equivalent to disp, except that it will support normal Java
* method invocation, in place of the InvocationHandler.invoke
* protocol, for each method supported by the InvocationHandler.
-*
+*
*
* The new object will implement each of the given target types.
* (The target types default to those declared by the InvocationHandler
* itself.) The new object will also implement the "administrative"
* interface Proxies.ProxyTarget.
-*
+*
*
* For each "overrideable" (public, non-static, non-final)
* method T.m of T, calling x.m(...)
* will immediately cause a corresponding reflective call of the
* form disp.invoke(RM, new Object[]{ ... }), where RM
* is the reflective object for m.
-*
+*
*
* The concrete class of this target object will be
* something mysterious and indefinite. Many callers will
@@ -60,7 +61,7 @@
{
return Impl.getImpl(targetTypes).newTarget(InvocationHandler, parent);
}
-
+
//public static ProxyTarget newTarget(InvocationHandler InvocationHandler) {
// return newTarget(InvocationHandler, InvocationHandler.getTargetTypes());
//}
@@ -77,24 +78,24 @@
* proxy is wrapped.
*/
InvocationHandler getInvocationHandler();
-
+
/**
* Recover the original target types for which this proxy was wrapped.
*/
Class[] getTargetTypes();
}
-
+
/**
* Create a new reflective InvocationHandler object
* InvocationHandler wrapped around the given target object, for
* the given target type(s).
-*
+*
*
* The new object will be operationally equivalent to target,
* except that it will support a reflective method invocation sequence
* (InvocationHandler.invoke) instead of the normal Java method
* invocation mechanism.
-*
+*
*
* The target type must be specified, since the complete implementation
* type of the target object is usually irrelevant to the application.
@@ -110,13 +111,13 @@
{
return Impl.getImpl(targetType).newInvocationHandler(target);
}
-
+
public static ProxyInvocationHandler newInvocationHandler(Object target,
Class targetTypes[])
{
return Impl.getImpl(targetTypes).newInvocationHandler(target);
}
-
+
/**
* A common interface shared by all objects created
* by Proxies.newInvocationHandler.
@@ -130,12 +131,12 @@
*/
Object getTarget();
}
-
+
/**
* Utility built on top of newTarget to find
* or create a proxy for the given InvocationHandler.
* It is the inverse of getInvocationHandler.
-*
+*
*
* If the InvocationHandler implements ProxyInvocationHandler,
* it is a proxy for some original target object; extract and return
@@ -152,7 +153,7 @@
// }
// return target;
// }
-
+
if (InvocationHandler instanceof ProxyInvocationHandler) {
Object target = ((ProxyInvocationHandler)InvocationHandler).getTarget();
if (target != null) {
@@ -160,11 +161,11 @@
}
// and fall through...
}
-
+
//return newTarget(InvocationHandler);
return null;
}
-
+
/**
* Utility built on top of newInvocationHandler to find
* or create a proxy for the given target object.
@@ -173,7 +174,7 @@
* If the target implements ProxyTarget, it is a p
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jrmp12/server JRMPContainerInvoker.java
User: kimptoc
Date: 01/09/01 12:50:31
Modified:src/main/org/jboss/ejb/plugins/jrmp12/server
JRMPContainerInvoker.java
Log:
remove deprecated logging import, where possible, otherwise comment as needing
replacement with log4j must find out how it is use would be good if the
deprecation message pointed to an example to use...
Revision ChangesPath
1.15 +16 -14
jboss/src/main/org/jboss/ejb/plugins/jrmp12/server/JRMPContainerInvoker.java
Index: JRMPContainerInvoker.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jrmp12/server/JRMPContainerInvoker.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- JRMPContainerInvoker.java 2001/08/03 17:15:50 1.14
+++ JRMPContainerInvoker.java 2001/09/01 19:50:31 1.15
@@ -27,16 +27,18 @@
import org.jboss.ejb.plugins.jrmp12.interfaces.StatelessSessionProxy;
import org.jboss.ejb.plugins.jrmp12.interfaces.StatefulSessionProxy;
import org.jboss.ejb.plugins.jrmp12.interfaces.EntityProxy;
+
+// TODO this needs to be replaced with the log4j logging
import org.jboss.logging.Logger;
/**
- *
- *
- * @see
- * @author mailto:[EMAIL PROTECTED]";>Rickard Öberg
+ *
+ *
+ * @see
+ * @author mailto:[EMAIL PROTECTED]";>Rickard Öberg
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
- * @version $Revision: 1.14 $
+ * @version $Revision: 1.15 $
*/
public final class JRMPContainerInvoker
implements ContainerInvoker
@@ -46,24 +48,24 @@
Container container;
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker ci; // Parent invoker
-
+
public
JRMPContainerInvoker(org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker ci)
{
this.ci = ci;
}
-
+
public void setContainer(Container con)
{
this.container = con;
}
-
+
public void init()
{
// Create EJBHome object
// We add the Handle methods to the Home
Class handleClass;
- try
- {
+ try
+ {
handleClass = Class.forName("javax.ejb.Handle");
} catch (Exception e)
{
@@ -75,7 +77,7 @@
new HomeProxy(ci.getJndiName(), ci.getEJBMetaData(), ci,
ci.isOptimized()));
// Create stateless session object
- // Same instance is used for all objects
+ // Same instance is used for all objects
if (!(container.getBeanMetaData() instanceof EntityMetaData) &&
((SessionMetaData)container.getBeanMetaData()).isStateless())
{
@@ -83,7 +85,7 @@
new Class[] { ((ContainerInvokerContainer)container).getRemoteClass() }
,
new StatelessSessionProxy(ci.getJndiName(), ci, ci.isOptimized()));
}
-
+
Logger.debug("JRMP 1.2.2 CI initialized");
}
@@ -104,7 +106,7 @@
// Ignore, never called
return null;
}
-
+
public EJBHome getEJBHome()
{
return home;
@@ -130,7 +132,7 @@
}
public Collection getEntityCollection(Collection ids)
- {
+ {
ArrayList list = new ArrayList(ids.size());
Iterator idEnum = ids.iterator();
while(idEnum.hasNext())
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/jmx/server JMXAdaptorService.java
User: kimptoc
Date: 01/09/01 12:50:32
Modified:src/main/org/jboss/jmx/server JMXAdaptorService.java
Log:
remove deprecated logging import, where possible, otherwise comment as needing
replacement with log4j must find out how it is use would be good if the
deprecation message pointed to an example to use...
Revision ChangesPath
1.6 +25 -26jboss/src/main/org/jboss/jmx/server/JMXAdaptorService.java
Index: JMXAdaptorService.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/jmx/server/JMXAdaptorService.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- JMXAdaptorService.java2001/08/30 03:18:14 1.5
+++ JMXAdaptorService.java2001/09/01 19:50:32 1.6
@@ -4,7 +4,7 @@
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
-
+
package org.jboss.jmx.server;
import java.io.File;
@@ -27,66 +27,65 @@
import javax.management.MBeanServer;
import javax.naming.InitialContext;
-import org.jboss.logging.Log;
import org.jboss.system.ServiceMBeanSupport;
/**
- *
- *
+ *
+ *
* @see
* @author mailto:[EMAIL PROTECTED]";>Rickard Öberg
- * @version $Revision: 1.5 $
+ * @version $Revision: 1.6 $
*/
public class JMXAdaptorService
extends ServiceMBeanSupport
implements JMXAdaptorServiceMBean
{
// Constants -
- public static String JNDI_NAME = "jmx";
-
+public static String JNDI_NAME = "jmx";
+
// Attributes
- MBeanServer server;
- JMXAdaptorImpl adaptor;
-
+MBeanServer server;
+JMXAdaptorImpl adaptor;
+
// Static
// Constructors --
-
+
// Public
public ObjectName getObjectName(MBeanServer server, ObjectName name)
throws javax.management.MalformedObjectNameException
{
- this.server = server;
+this.server = server;
return new ObjectName(OBJECT_NAME);
}
-
+
public String getName()
{
return "JMX RMI Adaptor";
- }
-
+}
+
// Protected -
protected void initService()
throws Exception
{
- adaptor = new JMXAdaptorImpl(server);
+adaptor = new JMXAdaptorImpl(server);
}
-
+
protected void startService()
throws Exception
{
- new InitialContext().bind(JNDI_NAME, adaptor);
+new InitialContext().bind(JNDI_NAME, adaptor);
}
-
+
protected void stopService()
{
- try
- {
- new InitialContext().unbind(JNDI_NAME);
- } catch (Exception e)
- {
- log.exception(e);
- }
+try
+{
+new InitialContext().unbind(JNDI_NAME);
+} catch (Exception e)
+{
+log.exception(e);
+}
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jrmp/interfaces SecureSocketFactory.java StatefulHandleImpl.java
User: kimptoc
Date: 01/09/01 12:50:31
Modified:src/main/org/jboss/ejb/plugins/jrmp/interfaces
SecureSocketFactory.java StatefulHandleImpl.java
Log:
remove deprecated logging import, where possible, otherwise comment as needing
replacement with log4j must find out how it is use would be good if the
deprecation message pointed to an example to use...
Revision ChangesPath
1.9 +40 -39
jboss/src/main/org/jboss/ejb/plugins/jrmp/interfaces/SecureSocketFactory.java
Index: SecureSocketFactory.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jrmp/interfaces/SecureSocketFactory.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- SecureSocketFactory.java 2001/08/03 17:15:49 1.8
+++ SecureSocketFactory.java 2001/09/01 19:50:31 1.9
@@ -11,33 +11,34 @@
import java.rmi.server.*;
import java.security.*;
+// TODO this needs to be replaced with the log4j logging
import org.jboss.logging.Logger;
/**
- * NOT IN USE?
+ * NOT IN USE?
*
* @deprecated This this class in use at all?
- *
- * @see
- * @author mailto:[EMAIL PROTECTED]";>Rickard Öberg
- * @version $Revision: 1.8 $
+ *
+ * @see
+ * @author mailto:[EMAIL PROTECTED]";>Rickard Öberg
+ * @version $Revision: 1.9 $
*/
public class SecureSocketFactory
extends RMISocketFactory
implements java.io.Serializable
{
// Constants -
-
+
// Attributes
-
+
// Static
static ThreadLocal principals = new ThreadLocal();
-
+
static void setPrincipal(Principal p) { principals.set(p); }
public static Principal getPrincipal() { return (Principal)principals.get(); }
-
+
// Constructors --
-
+
// Public
public ServerSocket createServerSocket(int port)
throws IOException
@@ -50,22 +51,22 @@
{
return new AuthenticatedSocket(host, port);
}
-
+
public boolean equals(Object obj)
{
- System.out.println(obj instanceof SecureSocketFactory);
+System.out.println(obj instanceof SecureSocketFactory);
return obj instanceof SecureSocketFactory;
}
-
+
public int hashCode()
{
return getClass().getName().hashCode();
}
-
- // Package protected -
+ // Package protected -
+
// Protected -
-
+
// Private ---
// Inner classes -
@@ -77,19 +78,19 @@
{
super(port);
}
-
+
public Socket accept()
throws IOException
{
Socket s = new SecureSocket();
-
+
super.implAccept(s);
-
+
return s;
}
-
+
}
-
+
class SecureSocket
extends Socket
{
@@ -99,13 +100,13 @@
InputStream in = super.getInputStream();
DataInputStream din = new DataInputStream(in);
setPrincipal(new PrincipalImpl(din.readUTF()));
-
+
Logger.debug("Connected user:"+getPrincipal());
-
+
return in;
}
}
-
+
class AuthenticatedSocket
extends Socket
{
@@ -114,34 +115,34 @@
{
super(host, port);
System.out.println("Create socket to "+host+" "+port);
-
- try
- {
- throw new Exception();
- } catch (Exception e)
- {
- e.printStackTrace();
- }
-
+
+try
+{
+throw new Exception();
+} catch (Exception e)
+{
+e.printStackTrace();
+}
+
DataOutputStream out = new DataOutputStream(getOutputStream());
out.writeUTF(System.getProperty("user.name"));
}
}
-
+
static class PrincipalImpl
implements Principal
{
String name;
-
+
PrincipalImpl(String name)
{
this.name = name;
}
-
+
public String getName() { return name; }
[JBoss-dev] CVS update: jboss/src/main/org/jboss/management ContainerManagement.java
User: kimptoc
Date: 01/09/01 12:50:32
Modified:src/main/org/jboss/management ContainerManagement.java
Log:
remove deprecated logging import, where possible, otherwise comment as needing
replacement with log4j must find out how it is use would be good if the
deprecation message pointed to an example to use...
Revision ChangesPath
1.6 +9 -10 jboss/src/main/org/jboss/management/ContainerManagement.java
Index: ContainerManagement.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/management/ContainerManagement.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ContainerManagement.java 2001/08/30 03:59:25 1.5
+++ ContainerManagement.java 2001/09/01 19:50:32 1.6
@@ -52,8 +52,7 @@
import org.jboss.metadata.ConfigurationMetaData;
import org.jboss.metadata.XmlLoadable;
import org.jboss.metadata.XmlFileLoader;
-import org.jboss.logging.Logger;
-
+
/**
* A ContainerMgt is used as the long arm of a deployed EJB's container.
*
@@ -61,7 +60,7 @@
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
* @author mailto:[EMAIL PROTECTED]";>Andreas Schaefer
*
-* @version $Revision: 1.5 $
+* @version $Revision: 1.6 $
*/
public class ContainerManagement
extends org.jboss.system.ServiceMBeanSupport
@@ -79,17 +78,17 @@
public ContainerManagement( Container pContainer ) {
setContainer( pContainer );
}
-
+
// Public
private void setContainer( Container pContainer ) {
mContainer = pContainer;
}
-
+
public Container getContainer() {
return mContainer;
}
-
+
/**
* Implements the abstract getObjectName() method in superclass
* to return this service's name.
@@ -106,7 +105,7 @@
mName = name;
return name;
}
-
+
/**
* Implements the abstract getName() method in superclass to
* return the name of this object.
@@ -116,19 +115,19 @@
public String getName() {
return "Container Management Proxy";
}
-
+
/**
* Implements the template method in superclass. This method stops all the
* applications in this server.
*/
public void stopService() {
}
-
+
/**
* Implements the template method in superclass. This method destroys all
* the applications in this server and clears the deployments list.
*/
public void destroyService() {
}
-
+
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/metadata CMPFieldMetaData.java JawsEntityMetaData.java MappingMetaData.java TypeMappingMetaData.java
User: kimptoc
Date: 01/09/01 12:50:31
Modified:src/main/org/jboss/ejb/plugins/jaws/metadata
CMPFieldMetaData.java JawsEntityMetaData.java
MappingMetaData.java TypeMappingMetaData.java
Log:
remove deprecated logging import, where possible, otherwise comment as needing
replacement with log4j must find out how it is use would be good if the
deprecation message pointed to an example to use...
Revision ChangesPath
1.10 +2 -2
jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/CMPFieldMetaData.java
Index: CMPFieldMetaData.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/CMPFieldMetaData.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- CMPFieldMetaData.java 2001/08/03 17:15:49 1.9
+++ CMPFieldMetaData.java 2001/09/01 19:50:31 1.10
@@ -22,8 +22,8 @@
import java.util.*;
+//TODO replace logging with log4j stuff
import org.jboss.logging.Log;
-import org.jboss.logging.Logger;
/**
* This class holds all the information jaws needs to know about a CMP field.
@@ -34,7 +34,7 @@
* @author mailto:[EMAIL PROTECTED]";>Dirk Zimmermann
* @author mailto:[EMAIL PROTECTED]";>Vincent Harcq
* @author mailto:[EMAIL PROTECTED]";>David Jencks
- * @version $Revision: 1.9 $
+ * @version $Revision: 1.10 $
*
* Revison:
* 20010621 danch: merged patch from David Jenks - null constraint on columns.
1.15 +1 -3
jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/JawsEntityMetaData.java
Index: JawsEntityMetaData.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/JawsEntityMetaData.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- JawsEntityMetaData.java 2001/08/03 17:15:49 1.14
+++ JawsEntityMetaData.java 2001/09/01 19:50:31 1.15
@@ -27,8 +27,6 @@
import org.jboss.metadata.MetaData;
import org.jboss.metadata.XmlLoadable;
-// TODO
-import org.jboss.logging.Logger;
/**
*
@@ -38,7 +36,7 @@
* @author mailto:[EMAIL PROTECTED]";>Dirk Zimmermann
* @author mailto:[EMAIL PROTECTED]";>Bill Burke
* @author mailto:[EMAIL PROTECTED]";>Vinay Menon
- * @version $Revision: 1.14 $
+ * @version $Revision: 1.15 $
*
* Revisions:
* 20010621 Bill Burke: made read-ahead defaultable in standardjboss.xml and
jaws.xml
1.4 +59 -57
jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/MappingMetaData.java
Index: MappingMetaData.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/MappingMetaData.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- MappingMetaData.java 2001/08/03 17:15:49 1.3
+++ MappingMetaData.java 2001/09/01 19:50:31 1.4
@@ -10,76 +10,78 @@
import org.w3c.dom.Element;
+// TODO this needs to be replaced with the log4j logging
import org.jboss.logging.Logger;
+
import org.jboss.ejb.DeploymentException;
import org.jboss.metadata.MetaData;
import org.jboss.metadata.XmlLoadable;
/**
- *
- *
- * @see
- * @author Sebastien Alborini
- * @version $Revision: 1.3 $
+ *
+ *
+ * @see
+ * @author Sebastien Alborini
+ * @version $Revision: 1.4 $
*/
public class MappingMetaData extends MetaData implements XmlLoadable {
- // Constants -
-
- // Attributes
+// Constants -
+
+// Attributes
private String javaType;
-
- private int jdbcType;
-
- private String sqlType;
-
-
- // Static
-
- public static int getJdbcTypeFromName(String name) throws DeploymentException
{
- if (name == null) {
- throw new DeploymentException("jdbc-type cannot be null");
- }
-
- try {
- Integer constant =
(Integer)Types.class.getField(name).get(null);
- return constant.intValue();
-
- } catch (Exception e) {
- Logger.warning("Unrecognized jdbc-type: " + name + ", using
Types.OTHER");
- return Types.OTHER;
- }
- }
-
-
- // Constructors
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/local BaseLocalContainerInvoker.java
User: kimptoc
Date: 01/09/01 12:50:32
Modified:src/main/org/jboss/ejb/plugins/local
BaseLocalContainerInvoker.java
Log:
remove deprecated logging import, where possible, otherwise comment as needing
replacement with log4j must find out how it is use would be good if the
deprecation message pointed to an example to use...
Revision ChangesPath
1.10 +82 -81
jboss/src/main/org/jboss/ejb/plugins/local/BaseLocalContainerInvoker.java
Index: BaseLocalContainerInvoker.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/local/BaseLocalContainerInvoker.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- BaseLocalContainerInvoker.java2001/08/03 17:15:50 1.9
+++ BaseLocalContainerInvoker.java2001/09/01 19:50:32 1.10
@@ -60,6 +60,7 @@
import org.jboss.security.SecurityAssociation;
+// TODO this needs to be replaced with the log4j logging
import org.jboss.logging.Logger;
import org.jboss.ejb.DeploymentException;
@@ -86,7 +87,7 @@
protected Map beanMethodInvokerMap;
protected Map homeMethodInvokerMap;
-
+
// Static
private static TransactionPropagationContextFactory tpcFactory;
@@ -94,8 +95,8 @@
// Constructors --
// Public
+
-
public String getJndiName()
{
return jndiName;
@@ -112,7 +113,7 @@
{
if (((ContainerInvokerContainer)container).getLocalClass() == null)
return;
-
+
Context ctx = new InitialContext();
jndiName = container.getBeanMetaData().getJndiName();
@@ -126,7 +127,7 @@
beanMethodInvokerMap = new HashMap();
for (int i = 0; i < methods.length; i++)
beanMethodInvokerMap.put(new
Long(RemoteMethodInvocation.calculateHash(methods[i])), methods[i]);
-
+
methods =
((ContainerInvokerContainer)container).getLocalHomeClass().getMethods();
homeMethodInvokerMap = new HashMap();
for (int i = 0; i < methods.length; i++)
@@ -136,44 +137,44 @@
public void start()
throws Exception
{
- Class localHome =
((ContainerInvokerContainer)container).getLocalHomeClass();
-if(localHome == null) {
- Logger.debug(container.getBeanMetaData().getEjbName() + "
cannot be Bound, doesn't have local home.");
- return;
- }
-
- InitialContext context = new InitialContext();
- String jndiName = container.getBeanMetaData().getLocalJndiName();
- String beanName = container.getBeanMetaData().getEjbName();
-
- // unique key name
- String uniqueKey = Long.toString( (new java.util.Date()).getTime() );
-
- // setup local home object factory, which is used for non-serializable
objects such as local home
-
- // create link from unique name to application and container
- LocalHomeObjectFactory.rebind( uniqueKey + jndiName,
container.getApplication(), container);
-
- // address used to lookup referance in LocalHomeObjectFactory
- StringRefAddr refAddr = new StringRefAddr("nns", uniqueKey + jndiName
);
-
- // create a jndi referance to LocalHomeObjectFactory
- Reference jndiRef = new
Reference(container.getBeanMetaData().getLocalHome(),
- refAddr, LocalHomeObjectFactory.class.getName(), null );
-
- // bind that referance to my name
- rebind(context, jndiName, jndiRef);
+Class localHome =
((ContainerInvokerContainer)container).getLocalHomeClass();
+ if(localHome == null) {
+Logger.debug(container.getBeanMetaData().getEjbName() + " cannot be
Bound, doesn't have local home.");
+return;
+}
+
+InitialContext context = new InitialContext();
+String jndiName = container.getBeanMetaData().getLocalJndiName();
+String beanName = container.getBeanMetaData().getEjbName();
+
+// unique key name
+String uniqueKey = Long.toString( (new java.util.Date()).getTime() );
+
+// setup local home object factory, which is used for non-serializable
objects such as local home
+
+// create link from unique name to application and container
+LocalHomeObjectFactory.rebind( uniqueKey + jndiName,
container.getApplication(), container);
+
+// address used to lookup
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/bmp CustomFindByEntitiesCommand.java
User: kimptoc
Date: 01/09/01 12:50:31
Modified:src/main/org/jboss/ejb/plugins/jaws/bmp
CustomFindByEntitiesCommand.java
Log:
remove deprecated logging import, where possible, otherwise comment as needing
replacement with log4j must find out how it is use would be good if the
deprecation message pointed to an example to use...
Revision ChangesPath
1.7 +11 -8
jboss/src/main/org/jboss/ejb/plugins/jaws/bmp/CustomFindByEntitiesCommand.java
Index: CustomFindByEntitiesCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/bmp/CustomFindByEntitiesCommand.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- CustomFindByEntitiesCommand.java 2001/08/03 17:15:48 1.6
+++ CustomFindByEntitiesCommand.java 2001/09/01 19:50:31 1.7
@@ -16,7 +16,10 @@
import javax.ejb.FinderException;
import org.jboss.ejb.EntityEnterpriseContext;
+
+// TODO this needs to be replaced with the log4j logging
import org.jboss.logging.Logger;
+
import org.jboss.ejb.plugins.jaws.JPMFindEntitiesCommand;
import org.jboss.metadata.BeanMetaData;
import org.jboss.util.FinderResults;
@@ -30,7 +33,7 @@
*
* @see org.jboss.ejb.plugins.jaws.jdbc.JDBCFindEntitiesCommand
* @author mailto:[EMAIL PROTECTED]";>Michel de Groot
- * @version $Revision: 1.6 $
+ * @version $Revision: 1.7 $
*/
public class CustomFindByEntitiesCommand
implements JPMFindEntitiesCommand
@@ -87,12 +90,12 @@
throw new FinderException("Illegal arguments for finder
implementation:"+finderImplMethod.getName());
} catch (ExceptionInInitializerError e5) {
throw new FinderException("Unable to initialize finder
implementation:"+finderImplMethod.getName());
- } catch (InvocationTargetException e) {
- Throwable target = e.getTargetException();
- if(target instanceof Exception) {
- throw (Exception)target;
- }
- throw new FinderException("Unable to initialize finder
implementation: " + finderImplMethod.getName());
- }
+} catch (InvocationTargetException e) {
+Throwable target = e.getTargetException();
+if(target instanceof Exception) {
+throw (Exception)target;
+}
+throw new FinderException("Unable to initialize finder implementation:
" + finderImplMethod.getName());
+}
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmx/src/main/org/jboss/ejb/plugins/jrmp/server JRMPContainerInvokerHA.java
User: kimptoc
Date: 01/09/01 12:50:28
Modified:src/main/org/jboss/ejb/plugins/jrmp/server
JRMPContainerInvokerHA.java
Log:
remove deprecated logging import, where possible, otherwise comment as needing
replacement with log4j must find out how it is use would be good if the
deprecation message pointed to an example to use...
Revision ChangesPath
1.2 +12 -11
jbossmx/src/main/org/jboss/ejb/plugins/jrmp/server/JRMPContainerInvokerHA.java
Index: JRMPContainerInvokerHA.java
===
RCS file:
/cvsroot/jboss/jbossmx/src/main/org/jboss/ejb/plugins/jrmp/server/JRMPContainerInvokerHA.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- JRMPContainerInvokerHA.java 2001/08/19 18:28:32 1.1
+++ JRMPContainerInvokerHA.java 2001/09/01 19:50:28 1.2
@@ -7,6 +7,7 @@
package org.jboss.ejb.plugins.jrmp.server;
+// TODO this needs to be replaced with the log4j logging
import org.jboss.logging.Logger;
import org.jboss.ejb.DeploymentException;
@@ -25,7 +26,7 @@
* @author Rickard Öberg ([EMAIL PROTECTED])
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
* @author mailto:[EMAIL PROTECTED]";>Sacha Labourey
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*
* Revisions:
*
@@ -37,42 +38,42 @@
public class JRMPContainerInvokerHA extends JRMPContainerInvoker
{
-
+
/** Creates new JRMPContainerInvokerHA */
public JRMPContainerInvokerHA ()
{
super ();
}
-
+
public void start ()
throws Exception
{
super.start ();
ciDelegate.start ();
}
-
+
public void stop ()
{
super.stop ();
ciDelegate.stop ();
}
-
+
public void destroy ()
{
super.destroy ();
ciDelegate.destroy ();
}
-
-
+
+
// XmlLoadable implementation
public void importXml (Element element) throws DeploymentException
{
String opt = MetaData.getElementContent (MetaData.getUniqueChild (element,
"Optimized"));
optimize = Boolean.valueOf (opt).booleanValue ();
-
+
if ((System.getProperty ("java.vm.version").compareTo ("1.3") >= 0)) jdk122 =
false;
else jdk122 = true;
-
+
// Create delegate depending on JDK version
if (jdk122)
{
@@ -81,7 +82,7 @@
{
ciDelegate = new
org.jboss.ejb.plugins.jrmp13.server.JRMPContainerInvokerHA (this);
}
-
+
try
{
String port = MetaData.getElementContent (MetaData.getUniqueChild
(element, "RMIObjectPort"));
@@ -96,5 +97,5 @@
Logger.debug ("Container Invoker RMI Port='"+(rmiPort == ANONYMOUS_PORT ?
"Anonymous" : Integer.toString (rmiPort))+"'");
Logger.debug ("Container Invoker Optimize='"+optimize+"'");
}
-
+
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmx/src/main/org/jboss/ejb/plugins/jrmp12/server JRMPContainerInvokerHA.java
User: kimptoc
Date: 01/09/01 12:50:29
Modified:src/main/org/jboss/ejb/plugins/jrmp12/server
JRMPContainerInvokerHA.java
Log:
remove deprecated logging import, where possible, otherwise comment as needing
replacement with log4j must find out how it is use would be good if the
deprecation message pointed to an example to use...
Revision ChangesPath
1.2 +34 -32
jbossmx/src/main/org/jboss/ejb/plugins/jrmp12/server/JRMPContainerInvokerHA.java
Index: JRMPContainerInvokerHA.java
===
RCS file:
/cvsroot/jboss/jbossmx/src/main/org/jboss/ejb/plugins/jrmp12/server/JRMPContainerInvokerHA.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- JRMPContainerInvokerHA.java 2001/08/19 18:29:53 1.1
+++ JRMPContainerInvokerHA.java 2001/09/01 19:50:29 1.2
@@ -34,6 +34,8 @@
import org.jboss.ejb.plugins.jrmp12.interfaces.StatelessSessionProxyHA;
import org.jboss.ejb.plugins.jrmp12.interfaces.StatefulSessionProxy;
import org.jboss.ejb.plugins.jrmp12.interfaces.EntityProxy;
+
+// TODO this needs to be replaced with the log4j logging
import org.jboss.logging.Logger;
import org.jboss.ha.HAConfigNode;
@@ -52,7 +54,7 @@
* @author Rickard Öberg ([EMAIL PROTECTED])
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
* @author mailto:[EMAIL PROTECTED]";>Sacha Labourey
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*
* Revisions:
*
@@ -67,10 +69,10 @@
{
EJBHome home;
EJBObject statelessObject;
-
+
Container container;
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker ci; // Parent invoker
-
+
String _beanName = null;
String _appName = null;
String _nodeName = null;
@@ -78,17 +80,17 @@
HomeProxyHA _sshp = null; // optimization
Hashtable localJndiProps = null;
String haAppPathName = null;
-
+
public JRMPContainerInvokerHA
(org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker ci)
{
this.ci = ci;
}
-
+
public void setContainer (Container con)
{
this.container = con;
}
-
+
public void init ()
{
// Create stateless session object
@@ -99,23 +101,23 @@
try
{
Context ctx = new InitialContext ();
-
+
// names used for HA
//
_appName = new java.io.File (new java.net.URL
(this.container.getApplication ().getName ()).getFile ()).getName ();
_beanName = this.container.getBeanMetaData ().getEjbName ();
-
+
// Get the HAConfigService
//
HAConfigNode ha = (HAConfigNode)ctx.lookup ("java:/HAConfigServer");
_nodeName = ha.getNodeName ();
localJndiProps = ha.getLocalJndiProps ();
-
+
// Get already running replica
//
Vector replicateContainers = ha.getReplicateContainers (_appName ,
_beanName, HAConfigNode.REMOTE_TYPE);
haAppPathName = ha.getHaAppPath (_appName , _beanName,
HAConfigNode.REMOTE_TYPE);
-
+
this.createStatelessSessionProxy (replicateContainers,
ha.getNormalDelay (), ha.getDeathDelay ());
}
catch (Exception e)
@@ -140,10 +142,10 @@
{ ((ContainerInvokerContainer)container).getHomeClass (), handleClass },
new HomeProxy (ci.getJndiName (), ci.getEJBMetaData (), ci, ci.isOptimized
()));
}
-
+
Logger.debug ("JRMP 1.3 CI initialized (HA)");
}
-
+
public void start ()
{
if (!(container.getBeanMetaData () instanceof EntityMetaData) &&
@@ -153,40 +155,40 @@
{
Context ctx = new InitialContext ();
HAConfigNode ha = (HAConfigNode)ctx.lookup ("java:/HAConfigServer");
-HAConfigEntry detail = new HAConfigEntry
((ContainerRemote)java.rmi.server.RemoteObject.toStub (ci), null, null);
+HAConfigEntry detail = new HAConfigEntry
((ContainerRemote)java.rmi.server.RemoteObject.toStub (ci), null, null);
ha.registerContainer (this, _appName , _beanName,
HAConfigNode.REMOTE_TYPE, detail);
}
catch (Exception e)
{ e.printStackTrace (); }
}
}
-
+
public void stop ()
{
unregisterFromHA ();
}
-
+
public void destroy ()
{
unregisterFromHA ();
}
-
+
public EJBMetaData getEJBMetaData ()
{
// Ignore, never called
return null;
}
-
+
public EJBHome getEJBHome ()
{
return home;
}
-
+
public EJBObject getS
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jrmp13/server JRMPContainerInvoker.java
User: kimptoc
Date: 01/09/01 12:50:32
Modified:src/main/org/jboss/ejb/plugins/jrmp13/server
JRMPContainerInvoker.java
Log:
remove deprecated logging import, where possible, otherwise comment as needing
replacement with log4j must find out how it is use would be good if the
deprecation message pointed to an example to use...
Revision ChangesPath
1.13 +37 -35
jboss/src/main/org/jboss/ejb/plugins/jrmp13/server/JRMPContainerInvoker.java
Index: JRMPContainerInvoker.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jrmp13/server/JRMPContainerInvoker.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- JRMPContainerInvoker.java 2001/08/03 17:15:50 1.12
+++ JRMPContainerInvoker.java 2001/09/01 19:50:31 1.13
@@ -26,15 +26,17 @@
import org.jboss.ejb.plugins.jrmp13.interfaces.StatelessSessionProxy;
import org.jboss.ejb.plugins.jrmp13.interfaces.StatefulSessionProxy;
import org.jboss.ejb.plugins.jrmp13.interfaces.EntityProxy;
+
+// TODO this needs to be replaced with the log4j logging
import org.jboss.logging.Logger;
/**
- *
- *
- * @see
- * @author mailto:[EMAIL PROTECTED]";>Rickard Öberg
+ *
+ *
+ * @see
+ * @author mailto:[EMAIL PROTECTED]";>Rickard Öberg
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
- * @version $Revision: 1.12 $
+ * @version $Revision: 1.13 $
*/
public final class JRMPContainerInvoker
implements ContainerInvoker
@@ -44,24 +46,24 @@
Container container;
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker ci; // Parent invoker
-
+
public
JRMPContainerInvoker(org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker ci)
{
this.ci = ci;
}
-
+
public void setContainer(Container con)
{
this.container = con;
}
-
+
public void init()
{
// Create EJBHome object
// We add the Handle methods to the Home
Class handleClass;
- try
- {
+ try
+ {
handleClass = Class.forName("javax.ejb.Handle");
} catch (Exception e)
{
@@ -73,7 +75,7 @@
new HomeProxy(ci.getJndiName(), ci.getEJBMetaData(), ci,
ci.isOptimized()));
// Create stateless session object
- // Same instance is used for all objects
+ // Same instance is used for all objects
if (!(container.getBeanMetaData() instanceof EntityMetaData) &&
((SessionMetaData)container.getBeanMetaData()).isStateless())
{
@@ -81,8 +83,8 @@
new Class[] { ((ContainerInvokerContainer)container).getRemoteClass() }
,
new StatelessSessionProxy(ci.getJndiName(), ci, ci.isOptimized()));
}
-
- Logger.debug("JRMP 1.3 CI initialized");
+
+ Logger.debug("JRMP 1.3 CI initialized");
}
public void start()
@@ -102,7 +104,7 @@
// Ignore, never called
return null;
}
-
+
public EJBHome getEJBHome()
{
return home;
@@ -128,7 +130,7 @@
}
public Collection getEntityCollection(Collection ids)
- {
+ {
ArrayList list = new ArrayList(ids.size());
Iterator idEnum = ids.iterator();
while(idEnum.hasNext())
@@ -143,40 +145,40 @@
/**
- *
- *
- * @see
- * @author mailto:[EMAIL PROTECTED]";>Rickard Öberg
+ *
+ *
+ * @see
+ * @author mailto:[EMAIL PROTECTED]";>Rickard Öberg
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
- * @version $Revision: 1.12 $
+ * @version $Revision: 1.13 $
*/
-
+
/*
public final class JRMPContainerInvoker
implements ContainerInvoker
{
EJBHome home;
EJBObject statelessObject;
-
+
public void init()
{
// Create EJBHome object
// We add the Handle methods to the Home
Class handleClass;
- try
- {
+ try
+ {
handleClass = Class.forName("javax.ejb.Handle");
- } catch (Exception e)
+ } catch (Exception e)
{
Logger.exception(e);handleClass = null;
}
-
+
this.home =
(EJBHome)Proxy.newProxyInstance(((ContainerInvokerContainer)container).getHomeClass().getClassLoader(),
new Class[] { ((ContainerInvokerContainer)container).getHomeClass(),
handleClass },
new HomeProxy(jndiName,ejbMetaData, this, optimize));
-
+
// Create stateless session object
- // Same instance is used for all objects
+ // Same instance is used for all objects
if (!(con
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jrmp/server JRMPContainerInvoker.java
User: kimptoc
Date: 01/09/01 12:50:31
Modified:src/main/org/jboss/ejb/plugins/jrmp/server
JRMPContainerInvoker.java
Log:
remove deprecated logging import, where possible, otherwise comment as needing
replacement with log4j must find out how it is use would be good if the
deprecation message pointed to an example to use...
Revision ChangesPath
1.42 +13 -12
jboss/src/main/org/jboss/ejb/plugins/jrmp/server/JRMPContainerInvoker.java
Index: JRMPContainerInvoker.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jrmp/server/JRMPContainerInvoker.java,v
retrieving revision 1.41
retrieving revision 1.42
diff -u -r1.41 -r1.42
--- JRMPContainerInvoker.java 2001/08/03 17:15:50 1.41
+++ JRMPContainerInvoker.java 2001/09/01 19:50:31 1.42
@@ -48,6 +48,7 @@
import org.jboss.security.SecurityAssociation;
+// TODO this needs to be replaced with the log4j logging
import org.jboss.logging.Logger;
import org.jboss.ejb.DeploymentException;
@@ -68,7 +69,7 @@
* @author mailto:[EMAIL PROTECTED]";>Juha Lindfors
* @author mailto:[EMAIL PROTECTED]";>Ole Husgaard
* @author mailto:[EMAIL PROTECTED]";>Scott Stark
- * @version $Revision: 1.41 $
+ * @version $Revision: 1.42 $
*/
public class JRMPContainerInvoker
extends RemoteServer
@@ -102,7 +103,7 @@
protected Map beanMethodInvokerMap;
protected Map homeMethodInvokerMap;
-
+
protected ContainerInvoker ciDelegate; // Delegate depending on JDK version
// Static
@@ -116,7 +117,7 @@
public void setOptimized(boolean optimize)
{
this.optimize = optimize;
- //DEBUGLogger.debug("Container Invoker optimize set to
'"+optimize+"'");
+ //DEBUG Logger.debug("Container Invoker optimize set to
'"+optimize+"'");
}
public boolean isOptimized()
@@ -124,7 +125,7 @@
//DEBUG Logger.debug("Optimize in action: '"+optimize+"'");
return optimize;
}
-
+
public String getJndiName()
{
return jndiName;
@@ -147,7 +148,7 @@
// Get the transaction propagation context factory
// and the transaction propagation context importer
tpcFactory =
(TransactionPropagationContextFactory)ctx.lookup("java:/TransactionPropagationContextExporter");
- tpcImporter =
(TransactionPropagationContextImporter)ctx.lookup("java:/TransactionPropagationContextImporter");
+ tpcImporter =
(TransactionPropagationContextImporter)ctx.lookup("java:/TransactionPropagationContextImporter");
// Set the transaction manager and transaction propagation
// context factory of the GenericProxy class
@@ -159,12 +160,12 @@
beanMethodInvokerMap = new HashMap();
for (int i = 0; i < methods.length; i++)
beanMethodInvokerMap.put(new
Long(RemoteMethodInvocation.calculateHash(methods[i])), methods[i]);
-
+
methods = ((ContainerInvokerContainer)container).getHomeClass().getMethods();
homeMethodInvokerMap = new HashMap();
for (int i = 0; i < methods.length; i++)
homeMethodInvokerMap.put(new
Long(RemoteMethodInvocation.calculateHash(methods[i])), methods[i]);
-
+
try {
// Get the getEJBObjectMethod
Method getEJBObjectMethod =
Class.forName("javax.ejb.Handle").getMethod("getEJBObject", new Class[0]);
@@ -231,7 +232,7 @@
new HomeHandleImpl(jndiName));
}
}
-
+
ciDelegate.init();
}
@@ -289,7 +290,7 @@
public void destroy()
{
}
-
+
// ContainerInvoker implementation ---
public EJBMetaData getEJBMetaData()
{
@@ -341,7 +342,7 @@
rmi.setMethodMap(homeMethodInvokerMap);
return new MarshalledObject(container.invokeHome(new
MethodInvocation(null, rmi.getMethod(), rmi.getArguments(),
-importTPC(rmi.getTransactionPropagationContext()),
+importTPC(rmi.getTransactionPropagationContext()),
rmi.getPrincipal(), rmi.getCredential() )));
} finally {
Thread.currentThread().setContextClassLoader(oldCl);
@@ -362,7 +363,7 @@
rmi.setMethodMap(beanMethodInvokerMap);
return new MarshalledObject(container.invoke(new
MethodInvocation(rmi.getId(), rmi.getMethod(), rmi.getArguments(),
-importTPC(rmi.getTransactionPropagationContext()),
+importTPC(rmi.getTransactionPropagationContext()),
rmi.getPrincipal(), rmi.getCredential() )));
} finally {
Thread.currentThread().setContextClassLoader(oldCl);
@@ -4
[JBoss-dev] CVS update: jbossmx/src/main/org/jboss/ejb/plugins/jrmp13/server JRMPContainerInvokerHA.java
User: kimptoc
Date: 01/09/01 12:50:29
Modified:src/main/org/jboss/ejb/plugins/jrmp13/server
JRMPContainerInvokerHA.java
Log:
remove deprecated logging import, where possible, otherwise comment as needing
replacement with log4j must find out how it is use would be good if the
deprecation message pointed to an example to use...
Revision ChangesPath
1.2 +36 -34
jbossmx/src/main/org/jboss/ejb/plugins/jrmp13/server/JRMPContainerInvokerHA.java
Index: JRMPContainerInvokerHA.java
===
RCS file:
/cvsroot/jboss/jbossmx/src/main/org/jboss/ejb/plugins/jrmp13/server/JRMPContainerInvokerHA.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- JRMPContainerInvokerHA.java 2001/08/19 18:31:02 1.1
+++ JRMPContainerInvokerHA.java 2001/09/01 19:50:29 1.2
@@ -33,6 +33,8 @@
import org.jboss.ejb.plugins.jrmp13.interfaces.StatelessSessionProxyHA;
import org.jboss.ejb.plugins.jrmp13.interfaces.StatefulSessionProxy;
import org.jboss.ejb.plugins.jrmp13.interfaces.EntityProxy;
+
+// TODO this needs to be replaced with the log4j logging
import org.jboss.logging.Logger;
import org.jboss.ha.HAConfigNode;
@@ -52,7 +54,7 @@
* @author Rickard Öberg ([EMAIL PROTECTED])
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
* @author mailto:[EMAIL PROTECTED]";>Sacha Labourey
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*
* Revisions:
*
@@ -67,10 +69,10 @@
{
EJBHome home;
EJBObject statelessObject;
-
+
Container container;
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker ci; // Parent invoker
-
+
String _beanName = null;
String _appName = null;
String _nodeName = null;
@@ -78,17 +80,17 @@
HomeProxyHA _sshp = null; // optimization
Hashtable localJndiProps = null;
String haAppPathName = null;
-
+
public JRMPContainerInvokerHA
(org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker ci)
{
this.ci = ci;
}
-
+
public void setContainer (Container con)
{
this.container = con;
}
-
+
public void init ()
{
// Create stateless session object
@@ -99,23 +101,23 @@
try
{
Context ctx = new InitialContext ();
-
+
// names used for HA
//
_appName = new java.io.File (new java.net.URL
(this.container.getApplication ().getName ()).getFile ()).getName ();
_beanName = this.container.getBeanMetaData ().getEjbName ();
-
+
// Get the HAConfigService
//
HAConfigNode ha = (HAConfigNode)ctx.lookup ("java:/HAConfigServer");
_nodeName = ha.getNodeName ();
localJndiProps = ha.getLocalJndiProps ();
-
+
// Get already running replica
//
Vector replicateContainers = ha.getReplicateContainers (_appName ,
_beanName, HAConfigNode.REMOTE_TYPE);
haAppPathName = ha.getHaAppPath (_appName , _beanName,
HAConfigNode.REMOTE_TYPE);
-
+
this.createStatelessSessionProxy (replicateContainers,
ha.getNormalDelay (), ha.getDeathDelay ());
}
catch (Exception e)
@@ -140,10 +142,10 @@
{ ((ContainerInvokerContainer)container).getHomeClass (), handleClass },
new HomeProxy (ci.getJndiName (), ci.getEJBMetaData (), ci, ci.isOptimized
()));
}
-
+
Logger.debug ("JRMP 1.3 CI initialized (HA)");
}
-
+
public void start ()
{
if (!(container.getBeanMetaData () instanceof EntityMetaData) &&
@@ -153,40 +155,40 @@
{
Context ctx = new InitialContext ();
HAConfigNode ha = (HAConfigNode)ctx.lookup ("java:/HAConfigServer");
-HAConfigEntry detail = new HAConfigEntry
((ContainerRemote)java.rmi.server.RemoteObject.toStub (ci), null, null);
+HAConfigEntry detail = new HAConfigEntry
((ContainerRemote)java.rmi.server.RemoteObject.toStub (ci), null, null);
ha.registerContainer (this, _appName , _beanName,
HAConfigNode.REMOTE_TYPE, detail);
}
catch (Exception e)
{ e.printStackTrace (); }
}
}
-
+
public void stop ()
{
unregisterFromHA ();
}
-
+
public void destroy ()
{
unregisterFromHA ();
}
-
+
public EJBMetaData getEJBMetaData ()
{
// Ignore, never called
return null;
}
-
+
public EJBHome getEJBHome ()
{
return home;
}
-
+
public EJBObject getS
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/cmp/bmp CustomFindByEntitiesCommand.java
User: kimptoc
Date: 01/09/01 12:50:31
Modified:src/main/org/jboss/ejb/plugins/cmp/bmp
CustomFindByEntitiesCommand.java
Log:
remove deprecated logging import, where possible, otherwise comment as needing
replacement with log4j must find out how it is use would be good if the
deprecation message pointed to an example to use...
Revision ChangesPath
1.4 +52 -49
jboss/src/main/org/jboss/ejb/plugins/cmp/bmp/CustomFindByEntitiesCommand.java
Index: CustomFindByEntitiesCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/bmp/CustomFindByEntitiesCommand.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- CustomFindByEntitiesCommand.java 2001/08/03 17:15:45 1.3
+++ CustomFindByEntitiesCommand.java 2001/09/01 19:50:30 1.4
@@ -17,7 +17,10 @@
import org.jboss.ejb.EntityEnterpriseContext;
import org.jboss.ejb.plugins.cmp.FindEntitiesCommand;
+
+// TODO this needs to be replaced with the log4j logging
import org.jboss.logging.Logger;
+
import org.jboss.metadata.BeanMetaData;
import org.jboss.util.FinderResults;
@@ -31,57 +34,57 @@
*
* @see org.jboss.ejb.plugins.cmp.jdbc.JDBCFindEntitiesCommand
* @author mailto:[EMAIL PROTECTED]";>Michel de Groot
- * @version $Revision: 1.3 $
+ * @version $Revision: 1.4 $
*/
public class CustomFindByEntitiesCommand implements FindEntitiesCommand {
- // Attributes
+// Attributes
- /**
- * method that implements the finder
- */
- protected Method finderImplMethod;
-
- // Constructors --
-
- /**
- * Constructs a command which can handle multiple entity finders
- * that are BMP implemented.
- * @param finderMethod the EJB finder method implementation
- */
- public CustomFindByEntitiesCommand(Method finderMethod) {
- finderImplMethod = finderMethod;
-
- Logger.debug("Finder: Custom finder " + finderMethod.getName());
- }
-
- // FindEntitiesCommand implementation -
-
- public FinderResults execute(Method finderMethod,
- Object[] args,
- EntityEnterpriseContext ctx)
- throws Exception
- {
- try {
- // invoke implementation method on ejb instance
- Object result = finderImplMethod.invoke(ctx.getInstance(),
args);
-
- // if expected return type is Collection, return as is
- // if expected return type is not Collection, wrap result in
Collection
- if(!(result instanceof Collection)) {
- result = Collections.singleton(result);
- }
- return new FinderResults((Collection)result, null, null, null);
- } catch (IllegalAccessException e) {
- throw new FinderException("Unable to access finder
implementation: " + finderImplMethod.getName());
- } catch (IllegalArgumentException e) {
- throw new FinderException("Illegal arguments for finder
implementation: " + finderImplMethod.getName());
- } catch (InvocationTargetException e) {
- Throwable target = e.getTargetException();
- if(target instanceof Exception) {
- throw (Exception)target;
- }
- throw new FinderException("Unable to initialize finder
implementation: " + finderImplMethod.getName());
- }
- }
+/**
+ * method that implements the finder
+ */
+protected Method finderImplMethod;
+
+// Constructors --
+
+/**
+ * Constructs a command which can handle multiple entity finders
+ * that are BMP implemented.
+ * @param finderMethod the EJB finder method implementation
+ */
+public CustomFindByEntitiesCommand(Method finderMethod) {
+finderImplMethod = finderMethod;
+
+Logger.debug("Finder: Custom finder " + finderMethod.getName());
+}
+
+// FindEntitiesCommand implementation -
+
+public FinderResults execute(Method finderMethod,
+Object[] args,
+EntityEnterpriseContext ctx)
+throws Exception
+{
+try {
+// invoke implementation method on ejb instance
+Object result =
[JBoss-dev] CVS update: contrib/varia/src/main/org/jboss/jdo/castor CastorJDOImpl.java
User: kimptoc
Date: 01/09/01 12:50:29
Modified:varia/src/main/org/jboss/jdo/castor CastorJDOImpl.java
Log:
remove deprecated logging import, where possible, otherwise comment as needing
replacement with log4j must find out how it is use would be good if the
deprecation message pointed to an example to use...
Revision ChangesPath
1.3 +8 -10 contrib/varia/src/main/org/jboss/jdo/castor/CastorJDOImpl.java
Index: CastorJDOImpl.java
===
RCS file:
/cvsroot/jboss/contrib/varia/src/main/org/jboss/jdo/castor/CastorJDOImpl.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- CastorJDOImpl.java2001/08/30 02:42:38 1.2
+++ CastorJDOImpl.java2001/09/01 19:50:29 1.3
@@ -4,7 +4,7 @@
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
-
+
package org.jboss.jdo.castor;
import java.io.PrintWriter;
@@ -36,8 +36,6 @@
import org.exolab.castor.persist.spi.LogInterceptor;
import org.exolab.castor.xml.Unmarshaller;
-import org.jboss.logging.Log;
-import org.jboss.logging.Logger;
import org.jboss.logging.LogWriter;
import org.jboss.system.ServiceMBeanSupport;
@@ -50,12 +48,12 @@
* Castor JDO support
*
* @author Oleg Nitz ([EMAIL PROTECTED])
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.3 $
*/
-public class CastorJDOImpl extends ServiceMBeanSupport
+public class CastorJDOImpl extends ServiceMBeanSupport
implements DataObjects, ObjectFactory, Referenceable, Serializable,
CastorJDOImplMBean, MBeanRegistration, LogInterceptor {
-
+
private String _jndiName;
private String _dbConf;
@@ -87,7 +85,7 @@
throws javax.management.MalformedObjectNameException {
return new ObjectName(OBJECT_NAME+",name="+_jndiName);
}
-
+
public String getName() {
return "CastorJDO";
}
@@ -163,7 +161,7 @@
public boolean getLoggingEnabled() {
return (_jdo.getLogInterceptor() != null);
}
-
+
public void setCommonClassPath(boolean commonClassPath) {
_commonClassPath = commonClassPath;
}
@@ -223,12 +221,12 @@
throws Exception {
return _instances.get(name.toString());
}
-
+
// Private ---
private void bind(Context ctx, String name, Object val)
throws NamingException {
// Bind val to name in ctx, and make sure that all intermediate contexts
exist
-
+
Name n = ctx.getNameParser("").parse(name);
while (n.size() > 1)
{
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmx/src/main/org/jboss/ha HAConfigNodeImpl.java
User: kimptoc
Date: 01/09/01 12:50:29
Modified:src/main/org/jboss/ha HAConfigNodeImpl.java
Log:
remove deprecated logging import, where possible, otherwise comment as needing
replacement with log4j must find out how it is use would be good if the
deprecation message pointed to an example to use...
Revision ChangesPath
1.3 +102 -100 jbossmx/src/main/org/jboss/ha/HAConfigNodeImpl.java
Index: HAConfigNodeImpl.java
===
RCS file: /cvsroot/jboss/jbossmx/src/main/org/jboss/ha/HAConfigNodeImpl.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- HAConfigNodeImpl.java 2001/08/23 00:09:05 1.2
+++ HAConfigNodeImpl.java 2001/09/01 19:50:29 1.3
@@ -21,7 +21,9 @@
import JavaGroups.Address;
import JavaGroups.Common.Trace;
+// TODO this needs to be replaced with the log4j logging
import org.jboss.logging.Logger;
+
import org.jboss.ejb.plugins.jrmp.interfaces.ContainerRemote;
/**
@@ -29,7 +31,7 @@
*
* @see HAConfigNode
* @author mailto:[EMAIL PROTECTED]";>Sacha Labourey
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.3 $
*
* Revisions:
*
@@ -41,19 +43,19 @@
public class HAConfigNodeImpl implements HAConfigNode
{
-
+
public interface HAEventsCallbackable
{
void beanReplicaModified (java.util.Vector newValue);
}
-
+
public static final String REMOTE_TYPE = "remote";
public static final String HOME_TYPE = "home";
public static final String CONFIG_ENTRY = "*config*";
-
+
// Constants -
-
-
+
+
final String defConnection
="UDP(mcast_addr=224.100.100.200;mcast_port=4567;ip_ttl=31;trace=true):" +
"PING(timeout=3000;num_initial_members=10):" +
"FD(trace=true;timeout=5000):" +
@@ -79,7 +81,7 @@
*/
private final String JNDI_PROVIDER_PREFIX = "jnp";
private final String JNDI_PORT_NUMBER = "1099"; // read it from JMX config in a
next version
-
+
// Attributes
StringclusterName = null;
StringescClusterName = null;
@@ -90,21 +92,21 @@
JavaGroups.AddressjavaGropupsNodeName = null;
EventDispatcher dispatcher = null;
Hashtable jndiProps = null;
-
+
long proxyNormalRefresh = 3;
long proxyDeathRefresh = 5000;
-
+
// Static
-
+
// Constructors --
-
+
public HAConfigNodeImpl ()
{
super();
}
-
+
// Public
-
+
public void init (String cluster, String node, String haConnection, long
normalDelay, long deathDelay)
{
// set local values from our MBEAN service
@@ -119,10 +121,10 @@
this.haConnection = this.defConnection;
else
this.haConnection = haConnection;
-
+
// determine the URL of the locally used
}
-
+
public void start ()
throws Exception
{
@@ -134,30 +136,30 @@
jndiProps = new Hashtable (2);
jndiProps.put (Context.INITIAL_CONTEXT_FACTORY,
"org.jnp.interfaces.NamingContextFactory");
jndiProps.put (Context.PROVIDER_URL, java.net.InetAddress.getLocalHost
().getHostName ()+ ":" + JNDI_PORT_NUMBER);
-
+
// This is the main distributed tree we use for sharing HA info. In the
future, configuration such as
// refresh delay (proxyDeathRefresh and proxyNormalRefresh) should also be
shared this way.
//
beans = new DistributedTree ("JBossHA", haConnection);
-
+
// we want to be informed about any update of the shared tree ...
//
dispatcher = new EventDispatcher ();
beans.AddDistributedTreeListener (dispatcher);
-
+
// ... and membership composition (to clean dead entries)
//
beans.AddMembershipListener (dispatcher);
beans.Start ();
-
+
// we also remember our JavaGroups name
//
this.javaGropupsNodeName = (Address)beans.GetLocalAddress ();
-
+
} catch (Exception e)
{ e.printStackTrace (); }
}
-
+
public void setNormalDelay (long normalDelay)
{
this.proxyNormalRefresh = normalDelay;
@@ -166,7 +168,7 @@
{
this.proxyDeathRefresh = deathDelay;
}
-
+
public long getN
[JBoss-dev] CVS update: contrib/varia/src/main/org/jboss/tm/plugins/tyrex CoordinatorInvoker.java CoordinatorRemote.java ResourceInvoker.java ResourceRemote.java TransactionManagerService.java TyrexTransactionPropagationContextManager.java TyrexTxPropagationContext.java
User: kimptoc
Date: 01/09/01 12:50:29
Modified:varia/src/main/org/jboss/tm/plugins/tyrex
CoordinatorInvoker.java CoordinatorRemote.java
ResourceInvoker.java ResourceRemote.java
TransactionManagerService.java
TyrexTransactionPropagationContextManager.java
TyrexTxPropagationContext.java
Log:
remove deprecated logging import, where possible, otherwise comment as needing
replacement with log4j must find out how it is use would be good if the
deprecation message pointed to an example to use...
Revision ChangesPath
1.2 +1 -2
contrib/varia/src/main/org/jboss/tm/plugins/tyrex/CoordinatorInvoker.java
Index: CoordinatorInvoker.java
===
RCS file:
/cvsroot/jboss/contrib/varia/src/main/org/jboss/tm/plugins/tyrex/CoordinatorInvoker.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- CoordinatorInvoker.java 2001/08/01 00:39:59 1.1
+++ CoordinatorInvoker.java 2001/09/01 19:50:29 1.2
@@ -20,7 +20,6 @@
import java.io.Externalizable;
import java.io.IOException;
-import org.jboss.logging.Logger;
/**
* This is the InvocationHandler for the Proxy to the originator's Coordinator.
@@ -33,7 +32,7 @@
*CoordinatorRemote,
*ResourceRemote
* @author mailto:[EMAIL PROTECTED]";>Anatoly Akkerman
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*/
class CoordinatorInvoker implements InvocationHandler {
1.2 +1 -2
contrib/varia/src/main/org/jboss/tm/plugins/tyrex/CoordinatorRemote.java
Index: CoordinatorRemote.java
===
RCS file:
/cvsroot/jboss/contrib/varia/src/main/org/jboss/tm/plugins/tyrex/CoordinatorRemote.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- CoordinatorRemote.java2001/08/01 00:39:59 1.1
+++ CoordinatorRemote.java2001/09/01 19:50:29 1.2
@@ -17,7 +17,6 @@
import org.omg.CosTransactions.Inactive;
-import org.jboss.logging.Logger;
/**
* RMI Remote Proxy that enables the remote Transaction Manager
* to register the subordinate transaction as a resource
@@ -25,7 +24,7 @@
*
* @see CoordinatorRemoteInterface, CoordinatorInvoker, ResourceRemote
* @author mailto:[EMAIL PROTECTED]";>Anatoly Akkerman
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*/
public class CoordinatorRemote extends java.rmi.server.UnicastRemoteObject
implements CoordinatorRemoteInterface {
1.2 +1 -2
contrib/varia/src/main/org/jboss/tm/plugins/tyrex/ResourceInvoker.java
Index: ResourceInvoker.java
===
RCS file:
/cvsroot/jboss/contrib/varia/src/main/org/jboss/tm/plugins/tyrex/ResourceInvoker.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ResourceInvoker.java 2001/08/01 00:39:59 1.1
+++ ResourceInvoker.java 2001/09/01 19:50:29 1.2
@@ -18,7 +18,6 @@
import java.io.Externalizable;
import java.io.IOException;
-import org.jboss.logging.Logger;
/**
* This is the InvocationHandler for the Proxy we hand over to the
@@ -30,7 +29,7 @@
*ResourceRemote,
*CoordinatorRemote
* @author mailto:[EMAIL PROTECTED]";>Anatoly Akkerman
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*/
public class ResourceInvoker implements InvocationHandler, Externalizable {
1.2 +1 -2
contrib/varia/src/main/org/jboss/tm/plugins/tyrex/ResourceRemote.java
Index: ResourceRemote.java
===
RCS file:
/cvsroot/jboss/contrib/varia/src/main/org/jboss/tm/plugins/tyrex/ResourceRemote.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ResourceRemote.java 2001/08/01 00:39:59 1.1
+++ ResourceRemote.java 2001/09/01 19:50:29 1.2
@@ -19,7 +19,6 @@
import org.omg.CosTransactions.Resource;
import org.omg.CosTransactions._ResourceImplBase;
-import org.jboss.logging.Logger;
/**
* RMI Remote Proxy that enables the Coordinator on the originating
@@ -27,7 +26,7 @@
*
* @see ResourceRemoteInterface, ResourceInvoker, CoordinatorRemote
* @author mailto:[EMAIL PROTECTED]";>Anatoly Akkerman
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*/
public class ResourceRemote extends java.rmi.server.UnicastRemoteObject implements
ResourceRemoteInterface {
1.3 +1 -2
contrib/varia/src/main/org/jboss/tm/plugins/tyrex/TransactionManagerService.java
FW: [JBoss-dev] RE: Persistant HttpSession
I ment to send this to the list, but hit the wrong button. -Original Message- From: Dain Sundstrom Sent: Saturday, September 01, 2001 10:20 AM To: 'Julian Gosnell' Subject: RE: [JBoss-dev] RE: Persistant HttpSession I saw a presentation at JavaOne from HP on thier highly scaleable architecture and they were storing the http sessions into a db after each request. The trick was they used a seperate database just for storing the http session and this db was highly tuned for this type of use. With this type of architecture you could tune the system to have a minimal impact from the session storage. (As a side note if you know the structure of the http session you could make is very fast). -dain > -Original Message- > From: Julian Gosnell [mailto:[EMAIL PROTECTED]] > Sent: Saturday, September 01, 2001 9:47 AM > To: Bill Burke > Cc: Kevin Duffey; Greg Wilkins; > [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] RE: Persistant HttpSession > > > > I understand what you are saying, Bill. > > I am not proposing this as an enterprise level solution. > I am proposing it as a full-featured (distributed/persistant) > but trivial > implementation. > This means we can get it done quickly. More quickly than > perhaps Kevin might > get his solution implemented or a JavaGroups solution might get done. > > Because it is very simple, it is unlikely to be buggy. > > Once we have a rock-solid implementation, we can turn around > and look at better > solutions. If you want to write a JavaGroups solution you are > very welcome to. > I don't see anything on your website about persistance, which > I assume is the > reason why your proposed solution would be faster. However I > would be surprised > if it was actually simpler and required less additional > infrastructure (over > and above JBoss, because that is the perspective from which I > am working) than > a CMP solution. > > Besides DB access will only be necessary if a Servlet/JSP > needs to read/write > state. This is not the case with every click on a website. If > the Servlet is > reading/writing state, then is is probably accessing EJBs too (JBoss > perspective again), so the cost of one more access may not be > so unpalatable. > > I fully expect CMP to be the slowest solution, but I am not > going to launch > myself into a new problem space without a little recce trip > and that is what my > CMP HttpSession (If I actually write it) was intended to be - > sorry if this was > not made clear. > > Distribution may actually be a good enough solution, without > persistance, > provided that as new nodes come up they can update themselves > simply from the > rest of the cluster. Provided that the whole cluster does not > go down at once. > > With 2 or 3 solutions to the problem we will all be in a > better situation to > choose the one that best suits us. It's horses for courses. > > > Cheers, > > > > Jules > > > Bill Burke wrote: > > > Julian, > > > > Again, I don't think a CMP Bean is a good idea. You'll be > writing to the > > database for every click on your website! This is just not > scalable at all. > > Your database will just get flooded with too many requests. > > > > Bill > > > > > -Original Message- > > > From: jules [mailto:jules]On Behalf Of Julian Gosnell > > > Sent: Saturday, September 01, 2001 6:05 AM > > > To: Kevin Duffey > > > Cc: Greg Wilkins; [EMAIL PROTECTED]; > > > [EMAIL PROTECTED]; Bill Burke > > > Subject: Re: Persistant HttpSession > > > > > > > > > Here is what I suggest. > > > > > > Greg, as Kevin suggests, selects the HttpSession class > via property or > > > configuration parameter. > > > > > > The current unclustered implementation is the default. > > > > > > We put together a list of the features that such a class might > > > need to offer - > > > I have the following at the moment: > > > > > > Simple - no clustering support > > > Persistant - changes are remembered > > > Distributed - changes are replicated across the cluster > (easier with > > > persistance) > > > > > > > > > Possible implementations I have so far: > > > > > > Simple - already done > > > Persistant and Distributed - via e.g. a CMP bean, or a > more complex > > > implementation which is a bit cleverer > > > Just Distributed - could use some underlying distribution > technology, > > > javaspaces, http://www.javagroups.com/ - faster without > persistance > > > > > > I'm putting my hand up for the CMP bean stuff - unless I think of > > > an easier > > > way. > > > > > > Looks like Kevin is keen on a faster P&D solution > > > > > > Bill might be interested in a JavaGroups Distributed > implementation ??? > > > > > > > > > How does that sound ? > > > > > > Can anyone think of any more features that might be needed ? > > > > > > > > > Jules > > > > > > > > > Kevin Duffey wrote: > > > > > > > I am not sure I would agree mostly because I personally > like to design > > > > things right the firs
RE: [JBoss-dev] RE: Persistant HttpSession
Bill, Looking at JavaGroups it sounds like it would possibly allow a good mechanism for the HttpSession replication as well. My experience is mostly with Orion so I have to take my example from what they do. They use multicast for HttpSession fail-over, so when I clicked on that link and started reading, it sounded like this may be a possible way for HttpSession replication as well. What do you think? I read a few posts on the Orion lists saying that using multicast can hinder network bandwidth but I wasn't sure why this would be. If you set up x number of servers in a cluster to listen on a specific port for replication messages, wouldn't that only use one port? I'll have to read up more on multicast. I understand that it broadcasts out to potentially x number of listeners, but just not sure about the semantics of how it works. > -Original Message- > From: Bill Burke [mailto:[EMAIL PROTECTED]] > Sent: Saturday, September 01, 2001 10:11 AM > To: marc fleury; Julian Gosnell > Cc: Kevin Duffey; Greg Wilkins; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] RE: Persistant HttpSession > > > Hey Julian/Marc, > > I hope didn't sound rude before. I was just pointing out what I > think is a > serious problem in using CMP. > > Julian, seriously, take a look at JavaGroups.DistributedHashtable > http://www.javagroups.com It is really easy to use, and I think > you'll find > it really cool. > > Marc, the inVM thingy you were talking about before is a cluster SFSB. I > agree that using EJB is a good abstration for this. I know jack > squat about > Message Driven Beans, but would that be a possibility as well? > > Regards, > > Bill > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of marc > > fleury > > Sent: Saturday, September 01, 2001 11:47 AM > > To: Julian Gosnell; Bill Burke > > Cc: Kevin Duffey; Greg Wilkins; [EMAIL PROTECTED]; > > [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] RE: Persistant HttpSession > > > > > > reading this reply I feel I should say what is on my mind > > technologically-wise. > > > > It seems to me that you are asking for a EJB semantic and we > are answering > > with "persistence" issues. I think it is symptomatic and goes > back to the > > larger EJB discussions and particularly the Entity bashing that seems > > popular these days. > > > > They are largely orthogonal issues. You can replace the > > persistence engine > > in JBoss. We allow for this, if you want A IN VM STORE WITH > > REPLICATED JAVA > > GROUPS as opposed to database access, WHAT PREVENTS US FROM > DOING IT? (JMX > > multinode batches of mods :) > > > > Julian is saying "I can get to work, manhana on this if I use the EJB > > patterns". We as JBoss can get to work on this manhana if we > isolate the > > store work. Isolation. We have divided the work and the > implementation of > > the store is "irrelevant" from Julian's point of view. > > > > Bill, you are right, a database solution is probably the worst, but it > > should not stop Julian from working until WE come up with a great store. > > And what really gets me excited is the fact that EJB semantic is > > natural and > > the implementation is orthogonal... its the trend... > > > > Another example is the Jive forums... they use direct JDBC because the > > persistence blabla and the replication bla bla bla... Same category of > > problems the solution is in our camp. > > > > marcf > > > > |-Original Message- > > |From: [EMAIL PROTECTED] > > |[mailto:[EMAIL PROTECTED]]On Behalf Of > > |Julian Gosnell > > |Sent: Saturday, September 01, 2001 10:47 AM > > |To: Bill Burke > > |Cc: Kevin Duffey; Greg Wilkins; > [EMAIL PROTECTED]; > > |[EMAIL PROTECTED] > > |Subject: Re: [JBoss-dev] RE: Persistant HttpSession > > | > > | > > | > > |I understand what you are saying, Bill. > > | > > |I am not proposing this as an enterprise level solution. > > |I am proposing it as a full-featured (distributed/persistant) > but trivial > > |implementation. > > |This means we can get it done quickly. More quickly than perhaps > > |Kevin might > > |get his solution implemented or a JavaGroups solution might get done. > > | > > |Because it is very simple, it is unlikely to be buggy. > > | > > |Once we have a rock-solid implementation, we can turn around and > > |look at better > > |solutions. If you want to write a JavaGroups solution you are very > > |welcome to. > > |I don't see anything on your website about persistance, which I > > |assume is the > > |reason why your proposed solution would be faster. However I would > > |be surprised > > |if it was actually simpler and required less additional > > |infrastructure (over > > |and above JBoss, because that is the perspective from which I am > > |working) than > > |a CMP solution. > > | > > |Besides DB access will only be necessary if a Servlet/JSP needs to > > |read/write > > |state. This is not the case with every click on a website. If the > > |Servl
RE: [JBoss-dev] RE: Persistant HttpSession
Hey Julian/Marc, I hope didn't sound rude before. I was just pointing out what I think is a serious problem in using CMP. Julian, seriously, take a look at JavaGroups.DistributedHashtable http://www.javagroups.com It is really easy to use, and I think you'll find it really cool. Marc, the inVM thingy you were talking about before is a cluster SFSB. I agree that using EJB is a good abstration for this. I know jack squat about Message Driven Beans, but would that be a possibility as well? Regards, Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of marc > fleury > Sent: Saturday, September 01, 2001 11:47 AM > To: Julian Gosnell; Bill Burke > Cc: Kevin Duffey; Greg Wilkins; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] RE: Persistant HttpSession > > > reading this reply I feel I should say what is on my mind > technologically-wise. > > It seems to me that you are asking for a EJB semantic and we are answering > with "persistence" issues. I think it is symptomatic and goes back to the > larger EJB discussions and particularly the Entity bashing that seems > popular these days. > > They are largely orthogonal issues. You can replace the > persistence engine > in JBoss. We allow for this, if you want A IN VM STORE WITH > REPLICATED JAVA > GROUPS as opposed to database access, WHAT PREVENTS US FROM DOING IT? (JMX > multinode batches of mods :) > > Julian is saying "I can get to work, manhana on this if I use the EJB > patterns". We as JBoss can get to work on this manhana if we isolate the > store work. Isolation. We have divided the work and the implementation of > the store is "irrelevant" from Julian's point of view. > > Bill, you are right, a database solution is probably the worst, but it > should not stop Julian from working until WE come up with a great store. > And what really gets me excited is the fact that EJB semantic is > natural and > the implementation is orthogonal... its the trend... > > Another example is the Jive forums... they use direct JDBC because the > persistence blabla and the replication bla bla bla... Same category of > problems the solution is in our camp. > > marcf > > |-Original Message- > |From: [EMAIL PROTECTED] > |[mailto:[EMAIL PROTECTED]]On Behalf Of > |Julian Gosnell > |Sent: Saturday, September 01, 2001 10:47 AM > |To: Bill Burke > |Cc: Kevin Duffey; Greg Wilkins; [EMAIL PROTECTED]; > |[EMAIL PROTECTED] > |Subject: Re: [JBoss-dev] RE: Persistant HttpSession > | > | > | > |I understand what you are saying, Bill. > | > |I am not proposing this as an enterprise level solution. > |I am proposing it as a full-featured (distributed/persistant) but trivial > |implementation. > |This means we can get it done quickly. More quickly than perhaps > |Kevin might > |get his solution implemented or a JavaGroups solution might get done. > | > |Because it is very simple, it is unlikely to be buggy. > | > |Once we have a rock-solid implementation, we can turn around and > |look at better > |solutions. If you want to write a JavaGroups solution you are very > |welcome to. > |I don't see anything on your website about persistance, which I > |assume is the > |reason why your proposed solution would be faster. However I would > |be surprised > |if it was actually simpler and required less additional > |infrastructure (over > |and above JBoss, because that is the perspective from which I am > |working) than > |a CMP solution. > | > |Besides DB access will only be necessary if a Servlet/JSP needs to > |read/write > |state. This is not the case with every click on a website. If the > |Servlet is > |reading/writing state, then is is probably accessing EJBs too (JBoss > |perspective again), so the cost of one more access may not be so > |unpalatable. > | > |I fully expect CMP to be the slowest solution, but I am not > going to launch > |myself into a new problem space without a little recce trip and > |that is what my > |CMP HttpSession (If I actually write it) was intended to be - > |sorry if this was > |not made clear. > | > |Distribution may actually be a good enough solution, without persistance, > |provided that as new nodes come up they can update themselves > |simply from the > |rest of the cluster. Provided that the whole cluster does not go > |down at once. > | > |With 2 or 3 solutions to the problem we will all be in a better > |situation to > |choose the one that best suits us. It's horses for courses. > | > | > |Cheers, > | > | > | > |Jules > | > | > |Bill Burke wrote: > | > |> Julian, > |> > |> Again, I don't think a CMP Bean is a good idea. You'll be > writing to the > |> database for every click on your website! This is just not > |scalable at all. > |> Your database will just get flooded with too many requests. > |> > |> Bill > |> > |> > -Original Message- > |> > From: jules [mailto:jules]On Behalf Of Julian Gosnell > |> > Sent: Saturday, September 01, 2001 6:05 AM > |> > To: Kevin Duff
[JBoss-dev] CVS update: newsite build.bat
User: slaboure Date: 01/09/01 09:05:36 Modified:.build.bat Log: Put batch in SETLOCAL mode so that any environment variable modification is only active in the batch: once terminated, original variable values are re-activated. Cleared the ANT_HOME environment variable to force the use of our ANT version. Revision ChangesPath 1.2 +7 -2 newsite/build.bat Index: build.bat === RCS file: /cvsroot/jboss/newsite/build.bat,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- build.bat 2001/08/30 22:34:32 1.1 +++ build.bat 2001/09/01 16:05:36 1.2 @@ -8,7 +8,7 @@ REM REM == REM -REM $Id: build.bat,v 1.1 2001/08/30 22:34:32 user57 Exp $ +REM $Id: build.bat,v 1.2 2001/09/01 16:05:36 slaboure Exp $ REM REM Authors: REM Jason Dillon <[EMAIL PROTECTED]> @@ -16,12 +16,17 @@ REM REM ** +REM Ignore the ANT_HOME variable: we want to use *our* +REM ANT version and associated JARs. +REM ** REM Ignore the users classpath, cause it might mess REM things up REM ** + +SETLOCAL set CLASSPATH= - +set ANT_HOME= REM ** REM - "for" loops have been unrolled for compatibility ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: build/website build.bat
User: slaboure Date: 01/09/01 09:05:35 Modified:website build.bat Log: Put batch in SETLOCAL mode so that any environment variable modification is only active in the batch: once terminated, original variable values are re-activated. Cleared the ANT_HOME environment variable to force the use of our ANT version. Revision ChangesPath 1.2 +7 -2 build/website/build.bat Index: build.bat === RCS file: /cvsroot/jboss/build/website/build.bat,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- build.bat 2001/08/30 22:01:56 1.1 +++ build.bat 2001/09/01 16:05:35 1.2 @@ -8,7 +8,7 @@ REM REM == REM -REM $Id: build.bat,v 1.1 2001/08/30 22:01:56 user57 Exp $ +REM $Id: build.bat,v 1.2 2001/09/01 16:05:35 slaboure Exp $ REM REM Authors: REM Jason Dillon <[EMAIL PROTECTED]> @@ -16,12 +16,17 @@ REM REM ** +REM Ignore the ANT_HOME variable: we want to use *our* +REM ANT version and associated JARs. +REM ** REM Ignore the users classpath, cause it might mess REM things up REM ** + +SETLOCAL set CLASSPATH= - +set ANT_HOME= REM ** REM - "for" loops have been unrolled for compatibility ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: build/jbossmq build.bat
User: slaboure Date: 01/09/01 09:00:40 Modified:jbossmq build.bat Log: Put batch in SETLOCAL mode so that any environment variable modification is only active in the batch: once terminated, original variable values are re-activated. Cleared the ANT_HOME environment variable to force the use of our ANT version. Revision ChangesPath 1.3 +7 -2 build/jbossmq/build.bat Index: build.bat === RCS file: /cvsroot/jboss/build/jbossmq/build.bat,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- build.bat 2001/08/29 04:35:32 1.2 +++ build.bat 2001/09/01 16:00:40 1.3 @@ -8,7 +8,7 @@ REM REM == REM -REM $Id: build.bat,v 1.2 2001/08/29 04:35:32 chirino Exp $ +REM $Id: build.bat,v 1.3 2001/09/01 16:00:40 slaboure Exp $ REM REM Authors: REM Jason Dillon <[EMAIL PROTECTED]> @@ -16,12 +16,17 @@ REM REM ** +REM Ignore the ANT_HOME variable: we want to use *our* +REM ANT version and associated JARs. +REM ** REM Ignore the users classpath, cause it might mess REM things up REM ** + +SETLOCAL set CLASSPATH= - +set ANT_HOME= REM ** REM - "for" loops have been unrolled for compatibility ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: build/jboss build.bat
User: slaboure Date: 01/09/01 08:57:37 Modified:jbossbuild.bat Log: Put batch in SETLOCAL mode so that any environment variable modification is only active in the batch: once terminated, original variable values are re-activated. Cleared the ANT_HOME environment variable to force the use of our ANT version. Revision ChangesPath 1.4 +85 -89build/jboss/build.bat Index: build.bat === RCS file: /cvsroot/jboss/build/jboss/build.bat,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- build.bat 2001/09/01 12:06:17 1.3 +++ build.bat 2001/09/01 15:57:37 1.4 @@ -1,90 +1,86 @@ -@echo off -REM == -REM -REM This is the main entry point for the build system. -REM -REM Users should be sure to execute this file rather than 'ant' to ensure -REM the correct version is being used with the correct configuration. -REM -REM == -REM -REM $Id: build.bat,v 1.3 2001/09/01 12:06:17 kimptoc Exp $ -REM -REM Authors: -REM Jason Dillon <[EMAIL PROTECTED]> -REM Sacha Labourey <[EMAIL PROTECTED]> -REM - -REM ** -REM Ignore the users ANT_HOME, cause it might mess -REM things up -REM ** - -set ANT_HOME= - - - -REM ** -REM Ignore the users classpath, cause it might mess -REM things up -REM ** - -set CLASSPATH= - - -REM ** -REM - "for" loops have been unrolled for compatibility -REM with some WIN32 systems. -REM ** - -set NAMES=tools;tools\ant;tools\apache\ant -set SUBFOLDERS=..;..\..;..\..\..;..\..\..\.. - -REM ** -REM ** - -SET EXECUTED=FALSE -for %%i in (%NAMES%) do call :subLoop %%i %1 %2 %3 %4 %5 %6 - -goto :EOF - - -REM ** -REM * Search for names in the subfolders * -REM ** - -:subLoop -for %%j in (%SUBFOLDERS%) do call :testIfExists %%j\%1\bin\ant.bat %2 %3 %4 %5 %6 %7 - -goto :EOF - - -REM ** -REM Test if ANT Batch file exists *** -REM ** - -:testIfExists -if exist %1 call :BatchFound %1 %2 %3 %4 %5 %6 %7 %8 - -goto :EOF - - -REM ** -REM ** Batch file has been found * -REM ** - -:BatchFound -if (%EXECUTED%)==(FALSE) call :ExecuteBatch %1 %2 %3 %4 %5 %6 %7 %8 -set EXECUTED=TRUE - -goto :EOF - -REM ** -REM * Execute Batch file only once *** -REM ** - -:ExecuteBatch -echo Calling %1 %2 %3 %4 %5 %6 %7 %8 -call %1 %2 %3 %4 %5 %6 %7 %8 - +@echo off +REM == +REM +REM This is the main entry point for the build system. +REM +REM Users should be sure to execute this file rather than 'ant' to ensure +REM the correct version is being used with the correct configuration. +REM +REM == +REM +REM $Id: build.bat,v 1.4 2001/09/01 15:57:37 slaboure Exp $ +REM +REM Authors: +REM Jason Dillon <[EMAIL PROTECTED]> +REM Sacha Labourey <[EMAIL PROTECTED]> +REM + +REM ** +REM Ignore the ANT_HOME variable: we want to use *our* +REM ANT version and associated JARs. +REM ** +REM Ignore the users classpath, cause it might mess +REM things up +REM ** + +SETLOCAL + +set CLASSPATH= +set ANT_HOME= + +REM ** +REM - "for" loops have been unrolled for compatibility +REM with some WIN32 systems. +REM ** + +set NAMES=tools;tools\ant;tools\apache\ant +set SUBFOLDERS=..;..\..;..\..\..;..\..\..\.. + +REM ** +REM **
[JBoss-dev] CVS update: contrib/varia build.bat
User: slaboure Date: 01/09/01 08:50:33 Modified:variabuild.bat Log: Put batch in SETLOCAL mode so that any environment variable modification is only active in the batch: once terminated, original variable values are re-activated. Cleared the ANT_HOME environment variable to force the use of our ANT version. Revision ChangesPath 1.2 +7 -2 contrib/varia/build.bat Index: build.bat === RCS file: /cvsroot/jboss/contrib/varia/build.bat,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- build.bat 2001/08/27 23:51:34 1.1 +++ build.bat 2001/09/01 15:50:33 1.2 @@ -8,7 +8,7 @@ REM REM == REM -REM $Id: build.bat,v 1.1 2001/08/27 23:51:34 user57 Exp $ +REM $Id: build.bat,v 1.2 2001/09/01 15:50:33 slaboure Exp $ REM REM Authors: REM Jason Dillon <[EMAIL PROTECTED]> @@ -16,12 +16,17 @@ REM REM ** +REM Ignore the ANT_HOME variable: we want to use *our* +REM ANT version and associated JARs. +REM ** REM Ignore the users classpath, cause it might mess REM things up REM ** + +SETLOCAL set CLASSPATH= - +set ANT_HOME= REM ** REM - "for" loops have been unrolled for compatibility ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty build.bat
User: slaboure Date: 01/09/01 08:50:33 Modified:jettybuild.bat Log: Put batch in SETLOCAL mode so that any environment variable modification is only active in the batch: once terminated, original variable values are re-activated. Cleared the ANT_HOME environment variable to force the use of our ANT version. Revision ChangesPath 1.2 +7 -2 contrib/jetty/build.bat Index: build.bat === RCS file: /cvsroot/jboss/contrib/jetty/build.bat,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- build.bat 2001/08/27 23:51:34 1.1 +++ build.bat 2001/09/01 15:50:33 1.2 @@ -8,7 +8,7 @@ REM REM == REM -REM $Id: build.bat,v 1.1 2001/08/27 23:51:34 user57 Exp $ +REM $Id: build.bat,v 1.2 2001/09/01 15:50:33 slaboure Exp $ REM REM Authors: REM Jason Dillon <[EMAIL PROTECTED]> @@ -16,12 +16,17 @@ REM REM ** +REM Ignore the ANT_HOME variable: we want to use *our* +REM ANT version and associated JARs. +REM ** REM Ignore the users classpath, cause it might mess REM things up REM ** + +SETLOCAL set CLASSPATH= - +set ANT_HOME= REM ** REM - "for" loops have been unrolled for compatibility ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jnp build.bat
User: slaboure Date: 01/09/01 08:50:32 Modified:.build.bat Log: Put batch in SETLOCAL mode so that any environment variable modification is only active in the batch: once terminated, original variable values are re-activated. Cleared the ANT_HOME environment variable to force the use of our ANT version. Revision ChangesPath 1.2 +7 -2 jnp/build.bat Index: build.bat === RCS file: /cvsroot/jboss/jnp/build.bat,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- build.bat 2001/08/27 23:51:34 1.1 +++ build.bat 2001/09/01 15:50:32 1.2 @@ -8,7 +8,7 @@ REM REM == REM -REM $Id: build.bat,v 1.1 2001/08/27 23:51:34 user57 Exp $ +REM $Id: build.bat,v 1.2 2001/09/01 15:50:32 slaboure Exp $ REM REM Authors: REM Jason Dillon <[EMAIL PROTECTED]> @@ -16,12 +16,17 @@ REM REM ** +REM Ignore the ANT_HOME variable: we want to use *our* +REM ANT version and associated JARs. +REM ** REM Ignore the users classpath, cause it might mess REM things up REM ** + +SETLOCAL set CLASSPATH= - +set ANT_HOME= REM ** REM - "for" loops have been unrolled for compatibility ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosspool build.bat
User: slaboure Date: 01/09/01 08:50:33 Modified:.build.bat Log: Put batch in SETLOCAL mode so that any environment variable modification is only active in the batch: once terminated, original variable values are re-activated. Cleared the ANT_HOME environment variable to force the use of our ANT version. Revision ChangesPath 1.2 +7 -2 jbosspool/build.bat Index: build.bat === RCS file: /cvsroot/jboss/jbosspool/build.bat,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- build.bat 2001/08/27 23:51:34 1.1 +++ build.bat 2001/09/01 15:50:33 1.2 @@ -8,7 +8,7 @@ REM REM == REM -REM $Id: build.bat,v 1.1 2001/08/27 23:51:34 user57 Exp $ +REM $Id: build.bat,v 1.2 2001/09/01 15:50:33 slaboure Exp $ REM REM Authors: REM Jason Dillon <[EMAIL PROTECTED]> @@ -16,12 +16,17 @@ REM REM ** +REM Ignore the ANT_HOME variable: we want to use *our* +REM ANT version and associated JARs. +REM ** REM Ignore the users classpath, cause it might mess REM things up REM ** + +SETLOCAL set CLASSPATH= - +set ANT_HOME= REM ** REM - "for" loops have been unrolled for compatibility ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosssx build.bat
User: slaboure Date: 01/09/01 08:50:33 Modified:.build.bat Log: Put batch in SETLOCAL mode so that any environment variable modification is only active in the batch: once terminated, original variable values are re-activated. Cleared the ANT_HOME environment variable to force the use of our ANT version. Revision ChangesPath 1.2 +7 -2 jbosssx/build.bat Index: build.bat === RCS file: /cvsroot/jboss/jbosssx/build.bat,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- build.bat 2001/08/27 23:51:34 1.1 +++ build.bat 2001/09/01 15:50:33 1.2 @@ -8,7 +8,7 @@ REM REM == REM -REM $Id: build.bat,v 1.1 2001/08/27 23:51:34 user57 Exp $ +REM $Id: build.bat,v 1.2 2001/09/01 15:50:33 slaboure Exp $ REM REM Authors: REM Jason Dillon <[EMAIL PROTECTED]> @@ -16,12 +16,17 @@ REM REM ** +REM Ignore the ANT_HOME variable: we want to use *our* +REM ANT version and associated JARs. +REM ** REM Ignore the users classpath, cause it might mess REM things up REM ** + +SETLOCAL set CLASSPATH= - +set ANT_HOME= REM ** REM - "for" loops have been unrolled for compatibility ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq build.bat
User: slaboure Date: 01/09/01 08:50:32 Modified:.build.bat Log: Put batch in SETLOCAL mode so that any environment variable modification is only active in the batch: once terminated, original variable values are re-activated. Cleared the ANT_HOME environment variable to force the use of our ANT version. Revision ChangesPath 1.2 +7 -2 jbossmq/build.bat Index: build.bat === RCS file: /cvsroot/jboss/jbossmq/build.bat,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- build.bat 2001/08/27 23:51:34 1.1 +++ build.bat 2001/09/01 15:50:32 1.2 @@ -8,7 +8,7 @@ REM REM == REM -REM $Id: build.bat,v 1.1 2001/08/27 23:51:34 user57 Exp $ +REM $Id: build.bat,v 1.2 2001/09/01 15:50:32 slaboure Exp $ REM REM Authors: REM Jason Dillon <[EMAIL PROTECTED]> @@ -16,12 +16,17 @@ REM REM ** +REM Ignore the ANT_HOME variable: we want to use *our* +REM ANT version and associated JARs. +REM ** REM Ignore the users classpath, cause it might mess REM things up REM ** + +SETLOCAL set CLASSPATH= - +set ANT_HOME= REM ** REM - "for" loops have been unrolled for compatibility ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss build.bat
User: slaboure Date: 01/09/01 08:50:33 Modified:.build.bat Log: Put batch in SETLOCAL mode so that any environment variable modification is only active in the batch: once terminated, original variable values are re-activated. Cleared the ANT_HOME environment variable to force the use of our ANT version. Revision ChangesPath 1.2 +7 -2 jboss/build.bat Index: build.bat === RCS file: /cvsroot/jboss/jboss/build.bat,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- build.bat 2001/08/27 23:51:35 1.1 +++ build.bat 2001/09/01 15:50:33 1.2 @@ -8,7 +8,7 @@ REM REM == REM -REM $Id: build.bat,v 1.1 2001/08/27 23:51:35 user57 Exp $ +REM $Id: build.bat,v 1.2 2001/09/01 15:50:33 slaboure Exp $ REM REM Authors: REM Jason Dillon <[EMAIL PROTECTED]> @@ -16,12 +16,17 @@ REM REM ** +REM Ignore the ANT_HOME variable: we want to use *our* +REM ANT version and associated JARs. +REM ** REM Ignore the users classpath, cause it might mess REM things up REM ** + +SETLOCAL set CLASSPATH= - +set ANT_HOME= REM ** REM - "for" loops have been unrolled for compatibility ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: admin build.bat
User: slaboure Date: 01/09/01 08:50:31 Modified:.build.bat Log: Put batch in SETLOCAL mode so that any environment variable modification is only active in the batch: once terminated, original variable values are re-activated. Cleared the ANT_HOME environment variable to force the use of our ANT version. Revision ChangesPath 1.2 +7 -2 admin/build.bat Index: build.bat === RCS file: /cvsroot/jboss/admin/build.bat,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- build.bat 2001/08/27 23:51:32 1.1 +++ build.bat 2001/09/01 15:50:31 1.2 @@ -8,7 +8,7 @@ REM REM == REM -REM $Id: build.bat,v 1.1 2001/08/27 23:51:32 user57 Exp $ +REM $Id: build.bat,v 1.2 2001/09/01 15:50:31 slaboure Exp $ REM REM Authors: REM Jason Dillon <[EMAIL PROTECTED]> @@ -16,12 +16,17 @@ REM REM ** +REM Ignore the ANT_HOME variable: we want to use *our* +REM ANT version and associated JARs. +REM ** REM Ignore the users classpath, cause it might mess REM things up REM ** + +SETLOCAL set CLASSPATH= - +set ANT_HOME= REM ** REM - "for" loops have been unrolled for compatibility ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss-j2ee build.bat
User: slaboure Date: 01/09/01 08:50:32 Modified:.build.bat Log: Put batch in SETLOCAL mode so that any environment variable modification is only active in the batch: once terminated, original variable values are re-activated. Cleared the ANT_HOME environment variable to force the use of our ANT version. Revision ChangesPath 1.2 +7 -2 jboss-j2ee/build.bat Index: build.bat === RCS file: /cvsroot/jboss/jboss-j2ee/build.bat,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- build.bat 2001/08/27 23:51:33 1.1 +++ build.bat 2001/09/01 15:50:32 1.2 @@ -8,7 +8,7 @@ REM REM == REM -REM $Id: build.bat,v 1.1 2001/08/27 23:51:33 user57 Exp $ +REM $Id: build.bat,v 1.2 2001/09/01 15:50:32 slaboure Exp $ REM REM Authors: REM Jason Dillon <[EMAIL PROTECTED]> @@ -16,12 +16,17 @@ REM REM ** +REM Ignore the ANT_HOME variable: we want to use *our* +REM ANT version and associated JARs. +REM ** REM Ignore the users classpath, cause it might mess REM things up REM ** + +SETLOCAL set CLASSPATH= - +set ANT_HOME= REM ** REM - "for" loops have been unrolled for compatibility ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: manual build.bat
User: slaboure Date: 01/09/01 08:50:32 Modified:.build.bat Log: Put batch in SETLOCAL mode so that any environment variable modification is only active in the batch: once terminated, original variable values are re-activated. Cleared the ANT_HOME environment variable to force the use of our ANT version. Revision ChangesPath 1.2 +7 -2 manual/build.bat Index: build.bat === RCS file: /cvsroot/jboss/manual/build.bat,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- build.bat 2001/08/27 23:51:33 1.1 +++ build.bat 2001/09/01 15:50:32 1.2 @@ -8,7 +8,7 @@ REM REM == REM -REM $Id: build.bat,v 1.1 2001/08/27 23:51:33 user57 Exp $ +REM $Id: build.bat,v 1.2 2001/09/01 15:50:32 slaboure Exp $ REM REM Authors: REM Jason Dillon <[EMAIL PROTECTED]> @@ -16,12 +16,17 @@ REM REM ** +REM Ignore the ANT_HOME variable: we want to use *our* +REM ANT version and associated JARs. +REM ** REM Ignore the users classpath, cause it might mess REM things up REM ** + +SETLOCAL set CLASSPATH= - +set ANT_HOME= REM ** REM - "for" loops have been unrolled for compatibility ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmx build.bat
User: slaboure Date: 01/09/01 08:50:32 Modified:.build.bat Log: Put batch in SETLOCAL mode so that any environment variable modification is only active in the batch: once terminated, original variable values are re-activated. Cleared the ANT_HOME environment variable to force the use of our ANT version. Revision ChangesPath 1.2 +7 -2 jbossmx/build.bat Index: build.bat === RCS file: /cvsroot/jboss/jbossmx/build.bat,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- build.bat 2001/08/27 23:51:33 1.1 +++ build.bat 2001/09/01 15:50:32 1.2 @@ -8,7 +8,7 @@ REM REM == REM -REM $Id: build.bat,v 1.1 2001/08/27 23:51:33 user57 Exp $ +REM $Id: build.bat,v 1.2 2001/09/01 15:50:32 slaboure Exp $ REM REM Authors: REM Jason Dillon <[EMAIL PROTECTED]> @@ -16,12 +16,17 @@ REM REM ** +REM Ignore the ANT_HOME variable: we want to use *our* +REM ANT version and associated JARs. +REM ** REM Ignore the users classpath, cause it might mess REM things up REM ** + +SETLOCAL set CLASSPATH= - +set ANT_HOME= REM ** REM - "for" loops have been unrolled for compatibility ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosscx build.bat
User: slaboure Date: 01/09/01 08:50:32 Modified:.build.bat Log: Put batch in SETLOCAL mode so that any environment variable modification is only active in the batch: once terminated, original variable values are re-activated. Cleared the ANT_HOME environment variable to force the use of our ANT version. Revision ChangesPath 1.2 +7 -2 jbosscx/build.bat Index: build.bat === RCS file: /cvsroot/jboss/jbosscx/build.bat,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- build.bat 2001/08/27 23:51:33 1.1 +++ build.bat 2001/09/01 15:50:32 1.2 @@ -8,7 +8,7 @@ REM REM == REM -REM $Id: build.bat,v 1.1 2001/08/27 23:51:33 user57 Exp $ +REM $Id: build.bat,v 1.2 2001/09/01 15:50:32 slaboure Exp $ REM REM Authors: REM Jason Dillon <[EMAIL PROTECTED]> @@ -16,12 +16,17 @@ REM REM ** +REM Ignore the ANT_HOME variable: we want to use *our* +REM ANT version and associated JARs. +REM ** REM Ignore the users classpath, cause it might mess REM things up REM ** + +SETLOCAL set CLASSPATH= - +set ANT_HOME= REM ** REM - "for" loops have been unrolled for compatibility ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RE: Persistant HttpSession
reading this reply I feel I should say what is on my mind technologically-wise. It seems to me that you are asking for a EJB semantic and we are answering with "persistence" issues. I think it is symptomatic and goes back to the larger EJB discussions and particularly the Entity bashing that seems popular these days. They are largely orthogonal issues. You can replace the persistence engine in JBoss. We allow for this, if you want A IN VM STORE WITH REPLICATED JAVA GROUPS as opposed to database access, WHAT PREVENTS US FROM DOING IT? (JMX multinode batches of mods :) Julian is saying "I can get to work, manhana on this if I use the EJB patterns". We as JBoss can get to work on this manhana if we isolate the store work. Isolation. We have divided the work and the implementation of the store is "irrelevant" from Julian's point of view. Bill, you are right, a database solution is probably the worst, but it should not stop Julian from working until WE come up with a great store. And what really gets me excited is the fact that EJB semantic is natural and the implementation is orthogonal... its the trend... Another example is the Jive forums... they use direct JDBC because the persistence blabla and the replication bla bla bla... Same category of problems the solution is in our camp. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Julian Gosnell |Sent: Saturday, September 01, 2001 10:47 AM |To: Bill Burke |Cc: Kevin Duffey; Greg Wilkins; [EMAIL PROTECTED]; |[EMAIL PROTECTED] |Subject: Re: [JBoss-dev] RE: Persistant HttpSession | | | |I understand what you are saying, Bill. | |I am not proposing this as an enterprise level solution. |I am proposing it as a full-featured (distributed/persistant) but trivial |implementation. |This means we can get it done quickly. More quickly than perhaps |Kevin might |get his solution implemented or a JavaGroups solution might get done. | |Because it is very simple, it is unlikely to be buggy. | |Once we have a rock-solid implementation, we can turn around and |look at better |solutions. If you want to write a JavaGroups solution you are very |welcome to. |I don't see anything on your website about persistance, which I |assume is the |reason why your proposed solution would be faster. However I would |be surprised |if it was actually simpler and required less additional |infrastructure (over |and above JBoss, because that is the perspective from which I am |working) than |a CMP solution. | |Besides DB access will only be necessary if a Servlet/JSP needs to |read/write |state. This is not the case with every click on a website. If the |Servlet is |reading/writing state, then is is probably accessing EJBs too (JBoss |perspective again), so the cost of one more access may not be so |unpalatable. | |I fully expect CMP to be the slowest solution, but I am not going to launch |myself into a new problem space without a little recce trip and |that is what my |CMP HttpSession (If I actually write it) was intended to be - |sorry if this was |not made clear. | |Distribution may actually be a good enough solution, without persistance, |provided that as new nodes come up they can update themselves |simply from the |rest of the cluster. Provided that the whole cluster does not go |down at once. | |With 2 or 3 solutions to the problem we will all be in a better |situation to |choose the one that best suits us. It's horses for courses. | | |Cheers, | | | |Jules | | |Bill Burke wrote: | |> Julian, |> |> Again, I don't think a CMP Bean is a good idea. You'll be writing to the |> database for every click on your website! This is just not |scalable at all. |> Your database will just get flooded with too many requests. |> |> Bill |> |> > -Original Message- |> > From: jules [mailto:jules]On Behalf Of Julian Gosnell |> > Sent: Saturday, September 01, 2001 6:05 AM |> > To: Kevin Duffey |> > Cc: Greg Wilkins; [EMAIL PROTECTED]; |> > [EMAIL PROTECTED]; Bill Burke |> > Subject: Re: Persistant HttpSession |> > |> > |> > Here is what I suggest. |> > |> > Greg, as Kevin suggests, selects the HttpSession class via property or |> > configuration parameter. |> > |> > The current unclustered implementation is the default. |> > |> > We put together a list of the features that such a class might |> > need to offer - |> > I have the following at the moment: |> > |> > Simple - no clustering support |> > Persistant - changes are remembered |> > Distributed - changes are replicated across the cluster (easier with |> > persistance) |> > |> > |> > Possible implementations I have so far: |> > |> > Simple - already done |> > Persistant and Distributed - via e.g. a CMP bean, or a more complex |> > implementation which is a bit cleverer |> > Just Distributed - could use some underlying distribution technology, |> > javaspaces, http://www.javagroups.com/ - faster without persistance |> > |> > I'm putting my hand up for the CMP bean stuff - unless I th
Re: [JBoss-dev] RE: Persistant HttpSession
I understand what you are saying, Bill. I am not proposing this as an enterprise level solution. I am proposing it as a full-featured (distributed/persistant) but trivial implementation. This means we can get it done quickly. More quickly than perhaps Kevin might get his solution implemented or a JavaGroups solution might get done. Because it is very simple, it is unlikely to be buggy. Once we have a rock-solid implementation, we can turn around and look at better solutions. If you want to write a JavaGroups solution you are very welcome to. I don't see anything on your website about persistance, which I assume is the reason why your proposed solution would be faster. However I would be surprised if it was actually simpler and required less additional infrastructure (over and above JBoss, because that is the perspective from which I am working) than a CMP solution. Besides DB access will only be necessary if a Servlet/JSP needs to read/write state. This is not the case with every click on a website. If the Servlet is reading/writing state, then is is probably accessing EJBs too (JBoss perspective again), so the cost of one more access may not be so unpalatable. I fully expect CMP to be the slowest solution, but I am not going to launch myself into a new problem space without a little recce trip and that is what my CMP HttpSession (If I actually write it) was intended to be - sorry if this was not made clear. Distribution may actually be a good enough solution, without persistance, provided that as new nodes come up they can update themselves simply from the rest of the cluster. Provided that the whole cluster does not go down at once. With 2 or 3 solutions to the problem we will all be in a better situation to choose the one that best suits us. It's horses for courses. Cheers, Jules Bill Burke wrote: > Julian, > > Again, I don't think a CMP Bean is a good idea. You'll be writing to the > database for every click on your website! This is just not scalable at all. > Your database will just get flooded with too many requests. > > Bill > > > -Original Message- > > From: jules [mailto:jules]On Behalf Of Julian Gosnell > > Sent: Saturday, September 01, 2001 6:05 AM > > To: Kevin Duffey > > Cc: Greg Wilkins; [EMAIL PROTECTED]; > > [EMAIL PROTECTED]; Bill Burke > > Subject: Re: Persistant HttpSession > > > > > > Here is what I suggest. > > > > Greg, as Kevin suggests, selects the HttpSession class via property or > > configuration parameter. > > > > The current unclustered implementation is the default. > > > > We put together a list of the features that such a class might > > need to offer - > > I have the following at the moment: > > > > Simple - no clustering support > > Persistant - changes are remembered > > Distributed - changes are replicated across the cluster (easier with > > persistance) > > > > > > Possible implementations I have so far: > > > > Simple - already done > > Persistant and Distributed - via e.g. a CMP bean, or a more complex > > implementation which is a bit cleverer > > Just Distributed - could use some underlying distribution technology, > > javaspaces, http://www.javagroups.com/ - faster without persistance > > > > I'm putting my hand up for the CMP bean stuff - unless I think of > > an easier > > way. > > > > Looks like Kevin is keen on a faster P&D solution > > > > Bill might be interested in a JavaGroups Distributed implementation ??? > > > > > > How does that sound ? > > > > Can anyone think of any more features that might be needed ? > > > > > > Jules > > > > > > Kevin Duffey wrote: > > > > > I am not sure I would agree mostly because I personally like to design > > > things right the first time over getting it out fast. But, I > > think we can do > > > both. I haven't been able to look at the source yet, but I > > imagine if the > > > container is configurable to specify what session manager to load (via a > > > class name perhaps), we can then create one (or more) HttpSession > > > implementations, each with their own special characteristics. > > In this way, > > > its pluggable right from the getgo. What we can then do is turn Greg's > > > existing HttpSession implementation into the "default" class to > > be loaded. > > > >From there you and I can maybe both create a different > > implementation of > > > HttpSession that is also pluggable so that Jetty will have 3 different > > > versions. One that is non clusterable (for single JVM use and thus a bit > > > more speed), and two that are for clustering. > > > > > > This is but one way we can maybe go about this. What do you two think? > > > > > > > -Original Message- > > > > From: Julian Gosnell [mailto:[EMAIL PROTECTED]] > > > > Sent: Friday, August 31, 2001 5:59 AM > > > > To: Greg Wilkins; Julian Gosnell > > > > Cc: [EMAIL PROTECTED] > > > > Subject: Persistant HttpSession > > > > > > > > > > > > > > > > > I don't know if it needs to be tied into EJBs? > > > > > Depends on how you > > > > > d
[JBoss-dev] RE: Persistant HttpSession
Julian, Again, I don't think a CMP Bean is a good idea. You'll be writing to the database for every click on your website! This is just not scalable at all. Your database will just get flooded with too many requests. Bill > -Original Message- > From: jules [mailto:jules]On Behalf Of Julian Gosnell > Sent: Saturday, September 01, 2001 6:05 AM > To: Kevin Duffey > Cc: Greg Wilkins; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; Bill Burke > Subject: Re: Persistant HttpSession > > > Here is what I suggest. > > Greg, as Kevin suggests, selects the HttpSession class via property or > configuration parameter. > > The current unclustered implementation is the default. > > We put together a list of the features that such a class might > need to offer - > I have the following at the moment: > > Simple - no clustering support > Persistant - changes are remembered > Distributed - changes are replicated across the cluster (easier with > persistance) > > > Possible implementations I have so far: > > Simple - already done > Persistant and Distributed - via e.g. a CMP bean, or a more complex > implementation which is a bit cleverer > Just Distributed - could use some underlying distribution technology, > javaspaces, http://www.javagroups.com/ - faster without persistance > > I'm putting my hand up for the CMP bean stuff - unless I think of > an easier > way. > > Looks like Kevin is keen on a faster P&D solution > > Bill might be interested in a JavaGroups Distributed implementation ??? > > > How does that sound ? > > Can anyone think of any more features that might be needed ? > > > Jules > > > Kevin Duffey wrote: > > > I am not sure I would agree mostly because I personally like to design > > things right the first time over getting it out fast. But, I > think we can do > > both. I haven't been able to look at the source yet, but I > imagine if the > > container is configurable to specify what session manager to load (via a > > class name perhaps), we can then create one (or more) HttpSession > > implementations, each with their own special characteristics. > In this way, > > its pluggable right from the getgo. What we can then do is turn Greg's > > existing HttpSession implementation into the "default" class to > be loaded. > > >From there you and I can maybe both create a different > implementation of > > HttpSession that is also pluggable so that Jetty will have 3 different > > versions. One that is non clusterable (for single JVM use and thus a bit > > more speed), and two that are for clustering. > > > > This is but one way we can maybe go about this. What do you two think? > > > > > -Original Message- > > > From: Julian Gosnell [mailto:[EMAIL PROTECTED]] > > > Sent: Friday, August 31, 2001 5:59 AM > > > To: Greg Wilkins; Julian Gosnell > > > Cc: [EMAIL PROTECTED] > > > Subject: Persistant HttpSession > > > > > > > > > > > > > I don't know if it needs to be tied into EJBs? > > > > Depends on how you > > > > design your EJBs I guess. > > > > > > I think an initial naive implementation would probably > > > use EJBs, simply because I'm sitting in an EJB Server, > > > with all the necessary infrastructure for persistance > > > and distribution surrounding me. > > > > > > Only problem is, an EJB is a _STATIC_ wrapper around a > > > dynamic resource (i.e. you can stick new slots into a > > > table at run time, but not into a Java instance), > > > whereas an HttpSession is basically a HashTable, with > > > dynamic runtime structure. So all I will really be > > > doing is having an EJB with one instance data member > > > called HashTable, which contains the serialised (by > > > value) hastable. > > > > > > More complex, intelligent and faster implementations > > > could be thought up afterwards, but I think the > > > initial one should be as simple as possible and out > > > there as quickly as possible, and bug-free. > > > > > > Of course this puts certain constraints on what you > > > can put in your HttpSession - it has to be > > > serialisable - something Sun did not consider when > > > they came up with the HttpSession interface. This > > > means that moving a Servlet from a single node > > > deployment into a cluster may result in a change in > > > behaviour if it is not written according to certain > > > guidelines. I assume Sun must have published something > > > to this effect - I shall have to hunt it down. > > > > > > WebSphere implements one other strategy that gets this > > > done. The Master which dispatches the request to the > > > cluster can be configured to look for a session-id and > > > route requests with the same session-id to the same > > > node. This approach would allow you to deploy those > > > problem Servlets with the standard HttpSession object, > > > and no change in semantics - but then it's not really > > > clustering is it ... just double processing an HTTP > > > request instead of single processing it > > > > > > Jules > > > > > > > > > ___
[JBoss-dev] NotificationBroadcaster for J2eeDeployerMBean
I was looking at JBoss 2.4 and noticed that org.jboss.deployment.J2eeDeployerMBean interface does not extend the javax.management.NotificationBroadcaster interface. My project needs this feature and if anyone hasn't already done it, I'd volunteer. Should I work from the 3.0 code base? Or if the J2eeDeployer hasn't changed that much, I could work from the 2.4? Let me know. Thank you. Frederick N. Brier Sr. Software Engineer Multideck Corporation ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: build/jboss build.bat
User: kimptoc Date: 01/09/01 05:06:17 Modified:jbossbuild.bat Log: ignore users ANT_HOME setting Revision ChangesPath 1.3 +89 -80build/jboss/build.bat Index: build.bat === RCS file: /cvsroot/jboss/build/jboss/build.bat,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- build.bat 2001/08/27 23:51:33 1.2 +++ build.bat 2001/09/01 12:06:17 1.3 @@ -1,81 +1,90 @@ -@echo off -REM == -REM -REM This is the main entry point for the build system. -REM -REM Users should be sure to execute this file rather than 'ant' to ensure -REM the correct version is being used with the correct configuration. -REM -REM == -REM -REM $Id: build.bat,v 1.2 2001/08/27 23:51:33 user57 Exp $ -REM -REM Authors: -REM Jason Dillon <[EMAIL PROTECTED]> -REM Sacha Labourey <[EMAIL PROTECTED]> -REM - -REM ** -REM Ignore the users classpath, cause it might mess -REM things up -REM ** - -set CLASSPATH= - - -REM ** -REM - "for" loops have been unrolled for compatibility -REM with some WIN32 systems. -REM ** - -set NAMES=tools;tools\ant;tools\apache\ant -set SUBFOLDERS=..;..\..;..\..\..;..\..\..\.. - -REM ** -REM ** - -SET EXECUTED=FALSE -for %%i in (%NAMES%) do call :subLoop %%i %1 %2 %3 %4 %5 %6 - -goto :EOF - - -REM ** -REM * Search for names in the subfolders * -REM ** - -:subLoop -for %%j in (%SUBFOLDERS%) do call :testIfExists %%j\%1\bin\ant.bat %2 %3 %4 %5 %6 %7 - -goto :EOF - - -REM ** -REM Test if ANT Batch file exists *** -REM ** - -:testIfExists -if exist %1 call :BatchFound %1 %2 %3 %4 %5 %6 %7 %8 - -goto :EOF - - -REM ** -REM ** Batch file has been found * -REM ** - -:BatchFound -if (%EXECUTED%)==(FALSE) call :ExecuteBatch %1 %2 %3 %4 %5 %6 %7 %8 -set EXECUTED=TRUE - -goto :EOF - -REM ** -REM * Execute Batch file only once *** -REM ** - -:ExecuteBatch -echo Calling %1 %2 %3 %4 %5 %6 %7 %8 -call %1 %2 %3 %4 %5 %6 %7 %8 - +@echo off +REM == +REM +REM This is the main entry point for the build system. +REM +REM Users should be sure to execute this file rather than 'ant' to ensure +REM the correct version is being used with the correct configuration. +REM +REM == +REM +REM $Id: build.bat,v 1.3 2001/09/01 12:06:17 kimptoc Exp $ +REM +REM Authors: +REM Jason Dillon <[EMAIL PROTECTED]> +REM Sacha Labourey <[EMAIL PROTECTED]> +REM + +REM ** +REM Ignore the users ANT_HOME, cause it might mess +REM things up +REM ** + +set ANT_HOME= + + + +REM ** +REM Ignore the users classpath, cause it might mess +REM things up +REM ** + +set CLASSPATH= + + +REM ** +REM - "for" loops have been unrolled for compatibility +REM with some WIN32 systems. +REM ** + +set NAMES=tools;tools\ant;tools\apache\ant +set SUBFOLDERS=..;..\..;..\..\..;..\..\..\.. + +REM ** +REM ** + +SET EXECUTED=FALSE +for %%i in (%NAMES%) do call :subLoop %%i %1 %2 %3 %4 %5 %6 + +goto :EOF + + +REM ** +REM * Search for names in the subfolders * +REM ** + +:subLoop +for %%j in (%SUBFOLDERS%) do call :testIfExists %%j\%1\bin\ant.bat %2 %3 %4 %5 %6 %7
RE: [JBoss-dev] requirements for build
Trying to support everyone's different environment is really not possible. There are currently 15 non-standard libraries used by some part of the build system, which means that every user who wants to use their own ANT_HOME, would have to have the exact same version for complete compatiblity. It is not just about the buildmagic stuff, there are required xslt jars for the testsuite & manual, junit to actually run the tests and so on. It might be possible with future versions of ant to support this, but for now there are better things to work on. Right now using the build.sh & build.bat scripts (or the ant scripts from tools/bin) are the only methods for building the system which are directly supported. If you would like to build from something else, I can probably help you set it up. There is a better way to deal with all of these support jars, I just haven't figure out what it is yet. --jason On Sat, 1 Sep 2001, Vincent Harcq wrote: > Hi, > I thought the idea was to permit the use of external ANT_HOME. > idea: JBoss build stops if it does not find build-magic.jar in ANT_HOME/lib > Also stops if ANT is not 1.4 version > Maybe other... > (with a 3 pages explanation if necessary)µ > Vincent > > > -Message d'origine- > > De : [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]De la part de > > Jason Dillon > > Envoyé : samedi 1 septembre 2001 8:51 > > À : Dan - Blue Lotus Software > > Cc : [EMAIL PROTECTED] > > Objet : RE: [JBoss-dev] requirements for build > > > > > > I will add that to my list of things todo. > > > > Thanks, > > > > --jason > > > > > > On Sat, 1 Sep 2001, Dan - Blue Lotus Software wrote: > > > > > Like I said, simply unsetting the environment variable ANT_HOME > > in the build > > > script should take care of this. > > > > > > I use Ant on many other non-JBoss related projects. I need > > ANT_HOME to be > > > set for these other projects. I assume others will have the > > same problem. > > > Because I was not aware JBoss included a fully functional Ant in the > > > distribution, I was thrown off by this. Simply unsetting ANT_HOME in > > > build.bat (and I suspect build.sh, as this is probably a > > problem for both > > > sides) would have fixed this. > > > > > > -dan > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On Behalf Of Jason > > > Dillon > > > Sent: Friday, August 31, 2001 11:49 PM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [JBoss-dev] requirements for build > > > > > > > > > Perhaps we should ignore any user set ANT_HOME, or warn the > > user if it is > > > set. > > > > > > --jason > > > > > > > > > On Fri, 31 Aug 2001, Dan - Blue Lotus Software wrote: > > > > > > > Yes, this was it. I suggest we unset ANT_HOME in the build script. > > > > > > > > -dan > > > > > > > > -Original Message- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED]]On Behalf Of > > > > Vincent Harcq > > > > Sent: Friday, August 31, 2001 7:50 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: RE: [JBoss-dev] requirements for build > > > > > > > > > > > > Hi, > > > > Is ANT_HOME env property set ? Unset it and it will run by > > finding ant > > > from > > > > tools/ > > > > Vincent. > > > > > > > > > -Message d'origine- > > > > > De : [EMAIL PROTECTED] > > > > > [mailto:[EMAIL PROTECTED]]De la > > part de Dan > > > > > - Blue Lotus Software > > > > > Envoyé : vendredi 31 août 2001 11:21 > > > > > À : JBoss Dev > > > > > Objet : [JBoss-dev] requirements for build > > > > > > > > > > > > > > > Well, I downloaded and compiled the Rabbit Hole release of > > JBoss today. > > > > > It's the first time I've built JBoss from scratch in about 6 > > > > > months. At any > > > > > rate, I thought I'd reflect a little on a couple of things, > > so that I > > > can > > > > > save people the 30 minutes I spent figuring it out. > > > > > > > > > > -You need v1.4beta of Ant. The current release is v1.4beta2. > > > > > -Copy the jar file from > > "/tools/buildmagic-tasks.jar" > > > into > > > > > the "lib" directory under Ant. > > > > > > > > > > Once that's done, you can cd into "/build" and > > > > > type "build". > > > > > > > > > > I'm sorry if this is obvious to everyone on this list. It > > wasn't for > > > me, > > > > > though. The directions for buildmagic say nothing about how to > > > *install* > > > > > it. And the build script contains the tag, which is > > > > > only supported > > > > > in v1.4beta1 and beyond. > > > > > > > > > > -dan > > > > > > > > > > -- > > > > > Dan Kirkpatrick, Software Architect > > > > > Blue Lotus Software+44 (0) 1224 575 985 > > > > > [EMAIL PROTECTED] > > > > > http://www.bluelotussoftware.com > > > > > > > > > > > > > > > ___ > > > > > Jboss-development mailing list > > > > > [EMAIL PROTECTED] > > > > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > > > __
RE: [JBoss-dev] requirements for build
Hi, I thought the idea was to permit the use of external ANT_HOME. idea: JBoss build stops if it does not find build-magic.jar in ANT_HOME/lib Also stops if ANT is not 1.4 version Maybe other... (with a 3 pages explanation if necessary)µ Vincent > -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]De la part de > Jason Dillon > Envoyé : samedi 1 septembre 2001 8:51 > À : Dan - Blue Lotus Software > Cc : [EMAIL PROTECTED] > Objet : RE: [JBoss-dev] requirements for build > > > I will add that to my list of things todo. > > Thanks, > > --jason > > > On Sat, 1 Sep 2001, Dan - Blue Lotus Software wrote: > > > Like I said, simply unsetting the environment variable ANT_HOME > in the build > > script should take care of this. > > > > I use Ant on many other non-JBoss related projects. I need > ANT_HOME to be > > set for these other projects. I assume others will have the > same problem. > > Because I was not aware JBoss included a fully functional Ant in the > > distribution, I was thrown off by this. Simply unsetting ANT_HOME in > > build.bat (and I suspect build.sh, as this is probably a > problem for both > > sides) would have fixed this. > > > > -dan > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Jason > > Dillon > > Sent: Friday, August 31, 2001 11:49 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] requirements for build > > > > > > Perhaps we should ignore any user set ANT_HOME, or warn the > user if it is > > set. > > > > --jason > > > > > > On Fri, 31 Aug 2001, Dan - Blue Lotus Software wrote: > > > > > Yes, this was it. I suggest we unset ANT_HOME in the build script. > > > > > > -dan > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On Behalf Of > > > Vincent Harcq > > > Sent: Friday, August 31, 2001 7:50 PM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [JBoss-dev] requirements for build > > > > > > > > > Hi, > > > Is ANT_HOME env property set ? Unset it and it will run by > finding ant > > from > > > tools/ > > > Vincent. > > > > > > > -Message d'origine- > > > > De : [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED]]De la > part de Dan > > > > - Blue Lotus Software > > > > Envoyé : vendredi 31 août 2001 11:21 > > > > À : JBoss Dev > > > > Objet : [JBoss-dev] requirements for build > > > > > > > > > > > > Well, I downloaded and compiled the Rabbit Hole release of > JBoss today. > > > > It's the first time I've built JBoss from scratch in about 6 > > > > months. At any > > > > rate, I thought I'd reflect a little on a couple of things, > so that I > > can > > > > save people the 30 minutes I spent figuring it out. > > > > > > > > -You need v1.4beta of Ant. The current release is v1.4beta2. > > > > -Copy the jar file from > "/tools/buildmagic-tasks.jar" > > into > > > > the "lib" directory under Ant. > > > > > > > > Once that's done, you can cd into "/build" and > > > > type "build". > > > > > > > > I'm sorry if this is obvious to everyone on this list. It > wasn't for > > me, > > > > though. The directions for buildmagic say nothing about how to > > *install* > > > > it. And the build script contains the tag, which is > > > > only supported > > > > in v1.4beta1 and beyond. > > > > > > > > -dan > > > > > > > > -- > > > > Dan Kirkpatrick, Software Architect > > > > Blue Lotus Software+44 (0) 1224 575 985 > > > > [EMAIL PROTECTED] > > > > http://www.bluelotussoftware.com > > > > > > > > > > > > ___ > > > > Jboss-development mailing list > > > > [EMAIL PROTECTED] > > > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > _ > > > Do You Yahoo!? > > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > > > > ___ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > ___ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___
[JBoss-dev] Re: Persistant HttpSession
Here is what I suggest. Greg, as Kevin suggests, selects the HttpSession class via property or configuration parameter. The current unclustered implementation is the default. We put together a list of the features that such a class might need to offer - I have the following at the moment: Simple - no clustering support Persistant - changes are remembered Distributed - changes are replicated across the cluster (easier with persistance) Possible implementations I have so far: Simple - already done Persistant and Distributed - via e.g. a CMP bean, or a more complex implementation which is a bit cleverer Just Distributed - could use some underlying distribution technology, javaspaces, http://www.javagroups.com/ - faster without persistance I'm putting my hand up for the CMP bean stuff - unless I think of an easier way. Looks like Kevin is keen on a faster P&D solution Bill might be interested in a JavaGroups Distributed implementation ??? How does that sound ? Can anyone think of any more features that might be needed ? Jules Kevin Duffey wrote: > I am not sure I would agree mostly because I personally like to design > things right the first time over getting it out fast. But, I think we can do > both. I haven't been able to look at the source yet, but I imagine if the > container is configurable to specify what session manager to load (via a > class name perhaps), we can then create one (or more) HttpSession > implementations, each with their own special characteristics. In this way, > its pluggable right from the getgo. What we can then do is turn Greg's > existing HttpSession implementation into the "default" class to be loaded. > >From there you and I can maybe both create a different implementation of > HttpSession that is also pluggable so that Jetty will have 3 different > versions. One that is non clusterable (for single JVM use and thus a bit > more speed), and two that are for clustering. > > This is but one way we can maybe go about this. What do you two think? > > > -Original Message- > > From: Julian Gosnell [mailto:[EMAIL PROTECTED]] > > Sent: Friday, August 31, 2001 5:59 AM > > To: Greg Wilkins; Julian Gosnell > > Cc: [EMAIL PROTECTED] > > Subject: Persistant HttpSession > > > > > > > > > I don't know if it needs to be tied into EJBs? > > > Depends on how you > > > design your EJBs I guess. > > > > I think an initial naive implementation would probably > > use EJBs, simply because I'm sitting in an EJB Server, > > with all the necessary infrastructure for persistance > > and distribution surrounding me. > > > > Only problem is, an EJB is a _STATIC_ wrapper around a > > dynamic resource (i.e. you can stick new slots into a > > table at run time, but not into a Java instance), > > whereas an HttpSession is basically a HashTable, with > > dynamic runtime structure. So all I will really be > > doing is having an EJB with one instance data member > > called HashTable, which contains the serialised (by > > value) hastable. > > > > More complex, intelligent and faster implementations > > could be thought up afterwards, but I think the > > initial one should be as simple as possible and out > > there as quickly as possible, and bug-free. > > > > Of course this puts certain constraints on what you > > can put in your HttpSession - it has to be > > serialisable - something Sun did not consider when > > they came up with the HttpSession interface. This > > means that moving a Servlet from a single node > > deployment into a cluster may result in a change in > > behaviour if it is not written according to certain > > guidelines. I assume Sun must have published something > > to this effect - I shall have to hunt it down. > > > > WebSphere implements one other strategy that gets this > > done. The Master which dispatches the request to the > > cluster can be configured to look for a session-id and > > route requests with the same session-id to the same > > node. This approach would allow you to deploy those > > problem Servlets with the standard HttpSession object, > > and no change in semantics - but then it's not really > > clustering is it ... just double processing an HTTP > > request instead of single processing it > > > > Jules > > > > > > > > Do You Yahoo!? > > Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk > > or your free @yahoo.ie address at http://mail.yahoo.ie _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Why did Fast Updates Based on Rowid disappeared?
Browsing the list i couldn't find any clear answers? /Lennart === Lennart Petersson www.benefit.se/english [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss 3.0 and Jetty
Bill, Thanks for the help. I think what will probably happen is that we write several implementations of our HttpSession object, with varying features and cost. Then the user will be able to pay as they go - i.e. only take on the performance hit associated with the particular feature set that they require. I was thinking of a CMP bean as an initial naive and exploratory implementation - I agree it would not be fast, but it would be simple and persistant. I've had a very quick look at your stuff and it looks interesting. It didn't look like it did persistance, but then many people may wish to avoid that overhead. There might well be room for an HttpSession object built on technology like this. When things get a little further I'll come back to you and we'll talk some more. I'd like to get a really simple implementation out of the door so that I understand the problem fully before I really launch into the ultimate solution. Thanks for your mail, Jules Bill Burke wrote: > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of > > Julian Gosnell > > Sent: Friday, August 31, 2001 7:18 AM > > To: marc fleury > > Cc: Greg Wilkins; [EMAIL PROTECTED] > > Subject: [JBoss-dev] JBoss 3.0 and Jetty > > > > > > Marc, > > > > I'm trying to gauge requirements for Jetty within a > > JBoss-3 context. > > > > This is what I have figured so far: > > > > 1. JettyService needs to be delivered as a self > > contained SAR. So it can be hot-deployed onto a JBoss > > node. My major concern here is whether the SAR is run > > packed/unpacked. Unpacked is probably not much work. > > Packed will probably require changes to Jetty itself > > (need to investigate). > > > > 2. Clustered Session support - if an incoming http > > request can be routed to any one of a number of nodes, > > then HttpSession objects need to be transparently > > distributed, in order that conversational state may be > > maintained between client and webapp. I was thinking > > that the simplest HttpSession implementation might be > > a CMP Bean ? Is this how clustering is expected to > > work in 3.0? Is this the sort of approach that you > > would expect ? > > > > Julian, take a look at http://www.javagroups.com especially the > DistributedHashtable. Putting the HttpSession in a CMP Bean is a bad idea. > You don't want to be hitting the database on every click to your site. When > Sacha and I get the HA SFSBs going, I was thinking of making the HttpSession > a SFSB. Just an idea though. > > Regards, > > Bill > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/src/bin update-website.sh
User: user57 Date: 01/09/01 01:36:28 Modified:src/bin update-website.sh Log: o explicitly setting JAVA_HOME so ant does not freak out. Revision ChangesPath 1.6 +5 -1 newsite/src/bin/update-website.sh Index: update-website.sh === RCS file: /cvsroot/jboss/newsite/src/bin/update-website.sh,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- update-website.sh 2001/09/01 02:35:39 1.5 +++ update-website.sh 2001/09/01 08:36:27 1.6 @@ -6,7 +6,7 @@ ## ## ### == ### -# $Id: update-website.sh,v 1.5 2001/09/01 02:35:39 user57 Exp $ +# $Id: update-website.sh,v 1.6 2001/09/01 08:36:27 user57 Exp $ ## ## Returns exit status 0 for success, 1 for errors and 2 for fatal errors. @@ -25,6 +25,10 @@ # Where we will deploy files too DEPLOYROOT="$HOME/website/deploy" + +# Setup Java +JAVA_HOME=/opt/java/jre +export JAVA_HOME ## ## Print an informative message ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: tools/bin ant
User: user57 Date: 01/09/01 01:31:01 Modified:bin ant Log: o exit 1 if we can't find java. Revision ChangesPath 1.4 +1 -1 tools/bin/ant Index: ant === RCS file: /cvsroot/jboss/tools/bin/ant,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- ant 2001/08/30 22:37:31 1.3 +++ ant 2001/09/01 08:31:01 1.4 @@ -66,7 +66,7 @@ if [ ! -x "$JAVACMD" ] ; then echo "Error: JAVA_HOME is not defined correctly." echo " We cannot execute $JAVACMD" - exit + exit 1 fi if [ -n "$CLASSPATH" ] ; then ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
