[JBoss-dev] php5 is coming
have a look at the new php 5 : http://talks.php.net they added : exceptions, modifiers, interfaces, abstract, namespaces and more. it's mono powered. it seems that now they want to reach enterprise level and have to get more credibility for that. julien --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] php5 is coming
sorry I gave a wrong link : http://talks.php.net/show/php5intro jv> have a look at the new php 5 : http://talks.php.net jv> they added : exceptions, modifiers, interfaces, abstract, namespaces and more. jv> it's mono powered. jv> it seems that now they want to reach enterprise level and have jv> to get more credibility for that. jv> julien jv> --- jv> This SF.net email is sponsored by: jv> The Definitive IT and Networking Event. Be There! jv> NetWorld+Interop Las Vegas 2003 -- Register today! jv> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en jv> ___ jv> Jboss-development mailing list jv> [EMAIL PROTECTED] jv> https://lists.sourceforge.net/lists/listinfo/jboss-development -- Best regards, julienmailto:[EMAIL PROTECTED] --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Generic ThreadPool in JBoss?
Hello! I need a thread pool to simplify my code for the HTTP-loadbalancer. Is there a generic ThreadPool in JBoss-code (HEAD)? Any hints welcome CU Thomas --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Generic ThreadPool in JBoss?
There is the jca 1.5 thread pool, BaseWorkManager. It is a simple implementation of the j2ee 1.4 official thread pool. If this provides more than you want to deal with, lets discuss design. david jencks On 2003.03.29 09:04 Thomas Peuss wrote: > Hello! > > I need a thread pool to simplify my code for the HTTP-loadbalancer. > Is there a generic ThreadPool in JBoss-code (HEAD)? > > Any hints welcome > > CU > Thomas > > > > --- > This SF.net email is sponsored by: > The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] hsqldb options
Prompted by a customer, I did some experiments with hsqldb options. Currently we specify a tcp port and require a hsqldb mbean to start the hsqldb server. This opens a port and requires explicit hsqldb shutdown. Two other options that appear to work are: specify url jdbc:hsqldb:. and remove the hsqldb mbean. This results in a totally in memory db, nothing saved to disk. IMO this is appropriate for most of the testsuite since it eliminates problems with data not being cleaned up between test runs. specify url jdbc:hsqldb:somefile and remove the hsqldb mbean. This results in the db saved in a couple of files named like somefile. No port is opened. No explicit shutdown of hsqldb seems to be required (although I didn't test how much data is actually saved) Could someone who knows more about hsqldb please explain clearly why we would want to continue using the setup we have now rather than one of the tcp-port free options? Thanks david jencks --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Generic ThreadPool in JBoss?
Thomas Peuss wrote: Hello! I need a thread pool to simplify my code for the HTTP-loadbalancer. Is there a generic ThreadPool in JBoss-code (HEAD)? I'd go for the concurrent.util (Doug Lea's stuff) thread pool (called PooledExecutor). It will be part of JDK 1.5 (Tiger). -- Bela Ban www.javagroups.com (408) 316-4459 --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] hsqldb options
There is no good reason. At 10:55 AM 3/29/03 -0500, you wrote: Prompted by a customer, I did some experiments with hsqldb options. Currently we specify a tcp port and require a hsqldb mbean to start the hsqldb server. This opens a port and requires explicit hsqldb shutdown. Two other options that appear to work are: specify url jdbc:hsqldb:. and remove the hsqldb mbean. This results in a totally in memory db, nothing saved to disk. IMO this is appropriate for most of the testsuite since it eliminates problems with data not being cleaned up between test runs. specify url jdbc:hsqldb:somefile and remove the hsqldb mbean. This results in the db saved in a couple of files named like somefile. No port is opened. No explicit shutdown of hsqldb seems to be required (although I didn't test how much data is actually saved) Could someone who knows more about hsqldb please explain clearly why we would want to continue using the setup we have now rather than one of the tcp-port free options? Thanks david jencks --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development LEGAL NOTICE This electronic mail transmission and any accompanying documents contain information belonging to the sender which may be confidential and legally privileged. This information is intended only for the use of the individual or entity to whom this electronic mail transmission was sent as indicated above. If you are not the intended recipient, any disclosure, copying, distribution, or action taken in reliance on the contents of the information contained in this transmission is strictly prohibited. If you have received this transmission in error, please delete the message. Thank you --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Generic ThreadPool in JBoss?
The thread pool needs to be a true mbean service with stats and its configuration exposed via JMX, not just a class. The JCA api and associated component David mentioned should be a good start for such a service. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Bela Ban" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, March 29, 2003 7:59 AM Subject: Re: [JBoss-dev] Generic ThreadPool in JBoss? > Thomas Peuss wrote: > > > Hello! > > > > I need a thread pool to simplify my code for the HTTP-loadbalancer. > > Is there a generic ThreadPool in JBoss-code (HEAD)? > > > I'd go for the concurrent.util (Doug Lea's stuff) thread pool (called > PooledExecutor). It will be part of JDK 1.5 (Tiger). > > > -- > Bela Ban > www.javagroups.com > (408) 316-4459 --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] 服装行业的先行者!
声明：以下是杭州服装网提供的部分全国服装代理商资料，如果您不需要该信息，请删除该邮件。 杭州服装网―― 服装行业的先行者 杭州服装网是杭州地区服装行业的门户网站。我们立足于杭州地区，向杭州乃至全国服装企业、服装客商提供优质服务。作为杭州地区服装行业的窗口，杭州服装网从多个层面向全世界展示杭州服装的品质、工艺、款式与文化内涵，帮助杭州服装企业开拓市场，树立品牌形象。 杭州服装网在宣传本地服装企业的同时，也为全国各地的服装客商提供服务。各地代理商，批发商，加工客商，库存贸易商可以通过杭州服装网了解到有关杭州服装企业的各种信息。杭州服装网将帮助各地客商寻找合适的代理厂家、品牌以及提供优质服装货源。 杭州服装网的版块设置非常全面，在网站中设有 [行业动态] [商业机会] [企业名录] [产品展示] [服装库存] [杭派女装] [流行趋势] [时尚论坛] 八大版块。在此基础上，杭州服装网向服装企业提供“国际互联网应用” “企业软件应用” “广告策划、设计” “服装企业市场营销策划”四个大类的综合服务。 杭州服装网期望与服装企业深入、长远的合作。在坦诚相待的基础上，双方保持一种互利互惠，相互扶持的关系。我们非常深刻的理解到，企业的任何投入都期望产生实际效益，因此杭州服装网在制定各项服务时，首先考虑的既是这一点。杭州服装网以帮助企业实现业绩增长为主要宗旨，而我们对服装行业的深入了解以及服装行业的运作经验将保证这一切的实现。 杭州服装网服务宗旨： * 一切从客户的实际效益出发 * 以最少的投入达到最好成效 * 整合资源提供优质全面服务 杭州服装网办公地址：杭州市天成路95号浙江大学科技创业园206 电话：(0571) 86465080 86467128 86455732 传真：(0571)86469732 联系人：郁胜泓 移动电话：13958106746 E_mail：[EMAIL PROTECTED] 网址：www.hzefu.com www.hzefu.net www.hzefu.cn 在线客服（QQ）：965301 --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] hsqldb options
There is no reason why we can't just document both configs and let the user choose what they want. The pure in memory version seems like the better default configuration. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "David Jencks" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, March 29, 2003 7:55 AM Subject: [JBoss-dev] hsqldb options > Prompted by a customer, I did some experiments with hsqldb options. > > Currently we specify a tcp port and require a hsqldb mbean to start the > hsqldb server. This opens a port and requires explicit hsqldb shutdown. > > Two other options that appear to work are: > > specify url jdbc:hsqldb:. and remove the hsqldb mbean. This results in a > totally in memory db, nothing saved to disk. IMO this is appropriate for > most of the testsuite since it eliminates problems with data not being > cleaned up between test runs. > > specify url jdbc:hsqldb:somefile and remove the hsqldb mbean. This results > in the db saved in a couple of files named like somefile. No port is > opened. No explicit shutdown of hsqldb seems to be required (although I > didn't test how much data is actually saved) > > Could someone who knows more about hsqldb please explain clearly why we > would want to continue using the setup we have now rather than one of the > tcp-port free options? > > Thanks > david jencks --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Generic ThreadPool in JBoss?
Also, the jca mbean I wrote uses Doug Lea's implementation for the actual pool. david On 2003.03.29 11:59 Scott M Stark wrote: > The thread pool needs to be a true mbean service with stats and its > configuration > exposed via JMX, not just a class. The JCA api and associated component > David > mentioned should be a good start for such a service. > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > - Original Message - > From: "Bela Ban" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, March 29, 2003 7:59 AM > Subject: Re: [JBoss-dev] Generic ThreadPool in JBoss? > > > > Thomas Peuss wrote: > > > > > Hello! > > > > > > I need a thread pool to simplify my code for the HTTP-loadbalancer. > > > Is there a generic ThreadPool in JBoss-code (HEAD)? > > > > > > I'd go for the concurrent.util (Doug Lea's stuff) thread pool (called > > PooledExecutor). It will be part of JDK 1.5 (Tiger). > > > > > > -- > > Bela Ban > > www.javagroups.com > > (408) 316-4459 > > > > --- > This SF.net email is sponsored by: > The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Generic ThreadPool in JBoss?
I say write your own pool. You can usually optimize it more closely than a generic service. Well, that's my experience from writing the PooledInvoker. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of David > Jencks > Sent: Saturday, March 29, 2003 12:44 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Generic ThreadPool in JBoss? > > > Also, the jca mbean I wrote uses Doug Lea's implementation for the actual > pool. > > david > > On 2003.03.29 11:59 Scott M Stark wrote: > > The thread pool needs to be a true mbean service with stats and its > > configuration > > exposed via JMX, not just a class. The JCA api and associated component > > David > > mentioned should be a good start for such a service. > > > > > > Scott Stark > > Chief Technology Officer > > JBoss Group, LLC > > > > > > - Original Message - > > From: "Bela Ban" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Saturday, March 29, 2003 7:59 AM > > Subject: Re: [JBoss-dev] Generic ThreadPool in JBoss? > > > > > > > Thomas Peuss wrote: > > > > > > > Hello! > > > > > > > > I need a thread pool to simplify my code for the HTTP-loadbalancer. > > > > Is there a generic ThreadPool in JBoss-code (HEAD)? > > > > > > > > > I'd go for the concurrent.util (Doug Lea's stuff) thread pool (called > > > PooledExecutor). It will be part of JDK 1.5 (Tiger). > > > > > > > > > -- > > > Bela Ban > > > www.javagroups.com > > > (408) 316-4459 > > > > > > > > --- > > This SF.net email is sponsored by: > > The Definitive IT and Networking Event. Be There! > > NetWorld+Interop Las Vegas 2003 -- Register today! > > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > --- > This SF.net email is sponsored by: > The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] hsqldb options
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of David > Jencks > Sent: Saturday, March 29, 2003 10:55 AM > To: [EMAIL PROTECTED] > Subject: [JBoss-dev] hsqldb options > > > Prompted by a customer, I did some experiments with hsqldb options. > > Currently we specify a tcp port and require a hsqldb mbean to start the > hsqldb server. This opens a port and requires explicit hsqldb shutdown. > > Two other options that appear to work are: > > specify url jdbc:hsqldb:. and remove the hsqldb mbean. This results in a > totally in memory db, nothing saved to disk. IMO this is appropriate for > most of the testsuite since it eliminates problems with data not being > cleaned up between test runs. > > specify url jdbc:hsqldb:somefile and remove the hsqldb mbean. > This results > in the db saved in a couple of files named like somefile. No port is > opened. No explicit shutdown of hsqldb seems to be required (although I > didn't test how much data is actually saved) > > Could someone who knows more about hsqldb please explain clearly why we > would want to continue using the setup we have now rather than one of the > tcp-port free options? > Man, if only hsqldb was transactional. We should recruit them to become a JBoss project and put keen transactional minds like David Jencks on the subject. A fully transactional in-memory DBMS would kick the crap out of everybody in benchmarking. I'm surprise Oracle 9iAS doesn't run in-process with the Oracle DBMS already Bill --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] hsqldb options
Well, for quick prototyping it is nice to use the persistent version which allows to use JBossMQ for example and restart JBoss without loosing persistent messages. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Scott M Stark > Sent: samedi, 29. mars 2003 18:45 > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] hsqldb options > > > There is no reason why we can't just document both configs > and let the user > choose what they want. The pure in memory version seems like > the better > default configuration. > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > - Original Message - > From: "David Jencks" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, March 29, 2003 7:55 AM > Subject: [JBoss-dev] hsqldb options > > > > Prompted by a customer, I did some experiments with hsqldb options. > > > > Currently we specify a tcp port and require a hsqldb mbean > to start the > > hsqldb server. This opens a port and requires explicit > hsqldb shutdown. > > > > Two other options that appear to work are: > > > > specify url jdbc:hsqldb:. and remove the hsqldb mbean. > This results in a > > totally in memory db, nothing saved to disk. IMO this is > appropriate for > > most of the testsuite since it eliminates problems with > data not being > > cleaned up between test runs. > > > > specify url jdbc:hsqldb:somefile and remove the hsqldb > mbean. This results > > in the db saved in a couple of files named like somefile. > No port is > > opened. No explicit shutdown of hsqldb seems to be > required (although I > > didn't test how much data is actually saved) > > > > Could someone who knows more about hsqldb please explain > clearly why we > > would want to continue using the setup we have now rather > than one of the > > tcp-port free options? > > > > Thanks > > david jencks > > > > --- > This SF.net email is sponsored by: > The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] hsqldb options
Did you take a look at McKoi? http://www.mckoi.com/database/ >From the DOC: = There are four transaction isolation levels defined by the SQL standard. Each isolation level provides varying degrees of protection from seeing changes made by concurrent connections. The Mckoi database engine supports the strongest isolation level defined by the standard - TRANSACTION_SERIALIZABLE. This isolation level prevents a transaction from seeing all types of concurrent changes. The Mckoi database engine achieves this through a multi-version data model that efficiently manages and isolates multiple views of the underlying data. During a transaction the connection sees a version (or snapshot) of the database that is isolated from any changes made by other connections. Additionally, any changes made within the context of a transaction are isolated from the rest of the database. This means that while a transaction is open the view a connection has of the database is blind from changes made by other concurrent connections. The multi-version data model allows the Mckoi database engine to avoid all inter-transactional table/row locking and deadlock issues. No tables or rows are locked between concurrent transactions. While one transaction is reading from a table, another transaction may update the table at the same time. Any data consistency conflicts (for example, two connections committing a change that deletes the same row from a table) are detected when a transaction is committed. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Bill Burke > Sent: samedi, 29. mars 2003 19:00 > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] hsqldb options > > > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > Behalf Of David > > Jencks > > Sent: Saturday, March 29, 2003 10:55 AM > > To: [EMAIL PROTECTED] > > Subject: [JBoss-dev] hsqldb options > > > > > > Prompted by a customer, I did some experiments with hsqldb options. > > > > Currently we specify a tcp port and require a hsqldb mbean > to start the > > hsqldb server. This opens a port and requires explicit > hsqldb shutdown. > > > > Two other options that appear to work are: > > > > specify url jdbc:hsqldb:. and remove the hsqldb mbean. > This results in a > > totally in memory db, nothing saved to disk. IMO this is > appropriate for > > most of the testsuite since it eliminates problems with > data not being > > cleaned up between test runs. > > > > specify url jdbc:hsqldb:somefile and remove the hsqldb mbean. > > This results > > in the db saved in a couple of files named like somefile. > No port is > > opened. No explicit shutdown of hsqldb seems to be > required (although I > > didn't test how much data is actually saved) > > > > Could someone who knows more about hsqldb please explain > clearly why we > > would want to continue using the setup we have now rather > than one of the > > tcp-port free options? > > > > > Man, if only hsqldb was transactional. We should recruit > them to become a > JBoss project and put keen transactional minds like David > Jencks on the > subject. A fully transactional in-memory DBMS would kick the > crap out of > everybody in benchmarking. I'm surprise Oracle 9iAS doesn't > run in-process > with the Oracle DBMS already > > Bill > > > > --- > This SF.net email is sponsored by: > The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] hsqldb options
Thinking more about this, the default config should continue to be the file based persistence version since that is what users may already be using for a persistent store across server restarts. If you want a change in this behavior you need to change the hsqldb jca setup. Just document it in the configs so its easy to do. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Scott M Stark" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, March 29, 2003 9:44 AM Subject: Re: [JBoss-dev] hsqldb options > There is no reason why we can't just document both configs and let the user > choose what they want. The pure in memory version seems like the better > default configuration. > --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Generic ThreadPool in JBoss?
And that is contrary to the generic services architecture we want. First demonstrate the generic service does not work before coding a one-off. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Bill Burke" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, March 29, 2003 9:52 AM Subject: RE: [JBoss-dev] Generic ThreadPool in JBoss? > I say write your own pool. You can usually optimize it more closely than a > generic service. Well, that's my experience from writing the PooledInvoker. > > Bill --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] XMBean and transient attributes
I'm working on updating the xmbean tests in 3.2 to make sure what we will have in the 3.2.0 release is usable and there is an issue with transient attributes and the default value for currencyTimeLimit. An attribute element like: SecMgr is a read-write attribute added at the metadata level for which there is no state in the User2 instance. SecMgr javax.management.ObjectName where there is no currencyTimeLimit defined fails to have a value for this attribute, and a value cannot be set. Given that it has a default value this does not seem like valid behavior. If the currencyTimeLimit set to -1 then the default value is seen as the initial value for the attribute and it may be updated. SecMgr is a read-write attribute added at the metadata level for which there is no state in the User2 instance. SecMgr javax.management.ObjectName The question is why should a failure to specify the attribute descriptors result in an unusable attribute? Either the caching logic is faulty or the implicit settings for the attribute descriptors a not correct. --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] hsqldb options
Too many writes, to many Optimistic exceptions. TRANSACTION_SERIALIZABLE usually is considered a performance bottleneck in the same way that our QueuedPessismistic Entity bean lock can be a bottleneck as well. I would like to try out ECPERF with Mckoi to see what kind of performance boost we could get. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Sacha > Labourey > Sent: Saturday, March 29, 2003 1:09 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] hsqldb options > > > Did you take a look at McKoi? http://www.mckoi.com/database/ > > >From the DOC: > = > There are four transaction isolation levels defined by the SQL standard. > Each isolation level provides varying degrees of protection from seeing > changes made by concurrent connections. The Mckoi database engine supports > the strongest isolation level defined by the standard - > TRANSACTION_SERIALIZABLE. This isolation level prevents a transaction from > seeing all types of concurrent changes. The Mckoi database engine achieves > this through a multi-version data model that efficiently manages and > isolates multiple views of the underlying data. > > During a transaction the connection sees a version (or snapshot) of the > database that is isolated from any changes made by other connections. > Additionally, any changes made within the context of a transaction are > isolated from the rest of the database. This means that while a > transaction > is open the view a connection has of the database is blind from > changes made > by other concurrent connections. > > The multi-version data model allows the Mckoi database engine to avoid all > inter-transactional table/row locking and deadlock issues. No > tables or rows > are locked between concurrent transactions. While one transaction > is reading > from a table, another transaction may update the table at the > same time. Any > data consistency conflicts (for example, two connections > committing a change > that deletes the same row from a table) are detected when a transaction is > committed. > > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On > > Behalf Of Bill Burke > > Sent: samedi, 29. mars 2003 19:00 > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] hsqldb options > > > > > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] > > Behalf Of David > > > Jencks > > > Sent: Saturday, March 29, 2003 10:55 AM > > > To: [EMAIL PROTECTED] > > > Subject: [JBoss-dev] hsqldb options > > > > > > > > > Prompted by a customer, I did some experiments with hsqldb options. > > > > > > Currently we specify a tcp port and require a hsqldb mbean > > to start the > > > hsqldb server. This opens a port and requires explicit > > hsqldb shutdown. > > > > > > Two other options that appear to work are: > > > > > > specify url jdbc:hsqldb:. and remove the hsqldb mbean. > > This results in a > > > totally in memory db, nothing saved to disk. IMO this is > > appropriate for > > > most of the testsuite since it eliminates problems with > > data not being > > > cleaned up between test runs. > > > > > > specify url jdbc:hsqldb:somefile and remove the hsqldb mbean. > > > This results > > > in the db saved in a couple of files named like somefile. > > No port is > > > opened. No explicit shutdown of hsqldb seems to be > > required (although I > > > didn't test how much data is actually saved) > > > > > > Could someone who knows more about hsqldb please explain > > clearly why we > > > would want to continue using the setup we have now rather > > than one of the > > > tcp-port free options? > > > > > > > > > Man, if only hsqldb was transactional. We should recruit > > them to become a > > JBoss project and put keen transactional minds like David > > Jencks on the > > subject. A fully transactional in-memory DBMS would kick the > > crap out of > > everybody in benchmarking. I'm surprise Oracle 9iAS doesn't > > run in-process > > with the Oracle DBMS already > > > > Bill > > > > > > > > --- > > This SF.net email is sponsored by: > > The Definitive IT and Networking Event. Be There! > > NetWorld+Interop Las Vegas 2003 -- Register today! > > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > --- > This SF.net email is sponsored by: > The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --
RE: [JBoss-dev] hsqldb options
Strange, seems that you can turn of commit conflicts for dirty reads. This is actually READ_COMMITTED behavior. Cool. This DB seem cool. Wonder how well it works. > -Original Message- > From: Bill Burke [mailto:[EMAIL PROTECTED] > Sent: Saturday, March 29, 2003 3:00 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] hsqldb options > > > Too many writes, to many Optimistic exceptions. > TRANSACTION_SERIALIZABLE usually is considered a performance > bottleneck in the same way that our QueuedPessismistic Entity > bean lock can be a bottleneck as well. I would like to try out > ECPERF with Mckoi to see what kind of performance boost we could get. > > Bill > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of Sacha > > Labourey > > Sent: Saturday, March 29, 2003 1:09 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] hsqldb options > > > > > > Did you take a look at McKoi? http://www.mckoi.com/database/ > > > > >From the DOC: > > = > > There are four transaction isolation levels defined by the SQL standard. > > Each isolation level provides varying degrees of protection from seeing > > changes made by concurrent connections. The Mckoi database > engine supports > > the strongest isolation level defined by the standard - > > TRANSACTION_SERIALIZABLE. This isolation level prevents a > transaction from > > seeing all types of concurrent changes. The Mckoi database > engine achieves > > this through a multi-version data model that efficiently manages and > > isolates multiple views of the underlying data. > > > > During a transaction the connection sees a version (or snapshot) of the > > database that is isolated from any changes made by other connections. > > Additionally, any changes made within the context of a transaction are > > isolated from the rest of the database. This means that while a > > transaction > > is open the view a connection has of the database is blind from > > changes made > > by other concurrent connections. > > > > The multi-version data model allows the Mckoi database engine > to avoid all > > inter-transactional table/row locking and deadlock issues. No > > tables or rows > > are locked between concurrent transactions. While one transaction > > is reading > > from a table, another transaction may update the table at the > > same time. Any > > data consistency conflicts (for example, two connections > > committing a change > > that deletes the same row from a table) are detected when a > transaction is > > committed. > > > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On > > > Behalf Of Bill Burke > > > Sent: samedi, 29. mars 2003 19:00 > > > To: [EMAIL PROTECTED] > > > Subject: RE: [JBoss-dev] hsqldb options > > > > > > > > > > > > > > > > -Original Message- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] > > > Behalf Of David > > > > Jencks > > > > Sent: Saturday, March 29, 2003 10:55 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: [JBoss-dev] hsqldb options > > > > > > > > > > > > Prompted by a customer, I did some experiments with hsqldb options. > > > > > > > > Currently we specify a tcp port and require a hsqldb mbean > > > to start the > > > > hsqldb server. This opens a port and requires explicit > > > hsqldb shutdown. > > > > > > > > Two other options that appear to work are: > > > > > > > > specify url jdbc:hsqldb:. and remove the hsqldb mbean. > > > This results in a > > > > totally in memory db, nothing saved to disk. IMO this is > > > appropriate for > > > > most of the testsuite since it eliminates problems with > > > data not being > > > > cleaned up between test runs. > > > > > > > > specify url jdbc:hsqldb:somefile and remove the hsqldb mbean. > > > > This results > > > > in the db saved in a couple of files named like somefile. > > > No port is > > > > opened. No explicit shutdown of hsqldb seems to be > > > required (although I > > > > didn't test how much data is actually saved) > > > > > > > > Could someone who knows more about hsqldb please explain > > > clearly why we > > > > would want to continue using the setup we have now rather > > > than one of the > > > > tcp-port free options? > > > > > > > > > > > > > Man, if only hsqldb was transactional. We should recruit > > > them to become a > > > JBoss project and put keen transactional minds like David > > > Jencks on the > > > subject. A fully transactional in-memory DBMS would kick the > > > crap out of > > > everybody in benchmarking. I'm surprise Oracle 9iAS doesn't > > > run in-process > > > with the Oracle DBMS already > > > > > > Bill > > > > > > > > > > > > --- > > > This SF.net email is sponsored by: > > > The Definitive IT and Networking Event. Be There! > > > NetWorld+Interop Las Vegas 2003 -- Register today! > > > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > > >
[JBoss-dev] [ jboss-Bugs-710396 ] Deployed .war unaccessible in Tomcat 4.1
Bugs item #710396, was opened at 2003-03-26 15:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=710396&group_id=22866 Category: CatalinaBundle Group: v3.2 Status: Open Resolution: Works For Me Priority: 5 Submitted By: Stefan Reich (sreich) Assigned to: Scott M Stark (starksm) Summary: Deployed .war unaccessible in Tomcat 4.1 Initial Comment: Platform MacOSX 10.2.4, JDK 1.4.1, Jboss 3.2 latest CVS, Tomcat 4.1.24 (and 4.1.18). Some recent change broke tomcat deployment. Although there is no error during the deployment, the servlet can't be accessed. To reproduce try to access jmx-console. -- >Comment By: Remy Maucherat (remm) Date: 2003-03-29 12:46 Message: Logged In: YES user_id=24140 Let's start with the first issue (the NPE). Since you can build the bundle, could you try using the new SAR based packaging ? If there's a path related problem, it could help (or makes things worse, but in any case, it needs testing). Use the "bundle-express" target to create the SAR based bundle. -- Comment By: Stefan Reich (sreich) Date: 2003-03-28 15:26 Message: Logged In: YES user_id=429729 Great, the attachment is too long for SF. You can also check out and build ecperf from the jboss cvs, which will give you the same files. -- Comment By: Stefan Reich (sreich) Date: 2003-03-28 15:16 Message: Logged In: YES user_id=429729 When I launch run.sh from the local directory I am able to access jmx-console. That's fine. However, when I deploy emulator.ear and ecperf.ear from ECperf the servlet can't find the java:comp context. This used to work about two weeks ago. I attached the jar files. To reproduce: untar the attachment in your deployment dir and start the container. Don't worry if you see SQLException exceptions during deployment, the exception below happens regardless if the database is up or not: javax.servlet.ServletException: comp not bound at com.sun.ecperf.supplier.web.SupplierDomainServlet.init(SupplierDomainServlet.java:94) at javax.servlet.GenericServlet.init(GenericServlet.java:256) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:935) at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:668) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) [..] 14:26:20,012 ERROR [STDERR] javax.naming.NameNotFoundException: comp not bound 14:26:20,014 ERROR [STDERR] at org.jnp.server.NamingServer.getBinding(NamingServer.java:495) 14:26:20,014 ERROR [STDERR] at org.jnp.server.NamingServer.getBinding(NamingServer.java:503) 14:26:20,014 ERROR [STDERR] at org.jnp.server.NamingServer.getObject(NamingServer.java:509) 14:26:20,015 ERROR [STDERR] at org.jnp.server.NamingServer.lookup(NamingServer.java:253) 14:26:20,015 ERROR [STDERR] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:492) 14:26:20,015 ERROR [STDERR] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:471) 14:26:20,016 ERROR [STDERR] at javax.naming.InitialContext.lookup(InitialContext.java:347) 14:26:20,016 ERROR [STDERR] at com.sun.ecperf.supplier.web.SupplierDomainServlet.init(SupplierDomainServlet.java:86) 14:26:20,016 ERROR [STDERR] at javax.servlet.GenericServlet.init(GenericServlet.java:256) 14:26:20,017 ERROR [STDERR] at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:935) 14:26:20,017 ERROR [STDERR] at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:668) 14:26:20,017 ERROR [STDERR] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210) 14:26:20,017 ERROR [STDERR] at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) 14:26:20,018 ERROR [STDERR] at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) 14:26:20,018 ERROR [STDERR] at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) 14:26:20,018 ERROR [STDERR] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) 14:26:20,018 ERROR [STDERR] at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) 14:26:20,019 ERROR [STDERR] at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246) 14:26:20,019 ERROR [STDERR] at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) 14:26:20,019 ERROR [STDERR] at org.apache.catalina.core.StandardPipeline.inv
[JBoss-dev] 服装行业的先行者!
声明：以下是杭州服装网提供的部分全国服装代理商资料，如果您不需要该信息，请删除该邮件。 杭州服装网―― 服装行业的先行者 杭州服装网是杭州地区服装行业的门户网站。我们立足于杭州地区，向杭州乃至全国服装企业、服装客商提供优质服务。作为杭州地区服装行业的窗口，杭州服装网从多个层面向全世界展示杭州服装的品质、工艺、款式与文化内涵，帮助杭州服装企业开拓市场，树立品牌形象。 杭州服装网在宣传本地服装企业的同时，也为全国各地的服装客商提供服务。各地代理商，批发商，加工客商，库存贸易商可以通过杭州服装网了解到有关杭州服装企业的各种信息。杭州服装网将帮助各地客商寻找合适的代理厂家、品牌以及提供优质服装货源。 杭州服装网的版块设置非常全面，在网站中设有 [行业动态] [商业机会] [企业名录] [产品展示] [服装库存] [杭派女装] [流行趋势] [时尚论坛] 八大版块。在此基础上，杭州服装网向服装企业提供“国际互联网应用” “企业软件应用” “广告策划、设计” “服装企业市场营销策划”四个大类的综合服务。 杭州服装网期望与服装企业深入、长远的合作。在坦诚相待的基础上，双方保持一种互利互惠，相互扶持的关系。我们非常深刻的理解到，企业的任何投入都期望产生实际效益，因此杭州服装网在制定各项服务时，首先考虑的既是这一点。杭州服装网以帮助企业实现业绩增长为主要宗旨，而我们对服装行业的深入了解以及服装行业的运作经验将保证这一切的实现。 杭州服装网服务宗旨： * 一切从客户的实际效益出发 * 以最少的投入达到最好成效 * 整合资源提供优质全面服务 杭州服装网办公地址：杭州市天成路95号浙江大学科技创业园206 电话：(0571) 86465080 86467128 86455732 传真：(0571)86469732 联系人：郁胜泓 移动电话：13958106746 E_mail：[EMAIL PROTECTED] 网址：www.hzefu.com www.hzefu.net www.hzefu.cn 在线客服（QQ）：965301 --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] What is the diff between the two xmbean default settings
There are two "default" values in an xmbean attribute declaration, one of which appears to be ignored. For this attribute: Pi is a read-only attribute added at the metadata level for which there is no state in the User2 instance. Pi double only the in the descriptors results in the attribute having a value that is accessible via a getAttribute call on the mbean server. What is the purpose of the default attribute in the attribute element? Scott Stark Chief Technology Officer JBoss Group, LLC --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] XMBean and transient attributes
it should set the value to -1 in the MBeanAttributeInfo descriptor if no getMethod fields are specified // if no method mapping, enable caching automatically if (getMethod == null && currTimeLimit == null) descr.setField(CURRENCY_TIME_LIMIT, "-1"); -- Juha On Sat, 29 Mar 2003, Scott M Stark wrote: > I'm working on updating the xmbean tests in 3.2 to make sure what we will > have in the 3.2.0 release is usable and there is an issue with transient attributes > and the default value for currencyTimeLimit. An attribute element like: > > default="jboss.security:service=JaasSecurityManager"> > SecMgr is a read-write attribute added at the metadata level > for which there is no state in the User2 instance. > > SecMgr > javax.management.ObjectName > > > where there is no currencyTimeLimit defined fails to have a value for this attribute, > and a value cannot be set. Given that it has a default value this does not seem like > valid behavior. If the currencyTimeLimit set to -1 then the default value is seen > as the initial value for the attribute and it may be updated. > > default="jboss.security:service=JaasSecurityManager"> > SecMgr is a read-write attribute added at the metadata level > for which there is no state in the User2 instance. > > SecMgr > javax.management.ObjectName > > > > > > The question is why should a failure to specify the attribute descriptors result in > an unusable attribute? Either the caching logic is faulty or the implicit settings > for > the attribute descriptors a not correct. > > > > > --- > This SF.net email is sponsored by: > The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > -- Juha Lindfors Author of "JMX: Managing J2EE with Java Management Extensions" --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] hsqldb options
lördagen den 29 mars 2003 kl 18.54 skrev Sacha Labourey: Well, for quick prototyping it is nice to use the persistent version which allows to use JBossMQ for example and restart JBoss without loosing persistent messages. Yes when You want to prototype a remote DB for some reason, the legacy start of a org.hsqldb.Server is quick. For running testsuites or using a "sql-cashe" the recommended way is to start the Hypesonic mbean with the "Persist = false" flag, that will yield a non-network hsqldb instance. That is about 300% faster then a legacy networked instance. Read the Change note [ 636781 ] hsqldb configuration v 1.7.1 here : http://sourceforge.net/tracker/ index.php?func=detail&aid=636781&group_id=22866&atid=381174 Many moons ago Richard punched out a sample mbean for a thirdparty lib - that has resulted in the hsqldb legacy mbean with funky lingering threads holding on to sockets ... Other then that the Hypersonic mbean also let us use the Hypersonic DatabaseManager in a easy fashion - needed when running as "Persist = false" since that instance is not visible outside of the VM. The natural way is for the hsqldb team to make a JMX distro - and I understand they are working on the DatabaseManager to become a jmx component - discussion here : http://sourceforge.net/forum/forum.php?thread_id=817198&forum_id=73673 Also it has been expressed, some directions toward a JMX HSQLDB, for us and others to use. /peter_f --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] What is the diff between the two xmbean default settings
I think the one that is an attribute of the attribute element is a leftover from the xmbean implementation in Juha's book, later replaced with the "default" element in the descriptors. david jencks On 2003.03.29 16:41 Scott M Stark wrote: > There are two "default" values in an xmbean attribute declaration, one of > which appears to be ignored. For this attribute: > > > Pi is a read-only attribute added at the metadata > level > for which there is no state in the User2 instance. > > Pi > double > > > > > > > only the in the descriptors results in the > attribute > having a value that is accessible via a getAttribute call on the mbean > server. What > is the purpose of the default attribute in the attribute element? > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > > --- > This SF.net email is sponsored by: > The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] What is the diff between the two xmbean default settings
Ok, its not used anywhere in the code so I dropped it from the dtd. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "David Jencks" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, March 29, 2003 7:06 PM Subject: Re: [JBoss-dev] What is the diff between the two xmbean default settings > I think the one that is an attribute of the attribute element is a leftover > from the xmbean implementation in Juha's book, later replaced with the > "default" element in the descriptors. > > david jencks --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
