RE: [JBoss-dev] Fixing the management info layer
FYI, I've created a forum on the topic. http://www.jboss.org/forums/forum.jsp?forum=160 Scott McLaughlin, do you want to drive any of this? Seems you've had some energy around this. Bill Burke Chief Architect JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Scott M Stark Sent: Monday, December 23, 2002 2:48 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Fixing the management info layer We need better management information. A lot of the JSR-77 stuff is useful information, the only problem was with how it was integrated, not really tested, and not understood by the people working on the core stuff into which this foreign code was interjected. Where applicable this should be integrated via interceptors and/or aspects that emit JMX notifications on which JSR-77 bean may be created. So the first step is to replace the existing JSR-77 stuff with what we actually need to do management and support of JBoss. For caches, pools, invocations, etc. there needs to be low impact asynchronous events that allow for collection of this information and rehashing statistically and historically. I want this working in 3.2 as well so where the aspect stuff cannot be used alternative approaches are needed. Scott Stark Chief Technology Officer JBoss Group, LLC From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 23, 2002 11:22 AM Subject: Management layer Before you do anything to the jsr-77 stuff, I'd like to know if we plan to continue to implement it. Although I personally never got why it is useful under any circumstances, I'm willing to believe e.g. marc if he says we should keep it. anyway, -- if we plan to implement it, I suggest moving directly to an mbean interceptor/aspect based implementation where we keep the management module more or less the same but replace the stuff spread all over the rest of the code with interceptors. -- if we plan to not implement it, ... remove it all. I think even a somewhat lame implementation will provide an easier base for improvement than starting over from scratch. Do we have anyone interested in working on it? There was a guy helping andy for a while. thanks david --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Good-bye
Hiram, you still have access! We need you man! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Hiram Chirino Sent: Saturday, December 21, 2002 2:06 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Good-bye Yep.. i'd like to know the same. Seems like that same thing has happend to me too. Today I tried to do a CVS commit and i got a [server aborted]: commit requires write access to the repository I's this right? What's the inactivity period before write access is revoked?? Regards, Hiram -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Darrell Sent: Saturday, December 21, 2002 12:47 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Good-bye why did they do that? - Original Message - From: Andy [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, December 20, 2002 6:39 PM Subject: [JBoss-dev] Good-bye Hi Geeks Yesterday my CVS RW access to JBoss was revoked and therefore I will not work on the JBoss project at all. Unfortunately this also means that I cannot update my changes to the Quick Start Guide and the EJB Timer Service I was working on. Even though that it makes me angry that I spent many hours helping JBoss become a success I still wish the project all the success it deserves. Have a nice day Andreas Schaefer Code or be coded Check out www.madplanet.com --- This SF.NET email is sponsored by: The Best Geek Holiday Gifts! Time is running out! Thinkgeek.com has the coolest gifts for your favorite geek. Let your fingers do the typing. Visit Now. T H I N K G E E K . C O Mhttp://www.thinkgeek.com/sf/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: The Best Geek Holiday Gifts! Time is running out! Thinkgeek.com has the coolest gifts for your favorite geek. Let your fingers do the typing. Visit Now. T H I N K G E E K . C O Mhttp://www.thinkgeek.com/sf/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: The Best Geek Holiday Gifts! Time is running out! Thinkgeek.com has the coolest gifts for your favorite geek. Let your fingers do the typing. Visit Now. T H I N K G E E K . C O Mhttp://www.thinkgeek.com/sf/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: Order your Holiday Geek Presents Now! Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap, MP3 Players, XBox Games, Flying Saucers, WebCams, Smart Putty. T H I N K G E E K . C O M http://www.thinkgeek.com/sf/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Finder isolationlevel/synchronization
The only way to avoid dirty reads I think is at the JDBC isolation level and
setting the Isolation level to SERIALIZED.
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Peter
Antman
Sent: Friday, December 20, 2002 9:12 AM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] Finder isolationlevel/synchronization
Hi,
maybe have have missed something in the specs or just am igonrant, but I
know what I now will explained used to work:
Doing a findByXXX at the same time from different threads, where the
thread will compete about being the first one to create an entity, which
the other one should use if found used to work in 2.4, but does not work
in 3.0.
Pseudocode
try {
findByMessageKey()
}catch(FinderException e) {
creatBeanWithKey
}
Is this not possible to do according to the EJB spec or JBoss, or is it
possible that a bug is lurking. Basically what I am asking is this:
is there any mechanism to see to it that a finder that is invoked in a
transaction will not answer a new finder question untill the first
transaction has commited. To mee it seems to be the only way to be
guaranteed from dirty reads in findBy:s?
//Peter
--
Peter Antman Chief Technology Officer, Development
Technology in Media, Box 34105 100 26 Stockholm
WWW: http://www.tim.seWWW: http://www.backsource.org
Email: [EMAIL PROTECTED]
Phone: +46-(0)8-506 381 11 Mobile: +46-(0)704 20 58 11
---
This SF.NET email is sponsored by: The Best Geek Holiday Gifts!
Time is running out! Thinkgeek.com has the coolest gifts for
your favorite geek. Let your fingers do the typing. Visit Now.
T H I N K G E E K . C O Mhttp://www.thinkgeek.com/sf/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by: The Best Geek Holiday Gifts!
Time is running out! Thinkgeek.com has the coolest gifts for
your favorite geek. Let your fingers do the typing. Visit Now.
T H I N K G E E K . C O Mhttp://www.thinkgeek.com/sf/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JSR-77 Statistics Provider
You are? There are a bunch of people working on the same thing. Can you post what you're doing? Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Sacha Labourey Sent: Tuesday, December 17, 2002 4:22 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JSR-77 Statistics Provider FYI I am currently working on a Web Console framework for JBoss. Cheers, Sacha -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Marcus Redeker Envoyé : mardi, 17 décembre 2002 22:14 À : [EMAIL PROTECTED] Objet : [JBoss-dev] JSR-77 Statistics Provider All, is there currently any more developing going on to implement the JSR-77 statistics provider. I am currently looking at creating a webapp similar to the BEW console because a lot of big companies are looking for something like that. Especially the statistics. So far I only know of the BeachCacheMonitorMBean and the BeanLockingMonitor. Is there anything else?? And if so is it reachable through JSR-77 statistics provider or just through the MBean Server? Thanks, --Marcus --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss and UML?
You want it. Do it. Bill Burke Chief Architect JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of wonder sonic Sent: Saturday, December 14, 2002 12:24 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] JBoss and UML? Hello, Looking the source code of the 4.0.0alpha version, I noticed the presence of Together diagrams in the jboss.net/testsuite directory. Wouldn't it be useful to add such development documentation (UML diagrams, not only classes diagrams) to other modules? I think it could help new developers who wish to contribute. Best regards, WS ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss and UML?
There's some tool out there, forget the name JVision or something like that that allows you to specify java classes and it will suck up classes and create diagrams. UML is nice, but not necessary. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks Sent: Saturday, December 14, 2002 6:29 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JBoss and UML? On 2002.12.14 16:47:48 -0500 wonder sonic wrote: --- David Jencks [EMAIL PROTECTED] a écrit : On 2002.12.14 14:01:45 -0500 wonder sonic wrote: Well, it's a sort of answer I really appreciate (seriously). However, I think it should be detailed. -1- Where should those diagrams reside? in the same directories of the java files or in an other directory named diagrams (for example). -2- AFAIK, only the ones who have designed the different modules might create the best UML diagrams (activity, usecase...). I haven't the impertinence to say that I could do that! :) -3- A synchronization problem could occur for the developers who don't have such tools: modification of the source code whitout modification of the diagrams. I think this is a really serious problem. I also think most developers don't think uml diagrams work very well for the kind of meta-programming done in a lot of the server core. Could you please explain what you mean by meta-programming? Basically interceptor based, reflective, or aspect oriented programming techniques. Do you think a uml diagram of say a transaction interceptor or a lock interceptor provides a useful explanation of what it does? I haven't seen any evidence that it does, but am very open to demonstrations. I haven't tried, but would be happy if this was demonstrated to be wrong. In most cases, UML diagrams could help to communicate new developments design, explain *quickly* the dependencies between packages, classes and interfaces, show the logic of an algorithm... Moreover, the fact that UML is a graphical language reduces the explanation of a complex algorithm for example: - http://www.visualuml.com/Sample%20Diagrams/Fig%209-1%20Activity%20 Diagram.jpg - http://msdn.microsoft.com/library/en-us/f_and_m/html/vxfm7_topleve ldiagram.gif - http://www.smartdraw.com/resources/centers/flowcharts/images/flowc hart_deployment_example.gif Personally I have found uml diagrams sometimes useful in organizing my own thinking but have never been able to communicate any useful ideas using them. -4- Perhaps some Together project files could be added? Who is going to keep them in sync? Out of date is worse than not there. Indeed! In fact, we can consider UML diagrams as a complement to javadoc. When a development is done, javadoc should be synchronized with it, UML diagrams should be synchronized the same way. Should covers a lot of territory here. Our javadocs are mostly missing and wrong. I think developers will have to find any such diagram very easy to create and very helpful in their own development process before you will find anyone making or updating them. I suspect this would only take off if the diagrams were the basis of some kind of code generation, such as done with uml2ejb. The main problem is how can developers update UML diagrams? An open source tool would be welcome. Thus my suggestion of argo (free, open source)/poseidon (commercial version of the same tool, with free community edition). -5- I can personnaly create class diagrams for the JBoss modules. What format shall I use? wmf, gif, Together (v6)? I suggest xmi using argo/poseidon. Yes, xmi is a standard for UML diagrams. But they only are useful to those who can use them with the right tool. I think an image format could be used too for those who don't have such tool. again, argo is completely free and poseidon has a free version. They are both pretty lightweight. I'll be interested to see what you come up with. thanks david jencks WS david jencks WS --- Bill Burke [EMAIL PROTECTED] a écrit : You want it. Do it. Bill Burke Chief Architect JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of wonder sonic Sent: Saturday, December 14, 2002 12:24 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] JBoss and UML? Hello, Looking the source code of the 4.0.0alpha version, I noticed the presence of Together diagrams in the jboss.net/testsuite directory. Wouldn't it be useful to add such development documentation (UML diagrams, not only classes diagrams) to other modules
[JBoss-dev] ATTENTION Peter Antman
Peter, The emails I send to you get bounced back. I'm emailing [EMAIL PROTECTED] What is your real email? Thanks, Bill --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] NEED YOUR HELP!
Hi all! JBoss has become a huge success and has reached the milestone of over 2 million downloads. Unfortunately though, because we're open-source and free, we rarely get any testamonials on JBoss success stories. Please help us spread the word! Enter your testamonial at the forum below. In-production testamonials are the most desired. http://www.jboss.org/forums/forum.jsp?forum=159 Thanks, Bill Burke Chief Architect JBoss Group, LLC --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] NEED JBOSS SUCCESS STORIES!
Hi all! JBoss has become a huge success and has reached the milestone of over 2 million downloads. Unfortunately though, because we're open-source and free, we rarely get any testamonials on JBoss success stories. Please help us spread the word! Enter your testamonial at the forum below. In-production testamonials are the most desired. http://www.jboss.org/forums/forum.jsp?forum=159 Thanks, Bill Burke Chief Architect JBoss Group, LLC --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] ATTENTION! Developers with CVS access
Hi all! Its time to gear up and embark on the journey that is JBoss 4.0. Our schedule is ambitious. We want to get a release done by JavaOne(the next JBossOne) in June 2003 so its gonna take a lot of hard work and focus from us over the next 6 months. That being said, I need some information from those developers/contributors that have CVS read/write access. 1. What have you worked on in the past? 2. What are you currently working on? 3. What will you be working on and when? 4. What do you want to work on? 5. What is your SourceForge name/id? (So I can cross you off list of who contacted me). The requirements/feature set for 4.0 is available here. http://www.jboss.org/developers/projects/jboss/projects.jsp Please comment and suggest bugs/features/requirements you want added to this list. I really need this information from you. You RISK LOSING YOUR CVS access if you don't respond! So please get back to me soon. Also, this information will also be used to help the Compensation Committee determine if you are eligible to receive incentive from the Compensation Program. http://www.jboss.org/news/compensation.jsp If you're wondering, my job as Chief Architect will be to make sure that everybody is focused on the vision of JBoss 4.0. This vision will be based on your collective vision as a group. I will also make sure that things are getting done and moving forward. If you say you will do something and end up not doing after a certain amount of time, I will recruit somebody else to do it. After I've collected this information from you, we(Marc, Scott, and I) will be deciding upon the lead developers for each of JBoss's subprojects. Lead Developers will have a list of responsibilites and perks that I will discuss at a later time. I will also be setting up Task lists for each sub-project on SourceForge so we can track how things are going. Thanks for your cooperation! Bill Burke Chief Architect JBoss Group, LLC --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] new direction for JBoss AOP
Code is under jboss-head/aop
It compiles but that's about it. Its incomplete.
The new direction is shown in the below xml if you can follow along. Don't
have much time for explanation before Thanksgiving, but the idea is POJOs
and DynamicProxies married into one framework. Field access, Constructors
and methods interceptable on POJOs. More funtionality can be inferred if
you read the following XML.
!-- Interceptor definition. This is just a template
name is the string reference to the interceptor
classname is its classname
scope defines how the interceptor is instantiated
instance - one interceptor instance per object instance
class - one instance per class
global - one instance for entire VM
config - defines any arbitrary xml to pass to component for
initialization
--
interceptor name=service1 classname= scope=instance,class,global
config/
/interceptor-service
!-- Extensions are classes that can be attached to an object to provide
extended APIs.
name is the string reference to the extention
classname is its classname
scope defines how the extension is instantiated
instance - one extension instance per object instance
class - one instance per class
global - one instance for entire VM
interfaces - are a list of interfaces to extend the aspected object.
Any methods invoked on the aspect that pertain to these
interfaces will be delegated directly to the extension class
config - defines any arbitrary xml to pass to component for
initialization
i.e.
Class MyClass {}
interface api { void doSometing(); }
Class MyExtension implements api { public void doSomething(){ ... } }
You could do in code
{
MyClass instance = new MyClass();
api a = (api)instance;
a.doSomething();
}
Even though MyClass doesn't implement the api interface, or has the
code for it
you can cast and invoke on it anyways. This is the extension.
--
extension nameextension1 classname= scope=instance,class,global
interfaces/
config/
/extension
!-- chain of interceptor definition --
stack name=stack1
interceptor-ref name=service1/
interceptor name=int1 classname=
config/
/interceptor
/stack
!-- interceptor pointcut defines what classes, methods,fields must be
intercepted
and by what --
interceptor-pointcut name= class=.*pattern*
method-pointcut expr=*set*/
!-- Don't intercept method defined in these interfaces --
method-pointcut
excluded-interfaces/
/method-pointcut
!-- Intercept methods defined in all these interfaces --
method-pointcut
included-interfaces/
/method-pointcut
field-pointcut expr=*variable*/
field-pointcut expr={PUBLIC,PRIVATE,PROTECTED}/
interceptors
stack-ref name=stack1/
interceptor-ref name=
config/
/interceptor-ref
interceptors/
/interceptor-pointcut
!-- Extension pointcut defines what classes should be extended --
extension-pointcut name= class=.*
extensions
extension-ref name=extension1/
extension/
/extensions
/extension-pointcut
!--
A proxy is a template for creating Dynamic Proxies.
--
proxy name=
interfaces/
interceptor-pointcuts/
extensions/
/proxy
!--
Add a pointcut to created proxy
--
interceptor-pointcut name= proxy=
method-pointcut
included-interfaces/
/method-pointcut
interceptors
stack-ref name=stack1/
interceptor-ref name=
config/
/interceptor-ref
interceptors/
/interceptor-pointcut
---
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] new PooledInvoker: speeds up invocations
Why does the proxy object have to setup the callback channel on deserialization? Just stuff the proxy in the invocation object as party of the payload. Invoker pulls this proxy shell out of the invocation and initializes it with the real callback channel.. -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Hiram ChirinoSent: Tuesday, November 19, 2002 4:03 AMTo: [EMAIL PROTECTED]Subject: RE: [JBoss-dev] new PooledInvoker: speeds up invocations I agree.. same socket bi-directionality is exotic and does not have to be in the public interface. Currently,it's not very nice how the proxy going back client gets setup. I won't go into detailsabout the current way I do it (it sucks). Here's the route I hope I can change too soon: 1) client sends a proxy object down an invocation to the server.. 2) server invoker sets either (a) an Invocationattribute or (b) and ThreadLocal to identify the socket the invocation came over. 3) When the proxy object is de-serialized, he looks up the object in (2) to setup the callback channel to go through the original socket. But for this to work in the(a) case the proxy object would need to be able to access the Invocation object during deserization. And for it to work in the (b) case the proxy object has to be deserialized while in the context of the thread the invocation came in. I don't think I'll be able to do this the way invocations are done right now. You think this is a bad route? Regards, Hiram -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bill BurkeSent: Sunday, November 17, 2002 11:16 PMTo: [EMAIL PROTECTED]Subject: RE: [JBoss-dev] new PooledInvoker: speeds up invocations I agree Scott (no public interface for bi-directionality). It will be tricky to implement the bi-directional behavior if Invokers don't have a bi-directional public interface. I wonder how you abstract this out now Hiram. One way to do this would be to use the trick I used with EJBs and multiple-invokers. 1. Have a proxy factory. 2. Pass this information with the client request. 3. Look up the proxy factory whenever you have to create proxies via the tag in the invocation. Bill -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Scott M StarkSent: Saturday, November 16, 2002 1:49 PMTo: [EMAIL PROTECTED]Subject: Re: [JBoss-dev] new PooledInvoker: speeds up invocations It should be possible to route invocations over the incoming channel, but it cannot be a requirement. This does not imply the invocation interfaces are bi-directional however. There simply needs to be the ability to compose the invokers such that there is a shared communications channel. Scott StarkChief Technology OfficerJBoss Group, LLC - Original Message - From: Victor Langelo To: [EMAIL PROTECTED] Sent: Friday, November 15, 2002 7:11 PM Subject: Re: [JBoss-dev] new PooledInvoker: speeds up invocations Hiram Chirino wrote: Hiram Chirino wrote: Anyways. JMS need bi-directional invocations (BADLY). Should this become a requirement for the other invokers??I completely disagree. There is no reason server to clientcommunication has to go over the back channel of a client to serverI might have said this before, but there is one reason it's a nice feature:This allows callback to clients that are sitting behind a firewall.Let me agree with Hiram. I would add it is essential to use the client connection if the client network is using NAT (network address translation). With the advent of new security measures, many of our clients are adding firewalls and NAT. The worst case is when the server has a public IP and the local LAN clients are on the otherside of a NAT router.--Victor
RE: [JBoss-dev] new PooledInvoker: speeds up invocations
The Pooled Invoker pools threads up to a maximum limit, after that new threads are still created but are allowed to die after they service a request. (I guess I should block, but I didn't want to have a hard limit.) In other words, this won't help you But...your problem seems related to JMS. Is it possible you are not closing client JMS connections? Or closing them properly? (8090 is the OIL JMS transport port). I suggest using the in-JVM transport if all JMS connections are local within JMS. Also, the RMI JMS transport will probably eliminate the problems you are seeing to, but first look to make sure you are closing your JMS connections. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dan A. Dickey Sent: Monday, November 18, 2002 2:15 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] new PooledInvoker: speeds up invocations On Thursday 14 November 2002 10:57 am, Bill Burke wrote: ... Code is in 3.2 and head under server/src/main/org/jboss/invocation/pooled. If you want to know how to use this, look at the testsuite under pooled/ test. Is there any chance that this PooledInvoker in 3.2 can fix my problem with the Invoker in 3.0.4? Currently, I'm at the point where the Invoker quits because a call to Thread.start() failed (hit max of 1024 threads). And, to make matters worse... there are 954 threads sitting around doing nothing at all other than keeping a socket open on port 8090. Looks like doing nothing because one side did not tell the other to close or something. I haven't gotten that far on this problem yet. But I'm still looking. I was sort of expecting that what a thread was done, it would sort of go away or something... that is not the situation currently. Has anyone fixed this problem in 3.0.4 yet? -Dan -- Dan A. Dickey [EMAIL PROTECTED] --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] new PooledInvoker: speeds up invocations
I use a LRU pool. Please see previous emails or examine code if you want more details. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Adam Heath Sent: Monday, November 18, 2002 5:16 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] new PooledInvoker: speeds up invocations On Mon, 18 Nov 2002, Bill Burke wrote: The Pooled Invoker pools threads up to a maximum limit, after that new threads are still created but are allowed to die after they service a request. (I guess I should block, but I didn't want to have a hard limit.) Minor nitpick, but when you reach this maximum value, shouldn't the old threads die off, and the new ones be recycled? --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] new PooledInvoker: speeds up invocations
I agree Scott (no public interface for bi-directionality). It will be tricky to implement the bi-directional behavior if Invokers don't have a bi-directional public interface. I wonder how you abstract this out now Hiram. One way to do this would be to use the trick I used with EJBs and multiple-invokers. 1. Have a proxy factory. 2. Pass this information with the client request. 3. Look up the proxy factory whenever you have to create proxies via the tag in the invocation. Bill -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Scott M StarkSent: Saturday, November 16, 2002 1:49 PMTo: [EMAIL PROTECTED]Subject: Re: [JBoss-dev] new PooledInvoker: speeds up invocations It should be possible to route invocations over the incoming channel, but it cannot be a requirement. This does not imply the invocation interfaces are bi-directional however. There simply needs to be the ability to compose the invokers such that there is a shared communications channel. Scott StarkChief Technology OfficerJBoss Group, LLC - Original Message - From: Victor Langelo To: [EMAIL PROTECTED] Sent: Friday, November 15, 2002 7:11 PM Subject: Re: [JBoss-dev] new PooledInvoker: speeds up invocations Hiram Chirino wrote: Hiram Chirino wrote: Anyways. JMS need bi-directional invocations (BADLY). Should this become a requirement for the other invokers??I completely disagree. There is no reason server to clientcommunication has to go over the back channel of a client to serverI might have said this before, but there is one reason it's a nice feature:This allows callback to clients that are sitting behind a firewall.Let me agree with Hiram. I would add it is essential to use the client connection if the client network is using NAT (network address translation). With the advent of new security measures, many of our clients are adding firewalls and NAT. The worst case is when the server has a public IP and the local LAN clients are on the otherside of a NAT router.--Victor
RE: [JBoss-dev] new PooledInvoker: speeds up invocations
-Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Hiram Chirino Sent: Thursday, November 14, 2002 8:20 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] new PooledInvoker: speeds up invocations scenario. The PooledInvoker is 300% faster than the default RMI Invoker. 2nd scenario: invokor is 30% faster than the default RMI based invoker. P.S. This code is extremely more simple than the Trunk Invoker and I've been told that the Trunk Invoker provides no performance boost. Plus the name sucks. Let's stir clear of 'cute names', PooledInvoker clearly describes what it is. Yes the 'trunk' name sucks.. Maybe you can help me give it a better name. here are the things it does: - bi-directional invocations. client can invoke the server, server can invoke the client. Ahh...Ok then that's the reason for most of the complexity. - Thread pooling (same as the PooledInvoker). When I looked at code it looked like there still was a thread being spawned for each invocation. Sure, when you hand off the message, there is a pool there, but there seemed to be a thread spawn before this. This needs to be avoided. - Connection sharing. Multiple invocations can be sent to the server at the same time. Sending an invocation down the socket does not stop other invocation from going down the pipe. Is this possible? Doesn't the socket get synchronized (and thus serialized invocations) when a lot of threads hit it? - Uses NIO if running under java 1.4, normal blocking IO if on 1.3 My performance testing did not show it was better than RMI. Perhaps I was running a bad test, perhaps I need to add connection pooling so that more than one socket is established from the client to the server. Perhaps all this functionality is just adding too much overhead. I'll add the benchmark to the pooled test in the testsuite. It already benchmarks RMI vs. Pooled. Anyways. JMS need bi-directional invocations (BADLY). Should this become a requirement for the other invokers?? Could a InvocationResponse object be used instead? Or, if you had detyped invocations, couldn't you just pass a callback object along with the request via a client-side interceptor? Just curious...why do you need bi-directional invocations? Acknowledgements? Callbacks? Is David using the bi-directional capability for Distributed Trans callbacks? The whole point of the Invoker architecture is to detach the transport layer from the actual service. Bill --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] new PooledInvoker: speeds up invocations
-Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Hiram Chirino Sent: Friday, November 15, 2002 8:36 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] new PooledInvoker: speeds up invocations - Thread pooling (same as the PooledInvoker). When I looked at code it looked like there still was a thread being spawned for each invocation. Sure, when you hand off the message, there is a pool there, but there seemed to be a thread spawn before this. This needs to be avoided. Perhaps.. I've not double checked the pool code. The first time an invocation comes though shure, but the second time, the pooled thread should get reused. Please make sure. It didn't read that way when I looked at it last. - Connection sharing. Multiple invocations can be sent to the server at the same time. Sending an invocation down the socket does not stop other invocation from going down the pipe. Is this possible? Doesn't the socket get synchronized (and thus serialized invocations) when a lot of threads hit it? Yep.. But this is good, if servicing requests has a delay in it.. You can sqeeze more requests into one socket. I need to make the connections pooled also so that a single socket does not get over-used. Yeah, maybe good for your design, but not good for performance. BTW, with the PooledInvoker vs. RMI tests, I'm pretty sure that RMI caches the connection. If I re-use the the same RMI proxy then Pooled is only 30% faster. Also, BTW, I borrowed your marshalling code at first and it was significantly slower than straight ObjectStreams. (Don't remember percentages.) - Uses NIO if running under java 1.4, normal blocking IO if on 1.3 My performance testing did not show it was better than RMI. Perhaps I was running a bad test, perhaps I need to add connection pooling so that more than one socket is established from the client to the server. Perhaps all this functionality is just adding too much overhead. I'll add the benchmark to the pooled test in the testsuite. It already benchmarks RMI vs. Pooled. thanks. Anyways. JMS need bi-directional invocations (BADLY). Should this become a requirement for the other invokers?? Could a InvocationResponse object be used instead? Or, if you had detyped invocations, couldn't you just pass a callback object along with the request via a client-side interceptor? Just curious...why do you need bi-directional invocations? Acknowledgements? Callbacks? Is David using the bi-directional capability for Distributed Trans callbacks? The whole point of the Invoker architecture is to detach the transport layer from the actual service. The JMS server uses callbacks. Thats how it drives asynchronous message delivery. A normal RMI callback object cannot allways be used since the client may be behind a firewall. I want to be able to communicate with the client over the same socket that he established with the server. Make sense?? Are the callbacks both for subscribers and Acks? Or are acks delivered as a response. Regards, Hiram Bill --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Metadata Service
Wow Peter! This is exactly what I was thinking of. Any JMX guys have any ideas how we could integrate this? Bill -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Peter Antman Sent: Thursday, November 14, 2002 4:12 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Metadata Service Hi, have any one of you looked at XmlBlaster? (www.xmlBlaster.org). I guess it could really work as a central XmlRepository. XmlBlaster is an XML based MOM. You publish your XML to it and it will save it in an Xml DOM tree, even persist it a RDMB or Xincice. You can then subscribe to event with an XPath expression (or do a synchronous get (with an XPath). Ok. You can not just subsribe to one element, thats true, but you can subscribe on a domain or config, say MyMessageDrivenBean and get any update notifications for that XML config. Or you could do a get(//x/y/port) (pseudocode!) and get all configs wich contains that element. There are a lot more to XmlBlaster (I have done the JBoss integration thats currently is available in XmlBlaster ;.)) Well, just a thought. //Peter On 13 Nov, Bill Burke wrote: 1. I'm not talking about a central config file...Components register their XML with this service. MBean, EJB, whatever... 2. You know what XPATHs are right? If not, look them up. They are really cool. Xerces/Xalan (forget which) support looking up Elements via XPATHS. What's not supported, which we would have to write, would be the ability to register for change notifications via an XPATH. Other ideas: - A redeployed bean, updates the Centralized (in-memory) Xerces XML Doc. Services/components registered as listening for changes, recieve notification. - JMX console needs an additional XML editor for MBean attributes that are XML elements. - This sort of centralized service allows you to query, via XPATHS, for all components that have a port attribute for instance. Allows you to do global things on configuration when you don't know the actual components that have that type of attribute Another thing about configuration I wanted to have is the concept of Configuration Domains. A component would get configuration by searching a set of chained configuration domains. invocation domain-instance domain-component domain-app server domain-cluster domain etc... So, when a component needs config information, it looks it up via the chain. Any domain in the chain can override a config value. As the chain is traversed, if the config info is not there, it searches farther up the chain. This would allow us to have a layered way of obtaining default config information, or overriding existing configuration at different levels at different times. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Matt Munz Sent: Wednesday, November 13, 2002 1:26 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Metadata Service Dain, Meta data for an invocation. I assume you refer here to EJB/servlet invocations. Just out of curiosity, how is that metadata currently stored? - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Dain Sundstrom Sent: Wednesday, November 13, 2002 1:13 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Metadata Service Meta data for an invocation. What are the tx attributes? What is the security manager? What are the required roles? What is the readahead configuration? That kind of data. -dain Matt Munz wrote: Dain/Bill/Scott, Could you clarify this? Metadata for what data? Are you referring to MBeanInfo, or something else? - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Dain Sundstrom Sent: Wednesday, November 13, 2002 12:52 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Metadata Service Bill Burke wrote: Dain and I were IMing. He said Scott was thinking about a MetaData service... My idea for a MetaData/Configuration service would be the ability to register for callbacks based on XPATHS. So, all config of jboss would be stored in one big XML Document. Components insert their config there, and register for callbacks on this config via XPATHS. So, this config can be managed centrally, yet, components can easily be notified with changes via a simple mechanism. I didn't know you could do that. What spec/library is this in? I want to read it. Scott and I were really only talking about use. We need something like this for component, application, and domain data, but we didn't get into the actually implementation. We just
RE: [JBoss-dev] Metadata Service
Jason, we're not talking about one file on disk. We're talking about in memory...(well that's at least what I'm talking about). Bill -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Dain Sundstrom Sent: Wednesday, November 13, 2002 5:49 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Metadata Service One huge file is better than a million little files scattered across my hard drive, but that's not saying a lot. -dain Jason Dillon wrote: I would be careful about going with a huge file, these tend to become unnamable fast. --jason On Wednesday, November 13, 2002, at 09:07 AM, Bill Burke wrote: Dain and I were IMing. He said Scott was thinking about a MetaData service... My idea for a MetaData/Configuration service would be the ability to register for callbacks based on XPATHS. So, all config of jboss would be stored in one big XML Document. Components insert their config there, and register for callbacks on this config via XPATHS. So, this config can be managed centrally, yet, components can easily be notified with changes via a simple mechanism. Bill --- This sf.net email is sponsored by: Are you worried about your web server security? Click here for a FREE Thawte Apache SSL Guide and answer your Apache SSL security needs: http://www.gothawte.com/rd523.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Are you worried about your web server security? Click here for a FREE Thawte Apache SSL Guide and answer your Apache SSL security needs: http://www.gothawte.com/rd523.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC --- This sf.net email is sponsored by: Are you worried about your web server security? Click here for a FREE Thawte Apache SSL Guide and answer your Apache SSL security needs: http://www.gothawte.com/rd523.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] chill on MetadataRepository
Dain, Chill on the metadata repository. This is a significant change to JBoss and you have not thought through all the issues. (Notification, persistence, JMX integation, etc...) David is right, we really need to flush out the usecases for this and how it will help the system and effect it. Your use case of the read-ahead cache could be implemented with attaching interfaces to the CMP proxy with the Aspect framework. Don't you have more important work to do anyways? Like the new cache stuff for CMP 2.0, or CMP 2.0 rewrite? Focus dude. Focus. Besides... Also, I think we should investigate XmlBlaster (peter antman suggested) which does exactly the magic I was talking about with XPATHs. Others have suggested Jelly, JXpath...These also could help tremedously. Here's some of the requirements I think the repository should have if we go forward with it - layered config (you already have this idea with parents and such) so that config info can be layerd across cluster, app server, component, invocation as I discussed before. - Notifications on config changes. THis is really really important. We want to be able to change config clusterwide and have it trickle down to interested components. - JMX needs to be brought into this too. We need to figure out how JMX fits in so there is no redundancy. - XML is the perfect format and API for the repository IMHO. I see components wanting to iterate over a namespace (Element). XML also provides us with the search capabilities and such. FYI, I've written centralized configuration repositories in the past at Iona for Orbix2000, so I've seen this shit in action. Bill --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] MetaDataRepository Proposal
-Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Dain Sundstrom Sent: Thursday, November 14, 2002 12:55 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] MetaDataRepository Proposal Hiram Chirino wrote: David, Actually it simplifies the code. If you take a look at our interceptor stack most have a ton of code just to load and maintain the metadata, Yes there is alot of Metadata now. 1/2 the ton of code that we have there is just taking XML and creating a metadata objects. I think that something like Jelly (http://jakarta.apache.org/commons/sandbox/jelly/) should be able eliminate that code. A tool that will take XML config and generate the Metadata objects that our interceptors can use directly. Sure. It is just a detail. I want to put in an interface between the interceptor and the metadata repository. and the worst part is we have no control over it at runtime. It is way simpler. You'll see. I agree there. But wouldn't it be simpler if we just exposed an API to the client that would allow him to modify the metadata (thus turning something that is static now, into something dynamic)? For example. Say you have a CMP bean x, and the configuration API is exposed via an aspect, then on the client side you would do: CMPConfiguration c = (CMPConfiguration)x; c.setReadAhead( 500 ); And the would in turn create a Invocation with method=setReadAhead that the CMP interceptor would handle by updating the metadata configuration for the bean. Does this make sense? Are you trying to achieve something similar but in a more automated way? This could easily happen but is not my motivation. I really just want simplify the containers and interceptors. Anyway, where would this data live? How would it get into the invocation? My guess is that the same repository code could be used on the client side for client specific configuration, but maybe it won't work for that. In all honesty Dain, I don't think this is a simplification. And Hiram's right. Attaching interfaces with the aspect framework should give you the functionality you want here of adding read-ahead apis. How would it get into the invocation? EasilyIts just another invocation on the invocation stack. A client interceptor intercepts the setReadAhead method, and stuff 500 into some variable. With regular calls, that same interceptor attaches the read-ahead value into the invocation object. CMP picks up the value from the invocation if it is there. -dain --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] new PooledInvoker: speeds up invocations
Ok, when I was doing ECPerf tests, I was trying anything to squeak out better performance. Here's where the PooledInvoker came in. The idea is to pool connections at the remote client as well as pool threads/connections on the server side. So, when a remote client first connects, the server will create a dedicated thread/connection for that client. The client will pool the connection locally for re-use by ANY proxy on the client. If the client goes away, or the connection times out, the server will throw away and close the socket, but pool the thread for later use. Also, the server's pool is LRU so that it can manage the size of the pool. Please check out the code for more info. Code is in 3.2 and head under server/src/main/org/jboss/invocation/pooled. If you want to know how to use this, look at the testsuite under pooled/ test. Now the numbers: The testsuite spawns 300 threads under 2 scenarios: 1st scenario: Each thread loops 10 times with the following: SLSB slsb = home.create(); slsb.noop(); So a new proxy is obtained for each invocation. In this scenario. The PooledInvoker is 300% faster than the default RMI Invoker. 2nd scenario: home.create() is called before launching the benchmark and the SLSB proxy is passed to each thread. Each thread loops 10 times calling the noop(). In this scenario the pooled invokor is 30% faster than the default RMI based invoker. Dain has a customer that is potentially using this new invoker I wrote and he has suggested that it because the default invoker for 3.2 and higher. Let me know if you think this is a possibility. Thanks, Bill P.S. This code is extremely more simple than the Trunk Invoker and I've been told that the Trunk Invoker provides no performance boost. --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] MetaDataRepository Proposal
-Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Dain Sundstrom Sent: Thursday, November 14, 2002 1:04 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] MetaDataRepository Proposal Matt Munz wrote: and the worst part is we have no control over it at runtime. It is way simpler. You'll see. It sounds like you have a vision. Please continue to make the effort to get the rest of us into the loop. I want to see also, but I'd prefer to do so sooner rather than later (not after it's done and finished). We can just throw away any code I add later. It won't take very long.. What I am suggesting is a fairly small change. You guys are just getting way to excited about repository implementation details. I just I'm not focusing on implementation details, just throwing in ideas... Requirements: - Layered config. i.e. Cluster-wide vs. App-Server vs. Component - Notifications - search capability. - integration with JMX (or leveraging/extending it.) Whatever is decided. need a place to get information. I really don't care where it comes from. Until you guys decide on how to load the repository and keep it in sync with a physical store, I'll just write a very simple one that uses our current metadata code. I made the interface super simple so it can be replace later. Also the total size of the code will be a 3-4 small classes, so we can just toss the entire idea if needed later. The easiest case for me the read ahead configuration in entity beans. There is no reason for this to be static. In fact it should be manageable at runtime, and if I'm luck I'll be able to pull it off for 4.0. Scott tells me there is a similar need to manage security at Great, now we're getting somewhere. Can you pick one of these (perhaps the read ahead), and provide some details? What does the server admin have to do that is particularly time consuming? It may be obvious to you, but I'd love to hear the details on this one. I'm saying that it is currently not possible to changes this type of information, and if we could the metadata is scattered across the interceptor and plugins. There is no regular usage, storage, or management of the current data. I am only proposing a clean separation between the data and the users (Interceptors) and nothing more. runtime. There really is no need to shut down an application in production just to change some configuration data. This is *exactly* what MBean Persistence is supposed to do, IMO. Feel free to reread that last sentence for added emphasis. Why not channel this energy into making MBean Persistence even better? Shouldn't any and all server configuration be done through JMX anyway? Isn't that the point of JMX in the first place? I only want a clean separation. I really don't care what the backing store is or how we actually managing it. I fully expect my lame repository to be tossed and replaced with several implementations (until we figure out the best way). Even if there is no real need the code is simpler. Simple is the key word. I'm new and all, so feel free to ignore me, but this whole thing just sets off my KISS alarm system -- it actually sounds rather complicated. Go take a look at the TxInterceptors, SecurityInterceptors and the Containers. 90% of the code is getting data out of the metadata objects and caching it in an internal hashtable. I am just proposing we centralize that code into a single interceptor with a repository for caching. Simpler. -dain --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Metadata Service
1. I'm not talking about a central config file...Components register their XML with this service. MBean, EJB, whatever... 2. You know what XPATHs are right? If not, look them up. They are really cool. Xerces/Xalan (forget which) support looking up Elements via XPATHS. What's not supported, which we would have to write, would be the ability to register for change notifications via an XPATH. Other ideas: - A redeployed bean, updates the Centralized (in-memory) Xerces XML Doc. Services/components registered as listening for changes, recieve notification. - JMX console needs an additional XML editor for MBean attributes that are XML elements. - This sort of centralized service allows you to query, via XPATHS, for all components that have a port attribute for instance. Allows you to do global things on configuration when you don't know the actual components that have that type of attribute Another thing about configuration I wanted to have is the concept of Configuration Domains. A component would get configuration by searching a set of chained configuration domains. invocation domain-instance domain-component domain-app server domain-cluster domain etc... So, when a component needs config information, it looks it up via the chain. Any domain in the chain can override a config value. As the chain is traversed, if the config info is not there, it searches farther up the chain. This would allow us to have a layered way of obtaining default config information, or overriding existing configuration at different levels at different times. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Matt Munz Sent: Wednesday, November 13, 2002 1:26 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Metadata Service Dain, Meta data for an invocation. I assume you refer here to EJB/servlet invocations. Just out of curiosity, how is that metadata currently stored? - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Dain Sundstrom Sent: Wednesday, November 13, 2002 1:13 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Metadata Service Meta data for an invocation. What are the tx attributes? What is the security manager? What are the required roles? What is the readahead configuration? That kind of data. -dain Matt Munz wrote: Dain/Bill/Scott, Could you clarify this? Metadata for what data? Are you referring to MBeanInfo, or something else? - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Dain Sundstrom Sent: Wednesday, November 13, 2002 12:52 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Metadata Service Bill Burke wrote: Dain and I were IMing. He said Scott was thinking about a MetaData service... My idea for a MetaData/Configuration service would be the ability to register for callbacks based on XPATHS. So, all config of jboss would be stored in one big XML Document. Components insert their config there, and register for callbacks on this config via XPATHS. So, this config can be managed centrally, yet, components can easily be notified with changes via a simple mechanism. I didn't know you could do that. What spec/library is this in? I want to read it. Scott and I were really only talking about use. We need something like this for component, application, and domain data, but we didn't get into the actually implementation. We just decided to have an metadata loader interceptor and a metadata loader interface for the interceptor to call. The goal is to create a place to put a good metadata service, but those details are for another day (one step at a time). -dain --- This sf.net email is sponsored by: Are you worried about your web server security? Click here for a FREE Thawte Apache SSL Guide and answer your Apache SSL security needs: http://www.gothawte.com/rd523.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Are you worried about your web server security? Click here for a FREE Thawte Apache SSL Guide and answer your Apache SSL security needs: http://www.gothawte.com/rd523.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC --- This sf.net email is sponsored
RE: [JBoss-dev] Metadata Service
BTW -- I aggree that XPath is cool. What makes a central XML file work better as a metadata database than a well-crafted object graph or relational database, in your opinion? My thinking is that a well-crafted object graph or relational db needs to be crafted and the code maintained. Most components in JBoss are configured via XML files. Why not store this XML in memory with Xerces? XML Objects provide us with a common, simple, easy way to store config data in memory and reference it(XPath). Is there something specific to this metadata problem that makes a central XML file a more attractive solution? I saying Document as in the Java Object. Not in a XML file stored on disk. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Bill Burke Sent: Wednesday, November 13, 2002 2:02 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Metadata Service 1. I'm not talking about a central config file...Components register their XML with this service. MBean, EJB, whatever... 2. You know what XPATHs are right? If not, look them up. They are really cool. Xerces/Xalan (forget which) support looking up Elements via XPATHS. What's not supported, which we would have to write, would be the ability to register for change notifications via an XPATH. Other ideas: - A redeployed bean, updates the Centralized (in-memory) Xerces XML Doc. Services/components registered as listening for changes, recieve notification. - JMX console needs an additional XML editor for MBean attributes that are XML elements. - This sort of centralized service allows you to query, via XPATHS, for all components that have a port attribute for instance. Allows you to do global things on configuration when you don't know the actual components that have that type of attribute Another thing about configuration I wanted to have is the concept of Configuration Domains. A component would get configuration by searching a set of chained configuration domains. invocation domain-instance domain-component domain-app server domain-cluster domain etc... So, when a component needs config information, it looks it up via the chain. Any domain in the chain can override a config value. As the chain is traversed, if the config info is not there, it searches farther up the chain. This would allow us to have a layered way of obtaining default config information, or overriding existing configuration at different levels at different times. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Matt Munz Sent: Wednesday, November 13, 2002 1:26 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Metadata Service Dain, Meta data for an invocation. I assume you refer here to EJB/servlet invocations. Just out of curiosity, how is that metadata currently stored? - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Dain Sundstrom Sent: Wednesday, November 13, 2002 1:13 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Metadata Service Meta data for an invocation. What are the tx attributes? What is the security manager? What are the required roles? What is the readahead configuration? That kind of data. -dain Matt Munz wrote: Dain/Bill/Scott, Could you clarify this? Metadata for what data? Are you referring to MBeanInfo, or something else? - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Dain Sundstrom Sent: Wednesday, November 13, 2002 12:52 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Metadata Service Bill Burke wrote: Dain and I were IMing. He said Scott was thinking about a MetaData service... My idea for a MetaData/Configuration service would be the ability to register for callbacks based on XPATHS. So, all config of jboss would be stored in one big XML Document. Components insert their config there, and register for callbacks on this config via XPATHS. So, this config can be managed centrally, yet, components can easily be notified with changes via a simple mechanism. I didn't know you could do that. What spec/library is this in? I want to read it. Scott and I were really only talking about use. We need something like this for component, application, and domain data, but we didn't get into the actually implementation. We just decided to have an metadata loader interceptor and a metadata loader interface for the interceptor to call. The goal is to create a place to put a good metadata service, but those details are for another day (one step at a time). -dain
RE: [JBoss-dev] Metadata Service
To me, JMX is all about metadata -- in a sense, it is the metadata that makes detyped invocation work. When you talk about adding metadata to an invocation, and storing that metadata somewhere, it sounds just like MBean persistence. At a minimum, you should be able to reuse some ideas, if not code, from the management module... IMHO, JMX is limiting. MBeans are declarations of object instances. standardjboss.xml, standardcmp-jdbc.xml, the new aspect configs, etc... are templates/defaultconfigs for object creations/instantiations. A major difference. Sometimes config is just config and there's really no object you can attach it to. Bill - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Dain Sundstrom Sent: Wednesday, November 13, 2002 2:34 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Metadata Service Matt Munz wrote: Dain, Please excuse my ignorance. I'm a bit JMX-centric at the moment. I see an org.jboss.mx.server.Invocation that doesn't seem to know about / relate to org.jboss.invocation.Invocation. Obviously the names are the same. Is there any deeper relationship? Got me. I am a bit to EJB centric at the moment. I would guess that plan it to merge them, but I don't know. When I hear metadata JBoss in the same sentence, I think of JMX MBeanInfo. Since I recently wrote some code to facilitate MBeanInfo persistence, I'm interested in any changes to the way MBeanInfo is stored in the server. Is this related at all? Cool. I'm interested in the MBean persistence stuff. I have no plans on writing the final metadata repository, I just want to use one, so I will quickly write something with a very simple interface that can be replaced later. I feel that all this stuff is related, we just need to figure out how it all fits together. -dain --- This sf.net email is sponsored by: Are you worried about your web server security? Click here for a FREE Thawte Apache SSL Guide and answer your Apache SSL security needs: http://www.gothawte.com/rd523.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Are you worried about your web server security? Click here for a FREE Thawte Apache SSL Guide and answer your Apache SSL security needs: http://www.gothawte.com/rd523.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Are you worried about your web server security? Click here for a FREE Thawte Apache SSL Guide and answer your Apache SSL security needs: http://www.gothawte.com/rd523.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Metadata Service
search/query is exactly the benefit I see from a centralized XML-based config repository. I see your point though. -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Scott M Stark Sent: Wednesday, November 13, 2002 3:17 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Metadata Service This has merit, but mbeans today do not know about XML in general, they know about attributes. Changes made to the XML config need to propagate as attribute setter invocations. Editing mbean attributes via JMX would have to update the repository. I'm not sure using XML as the manifest memory storage mechanism is a good programming API. Maybe that is just the search/query index representation. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Bill Burke [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 13, 2002 11:01 AM Subject: RE: [JBoss-dev] Metadata Service 1. I'm not talking about a central config file...Components register their XML with this service. MBean, EJB, whatever... 2. You know what XPATHs are right? If not, look them up. They are really cool. Xerces/Xalan (forget which) support looking up Elements via XPATHS. What's not supported, which we would have to write, would be the ability to register for change notifications via an XPATH. Other ideas: - A redeployed bean, updates the Centralized (in-memory) Xerces XML Doc. Services/components registered as listening for changes, recieve notification. - JMX console needs an additional XML editor for MBean attributes that are XML elements. - This sort of centralized service allows you to query, via XPATHS, for all components that have a port attribute for instance. Allows you to do global things on configuration when you don't know the actual components that have that type of attribute Another thing about configuration I wanted to have is the concept of Configuration Domains. A component would get configuration by searching a set of chained configuration domains. invocation domain-instance domain-component domain-app server domain-cluster domain etc... So, when a component needs config information, it looks it up via the chain. Any domain in the chain can override a config value. As the chain is traversed, if the config info is not there, it searches farther up the chain. This would allow us to have a layered way of obtaining default config information, or overriding existing configuration at different levels at different times. Bill --- This sf.net email is sponsored by: Are you worried about your web server security? Click here for a FREE Thawte Apache SSL Guide and answer your Apache SSL security needs: http://www.gothawte.com/rd523.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Are you worried about your web server security? Click here for a FREE Thawte Apache SSL Guide and answer your Apache SSL security needs: http://www.gothawte.com/rd523.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Metadata Service
-Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Matt Munz Sent: Wednesday, November 13, 2002 3:30 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Metadata Service Bill, My thinking is that a well-crafted object graph or relational db needs to be crafted and the code maintained. Most components in JBoss are configured Well, so do DTDs and XML schemas. It is an interesting argument I don't like DTDs and XML schemas for the very reason that they force you to update the DTD every time a new type of configuration comes along. The Components themselves should do the validation of their particular part of the large XML file/document. Consider an ISV who wants to add their new component to JBoss with new complex configuration. They have to modify our DTD? No, they shouldn't have to and we shouldn't allow them. (Don't know much about XML Schemasmaybe they address these issues?) that an XML Document object is a more flexible construct than a given arrangement of Data Objects (Hashtables, lists), and POJOs. I suppose the primary point is that an XPath query is more easily maintained than a given set of method calls. It certainly avoids the compiler, but so does the JMX bus, which does not use an XML document object as its metadata database... via XML files. Why not store this XML in memory with Xerces? XML Objects provide us with a common, simple, easy way to store config data in memory and reference it(XPath). Sure. But don't the XML Objects eventually get converted into Objects? Why not keep those Objects in memory? What I was trying to suggest is that complex xml config data is modified via a file or through some Management Console at runtime. Components can register via XPATHS to listen to this changed data. They are notified and update their local config, construct new objects, whatever... Hmmm...I'm starting to see what you're saying. MBeans already have notifications and ways to query, right? For the objects that end up as MBeans, perhaps an enhanced search mechanism for the MBean Registry would be another way to address the problem? XPATHs would be a perfect fit for something like this. Why recreate? Another thing that MBeans don't seem to address is the notion of layered configuration or in other words configuration domains. Each layer can inherit/modify the configuration from a top level layer. Cluster wide config. Per APp server config tailored to each machine. Overrides at the component and invocation level. Let's take a use-case. Let's say I want to change config cluster-wide for one particular attribute. Let's say DB connection pool max size. What you have to do now is go to each and every machine to do this. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Bill Burke Sent: Wednesday, November 13, 2002 2:58 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Metadata Service BTW -- I aggree that XPath is cool. What makes a central XML file work better as a metadata database than a well-crafted object graph or relational database, in your opinion? My thinking is that a well-crafted object graph or relational db needs to be crafted and the code maintained. Most components in JBoss are configured via XML files. Why not store this XML in memory with Xerces? XML Objects provide us with a common, simple, easy way to store config data in memory and reference it(XPath). Is there something specific to this metadata problem that makes a central XML file a more attractive solution? I saying Document as in the Java Object. Not in a XML file stored on disk. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Bill Burke Sent: Wednesday, November 13, 2002 2:02 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Metadata Service 1. I'm not talking about a central config file...Components register their XML with this service. MBean, EJB, whatever... 2. You know what XPATHs are right? If not, look them up. They are really cool. Xerces/Xalan (forget which) support looking up Elements via XPATHS. What's not supported, which we would have to write, would be the ability to register for change notifications via an XPATH. Other ideas: - A redeployed bean, updates the Centralized (in-memory) Xerces XML Doc. Services/components registered as listening for changes, recieve notification. - JMX console needs an additional XML editor for MBean attributes that are XML elements. - This sort of centralized service allows you to query, via XPATHS, for all components that have a port attribute for instance. Allows you to do global things on configuration when you don't know the actual components that have that type
[JBoss-dev] 3.2 branch doesn't seem to compile
[javac] Compiling 61 source files to C:\jboss\jboss-3.2\connector\output\classes C:\jboss\jboss-3.2\connector\src\main\org\jboss\resource\adapter\jdbc\local\ LocalPreparedStatement.java:190: illegal cha racter: \64 @JDK1.4START@ ^ C:\jboss\jboss-3.2\connector\src\main\org\jboss\resource\adapter\jdbc\local\ LocalPreparedStatement.java:190: illegal cha racter: \64 @JDK1.4START@ ^ C:\jboss\jboss-3.2\connector\src\main\org\jboss\resource\adapter\jdbc\local\ LocalPreparedStatement.java:199: illegal cha racter: \64 @JDK1.4END@ ^ --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Customizing JBoss server configurations
Yes that is a great idea. What kind of script? sh, perl, python, java, ?? I've done the same for the CD subscription but using InstallAnywhere. -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Igor Fedorenko Sent: Wednesday, November 06, 2002 5:07 PM To: jboss-development Subject: [JBoss-dev] Customizing JBoss server configurations Hi, I've created an ant script that allows easy creation of custom jboss server configurations (other then all, default and minimal). Basically, it defines a bunch of targets like jbossmq, transaction-manager and alike from which you can assemble your own unique server. I am using this script to reduce amount of resource used by jboss by removing services that are not used to my app but I can see other usages as well. Of course, this script is far from being complete but if it sounds like a good idea I can put it somewhere so people can start using/improving it. Thoughts? -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Upcoming releases
Personally I'd stay with 3.0.x series. New functionality will not be added to it while it will with 3.2. -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of James Higginbotham Sent: Wednesday, November 06, 2002 9:47 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Upcoming releases Scott, Can you or someone on the team tell me which version I should upgrade our product to - 3.0.x or 3.2? I'm about to move from 3.0.0 and want to make sure I'm on the right branch to make migration to 4.0 easier in the future while remaining stable for our product release that will occur by the EOY. Thanks, James -Original Message- From: Scott M Stark [mailto:scottmstark;attbi.com] Sent: Wednesday, November 06, 2002 8:17 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Upcoming releases Go ahead. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jules Gosnell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 06, 2002 1:09 PM Subject: Re: [JBoss-dev] Upcoming releases What has happened to the 3.2beta release ? I have some stuff to put in - am I to late ? Jules Scott M Stark wrote: I'm planning on the following releases so time your work accordingly: 2002-10-25jboss-2.4.10 2002-10-27jboss-3.0.4 2002-11-03jboss-3.0.2beta2 2002-12-22jboss-4.0alpha Scott Stark Chief Technology Officer JBoss Group, LLC --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss Clustering problem
Only communication exceptions will cause a failover. If the client proxies know that the request was delivered, the clustering code will never failover. This is to avoid duplicate invocations and also the client proxies really have no way of knowing what you want to do with a request. -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Vishal Shukla Sent: Thursday, November 07, 2002 1:14 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] JBoss Clustering problem Hello, I am facing problem in JBoss Clustering.I am having Two nodes in cluster.When One node is down.Client Automatically send request to other node.But if any node is getting the exception like.. Could not create entity:org.jboss.util.NestedSQLException: No ManagedConnections Available!; - nested throwable: (javax.resource.ResourceException: No ManagedConnections Available!) at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(Str eamRemoteCall.java:240) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:215) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:117) at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Unknown Source) at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPI nvokerProxy.java:128) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor. java:108) at org.jboss.proxy.TransactionInterceptor.invoke(TransactionIntercept or.java:73) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:76) at org.jboss.proxy.ejb.HomeInterceptor.invoke(HomeInterceptor.java:185) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:76) at $Proxy6.create(Unknown Source) at net4nuts.usermanagement.UserManagementServlet.processUserData(User ManagementServlet.java:330) at net4nuts.usermanagement.UserManagementServlet.authenticate(UserMan agementServlet.java:175) at net4nuts.usermanagement.UserManagementServlet.doPost(UserManagemen tServlet.java:95) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:405) at org.apache.tomcat.core.Handler.service(Handler.java:287) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.internalService(ContextManag er.java:806) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:752) at org.apache.tomcat.service.connector.Ajp12ConnectionHandler.process Connection(Ajp12ConnectionHandler.java:166) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:501) at java.lang.Thread.run(Thread.java:479) Second request again goes to same nodeI mean the node which is getting exception.So please elaborate on this ASAP thanks vishal --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] taming the beast
In short, whatever works for you. Personally, I don't use IDEs. Hate them. Everytime I start to use them, I just go back to Emacs, find, and grep. I use printlns to debug, or in more complex situations, write some monitor object. But that works best for me. The best advice is to just start doing things. We are starting to put structure around those who contribute. Contribute and you will get attention. -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Ben Tompkins Sent: Saturday, November 02, 2002 1:17 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] taming the beast First, I'd like to apologize to anyone I may have offended or irritated in recent days. I am not a whiner by nature and realize that this is a ***technical*** list. Nor do I intend to organize a build system revolution among JBoss contributors, or pollute this list with my personal issues, or disturb the JBoss universe in a major way. I also don't expect to be spoon fed - I have worked on large systems before and am fairly good at locating the ***source*** of a bug and ***fixing it*** (I prefer to leave ***finding*** the bug itself to the testers however.) Now that I have gotten past the build stage, I would lke to begin to be productive by fixing some bugs, but I have no idea what tools (preferably free tools for Linux (Red Hat 8.0)) work for JBoss development and debugging. If there are no useful tools and current contributors are using jdb in a console, or, at the other extreme, avoiding unix altogether and running a shrink-wrapped IDE under Windows XP over a Samba connection (for unix compatibility verification and testing) I would like to know that so I don't waste time trying to implement a utopian solution. On the other hand, if there exist useful applications for any of the following purposes that developers are actually using on this project, or a related purpose I have neglected to consider, I would like to know that too -- especially if there is a particularly useful combination of tools that is widely adhered to by members of the JBoss community: IDEs Advanced Source code analysis, visualization, code databases Primitive Source code tagging (e.g., like ctags but for Java) Build Management tools / techniques (I came up with a simple algorithm for cycling updates through my local cvs - i.e. synchronizing local and remote cvs - but suspect now that even that may be utopian or just unnecessary). Tools targeted at multithreaded server applications - in particular tools that are good at dealing with threads. Tools designed especially for testing parallel distributed apps. Anything else I've left out. I am eager to make a contribution and welcome any advice you may have to expedite this process. Secondly I need to know ***which builds are of highest priority. *** I have seen some very ancient bug reports on source forge. It is not obvious to me just by looking at a bug what is real and what isn't. Feel free to request a particular fix - I can't promise I'll pick that one though. Also, please do not just tell me to go read the documentation - I have looked at JMX and read the 3.0 book already. I have also perused this site fairly thoroughly I think. I'd be surprised to discover that I have overlooked some obvious source unless it has been added in the past week. At the same time, I must confess (as if it is not obvious enough already) that I am fairly new to open source - my professional experience lies primarily with offline mainframes and PCs in a development environment managed by somebody else. Feel free to contact me personally at the e-mail accompanying this posting. TIA, Ben Tompkins On Friday 01 November 2002 09:36 pm, Ben Tompkins wrote: Ok - great - but the physics bit (the first, shorter faq that goes on about cantorian fractal spacetime is mostly plagiarized from a real paper I found on the net. Do you want we me to cut it, seek permission, or what. I realize that I have created a silly issue - but you never know... On Friday 01 November 2002 05:05 pm, Jason Dillon wrote: This is funny, funny shit. Submit a real patch (ala sf.net w/attached file) and I will commit this. --jason --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
RE: [JBoss-dev] Where Have All The Great Development Discussions Gone?
We will be expanding the forums shortlyDiscussion will be organized there. Aspect Oriented Programming is already there. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Scott M Stark Sent: Friday, November 01, 2002 12:28 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Where Have All The Great Development Discussions Gone? Calm before the storm. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Hunter Hillegas [EMAIL PROTECTED] To: JBoss Dev [EMAIL PROTECTED] Sent: Friday, November 01, 2002 8:54 AM Subject: [JBoss-dev] Where Have All The Great Development Discussions Gone? Are you guys all hanging out on the private JBossGroup list? I miss the pre-3.0 development discussions about the future of JBoss... There were some great ideas and raging battles... They don't seem to have shifted to the forums, so I was wondering if there is some other public place they are going down? Hunter --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] problem in syncronization in clustering Jboss3.0
Commit option 'B' really gives you nothing for performance...I'll do my perf tests to find out. -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Sacha Labourey Sent: Thursday, October 24, 2002 7:26 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] problem in syncronization in clustering Jboss3.0 You say it is working correctly with CO C, but not with CO B?!? Are you sure? Is that BMP or CMP? Cheers, Sacha -Message d'origine- De : [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]De la part de Vishal Shukla Envoyé : jeudi, 24 octobre 2002 12:30 À : [EMAIL PROTECTED] Objet : [JBoss-dev] RE: Jboss-development digest, Vol 1 #4666 - 10 msgs Hello, Thanks for you prompt reply. One database is shared by both jboss instances .. thanks vishal Message: 8 From: Sacha Labourey [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] problem in syncronization in clustering Jboss3.0 Date: Thu, 24 Oct 2002 10:01:23 +0200 Reply-To: [EMAIL PROTECTED] Hello, How many databases do you use? One per JBoss-instance or one shared by both jboss instances? Cheers, Sacha -Message d'origine- De : [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]De la part de Vishal Shukla Envoyé : jeudi, 24 octobre 2002 08:27 À : [EMAIL PROTECTED] Objet : [JBoss-dev] problem in syncronization in clustering Jboss3.0 Hello, I have created one entitybean . i have deployed this entitybean in two jboss3.0 which are in cluster.Now i am updating rows of table through this entitybean .while updation i am deleting rows and then inserting again. while insertion it is giving follwing error java.rmi.ServerException: INSERTING AN ALREADY EXISTING BEAN, ID = avatar502138; nested exception is: java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = avatar502138 java.rmi.ServerException: INSERTING AN ALREADY EXISTING BEAN, ID = avatar502138; nested exception is: In commit option C it is working fine but What should i do if i want commit option B because of performace. awaiting for your prompt reply thanks vishal --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4729346;7592162;s?http://www.sun.com /javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4729346;7592162;s?http://www.sun.com /javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4729346;7592162;s?http://www.sun.com/javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss 4.0 Entity Redesign
-Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of David Jencks Sent: Monday, October 21, 2002 4:52 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JBoss 4.0 Entity Redesign On 2002.10.21 10:50:45 -0400 Bill Burke wrote: 1. Interceptors do not belong in the JMX layer. JMX should stay simple. If you want interceptors in front of an MBean, you should make the MBean an aspect. Let's gut out the JMX interceptors in favor of using Hiram's Aspect stuff when its mature enough. I disagree. Juha implemented the mbean server based on interceptors for the same reason most of jboss is based on interceptors. I think there should only be one kind of interceptor stack, used for mbeans, clients, aspects, ejbs. In the server, what's on the top makes it an mbean. In a client, it can be the proxy. For aspects, maybe something else. But we only need one kind of interceptor (as in interface that all interceptors implement and how do we invoke each interceptor in the stack, not as in they should all be stateless/ful). Yes there should be only one kind of interceptor stack. This is the Aspect framework (all aspects are, are interceptors anyways). JMX worries about deployment, dependencies, management, basically its a lightweight component framework. Aspects provide the interceptors. If you implement an MBean as an Aspect you can use the power of the Aspect framework. Complete separation. As you said, there only needs to be one kind of interceptor stack. This is the Aspect Framework. So both POJOs and MBeans can have interceptors via the Aspect Framework. Unified. For ejbs, this will translate into a slightly odd kind of mbean, since there won't exactly be one particular object at the end of the stack, but rather the instance will get selected by one of the interceptors. Its not odd at all. The object at the end of the stack is the Interceptor that invokes on the actual EJB. Bill 2. I really don't like this idea of storing state in some detached hashmap somewhere. You're getting back to functional programing with structures and functions. I agree with Marc, hashmap.getvalue is just plain unreadable as well. Hiram, example of state? An example is the Nuke pattern for replicated SFSB. The state of the SFSB stays with the client in the vent of a total destruction of the server. The client provides the state in the event of a failover. Another is IDEMPOTENT methods. Idenpotent methods return the same value no matter what. An interceptor knowing this could store the state of the returned method call and avoid a remote invocation. The above are examples of state per instance. Now I believe you would have singleton interceptors that needed to maintain state. An example is a client side interceptor that does clustering, loadbalancing and failover. It needs to maintain a list of available nodes. There are kind of 3 kinds of state: Configuration of interceptor instances of the same class, conceptually from some kind of interceptor factory. This should definitely be kept in the interceptor instance. Related to this is which interceptors are in the stack. Both of these are currently recorded in jboss.xml as a config-name for ejb stacks. State of interceptor instances depending not on stack name but on identity the top of stack object. This includes, for ejbs, stuff like local jndi environment, security proxy instances, tx-method associations. I think this is what we are debating. I think it will lead to significantly simpler stack management and clearer thinking about interceptors to store this in a hashmap at the top of the stack. If this state info is stored in the interceptors, you need an instance of the interceptor for each top of stack object. If it is store in the top of stack object, you only need one instance of each interceptor for each stack definition. Currently, most interceptors are stateless in this way, although many already are stateless because they store the state info in the top of stack object. I'm proposing that we formalize this and make the remaining interceptors (such as security proxy) use this model as well. Thirdly, there is state from the method invocation. I think everyone agrees that this state should stay in the method invocation, and we should not create and configure a stack for each invocation. david jencks Bill -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Hiram Chirino Sent: Sunday, October 20, 2002 11:25 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JBoss 4.0 Entity Redesign I think for simplicity we should have only stateless interceptors, any interceptor can store per-stack state in a the stack top in a hashmap. I rewrote
RE: [JBoss-dev] JBoss 4.0 Entity Redesign
we want to get this stuff under Hiram's aspect framework so that not every subproject in JBoss uses a different interceptor mechanism. Take a look at Hiram's stuff. ITs good. -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Dain Sundstrom Sent: Tuesday, October 22, 2002 10:22 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JBoss 4.0 Entity Redesign marc fleury wrote: One more request: stateless vs stateful interceptors. It is clear to me that both are needed. For example: stateful are easy to code you just have your variable in there and it is easy. A good example of stateless (taken from invocation) is the read-ahead interceptor. The read-ahead interceptor lives in the CMP stack (if you coded your CMP stack with interceptors). You need to have that information from the client. The client can then set the READ-AHEAD bucket to 3-5 or 20 or whatever it is that he wants to display, the invocation carries that information under the READ-AHEAD value and the interceptor reads it under that value *from the invocation*. It is my feeling that this is now a configuration thingy passed by the XML files. It is good as is, meaning we need the defaults to be configured by the XML file for all the invocations but let the Invocation overwrite them. Bottom line is that I believe the CMP optimization of READ-AHEAD is a good example of both coding practices, in fact they show the *need* for both. CMP will be an set of interceptors so this type of optimization will be trivial. Based on the work I've already done, I think I can eliminate EntityContainer, StatefullSessionContainer, StatelessSessionContainer and MessageDrivenContainer and replace all of them with the single Container class plus some interceptors. I'm not sure about this yet, but it looks like it will be a simple solution in the end. -dain --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com /javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss 4.0 Entity Redesign
sorry single container looks like a good idea. It will probably be refactored a bit more to fit in the Aspect stuff. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Dain Sundstrom Sent: Tuesday, October 22, 2002 10:22 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JBoss 4.0 Entity Redesign marc fleury wrote: One more request: stateless vs stateful interceptors. It is clear to me that both are needed. For example: stateful are easy to code you just have your variable in there and it is easy. A good example of stateless (taken from invocation) is the read-ahead interceptor. The read-ahead interceptor lives in the CMP stack (if you coded your CMP stack with interceptors). You need to have that information from the client. The client can then set the READ-AHEAD bucket to 3-5 or 20 or whatever it is that he wants to display, the invocation carries that information under the READ-AHEAD value and the interceptor reads it under that value *from the invocation*. It is my feeling that this is now a configuration thingy passed by the XML files. It is good as is, meaning we need the defaults to be configured by the XML file for all the invocations but let the Invocation overwrite them. Bottom line is that I believe the CMP optimization of READ-AHEAD is a good example of both coding practices, in fact they show the *need* for both. CMP will be an set of interceptors so this type of optimization will be trivial. Based on the work I've already done, I think I can eliminate EntityContainer, StatefullSessionContainer, StatelessSessionContainer and MessageDrivenContainer and replace all of them with the single Container class plus some interceptors. I'm not sure about this yet, but it looks like it will be a simple solution in the end. -dain --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com /javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss 4.0 Entity Redesign
I'm looking at Hiram's aspect stuff and will try to implement client-side interceptors with this new framework. After that i would like to move to the containers. -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of marc fleury Sent: Sunday, October 20, 2002 7:47 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JBoss 4.0 Entity Redesign Sounds good, When are we planing on converting the interceptor to having only a single invoke method? I can easily do this with a new abstract interceptor that breaks into the two methods based on invocation type. Any objections? not really, it was a needed clean step. Why must the last interceptor, ContainerInterceptor, be defined by the container? Unless there is a reason, I'm going to move this of the container. A reflective invoking interceptor is a good idea as it is needed for the pure aspect interceptors. One more request: stateless vs stateful interceptors. It is clear to me that both are needed. For example: stateful are easy to code you just have your variable in there and it is easy. A good example of stateless (taken from invocation) is the read-ahead interceptor. The read-ahead interceptor lives in the CMP stack (if you coded your CMP stack with interceptors). You need to have that information from the client. The client can then set the READ-AHEAD bucket to 3-5 or 20 or whatever it is that he wants to display, the invocation carries that information under the READ-AHEAD value and the interceptor reads it under that value *from the invocation*. It is my feeling that this is now a configuration thingy passed by the XML files. It is good as is, meaning we need the defaults to be configured by the XML file for all the invocations but let the Invocation overwrite them. Bottom line is that I believe the CMP optimization of READ-AHEAD is a good example of both coding practices, in fact they show the *need* for both. Does anyone have any general objections to this change? -- Dain Sundstrom Chief Architect JBossCMP JBoss Group, LLC --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [JBoss-user] capacity planning to use jboss
- You'll probably want to buy some Hardware based HTTP load-balancer for your web traffic. Make sure it supports sticky sessions. You can try Apache + modjk + AJP13 if you want a cheap software solution. Jetty and Tomcat can be hooked in. - Do you require HTTP Session replication and failover? If its ok for a user to relogin after a failover, I suggest not using JBoss clustering features at all, (Except for net boot and maybe farming). - On the performance tests I ran(ECPERF), replication had a 10% hit on performance for 2 boxes running in a cluster. You'll probably have more than 2 boxes(but not much more). - I suggest marrying the WEB and EJB layer into one JVM/process. You'll get better performance. - Next what you have to do is guess peak traffic. Multiply that number by 2 just to be safe. - Next you'll need to write a stress test program - Next you'll need to hire JBossGroup to help you out with all of this. :) - Next you'll need to purchase a high quality support contract from JBossGroup to iron out any problems you may have :) At Mercantec we had 2 dual 900mhz CPU running Linux and JBoss, 1 dual 900Mgz PIII running Oracle. We could support traffic from 10K merchants. But that's our application. How many users your app can support on a given piece of hardware is totally dependent on the type of application you're running. DON'T USE CLUSTERING UNLESS YOU HAVE TO! Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Emerson Cargnin - SICREDI Serviços Sent: Wednesday, October 16, 2002 11:59 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] [JBoss-user] capacity planning to use jboss Today i got a question from my manager (i work in a bank, there will be a web layer at the bank office and a central ejb layer) : Emerson, how many boxes in the ejblayer do we need to support 800 offices and more than 4000 simultaneous clients (from the offices). Imagine that you have available any number of xeon dual 2mhz with 2giga RAM connected through a gigabit lan, how many boxes of this kind do we need? I confess that i exitated a little. This is a though question, indeed. I think that CMP and mainly clustering will not have the same gain when you have too many nodes in the cluster, given the communication needed among the nodes to keep the data replicated. Does any one have any parameter for a capacity plan for a scenario like this? jboss group, any clue ?? What could be the limit beetwen number of nodes and replication overhead? Thanks in advance for any answer : ) -- | Emerson Cargnin | | Analista de Sistemas Sr. | | Tel : (051) 3358-4959| | SICREDI Serviços | | Porto Alegre - Brasil| |xx| --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [JBoss-user] capacity planning to use jboss
Easy. How to sync Entities? Use Commit 'B' and row-locking if using CMP, or select...for update for BMPs in ejbLoad. row-locking uses Select ...FOR UPDATE on ejbLoad. In CVS HEAD, Sacha and I have implemented a distributed cache via cache invalidation, but we still rely on DB for the distributed lock. A real Clustered distributed lock is in the works. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of James Higginbotham Sent: Wednesday, October 16, 2002 3:02 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [JBoss-user] capacity planning to use jboss Bill, This is interesting about not using clustering.. Are you guys using CMP at all? If so, how do you suggest synching the entity beans without using clustering? On a site without CMP, you can usually get away from clustering, but wondering if you have used the equiv of Javelin to do distributed caching, deployed the CMPs a specific way, or just depend on pessimistic locking and the DB vendor. Thanks, James -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 1:47 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [JBoss-user] capacity planning to use jboss - You'll probably want to buy some Hardware based HTTP load-balancer for your web traffic. Make sure it supports sticky sessions. You can try Apache + modjk + AJP13 if you want a cheap software solution. Jetty and Tomcat can be hooked in. - Do you require HTTP Session replication and failover? If its ok for a user to relogin after a failover, I suggest not using JBoss clustering features at all, (Except for net boot and maybe farming). - On the performance tests I ran(ECPERF), replication had a 10% hit on performance for 2 boxes running in a cluster. You'll probably have more than 2 boxes(but not much more). - I suggest marrying the WEB and EJB layer into one JVM/process. You'll get better performance. - Next what you have to do is guess peak traffic. Multiply that number by 2 just to be safe. - Next you'll need to write a stress test program - Next you'll need to hire JBossGroup to help you out with all of this. :) - Next you'll need to purchase a high quality support contract from JBossGroup to iron out any problems you may have :) At Mercantec we had 2 dual 900mhz CPU running Linux and JBoss, 1 dual 900Mgz PIII running Oracle. We could support traffic from 10K merchants. But that's our application. How many users your app can support on a given piece of hardware is totally dependent on the type of application you're running. DON'T USE CLUSTERING UNLESS YOU HAVE TO! Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Emerson Cargnin - SICREDI Serviços Sent: Wednesday, October 16, 2002 11:59 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] [JBoss-user] capacity planning to use jboss Today i got a question from my manager (i work in a bank, there will be a web layer at the bank office and a central ejb layer) : Emerson, how many boxes in the ejblayer do we need to support 800 offices and more than 4000 simultaneous clients (from the offices). Imagine that you have available any number of xeon dual 2mhz with 2giga RAM connected through a gigabit lan, how many boxes of this kind do we need? I confess that i exitated a little. This is a though question, indeed. I think that CMP and mainly clustering will not have the same gain when you have too many nodes in the cluster, given the communication needed among the nodes to keep the data replicated. Does any one have any parameter for a capacity plan for a scenario like this? jboss group, any clue ?? What could be the limit beetwen number of nodes and replication overhead? Thanks in advance for any answer : ) -- | Emerson Cargnin | | Analista de Sistemas Sr. | | Tel : (051) 3358-4959| | SICREDI Serviços | | Porto Alegre - Brasil| |xx| --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm
RE: [JBoss-dev] [JBoss-user] capacity planning to use jboss
JBoss clustering does load-balanching for ejb types. EB's and SFSB's are sticky for performance reasons. But all home invocations and SLSB invocations are round-robin by default. IN JBoss 3.0.x CMP does not have a distributed cache. So you would need to use commit 'B'. Hire us, we'll help you out. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Emerson Cargnin - SICREDI Serviços Sent: Wednesday, October 16, 2002 3:43 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] [JBoss-user] capacity planning to use jboss other unrelated point : We'll use web layer at the bank offices to avoid wasting band, so : is there a way to use load-balance at the ejb layer??? because I think that modjk does it just for http request, am I right?? lsanders wrote: Some additional comments: 1) If a hardware load balancer is out of the budget (Cisco local director series start at about $4000 - not too expensive), then I would recommend looking at Linux Virtual Server (http://www.linuxvirtualserver.org/). It is basically a customized Linux kernel to do the same stuff as the hardware solution. 2) We do not want to use clustered http sessions, because frankly our sessions are too damn bloated (yeah - we need to fix that, but alas there is only so much time in a day). I was thinking about a way to cluster just enough session info to preserve login context, but to ignore the rest of the junk that is not needed (most of the our http session info is just database cache that can be recreated as needed). Basically, the clustered servers would only share session-id/login-id pairs. I haven't spent any time actually working on this, but I would love to hear comments. Might this be useful to others? -Larry - You'll probably want to buy some Hardware based HTTP load-balancer for your web traffic. Make sure it supports sticky sessions. You can try Apache + modjk + AJP13 if you want a cheap software solution. Jetty and Tomcat can be hooked in. - Do you require HTTP Session replication and failover? If its ok for a user to relogin after a failover, I suggest not using JBoss clustering features at all, (Except for net boot and maybe farming). - On the performance tests I ran(ECPERF), replication had a 10% hit on performance for 2 boxes running in a cluster. You'll probably have more than 2 boxes(but not much more). - I suggest marrying the WEB and EJB layer into one JVM/process. You'll get better performance. - Next what you have to do is guess peak traffic. Multiply that number by 2 just to be safe. - Next you'll need to write a stress test program - Next you'll need to hire JBossGroup to help you out with all of this. :) - Next you'll need to purchase a high quality support contract from JBossGroup to iron out any problems you may have :) At Mercantec we had 2 dual 900mhz CPU running Linux and JBoss, 1 dual 900Mgz PIII running Oracle. We could support traffic from 10K merchants. But that's our application. How many users your app can support on a given piece of hardware is totally dependent on the type of application you're running. DON'T USE CLUSTERING UNLESS YOU HAVE TO! Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Emerson Cargnin - SICREDI Serviços Sent: Wednesday, October 16, 2002 11:59 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] [JBoss-user] capacity planning to use jboss Today i got a question from my manager (i work in a bank, there will be a web layer at the bank office and a central ejb layer) : Emerson, how many boxes in the ejblayer do we need to support 800 offices and more than 4000 simultaneous clients (from the offices). Imagine that you have available any number of xeon dual 2mhz with 2giga RAM connected through a gigabit lan, how many boxes of this kind do we need? I confess that i exitated a little. This is a though question, indeed. I think that CMP and mainly clustering will not have the same gain when you have too many nodes in the cluster, given the communication needed among the nodes to keep the data replicated. Does any one have any parameter for a capacity plan for a scenario like this? jboss group, any clue ?? What could be the limit beetwen number of nodes and replication overhead? Thanks in advance for any answer : ) -- | Emerson Cargnin | | Analista de Sistemas Sr. | | Tel : (051) 3358-4959| | SICREDI Serviços | | Porto Alegre - Brasil| |xx| --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm
[JBoss-dev] HEAD will not build
build files do not work. jason, fix this shit! This is the second week in a row that somebody has fucked things up with the build. Can you at least TEST THINGS before committing something like this?! C:\jboss\jboss-all\buildbuild Calling ..\tools\bin\ant.bat -logger org.apache.tools.ant.NoBannerLogger Buildfile: build.xml _buildmagic:init: Trying to override old definition of task property BUILD FAILED file:C:/jboss/jboss-all/build/../tools/etc/buildfragments/tools.ent:29: taskdef class xdoclet.modules.jmx.JMXDocletTask cannot be found Total time: 1 second Press any key to continue . . . C:\jboss\jboss-all\build --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] HEAD will not build
thanks, sorry. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Adrian Brock Sent: Tuesday, October 15, 2002 2:39 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] HEAD will not build Hi Bill, The module name for HEAD was changed from jboss-all to jboss-head last week. Regards, Adrian From: Bill Burke [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Jboss-Dev [EMAIL PROTECTED] CC: Jason Dillon [EMAIL PROTECTED] Subject: [JBoss-dev] HEAD will not build Date: Tue, 15 Oct 2002 14:21:04 -0400 build files do not work. jason, fix this shit! This is the second week in a row that somebody has fucked things up with the build. Can you at least TEST THINGS before committing something like this?! C:\jboss\jboss-all\buildbuild Calling ..\tools\bin\ant.bat -logger org.apache.tools.ant.NoBannerLogger Buildfile: build.xml _buildmagic:init: Trying to override old definition of task property BUILD FAILED file:C:/jboss/jboss-all/build/../tools/etc/buildfragments/tools.ent:29: taskdef class xdoclet.modules.jmx.JMXDocletTask cannot be found Total time: 1 second Press any key to continue . . . C:\jboss\jboss-all\build --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] HEAD will not build
Does the same apply to all branches??? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Adrian Brock Sent: Tuesday, October 15, 2002 2:39 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] HEAD will not build Hi Bill, The module name for HEAD was changed from jboss-all to jboss-head last week. Regards, Adrian From: Bill Burke [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Jboss-Dev [EMAIL PROTECTED] CC: Jason Dillon [EMAIL PROTECTED] Subject: [JBoss-dev] HEAD will not build Date: Tue, 15 Oct 2002 14:21:04 -0400 build files do not work. jason, fix this shit! This is the second week in a row that somebody has fucked things up with the build. Can you at least TEST THINGS before committing something like this?! C:\jboss\jboss-all\buildbuild Calling ..\tools\bin\ant.bat -logger org.apache.tools.ant.NoBannerLogger Buildfile: build.xml _buildmagic:init: Trying to override old definition of task property BUILD FAILED file:C:/jboss/jboss-all/build/../tools/etc/buildfragments/tools.ent:29: taskdef class xdoclet.modules.jmx.JMXDocletTask cannot be found Total time: 1 second Press any key to continue . . . C:\jboss\jboss-all\build --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] HEAD will not build
Sorry Jason about yelling before. I won't do it again. I don't read jboss-dev much. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Tuesday, October 15, 2002 5:35 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] HEAD will not build Dude... do you read your email? Anyways, each of the builds uses a seperate module name to allow the project structure to vary. Use jboss-head fo HEAD Use jboss-3.0 (or jboss-all) for Branch_3_0 Use jboss-3.2 for Branch_3_2 --jason On Tue, 15 Oct 2002, Bill Burke wrote: Does the same apply to all branches??? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Adrian Brock Sent: Tuesday, October 15, 2002 2:39 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] HEAD will not build Hi Bill, The module name for HEAD was changed from jboss-all to jboss-head last week. Regards, Adrian From: Bill Burke [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Jboss-Dev [EMAIL PROTECTED] CC: Jason Dillon [EMAIL PROTECTED] Subject: [JBoss-dev] HEAD will not build Date: Tue, 15 Oct 2002 14:21:04 -0400 build files do not work. jason, fix this shit! This is the second week in a row that somebody has fucked things up with the build. Can you at least TEST THINGS before committing something like this?! C:\jboss\jboss-all\buildbuild Calling ..\tools\bin\ant.bat -logger org.apache.tools.ant.NoBannerLogger Buildfile: build.xml _buildmagic:init: Trying to override old definition of task property BUILD FAILED file:C:/jboss/jboss-all/build/../tools/etc/buildfragments/tools.ent:29: taskdef class xdoclet.modules.jmx.JMXDocletTask cannot be found Total time: 1 second Press any key to continue . . . C:\jboss\jboss-all\build --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] README :: Thirdparty structure changed
How about these definitions: Aggravation: When somebody fucks up CVS and you waste a whole day of development. Annoyance: When somebody posts stupid definitions from www.dictionary.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tom Coleman Sent: Tuesday, October 08, 2002 2:37 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] README :: Thirdparty structure changed Oops. Missed an important one... From www.dictionary.com Ego - An inflated feeling of pride in your superiority to others --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] somebody has cvs lock in jboss-j2ee/src
...waiting for maximal's lock in /cvsroot/jboss/jboss-j2ee/src Please somebody remove it. Thanks, Bill --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Somebody forgot to check in sun-jaxp directories into branch_3_0
BUILD FAILED: Common module ...thirdparty\sun-jaxp\lib not found. Bill --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] README :: Thirdparty structure changed
All and all I think big structural changes and any big code changes, or any big features should be forbidden from being added to a production branch. IMHO, they shouldn't be allowed for any branched version as a branch means we are trying to stabalize. BTW, you've really hosed me so fix it! Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Scott M Stark Sent: Monday, October 07, 2002 2:58 PM To: [EMAIL PROTECTED] Cc: Jason Dillon Subject: Re: [JBoss-dev] README :: Thirdparty structure changed This has broken the existing 3.0 and 3.2 build structures. Fix these changes immediately as we are not going through the production branch build files to accommodate this change. I also changed the jboss-all alias to checkout its content into the jboss-all directory as this had been changed to jboss. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, October 06, 2002 8:05 PM Subject: [JBoss-dev] README :: Thirdparty structure changed Hi... me again ;) I finally got around to fixing, or rather getting around an unfortunate side-effect of the CVS 'update' command. The previous behavior would cause local clients to download the entire thirdparty/* module (which is time and space consuming). CVS is not desgined to handle nested structures very well, so I modified the _project_thirdparty cvs modules to flatten the directory structure. I also had to update the libraries.ent file to use the new root directories for each library. So, what this means to you is that you need to do the following: 1) Re-checkout the project you are working with OR: a) Remove the thirdparty sub-directory b) Check out the _project_thirdparty module. So for the 'jboss-all' project, you would checkout _jboss-all_thirdparty 2) Ensure that your 'tools' module is up to date. That's it. Unix users working on jboss-all (HEAD) you can execute the following from the jboss-all project directory: rm -rf thirdparty cvs get _jboss-all_thirdparty cvs update tools Let me know if you have any questions, comments or problems. Please no flames *whimper*... --jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] README :: Thirdparty structure changed
the directory structure and module structure is fucking fine! Why fucking change it! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks Sent: Monday, October 07, 2002 4:04 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] README :: Thirdparty structure changed This wasn't a code change, it was a change to how jboss is checked out from cvs. I think maybe Jason forgot that there is no branching available in CVSROOT. Basically the problem is that cvs sucks. I think the solution is to have jboss-all-3_0, jboss-all-3_2, and jboss-all-4_0 targets that check out the appropriate structure for each release. We won't change the production targets, newer ones can be subject to improvement. david jencks On 2002.10.07 15:19:40 -0400 Bill Burke wrote: All and all I think big structural changes and any big code changes, or any big features should be forbidden from being added to a production branch. IMHO, they shouldn't be allowed for any branched version as a branch means we are trying to stabalize. BTW, you've really hosed me so fix it! Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Scott M Stark Sent: Monday, October 07, 2002 2:58 PM To: [EMAIL PROTECTED] Cc: Jason Dillon Subject: Re: [JBoss-dev] README :: Thirdparty structure changed This has broken the existing 3.0 and 3.2 build structures. Fix these changes immediately as we are not going through the production branch build files to accommodate this change. I also changed the jboss-all alias to checkout its content into the jboss-all directory as this had been changed to jboss. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, October 06, 2002 8:05 PM Subject: [JBoss-dev] README :: Thirdparty structure changed Hi... me again ;) I finally got around to fixing, or rather getting around an unfortunate side-effect of the CVS 'update' command. The previous behavior would cause local clients to download the entire thirdparty/* module (which is time and space consuming). CVS is not desgined to handle nested structures very well, so I modified the _project_thirdparty cvs modules to flatten the directory structure. I also had to update the libraries.ent file to use the new root directories for each library. So, what this means to you is that you need to do the following: 1) Re-checkout the project you are working with OR: a) Remove the thirdparty sub-directory b) Check out the _project_thirdparty module. So for the 'jboss-all' project, you would checkout _jboss-all_thirdparty 2) Ensure that your 'tools' module is up to date. That's it. Unix users working on jboss-all (HEAD) you can execute the following from the jboss-all project directory: rm -rf thirdparty cvs get _jboss-all_thirdparty cvs update tools Let me know if you have any questions, comments or problems. Please no flames *whimper*... --jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: RMIAdaptorService still won't compile
Branch_3_0 BTW. Come on! Fix this shit! -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Monday, October 07, 2002 5:42 PM To: Jboss-Group@Jboss. Org Cc: Jboss-Dev Subject: RMIAdaptorService still won't compile line 39: should be declared abstract; it does not define getJndiName() line 76: cannot resolve symbol OBJECT_NAME Bill --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RMIAdaptorService still won't compile
line 39: should be declared abstract; it does not define getJndiName() line 76: cannot resolve symbol OBJECT_NAME Bill --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jmx/src/resources/test/log4j is hosed
I hang when get latest at this directory. What is going on I can't do work Bill --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RE: [jboss-group] jmx/src/resources/test/log4j is hosed
try there is no other information CVS hangs for me. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Monday, October 07, 2002 6:14 PM To: [EMAIL PROTECTED]; 'Jboss-Dev' Cc: 'Jboss-Group@Jboss. Org' Subject: [JBoss-dev] RE: [jboss-group] jmx/src/resources/test/log4j is hosed How about providing some more information so others can try to help the situation a? --jason -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Bill Burke Sent: Monday, October 07, 2002 2:58 PM To: Jboss-Dev Cc: Jboss-Group@Jboss. Org Subject: [jboss-group] jmx/src/resources/test/log4j is hosed I hang when get latest at this directory. What is going on I can't do work Bill ___ jboss-group mailing list [EMAIL PROTECTED] https://secure.jboss.org/mailman/listinfo/jboss-group --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Cannot build main with 1.4.1 anymore
Can latest version of Ant. I think I had same problem. Well, I had trouble running ant with 1.4.1 on XP. Use Ant 1.5. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Scott M Stark Sent: Friday, October 04, 2002 1:25 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Cannot build main with 1.4.1 anymore I did a fresh check of main this morning and find that I cannot build with 1.4.1 FCS release on WinXP any longer: build 63build.bat clean Calling ..\tools\bin\ant.bat clean Buildfile: build.xml _buildmagic:init:global: Trying to override old definition of task property _buildmagic:init: _buildmagic:init:local-properties: _buildmagic:init:buildlog: configure: configure-libraries: configure-modules: configure-defaults: configure-tools: _configure:xdoclet:tasks: _configure:xdoclet:ejbdoclet: _configure:xdoclet:webdoclet: configure-project: [echo] groups: default [echo] modules: jmx,common,system,j2ee,naming,management,transaction,server ,blocks,console,security,messaging,connector,varia,cluster,jetty,j boss.net,iiop _default:init: init: _buildmagic:modules:clean: BUILD FAILED java.lang.IllegalAccessError: tried to access field org.apache.tools.ant.Project Component.project from class org.jboss.tools.buildmagic.task.module.ExecuteModules$MyEcho at org.jboss.tools.buildmagic.task.module.ExecuteModules$MyEcho.execu te(ExecuteModules.java:417) at org.jboss.tools.buildmagic.task.module.ExecuteModules.printHeading (ExecuteModules.java:339) at org.jboss.tools.buildmagic.task.module.ExecuteModules.executeModul e(ExecuteModules.java:313) at org.jboss.tools.buildmagic.task.module.ExecuteModules.execute(Exec uteModules.java:210) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:166) at org.apache.tools.ant.Task.perform(Task.java:317) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:334) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.apache.tools.ant.Project.executeTargets(Project.java:1250) at org.apache.tools.ant.Main.runBuild(Main.java:610) at org.apache.tools.ant.Main.start(Main.java:196) at org.apache.tools.ant.Main.main(Main.java:235) Total time: 2 seconds java.lang.IllegalAccessError: tried to access field org.apache.tools.ant.Project Component.project from class org.jboss.tools.buildmagic.task.module.ExecuteModules$MyEcho at org.jboss.tools.buildmagic.task.module.ExecuteModules$MyEcho.execu te(ExecuteModules.java:417) at org.jboss.tools.buildmagic.task.module.ExecuteModules.printHeading (ExecuteModules.java:339) at org.jboss.tools.buildmagic.task.module.ExecuteModules.executeModul e(ExecuteModules.java:313) at org.jboss.tools.buildmagic.task.module.ExecuteModules.execute(Exec uteModules.java:210) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:166) at org.apache.tools.ant.Task.perform(Task.java:317) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:334) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.apache.tools.ant.Project.executeTargets(Project.java:1250) at org.apache.tools.ant.Main.runBuild(Main.java:610) at org.apache.tools.ant.Main.start(Main.java:196) at org.apache.tools.ant.Main.main(Main.java:235) tried to access field org.apache.tools.ant.ProjectComponent.project from class org.jboss.tools.buildmagic.task.module.ExecuteModules$MyEcho Press any key to continue . . . build 64java -version java version 1.4.1 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-b21) Java HotSpot(TM) Client VM (build 1.4.1-b21, mixed mode) Scott Stark Chief Technology Officer JBoss Group, LLC --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Cleaning up LOB support in JDBCUtil.java
great stuff steve. Keep it up. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Stephen Coy Sent: Friday, September 27, 2002 4:40 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Cleaning up LOB support in JDBCUtil.java Hi Dain, I've been doing some work on making the binary data support more portable in JDBCUtil.java. In particular, I wanted to get all use cases of this working with Oracle, where (despite what I may have said before) there are still issues with BLOBS. Current Oracle JDBC drivers absolutely do support the use of the java.sql.* apis for accessing LOBS and the other forms of binary data (VARBINARY, etc). I believe that you added the code that uses org.jboss.ejb.plugins.cmp.jdbc.ByteArrayBlob to try and resolve the Oracle issues. Please correct me if I am wrong as I've ditched it because Oracle barfs on it (technically, the provision of a java.sql.Blob implementation is in the driver's domain). The only other issue was the use of byte[] bytes = rs.getBytes(index); in getResult. According to the javadoc, ResultSet.getBytes() returns raw bytes from the driver. In Oracle's case, this seems to be the LOB pointer or something, rather than the LOB data. However, going direct to ResultSet.getBinaryStream works fine, so I've modified convertByteArrayToObject to take an InputStream instead, which seems to be a bit more streamlined as you were wrapping the array in a ByteArrayInputStream anyway, unless it already happened to be expecting a byte array. Currently, I have my changes working in Branch_3_0, and the cmp2 test suite passes using both Hypersonic and Oracle. I'll get it working in Branch_3_2 as well. I want to emphasize that I have not used any Oracle apis for this work, only the java.sql.* interfaces. This will not fix the Oracle issues with LOB size when using the thin drivers. The only way to fix that problem is to use the oci drivers. Anyway, I wanted to run this past you and make sure that I'm not working at cross purposes with anyone else before checking it in. Steve Coy --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Gosling has Web Services right...
What I've been saying all along... People have been building Web services under different names for 20 or 30 years, he explains. We've been building distributed systems for years out using CORBA and RMI and all of that. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: FW: [JBoss-dev] configuration of interceptors
: Thu, 12 Sep 2002 13:44:03 -0400 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of marc fleury Sent: Thursday, September 12, 2002 1:23 PM To: 'Bill Burke'; 'juha lindfors'; 'Adrian Brock' Cc: 'Hiram Chirino'; 'Jboss-Development@Lists. Sourceforge. Net' Subject: [JBoss-dev] configuration of interceptors Ok just had an interesting IM with hiram. He essentially has implemented the proxy factory we were talking about. I think he is missing the client/server side of it but we can very simply add these. Essentially it would revolve around a central proxyFactory.createProxy(Interfaces[], client-interceptors[], client-configurations[], server-interceptors[], serverconfigurations[] targetMbean); that returns a Dynamic Proxy, hooked up for remote/local calls with client and server side interceptors. If you are in one vm you can safely assume client=server and only configure one or the other. (meaning if one is null then don't configure transport it will be invm only) In the case of hiram he has only one aspect of it (and he calls it aspect everywhere) but that construct is really what we need. I also think we should have the MBean in there, even though we are talking about a POJO. I believe he has solid code for it and I am really interested in adding this to the base. I am not sure it is a JMX level construct (due to the pojo nature) but having the JMX base manage these configurations and associations between target and interceptors/configuration is the only sane way I can imagine to have these puppies manageable. I want visibility on that configuration for a given mbean (the generalized mbean againg being just a pojo or target). This is our generalized proxy factory. The AOP framework of the future is staring us in the eye... we got it. marc f xx Marc Fleury, Ph.D. President, Founder JBoss Group, LLC xx --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Deadlock retry interceptor
Great fucking idea! I shoulda thought of that. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Michael Bartmann Sent: Wednesday, September 11, 2002 4:07 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Deadlock retry interceptor Hi deadlock lovers, I just did a deadlock-retry-interceptor, which was more easy than I thought. There is a serverside variant and a client interceptor. I don't think you need a client interceptor. Only serverside. The reason? You need to do the retry outside the transaction. The transaction must be able to rollback before you can retry it. The interesting (i.e. non-perfect) points are: - how to configure retry strategy (quite simple now) - where to place the serverside thing in the chain (should be _outside_ of the transaction which just rolled back due to the deadlock; this probably implies that it could have to be done inside the TxInterceptor when entering a new tx. When _not_ doing RequiresNew the interceptor works fine between the SecutiyInterceptor and the TxInterceptor (I tried this with SLSB). You can only do a retry if the Beans starts a transaction. Required(if tx started) or RequiresNew. I think this stuff should be in the TxInterceptor, and maybe only the Container Managed one. - what to do with MDB (they are supposed to catch everything, so nothing gets through to the interceptor. My best guess is to use a UserTX inside the MDB, do the retry manually (w/o interceptor) and put all this in an AbstractDeadlockRetryMDB (I did this, it worked fine). Can't you put it in the TxInterceptor for MDB? Is there any interest to put this into Branch_3_2? Send it to me. I'll get it in. Its definately worth it. Bill --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Deadlock retry interceptor
Great catch! I'll commit this ASAP. Thanks for finding this. You may have actually solved one of my problems. :) Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Stephen Coy Sent: Wednesday, September 11, 2002 8:37 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Deadlock retry interceptor I think so too, because it's a real pain to do retrying from client code We spent a great deal of time eliminating deadlocks in our application. For what it's worth, my fix for bug #601097 eliminated many of them. On Thursday, September 12, 2002, at 08:02 AM, Bill Burke wrote: Great fucking idea! I shoulda thought of that. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Michael Bartmann Sent: Wednesday, September 11, 2002 4:07 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Deadlock retry interceptor Hi deadlock lovers, I just did a deadlock-retry-interceptor, which was more easy than I thought. There is a serverside variant and a client interceptor. I don't think you need a client interceptor. Only serverside. The reason? You need to do the retry outside the transaction. The transaction must be able to rollback before you can retry it. The interesting (i.e. non-perfect) points are: - how to configure retry strategy (quite simple now) - where to place the serverside thing in the chain (should be _outside_ of the transaction which just rolled back due to the deadlock; this probably implies that it could have to be done inside the TxInterceptor when entering a new tx. When _not_ doing RequiresNew the interceptor works fine between the SecutiyInterceptor and the TxInterceptor (I tried this with SLSB). You can only do a retry if the Beans starts a transaction. Required(if tx started) or RequiresNew. I think this stuff should be in the TxInterceptor, and maybe only the Container Managed one. - what to do with MDB (they are supposed to catch everything, so nothing gets through to the interceptor. My best guess is to use a UserTX inside the MDB, do the retry manually (w/o interceptor) and put all this in an AbstractDeadlockRetryMDB (I did this, it worked fine). Can't you put it in the TxInterceptor for MDB? Is there any interest to put this into Branch_3_2? Send it to me. I'll get it in. Its definately worth it. Bill --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] is pooling useless?
I was looking into pooling Invocation objects so I thought I'd test to see
if it is actually better. With this test case, its about 4% faster to pool
on JDK 1.3.1 Win2k.
With JDK 1.4.0 on Win2k, Non-pooling is actually 7% faster!
import java.util.*;
public class testpool
{
HashMap trans;
HashMap as;
HashMap pay;
public testpool()
{
trans = new HashMap();
as = new HashMap();
pay = new HashMap();
}
public void clear()
{
trans.clear();
as.clear();
pay.clear();
}
public void addStuff()
{
for (int i = 0; i 5; i++)
{
trans.put(new Integer(i), new Integer(i));
as.put(new Integer(i), new Integer(i));
pay.put(new Integer(i), new Integer(i));
}
}
public static LinkedList pool = new LinkedList();
public static void main(String[] args)
{
long start;
long end;
System.out.println(testing non pool);
start = System.currentTimeMillis();
for (int i = 0; i 100; i++)
{
testpool p = new testpool();
p.addStuff();
}
end = System.currentTimeMillis() - start;
System.out.println(time: + end);
System.out.println(testing pool);
start = System.currentTimeMillis();
for (int i = 0; i 100; i++)
{
testpool p = null;
if (pool.isEmpty()) p = new testpool();
else
{
synchronized(pool)
{
p = (testpool)pool.removeFirst();
}
}
if (p == null) p = new testpool();
p.addStuff();
p.clear();
synchronized(pool)
{
pool.add(p);
}
}
end = System.currentTimeMillis() - start;
System.out.println(time: + end);
}
}}
---
In remembrance
www.osdn.com/911/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] O'Reilly JBoss 3.0 Workbook
Hello all, Sacha Labourey and I have written a companion workbook to O'Reilly's EJB 3rd Edition by Richard Monson-Haefel. It will be published sometime in October and we would really like some feedback! Please refrain from grammar and spelling mistakes, since our editor will handle these sort of things. I have created a Forum thread to discuss all subjects pertaining to the workbook: http://www.jboss.org/forums/thread.jsp?forum=141thread=20594 To download a 1st draft of the workbook and corresponding examples, please go to: http://www.monson-haefel.com/titanbooks/jbos30worfor.html To use the book it is highly recommended that you also have a copy of EJB 3rd edition since the Workbook follows closely with the chapters of EJB 3rd edition. It can be purchased at: http://www.amazon.com/exec/obidos/tg/detail/-/0596002262/qid=1031070299/sr=1 -1/ref=sr_1_1/002-1658527-7362441?v=glances=books Thanks, Bill Burke JBossGroup --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] O'Reilly JBoss 3.0 Workbook
Hello all, Sacha Labourey and I have written a companion workbook to O'Reilly's EJB 3rd Edition by Richard Monson-Haefel. It will be published sometime in October and we would really like some feedback! Please refrain from grammar and spelling mistakes, since our editor will handle these sort of things. I have created a Forum thread to discuss all subjects pertaining to the workbook: http://www.jboss.org/forums/thread.jsp?forum=141thread=20594 To download a 1st draft of the workbook and corresponding examples, please go to: http://www.monson-haefel.com/titanbooks/jbos30worfor.html To use the book it is highly recommended that you also have a copy of EJB 3rd edition since the Workbook follows closely with the chapters of EJB 3rd edition. It can be purchased at: http://www.amazon.com/exec/obidos/tg/detail/-/0596002262/qid=1031070299/sr=1 -1/ref=sr_1_1/002-1658527-7362441?v=glances=books Thanks, Bill Burke JBossGroup --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] test
burkecentral --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] test
test --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] clusterwide configuration
This may be too simplified, but Juha in Germany was talking that eventually MBean state at runtime would be persistable. I figure that MBean persistence + the farming service + net boot would give a us a clusterwide configuration mechanism without the need to build a centralized configuration service. I guess what I'm getting at is that I've seen the idea floating around that we're moving in a direction of centralized configuration and I'm wondering if its a good idea. Bill --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
FIXED, sorry. didn't do a build.clean so errors crept in. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Friday, August 16, 2002 10:25 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed GUYS PLEASE, WHOEVER BROKE THE BUILD PLEASE FIX IT, marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED] Sent: Friday, August 16, 2002 10:18 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed = ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version 1.4.0_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03) Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE [xdoclet] Generating output for 'org.jboss.naming.NamingService' using template file 'jar:file:/disk/orig/home/lubega/jbossro/jboss-all/thirdparty/ xdoclet/xdoclet/lib/xdoclet.jar!/xdoclet/jmx/mbean.j'. [xdoclet] Generating output for 'org.jboss.web.AbstractWebContainer' using template file 'jar:file:/disk/orig/home/lubega/jbossro/jboss-all/thirdparty/ xdoclet/xdoclet/lib/xdoclet.jar!/xdoclet/jmx/mbean.j'. [xdoclet] Generating output for 'org.jboss.web.WebService' using template file 'jar:file:/disk/orig/home/lubega/jbossro/jboss-all/thirdparty/ xdoclet/xdoclet/lib/xdoclet.jar!/xdoclet/jmx/mbean.j'. compile-classes: [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/server/output/classes [javac] Compiling 513 source files to /disk/orig/home/lubega/jbossro/jboss-all/server/output/classes /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/j boss/ejb/EnterpriseContext.java:11: warning: java.security.Identity in java.security has been deprecated import java.security.Identity; ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/j boss/ejb/EnterpriseContext.java:243: warning: java.security.Identity in java.security has been deprecated public Identity getCallerIdentity() ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/j boss/ejb/EnterpriseContext.java:369: warning: java.security.Identity in java.security has been deprecated public boolean isCallerInRole(Identity id) ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/j boss/security/SecurityDomain.java:12: warning: com.sun.net.ssl.KeyManagerFactory in com.sun.net.ssl has been deprecated import com.sun.net.ssl.KeyManagerFactory; ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/j boss/security/SecurityDomain.java:13: warning: com.sun.net.ssl.TrustManagerFactory in com.sun.net.ssl has been deprecated import com.sun.net.ssl.TrustManagerFactory; ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/j boss/security/SecurityDomain.java:32: warning: com.sun.net.ssl.KeyManagerFactory in com.sun.net.ssl has been deprecated public KeyManagerFactory getKeyManagerFactory() throws SecurityException; ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/j boss/security/SecurityDomain.java:38: warning: com.sun.net.ssl.TrustManagerFactory in com.sun.net.ssl has been deprecated public TrustManagerFactory getTrustManagerFactory() throws SecurityException; ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/j boss/ejb/MessageDrivenContainer.java:362: org.jboss.ejb.MessageDrivenContainer.ContainerInterceptor should be declared abstract; it does not define setConfiguration(org.w3c.dom.Element) in org.jboss.ejb.Container.AbstractContainerInterceptor class ContainerInterceptor ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/j boss/ejb/StatelessSessionContainer.java:560: org.jboss.ejb.StatelessSessionContainer.ContainerInterceptor should be declared abstract; it does not define setConfiguration(org.w3c.dom.Element) in org.jboss.ejb.Container.AbstractContainerInterceptor class ContainerInterceptor ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/j boss/ejb/StatefulSessionContainer.java:754: org.jboss.ejb.StatefulSessionContainer.ContainerInterceptor should be declared abstract; it does not define setConfiguration(org.w3c.dom.Element) in org.jboss.ejb.Container.AbstractContainerInterceptor class ContainerInterceptor
RE: [JBoss-dev] Recruiting new developers
In my 11 year career I have yet to be on a software project that had complete, simple, up-to-date documentation on the overall design of the system. If you're a very talented coder, then you're just being lazy. Andreas is right, newbies need to show initiative. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of micael Sent: Thursday, August 15, 2002 2:11 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Recruiting new developers I think that sometimes people do not see the effort a newbie has put into something, because putting yourself into their place is also difficult, and is not so urgent, i.e. their pain is not your pain. I paid to get documentation that turned out to be a work in progress and have never really gotten value for the money. Maybe that has now changed. The site sure looks better. I downloaded the 3.0 start kit and will see. But, I am not putting in more money until I make sure I am getting something back. The sad thing is that I am a very talented coder who would love to be involved with coding on JBoss. Well, not that sad. I need to get a grip here. ///;-) Thanks for taking the time, Andreas. At 04:36 PM 8/14/2002 -0700, you wrote: Hi Everyone is welcomed to write docu but only a few did so. I know to start with JBoss is difficult but I don't think that people don't welcome beginners (see the JBoss forum, the new JBoss 3.0 docu etc.) but user questions are not welcomed on the developer list (that is why it is a developer list). The only important step I expect for a newcomer is to show initiative. I hate questions like please help I don't understand this but I help if someone is coming with a questions that shows initiative. So first search on the JBoss forum (maybe the questions is already solved), then check the docu and finally go to the forum. Another (additional) way would be to provide snappy and easy to read introductions to the basic code layout in JBoss. I am a Java Certified Programmer, so I know a little about Java, and I have coded many large sites, but know little about JBoss. I came here to learn about a year ago but left, not feeling welcome. Not crying, just letting you know. I have a big interest in JBoss and am a real fan, but do not have time to climb uphill to learn with you. Hasta la differences? Have fun x Andreas Schaefer Senior Consultant JBoss Group, LLC x --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] problem after switching jboss-2.4 to jboss-3.0
Are you using custom primary key classes? If so, make sure you have equals and hashCode implemented correctly and that your PK class serializes correctly as well. What exactly is the JBoss 2.4 version you're converting from? Thanks, Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Vishal Shukla Sent: Wednesday, August 14, 2002 1:49 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] problem after switching jboss-2.4 to jboss-3.0 Hello, I have switched my application from jboss-2.4 to jboss-3.0 because of its clustering feature.But while converting I am getting below mentioned error in most of the beans.. java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: java.rmi.ServerException: removing bean lock and it has tx set!; nested exception is: java.lang.IllegalStateException: removing bean lock and it has tx set! can anybody please guide me regarding this matter. thanks in advance awating for your prompt reply regards vishal --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code1 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] you can't configure interceptors...
After looking at EJBModule, there doesn't seem to be a way to pass configuration information to Interceptors. I'm going to put this in if nobody objects. Bill --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] you can't configure interceptors...
To minimize changes, you'll have to extract config information from XML attributes, ok? Otherwise we fuck up everybody's container configurations. i.e container-interceptors interceptor config1=hello config2=worldorg.jboss.some.fucking.interceptor/interceptor /container-interceptors ehMaybe I'm just being lazy... (BTW, this is for 4.0) Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Scott M Stark Sent: Tuesday, August 13, 2002 12:08 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] you can't configure interceptors... Do it, this is something we have been missing for a while. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Bill Burke [EMAIL PROTECTED] To: Jboss-Dev [EMAIL PROTECTED] Sent: Tuesday, August 13, 2002 8:44 AM Subject: [JBoss-dev] you can't configure interceptors... After looking at EJBModule, there doesn't seem to be a way to pass configuration information to Interceptors. I'm going to put this in if nobody objects. Bill --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] you can't configure interceptors...
I don't need the interceptor configuration for anything important right now, but I will commit something soon anyways. Let me know if development stalls on the new MBean interceptor stuff and I'll help out. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Tuesday, August 13, 2002 2:53 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] you can't configure interceptors... Bill, You are absolutely correct. The interceptor configuration is set. We discussed with Juha and Adrian in Palma and there is an elegant way to provide interceptor configuration. If you have a simple fix for EJB and you need it right now, go ahead, but we have a simple way at the JMX layer to specify this configuration. Have the configuration live at the head of the interceptors, have it be in the container (exactly like the client side architecture) and you have then the Context associated with the invocation. In that context you can set arbitrary name:value pairs, like we do in the client interceptors. And even Element objects as we do with the current configuration parsers. Then the interceptor is supposed to look up the object by name and use that value. This configuration is in one place with a one to one mapping between mbean/container and configuration. You can modify this configuration on the fly and come up with clever persistence schemas for it. marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Bill Burke Sent: Tuesday, August 13, 2002 11:45 AM To: Jboss-Dev Subject: [JBoss-dev] you can't configure interceptors... After looking at EJBModule, there doesn't seem to be a way to pass configuration information to Interceptors. I'm going to put this in if nobody objects. Bill --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] you can't configure interceptors...
Ok, I won't be lazy :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Scott M Stark Sent: Tuesday, August 13, 2002 2:50 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] you can't configure interceptors... I think your being too lazy now, and config via attributes is in general insufficient. Just check if an element has a child element that maps to a setXXX(Element) accessor where the XXX corresponds to the child element name. This does not break existing configs as no interceptors have configurable attributes right? Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Bill Burke [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, August 13, 2002 9:43 AM Subject: RE: [JBoss-dev] you can't configure interceptors... To minimize changes, you'll have to extract config information from XML attributes, ok? Otherwise we fuck up everybody's container configurations. i.e container-interceptors interceptor config1=hello config2=worldorg.jboss.some.fucking.interceptor/interceptor /container-interceptors ehMaybe I'm just being lazy... (BTW, this is for 4.0) Bill --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Is MetaData.getElementContent wrong?
Seems to get everything, the text of the node as well as all child elements.
Seems like it should ignore everything but TEXT_NODE and CDATA stuff.
public static String getElementContent(Element element, String
defaultStr)
throws DeploymentException
{
if (element == null)
return defaultStr;
NodeList children = element.getChildNodes();
String result = ;
for (int i = 0; i children.getLength(); i++)
{
if (children.item(i).getNodeType() == Node.TEXT_NODE ||
children.item(i).getNodeType() == Node.CDATA_SECTION_NODE)
{
result += children.item(i).getNodeValue();
}
else if( children.item(i).getNodeType() == Node.COMMENT_NODE )
{
// Ignore comment nodes
}
else
{
result += children.item(i).getFirstChild();
}
}
return result.trim();
}
---
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Please support Option B (response to Jim Cook)
yes, commit b is a requirement, and Instantce Per Transaction is available in 2.4.6. THe interceptors needed are EntityMultiInstanceInterceptor EntityMultiInstanceSynchronizationInterceptor and MethodOnlyEJBLock. Take a look at standardjboss.xml in 3.0 and you'll be able to apply it. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of James Cook Sent: Sunday, August 04, 2002 1:42 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Please support Option B (response to Jim Cook) I am deployed on jBoss 2.4.6, and I changed to MethodOnlyEJBLock to prevent some spurious ApplicationDeadlockExceptions that occur. Is it a requirement on the 2.4 version of the server to use commit option B as well? jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Bill Burke Sent: Friday, August 02, 2002 11:30 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Please support Option B (response to Jim Cook) Jim Do not use MethodOnlyEJBLock on its own. In JBoss 3.0.1 and higher there is an additional container configuration you can use that creates an Instance per transaction for each entity bean. The side-effects, you must use Commit-option 'B' and you do not get serialized access to your entity beans. (analogy is Read-committed behaviour instead of serialized). i.e. jboss enterprise-beans entity ejb-nameMyCMP2Bean/ejb-name jndi-nameMyCMP2/jndi-name configuration-nameInstance Per Transaction CMP 2.x EntityBean/configuration-name /entity entity ejb-nameMyBMPBean/ejb-name jndi-nameMyBMP/jndi-name configuration-nameInstance Per Transaction BMP EntityBean/configuration-name /entity /enterprise-beans /jboss Also, in 3.0, for the default pessimistic locking, you can now define methods as read-only(thanks to Peter Murray). Meaning, invoking on read-only methods will not lock the entity bean into the transaction. To use this: jboss enterprise-beans entity ejb-namenextgen.EnterpriseEntity/ejb-name jndi-namenextgen.EnterpriseEntity/jndi-name method-attributes method method-nameget*/method-name read-onlytrue/read-only /method method method-nameanotherReadOnlyMethod/method-name read-onlytrue/read-only /method /method-attributes /entity /enterprise-beans /jboss I have written a document on this stuff in the soon-to-be published 3.0 for-pay documentation. Email me if you have any further questions. Bill But back to EB locking, jBoss supports MethodOnlyEJBLock as a configuration option. I'm not absolutely sure, but isn't that the same thing as the opptomistic locking that WL and other servers support? jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Tom M. Yeh Sent: Thursday, August 01, 2002 8:04 AM To: Jboss-Development Subject: RE: [JBoss-dev] Please support Option B So, why Option B? Let us assume you have two beans, A and B. One transaction reads A and then B, while the other transaction reads B then A. If option A is used, a dead lock occurs even though both transactions won't modify A or B (this is OK if we access database directly without using EJB). So some says let us alter EJB spec a bit by allowing multiple bean instances (i.e., each transaction has an independent instance) for option A. But, if one transaction modifies A, how shall the other transactions know and react? Some says let developer specify which methods are read-only. If we do it correctly, we just redo what the database already do (read/update/exclusive locking, isolation level...). And, how about clustering? Some suggests to use stored procedure to trigger and invalidate corresponding instances. Beside the question of when to invalidate, it is hard to know what instances are affected by simply looking at a database table -- you need metainfo about how objects are mapped to tables and try to map tables back to objects. Even you could, how about clustering? One VM notifies another? If we have Option B, then we could let database do what they are good at. We just make sure the cached instances is consistent with records in database. How? Optimistic lock for one -- versioning or timestamp is good enough. It can be done easily when ejbLoad is called -- which is demanded for option B. However, in the current implementation, all instances are trashed
[JBoss-dev] RE: [jboss-group] FW: Sun says Opensource is bad
Is the RI source-available? I didn't think it was. Yeah, McNealy is an idiot. Even without JBoss, .Net's price point will bring down J2EE revenues. The difference is, with JBoss, people will stay under the Java/J2EE umbrella. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Saturday, August 03, 2002 7:43 AM To: 'Jboss-Group@Jboss. Org' Cc: Jboss-Development@Lists. Sourceforge. Net Subject: [jboss-group] FW: Sun says Opensource is bad Scott McNealy says we are destroying the revenue models of the J2EE marketplace, imbecile, he doesn't even know what is sexy. marcf -Original Message- From: Lawrence E. Rosen [mailto:[EMAIL PROTECTED]] Sent: Friday, August 02, 2002 8:13 PM To: 'Nathalie Mason'; 'marc fleury' Subject: FW: Sun says Opensource is bad I just received this today. /Larry -Original Message- From: Peter Donald [mailto:[EMAIL PROTECTED]] Sent: Friday, August 02, 2002 5:04 PM To: Jakarta General List Subject: Sun saids Opensource is bad http://www.oetrends.com/cgi-bin/page_display.cgi?77 And that is why I am glad that jakarta is starting to get .Net technologies on board. ___ jboss-group mailing list [EMAIL PROTECTED] https://secure.jboss.org/mailman/listinfo/jboss-group --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Please support Option B
: What is that notifications on A scheme marc is talking about? Dan Christopherson wrote: OK, so it's more a matter of allowing multiple bean instances. Once that's there, B or C doesn't really matter - the extra overhead implied by C is noise compared to the database read (which you need either way). Of course, anybody that can use option A should. -danch Bill Burke wrote: Yes, Tom, be more specific. I know you're smarter than that. You're probably talking about the Instance per Transaction locking scheme. This works fine with commit-option 'B'. Yes, it is not totally optimized, but is does pool dead instances. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dan Christopherson Sent: Friday, July 19, 2002 10:08 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Please support Option B Whahuh? JBoss doesn't support option B? Tom M. Yeh wrote: Dear All, According to the CSIRO report (http://www.cmis.csiro.au/adsat/jboss.htm), JBoss is doing well with Stateless session beans. It implies reflection, by comparing to static compiled codes, doesn't affect the performance much, while it has great architectural advantages such as pluggable interceptors. However, entity beans is not the case. One of the reason, I think, is this report uses Option B, which JBoss doesn't support (and uses Option C instead). In other words, all beans are trashed after a transaction is completed. It then introduces a lot of overhead since every transaction has to reload all beans involved from database (and you know accessing database kills the performance). After examining the codes and a few talks with Bill, I don't think I am capable to modify the codes to support Option B. Any volunteer is willing to do that? Thanks and Regards, Tom --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development N±µŠ²²u†Y￠￠’½¶þžz›%±z™™ŠŠnu–zŠ²q®z¶þ¶º~zþ¶Š±z™ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development +, 隊X'uNggr剞 zH^j m ( n, zZ) x%Inퟝ�, zZ) X y + zmض b q +-떳b ~n, ׯzZ) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Please support Option B (response to Jim Cook)
Jim Do not use MethodOnlyEJBLock on its own. In JBoss 3.0.1 and higher there is an additional container configuration you can use that creates an Instance per transaction for each entity bean. The side-effects, you must use Commit-option 'B' and you do not get serialized access to your entity beans. (analogy is Read-committed behaviour instead of serialized). i.e. jboss enterprise-beans entity ejb-nameMyCMP2Bean/ejb-name jndi-nameMyCMP2/jndi-name configuration-nameInstance Per Transaction CMP 2.x EntityBean/configuration-name /entity entity ejb-nameMyBMPBean/ejb-name jndi-nameMyBMP/jndi-name configuration-nameInstance Per Transaction BMP EntityBean/configuration-name /entity /enterprise-beans /jboss Also, in 3.0, for the default pessimistic locking, you can now define methods as read-only(thanks to Peter Murray). Meaning, invoking on read-only methods will not lock the entity bean into the transaction. To use this: jboss enterprise-beans entity ejb-namenextgen.EnterpriseEntity/ejb-name jndi-namenextgen.EnterpriseEntity/jndi-name method-attributes method method-nameget*/method-name read-onlytrue/read-only /method method method-nameanotherReadOnlyMethod/method-name read-onlytrue/read-only /method /method-attributes /entity /enterprise-beans /jboss I have written a document on this stuff in the soon-to-be published 3.0 for-pay documentation. Email me if you have any further questions. Bill But back to EB locking, jBoss supports MethodOnlyEJBLock as a configuration option. I'm not absolutely sure, but isn't that the same thing as the opptomistic locking that WL and other servers support? jim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Tom M. Yeh Sent: Thursday, August 01, 2002 8:04 AM To: Jboss-Development Subject: RE: [JBoss-dev] Please support Option B So, why Option B? Let us assume you have two beans, A and B. One transaction reads A and then B, while the other transaction reads B then A. If option A is used, a dead lock occurs even though both transactions won't modify A or B (this is OK if we access database directly without using EJB). So some says let us alter EJB spec a bit by allowing multiple bean instances (i.e., each transaction has an independent instance) for option A. But, if one transaction modifies A, how shall the other transactions know and react? Some says let developer specify which methods are read-only. If we do it correctly, we just redo what the database already do (read/update/exclusive locking, isolation level...). And, how about clustering? Some suggests to use stored procedure to trigger and invalidate corresponding instances. Beside the question of when to invalidate, it is hard to know what instances are affected by simply looking at a database table -- you need metainfo about how objects are mapped to tables and try to map tables back to objects. Even you could, how about clustering? One VM notifies another? If we have Option B, then we could let database do what they are good at. We just make sure the cached instances is consistent with records in database. How? Optimistic lock for one -- versioning or timestamp is good enough. It can be done easily when ejbLoad is called -- which is demanded for option B. However, in the current implementation, all instances are trashed after a transaction complete, no matter option B or C. Thus, optimistic lock is useless and we have to reload instances when a new transaction starts. After all, loading and comparing a timestamp is much cheaper than loading the whole instance, because an instance usually has multiple relations to other instances. Commit option A and when the row changes in the database a stored procedure notifies the server that the data in cache is no longer valid. -dain Ignacio Coloma wrote: What is that notifications on A scheme marc is talking about? Dan Christopherson wrote: OK, so it's more a matter of allowing multiple bean instances. Once that's there, B or C doesn't really matter - the extra overhead implied by C is noise compared to the database read (which you need either way). Of course, anybody that can use option A should. -danch Bill Burke wrote: Yes, Tom, be more specific. I know you're smarter than that. You're probably talking about the Instance per Transaction locking scheme. This works fine with commit-option 'B'. Yes, it is not totally optimized, but is does pool dead instances
RE: [JBoss-dev] InvocationResponse and Exceptions
COMPLETION_MAYBE is when you are actually in the invocation of the bean and you really don't know how far the invocation got.(for clustering don't failover invocation because you may be in inconsistent state.) COMPLETION_NO means an exception/problem occured before the actual invocation(definately failover) COMPLETION_YES means that everything is a ok. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Monday, July 08, 2002 2:59 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] InvocationResponse and Exceptions Completion maybe??? What would it be and why is it interesting? KISS, Marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Dain Sundstrom Sent: Saturday, July 06, 2002 11:51 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] InvocationResponse and Exceptions Cool. When you get this done, I'd like to add some code to send the stacktrace for remote exceptions on JDK 1.3. -dain Bill Burke wrote: As you might already now, I'm wrapping the return value from an invocation in a response object. This is so that the server side can communicate back to client-side interceptors. Eventually I even want to pass back an exception within this InvocationResponse object along with a completion status. COMPLETION_YES COMPLETION_NO COMPLETION_MAYBE (You CORBA guys might recognize this.) These will allow client-side interceptors like clustering to determine that exact state of a failure. Bill --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Got root? We do. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Oh, it's good to be a geek. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Oh, it's good to be a geek. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] InvocationResponse and Exceptions
it means that the invocation got to the bean but an exception/error was thrown in the middle of the actual invocation. So you could have a COMPLETION_YES if the invocation on the bean return but there was an error/exception thrown in the interceptor stack. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Monday, July 08, 2002 10:09 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] InvocationResponse and Exceptions COMPLETION_MAYBE is when you are actually in the invocation of the bean and you really don't know how far the invocation got.(for clustering don't failover invocation because you may be in inconsistent state.) Give me an example of being in the bean and not knowing how far the invocation went. When would it be? marcf COMPLETION_NO means an exception/problem occured before the actual invocation(definately failover) COMPLETION_YES means that everything is a ok. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Monday, July 08, 2002 2:59 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] InvocationResponse and Exceptions Completion maybe??? What would it be and why is it interesting? KISS, Marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Dain Sundstrom Sent: Saturday, July 06, 2002 11:51 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] InvocationResponse and Exceptions Cool. When you get this done, I'd like to add some code to send the stacktrace for remote exceptions on JDK 1.3. -dain Bill Burke wrote: As you might already now, I'm wrapping the return value from an invocation in a response object. This is so that the server side can communicate back to client-side interceptors. Eventually I even want to pass back an exception within this InvocationResponse object along with a completion status. COMPLETION_YES COMPLETION_NO COMPLETION_MAYBE (You CORBA guys might recognize this.) These will allow client-side interceptors like clustering to determine that exact state of a failure. Bill --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Got root? We do. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Oh, it's good to be a geek. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Oh, it's good to be a geek. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Oh, it's good to be a geek. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Oh, it's good to be a geek. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] when will head be fixed?
Is it already? --- This sf.net email is sponsored by:ThinkGeek Got root? We do. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] InvocationResponse and Exceptions
As you might already now, I'm wrapping the return value from an invocation in a response object. This is so that the server side can communicate back to client-side interceptors. Eventually I even want to pass back an exception within this InvocationResponse object along with a completion status. COMPLETION_YES COMPLETION_NO COMPLETION_MAYBE (You CORBA guys might recognize this.) These will allow client-side interceptors like clustering to determine that exact state of a failure. Bill --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] adding InvocationResponse object
I'm going to change the invocation stack so that a response object is passed back to the client instead of just the raw data. This will allow the server to send back information to the client. The client can already send back information via the Invocation object, just makes sense to add an InvocationResponse. Bill --- This sf.net email is sponsored by:ThinkGeek Caffeinated soap. No kidding. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] deadlock detection in JDK 1.4.1
CooL! Deadlock Detector in Java HotSpot VM A deadlock detection utility has been added to the Java HotSpot VM. The utility is invoked by a ctrl+\ (on Linux or the Solaris Operating Environment) or a ctrl-break (on Microsoft Windows) on the command line while an application is running. The utility detects Java-platform-level deadlocks, including locking done from the Java Native Interface (JNI), the Java Virtual Machine Profiler Interface (JVMPI), and Java Virtual Machine Debug Interface (JVMDI). When invoked, the utility displays a thread dump to standard out and indicates any Java-platform-level deadlocks it detects. Refer to this sample output. If the application is deadlocked because two or more threads are involved in a cylce to acquire monitors, then the list of such threads and monitors involved in the deadlocks are displayed. Note, however, that this will not find deadlocks involving threads waiting on monitors on which no signal will be forthcoming. --- This sf.net email is sponsored by:ThinkGeek No, I will not fix your computer. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] http transport
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Holger Engels Sent: Wednesday, June 26, 2002 6:19 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] http transport On Mon, 24 Jun 2002, Bill Burke wrote: ProxyFactory is not an MBean. Just an object right now. Config code, creates and attaches ProxyFactorys to each EJB. (Each EJB is an mbean though). Still trying to understand .. Seems like I don't need an HTTPInvoker. Only an HTTPInvokerProxy and a InvokerServlet, that forwards invocations to the local invoker. If I understand it, the proxy must provide a TransactionPropagationContext instance to each Invocation. This has to be imported in the servlet before the invocation is forwarded to the LocalInvoker. No invocation forward. Invoke directly on the EJB Container through the JMX Bus. Take a look at the JRMPInvoker as an example.(Or the local invoker). Also, there must be a HTTPProxyFactory, that binds an HTTPInvokerProxy into jndi for every ejb. An then, there's the setup / integration. I need some MBean, that sets up the proxy factory and deploys the servlet. Yes exactly. I may have time to break out JNDI into an MBean. So I could work on that. All that together should be packaged into one single deployment unit, e.g. a sar. Right? Yes, a sar is perfect for this since there's really no config for this invoker, right? Holger --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] http transport
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Holger Engels Sent: Wednesday, June 26, 2002 6:19 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] http transport On Mon, 24 Jun 2002, Bill Burke wrote: ProxyFactory is not an MBean. Just an object right now. Config code, creates and attaches ProxyFactorys to each EJB. (Each EJB is an mbean though). Still trying to understand .. Seems like I don't need an HTTPInvoker. Only an HTTPInvokerProxy and a InvokerServlet, that forwards invocations to the local invoker. If I understand it, the proxy must provide a TransactionPropagationContext instance to each Invocation. This has to be imported in the servlet before the invocation is forwarded to the LocalInvoker. No invocation forward. Invoke directly on the EJB Container through the JMX Bus. Take a look at the JRMPInvoker as an example.(Or the local invoker). Also, there must be a HTTPProxyFactory, that binds an HTTPInvokerProxy into jndi for every ejb. An then, there's the setup / integration. I need some MBean, that sets up the proxy factory and deploys the servlet. Yes exactly. I may have time to break out JNDI into an MBean. So I could work on that. All that together should be packaged into one single deployment unit, e.g. a sar. Right? Yes, a sar is perfect for this since there's really no config for this invoker, right? Holger --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] http transport
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Wednesday, June 26, 2002 12:55 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] http transport |Seems like I don't need an HTTPInvoker. Only an HTTPInvokerProxy and a |InvokerServlet, that forwards invocations to the local invoker. If I use the JMX bus directly, |understand it, the proxy must provide a TransactionPropagationContext |instance to each Invocation. This has to be imported in the servlet |before the invocation is forwarded to the LocalInvoker. The transaction is not mandatory, but if it is there then yes it has to be imported (this is a weakness, necessary I am told (?) of the current transaction engine design). This weakness needs to be corrected. |Also, there must be a HTTPProxyFactory, that binds an HTTPInvokerProxy |into jndi for every ejb. An then, there's the setup / integration. I need |some MBean, that sets up the proxy factory and deploys the servlet. I am thinking, bill, we should do a factory bind in JNDI that knows what I think we may have to use JNDI properties to implement this i.e. jndi.properties: java.naming.factory.initial=org.jnp.interfaces.HTTPNamingContextFactory java.naming.provider.url=http://yomama.com/JrmpInvoker Also, this may be the best solution anyways. I really want to avoid any proprietary configuration on the client side. protocol to add in the invoker but the proxy stuff should be generalized, the interface input generalized. This way you would just context.lookup(http/myMBean) or some way to specify what transport you want and we return to you the right invoker in the java stack with the interface _of the MBean_ not just EJB. This way you are talking to you remote server MBean through the HTTP protocol, and tunnelling through anything this way . Java interfaces to web services. simply done, I also agree that this whole proxy mess needs to be non-EJB specific and generic to MBeans. The first step though is creating an HTTPInvokerProxy and HTTPInvoker. Maybe based on the invocation type, you could reference a binding specific to that transport meaning, if you do context.lookup(myMBean) on a HTTP protocol, you get the HTTP MBean proxy. I've already done this sort of this with EJBs. |All that together should be packaged into one single deployment unit, e.g. |a sar. Right? yes marcf |Holger pull this off holger, pull it off, marcf | | | |--- |This sf.net email is sponsored by: Jabber Inc. |Don't miss the IM event of the season | Special offer for OSDN members! |JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] http transport
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Holger Engels Sent: Monday, June 24, 2002 2:37 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] http transport On Fri, 21 Jun 2002, Bill Burke wrote: Holger, in JBoss 3.0 we have client interceptors, and pluggable transports. The invocation has been totally decoupled from the EJB container. The EJB Container is now just an MBean and all EJB invocations go across the JMX bus. Great! JBoss 3.1 takes things a bit further. In 3.1 you can now define multiple invokers (transports) per EJB container. So an EJB container can be configured to receive requests from RMI, IIOP, SOAP, HTTP, whatever all at the same time. We'll want to hook your HTTP invoker into this architecture. Ok, I'm already trying to do that. The files and java packages you'll want to look at are as follows, There's also a detail email I sent out 2 months ago that is copied later on in this email: In server module: Packages org.jboss.invocation, org.jboss.proxy org.jboss.invocation.jrmp.server.JRMPInvoker.java is the main entry point on the server side. It accepts invocation requests and routes them across the JMX bus. I think your HTTP POST protocol can be very simple. Just marshall an Invocation and send it across the wire. The JRMPInvoker is stateless and can route any Invocation. So far, that's straight forward. I' am writing a HTTPInvoker, that deploys a servlet (same hack as jboss.net axis servlet) and forwards invocations to the HTTPInvoker. The invoker feeds them into jmx. For the client side, you'll need to implement a new org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy. This is really the Transport on the client side. You'll also need to implement a org.jboss.proxy.ejb.ProxyFactory. The JBoss clustering can be used as an example since it has extended JRMPInvokerProxy, ProxyFactory and has its own Invoker. see the cluster module. All classes under the above packages. If I understand it correctly, the ProxyFactory is an MBean, running on the server, facturing InvokerProxy instances that are moved to and used on the client (caller side)!? ProxyFactory is not an MBean. Just an object right now. Config code, creates and attaches ProxyFactorys to each EJB. (Each EJB is an mbean though). What sucks is that even if you've implemented this stuff, its not very helpful because JNDI does not have pluggable transports. Maybe I am still missing something, but what if the server configuration You currently can only invoke on JNDI remotely through RMI. JNDI is not currently an MBean, so you can't invoke on it through a different transport. would simply end with the invoker layer. container is server side. invoker is the entry point for the container, thus also server side. remaining config is _client_side_. In 3.1, that's what I'm trying to do. Separate server configuration from client configuration. This is very important when you have multiple invoker types. (SOAP, IIOP, RMI). The client (another bean, application-client, web-application) is always referring an (ejb|ejb-local|..)-ref (coded name) in its private jndi namespace. It is never accessing the server's jndi namespace directly! The ejb-ref is the place for configuration bits that: I agree that ejb-refs are a good place to define some things. If you notice from the multi-invoker testsute test, you'll see from the configuration that based on the Invoker type, you can bind different absolute JNDI bindings for each ejb-ref you have. So, for example, if you invoke on an IIOP invoker, the container will pass this information on to other container it interfaces with. So if you invoke with IIOP and that EJB calls a finder on one of its EJB refs, the proxies returned will be IIOP proxies. Am I making sense? So yes, ejb-refs are a good place to stuff certain kinds of information. o identify the target component o determine the transport protocol o locate the invoker Disagree, discovery is JNDI's responsibility. o setup the client interceptors (terms server and client often used in the sense of callee/caller) This would have some big advantages: o decoupling of client and server This has been done for EJBs at least in 3.1 (invoker-proxy bindings) and needs to be extended to MBeans. o no jndi plugins for different protocols required o jndi is mostly (if not completely) local Not sure if I agree with your JNDI ideas. The whole point of JNDI is to provide a central point to locate objects and services. Maybe I'm misunderstanding your ideas, but with your approach, for each client you would have to hard-code locations of things within ejb-refs. Not very flexible or maintable. o server is responsible for containment and accessibility o client can connect wherever it wants (also to different appservers in different locations with different
RE: [JBoss-dev] http transport
JDK already has built in RMI HTTP tunneling. Why would we need this transport? Here's directions: http://www.dmh2000.com/ApacheTomcatRMI.htm Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Holger Engels Sent: Friday, June 21, 2002 5:00 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] http transport I try to understand, how a http transport can be implemented within jboss .. so what do I need? on the server side: o a connector servlet / extra http deamon, that accepts invocations embedded in http posts. the result of a home invocation is a handle. subsequent invocations (remote interface) contain the handle to identify the target ejb. the servlet is completely stateless. o an mbean service, that manages the servlet / http deamon on the client: o some interceptor (the last one in the chain), that marshalls the invocation as an http post request and demarshalls results / throwables. I call it the 'Transport' o is a special handle implementation required? o usertransaction handling is transparent (part of Invocation)? configuration: o it's the server's job to provide the connector servlet. the servlet doesn't need to be configured. the invocations carry all the information that is required to perform home-/ remote-invocations. o the client will do a lookup first (coded name, declared in the application-client descriptor). it then gets a dynamic proxy passing on the java style invocation to the invocation handler. the invocation handler feeds the invocation into the interceptor chain. this chain has to be configured somehow (during deployment of the application-client jar). o afaik there's no application client deployment at the moment and the client side interceptors are configured from the server, right? so what makes up the whole interceptor chain? we distinguish: o client side interceptors o server side interceptors (synchronization, pooling / caching, security) o symmetric interceptors (encryption / decryption for instance) the overall configuration of the (ordered) interceptor chain is made of component aspects and reference aspects. transport is just another aspect of the reference. authentication: in the smartcc, using the http transport requires a http login module (basic/digest auth) to be configured. the authentication task is performed by the servlet container. the container cares about setting up the security association. dain asked for an http plugin for jndi. my question: why do I need the server side's jndi content on the client if I don't lookup homes? what does a java client need beside what's configured in the application client descriptor. what am i missing? holger --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] http transport
Good enough for me. Thanks for the info. Holger, we should talk. I can give you pointers on how to integrate the HTTP Invoker into the 3.1 architecture. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dave Smith Sent: Friday, June 21, 2002 10:21 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] http transport The HTTP RMI tunning is the shits. Firstly there is no option to go with https without getting really ugly. Secondly, the whole cgi-script or servlet which then calls the local rmi listener generates two network calls for lookup. Since jetty is running in the container the servlet lookup should be a local JNDI lookup. If you read Holger's web site (http://smartcc.sourceforge.net) he is trying to cleanup EJB transport issues when firwalls are in the way. I hope somebody with more knowledge than me steps up to the plate. I for 1 will be using this stuff.. On Fri, 2002-06-21 at 08:36, Bill Burke wrote: JDK already has built in RMI HTTP tunneling. Why would we need this transport? Here's directions: http://www.dmh2000.com/ApacheTomcatRMI.htm Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Holger Engels Sent: Friday, June 21, 2002 5:00 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] http transport I try to understand, how a http transport can be implemented within jboss .. so what do I need? on the server side: o a connector servlet / extra http deamon, that accepts invocations embedded in http posts. the result of a home invocation is a handle. subsequent invocations (remote interface) contain the handle to identify the target ejb. the servlet is completely stateless. o an mbean service, that manages the servlet / http deamon on the client: o some interceptor (the last one in the chain), that marshalls the invocation as an http post request and demarshalls results / throwables. I call it the 'Transport' o is a special handle implementation required? o usertransaction handling is transparent (part of Invocation)? configuration: o it's the server's job to provide the connector servlet. the servlet doesn't need to be configured. the invocations carry all the information that is required to perform home-/ remote-invocations. o the client will do a lookup first (coded name, declared in the application-client descriptor). it then gets a dynamic proxy passing on the java style invocation to the invocation handler. the invocation handler feeds the invocation into the interceptor chain. this chain has to be configured somehow (during deployment of the application-client jar). o afaik there's no application client deployment at the moment and the client side interceptors are configured from the server, right? so what makes up the whole interceptor chain? we distinguish: o client side interceptors o server side interceptors (synchronization, pooling / caching, security) o symmetric interceptors (encryption / decryption for instance) the overall configuration of the (ordered) interceptor chain is made of component aspects and reference aspects. transport is just another aspect of the reference. authentication: in the smartcc, using the http transport requires a http login module (basic/digest auth) to be configured. the authentication task is performed by the servlet container. the container cares about setting up the security association. dain asked for an http plugin for jndi. my question: why do I need the server side's jndi content on the client if I don't lookup homes? what does a java client need beside what's configured in the application client descriptor. what am i missing? holger --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss
RE: [JBoss-dev] http transport
Holger, in JBoss 3.0 we have client interceptors, and pluggable transports. The invocation has been totally decoupled from the EJB container. The EJB Container is now just an MBean and all EJB invocations go across the JMX bus. JBoss 3.1 takes things a bit further. In 3.1 you can now define multiple invokers (transports) per EJB container. So an EJB container can be configured to receive requests from RMI, IIOP, SOAP, HTTP, whatever all at the same time. We'll want to hook your HTTP invoker into this architecture. The files and java packages you'll want to look at are as follows, There's also a detail email I sent out 2 months ago that is copied later on in this email: In server module: Packages org.jboss.invocation, org.jboss.proxy org.jboss.invocation.jrmp.server.JRMPInvoker.java is the main entry point on the server side. It accepts invocation requests and routes them across the JMX bus. I think your HTTP POST protocol can be very simple. Just marshall an Invocation and send it across the wire. The JRMPInvoker is stateless and can route any Invocation. For the client side, you'll need to implement a new org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy. This is really the Transport on the client side. You'll also need to implement a org.jboss.proxy.ejb.ProxyFactory. The JBoss clustering can be used as an example since it has extended JRMPInvokerProxy, ProxyFactory and has its own Invoker. see the cluster module. All classes under the above packages. What sucks is that even if you've implemented this stuff, its not very helpful because JNDI does not have pluggable transports. This is something we wanted to work on for JBoss 4.0. Make JNDI an MBean, as well as rewrite client-interceptors/server-interceptors/proxy factories and their configurations all in terms of MBeans and MBean invocations and MBean xml descriptors. This is the major vision Marc has put forth. To make JBoss a Unified architecture that can describe any distributed object framework as a set of MBeans and MBean configurations. The classes are there, the configuration isn't. But, just get the HTTP invoker with EJB working, then we can work on JNDI later. Here's what I wrote back in April on the subject: JBoss 3.1 (CVS-HEAD) now has the ability to bind multiple invokers per EJB container. This means that one EJB container can serve up requests from IIOP, RMI, SOAP, your-protocol-here all at the same time. Also, if your EJBs are configured correctly in jboss.xml Beans accessed through bean ejb-refs will automatically and transparently use the correct protocol. Meaning, if you start off on IIOP, you'll stay on IIOP (unless the call is colocated). There have been some fundamental changes to configuration: 1. container-configuration no longer has client-interceptors defined within it. A new invoker to proxy factory binding has the client-interceptor definitions for each proxyfactory/invoker binding combo. 2. Also, container-invoker configuration tag has been removed from container-configuration. 3. jdk1.2.2 support has been removed from standardjboss.xml 4. THere are no more Clustered container-configuration definitions in standardjboss.xml. They're no longer needed Let's take a look at the new standardjboss.xml: jboss invoker-proxy-bindings invoker-proxy-binding nameentity-rmi-invoker/name invoker-mbeanjboss:service=invoker,type=jrmp/invoker-mbean proxy-factoryorg.jboss.proxy.ejb.ProxyFactory/proxy-factory proxy-factory-config client-interceptors home interceptororg.jboss.proxy.ejb.HomeInterceptor/interceptor interceptororg.jboss.proxy.SecurityInterceptor/interceptor interceptororg.jboss.proxy.TransactionInterceptor/interceptor interceptororg.jboss.invocation.InvokerInterceptor/interceptor /home bean interceptororg.jboss.proxy.ejb.EntityInterceptor/interceptor interceptororg.jboss.proxy.SecurityInterceptor/interceptor interceptororg.jboss.proxy.TransactionInterceptor/interceptor interceptororg.jboss.invocation.InvokerInterceptor/interceptor /bean list-entity interceptororg.jboss.proxy.ejb.ListEntityInterceptor/interceptor interceptororg.jboss.proxy.SecurityInterceptor/interceptor interceptororg.jboss.proxy.TransactionInterceptor/interceptor interceptororg.jboss.invocation.InvokerInterceptor/interceptor /list-entity /client-interceptors /proxy-factory-config /invoker-proxy-binding ... The invoker-proxy-binding is a description of the binding between an Invoker and the EJB proxy factory. It also contains the Proxy Factory's configuration. For RMI ejbs, proxy-factory-config contains a list of client-interceptors. If you look at the message-driven-bean invoker-proxy-factory binding, you'll see that the proxy-factory-config contains configuration for setting up JMS. invoker-proxy-binding
[JBoss-dev] GO Vote and tell your story
InternetWeek is collection stories. Put in a good word for JBoss and tell your story. http://www.internetweek.com/question02/question052802.htm ___ Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] adding multicast route on Win2k
Werner, I'm dumb, but not that dumb Yes, I know how to get the help page, but what do you type in to add a multicast route? Again, I'm pretty dumb -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Werner Ramaekers Sent: Wednesday, June 12, 2002 10:45 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] adding multicast route on Win2k Bill, by issuing route on the command line in Win2K you get the equivalent of a help page : C:\WINNT\system32route Manipulates network routing tables. ROUTE [-f] [-p] [command [destination] [MASK netmask] [gateway] [METRIC metric] [IF interface] -f Clears the routing tables of all gateway entries. If this is used in conjunction with one of the commands, the tables are cleared prior to running the command. -p When used with the ADD command, makes a route persistent across boots of the system. By default, routes are not preserved when the system is restarted. Ignored for all other commands, which always affect the appropriate persistent routes. This option is not supported in Windows 95. command One of these: PRINT Prints a route ADD Addsa route DELETEDeletes a route CHANGEModifies an existing route destination Specifies the host. MASK Specifies that the next parameter is the 'netmask' value. netmask Specifies a subnet mask value for this route entry. If not specified, it defaults to 255.255.255.255. gateway Specifies gateway. interfacethe interface number for the specified route. METRIC specifies the metric, ie. cost for the destination. All symbolic names used for destination are looked up in the network database file NETWORKS. The symbolic names for gateway are looked up in the host name database file HOSTS. If the command is PRINT or DELETE. Destination or gateway can be a wildcard, (wildcard is specified as a star '*'), or the gateway argument may be omitted. If Dest contains a * or ?, it is treated as a shell pattern, and only matching destination routes are printed. The '*' matches any string, and '?' matches any one char. Examples: 157.*.1, 157.*, 127.*, *224*. Diagnostic Notes: Invalid MASK generates an error, that is when (DEST MASK) != DEST. Example route ADD 157.0.0.0 MASK 155.0.0.0 157.55.80.1 IF 1 The route addition failed: The specified mask parameter is invalid. (Destination Mask) != Destination. Examples: route PRINT route ADD 157.0.0.0 MASK 255.0.0.0 157.55.80.1 METRIC 3 IF 2 destination^ ^mask ^gateway metric^^ Interface^ interfacethe interface number for the specified route. METRIC specifies the metric, ie. cost for the destination. All symbolic names used for destination are looked up in the network database file NETWORKS. The symbolic names for gateway are looked up in the host name database file HOSTS. If the command is PRINT or DELETE. Destination or gateway can be a wildcard, (wildcard is specified as a star '*'), or the gateway argument may be omitted. If Dest contains a * or ?, it is treated as a shell pattern, and only matching destination routes are printed. The '*' matches any string, and '?' matches any one char. Examples: 157.*.1, 157.*, 127.*, *224*. Diagnostic Notes: Invalid MASK generates an error, that is when (DEST MASK) != DEST. Example route ADD 157.0.0.0 MASK 155.0.0.0 157.55.80.1 IF 1 The route addition failed: The specified mask parameter is invalid. (Destination Mask) != Destination. Examples: route PRINT route ADD 157.0.0.0 MASK 255.0.0.0 157.55.80.1 METRIC 3 IF 2 destination^ ^mask ^gateway metric^^ Interface^ Werner Bill Burke wrote: Anybody know how to add a multicast route on Win2k/XP? Here's a similar command on Linux: $ route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0 I need this for the Clustering Troubleshooting guide. Thanks, Bill ___ Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- -- ir. Werner Ramaekers Enterprise Java Solutions Architect - Shift@ Sun Certified Java Programmer May the source be with you. mailto:[EMAIL PROTECTED] http
[JBoss-dev] adding multicast route on Win2k
Anybody know how to add a multicast route on Win2k/XP? Here's a similar command on Linux: $ route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0 I need this for the Clustering Troubleshooting guide. Thanks, Bill ___ Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Invocation keys are error prone
Scott, we need to get JBossPerf running. I started porting CSIRO's JBoss ECPerf. I got it running with Oracle sort of. I still need to tweak the Oracle configuration. I haven't been able to get back to this for awhile since I've been busy. I won't be able to get back to it for a couple of weeks, so if anybody wants to take a crack at let me know, otherwise, I'll pick it up in a little while. Bill ___ Multimillion Dollar Computer Inventory Live Webcast Auctions Thru Aug. 2002 - http://www.cowanalexander.com/calendar ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: [JBoss-user] CD Subscription Update
Oh and one more thing about the installer. It is a bit more than a glorified zip. You can decide what components are installed(Clustering, IIOP, JMS, etc.) and it will build the appropriate configuration. We will be expanding the features of this installer over the next few releases of the CD subscription. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Marius Kotsbak Sent: Tuesday, June 11, 2002 4:56 AM To: [EMAIL PROTECTED] Cc: Jboss-Dev Subject: [JBoss-dev] Re: [JBoss-user] CD Subscription Update I got the cd today, and tried the graphical installer, but it does'nt seem to work. Error: sh jboss.bin : command not found : command not found Preparing to install... : command not found jboss.bin: line 84: syntax error near unexpected token `elif' 'boss.bin: line 84: `elif [ -x /usr/bin/ls ]; then The win-version also didn't work when I tried in wine, but that could be wine's fault. It's not that I need the graphical installer, I prefer copying the files manually. Does it have any other features, like configuring? But the people that want it, should get a installer that works... On Thu, 2002-05-30 at 18:45, Bill Burke wrote: Hi All, After a bit of market research we've dropped the CD subscription price to $500. $500 includes: * 1 hour support. * 4 CDs over 1 year span * Document subscription * graphical installer Help support JBoss development. Regards, Bill Burke JBossGroup ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBoss/Websphere/Weblogic feature comparison
I remember somebody doing research on this. Can anybody help here? Bill ___ Multimillion Dollar Computer Inventory Live Webcast Auctions Thru Aug. 2002 - http://www.cowanalexander.com/calendar ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: [JBoss-user] Four more to go ... @ JDJ Best App Server
Wahoo! We're in 4th place now! Just went ahead Borland. Next lets shoot for Oracle -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tobias Frech Sent: Wednesday, June 05, 2002 10:16 AM To: [EMAIL PROTECTED] Subject: [JBoss-user] Four more to go ... @ JDJ Best App Server Hi! JBoss has been constantly catching up in this vote for the last days. The actual stats look like this: IBM WebSphere Application Server 4.0 - 3412 BEA WebLogic Server 6.1 - 3060 Oracle9i Application Server - 2692 Borland Enterprise Server - 1304 JBoss - 1300 [http://www.sys-con.com/java/readerschoice2002/liveupdate.cfm?cat= AppServer] That's only four (4!) votes to get JBoss from the 5th to the 4th place in this vote. Now would be a perfect time to take these 10 minutes to cast your vote at http://www.sys-con.com/java/readerschoice2002/nominationform.cfm if you didn't do it already. Ciao, Tobias PS: You need to go through all the questions and submit a valid email address at the end. But it still doesn't take more time than downloading JBoss3 :) ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Problems using UserTransaction
This may or may not workgive it a try and tell me if it works.
Use the TransactionManager directly.
void someEJBMethod()
{
InitialContext ctx = new InitialContext();
TransactionManager tm =
(TransactionManager)ctx.lookup(java:/TransactionManager);
Transaction tx = tm.getTransaction();
//...
//... Create your threads and pass in the tx as a parameter
}
// Thread code
void run()
{
tm.resume(this.tx);
//... do your stuff
}
Am I making sense?
Regards,
Bill Burke
JBossGroup
---
Don't forget to vote
for JBoss for the JDJ Awards!
http://www.sys-con.com/java/readerschoice2002/nominationform.cfm
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
Patrícia Soares Canela
Sent: Monday, June 03, 2002 2:18 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Problems using UserTransaction
OK!
So, do you know any way to implement cuncurrent processing with EJBs.
If I cannot use threads, how can I perform the execution of
several services
in the same transaction?
-Original Message-
From: David Jencks [mailto:[EMAIL PROTECTED]]
Sent: segunda-feira, 3 de Junho de 2002 19:04
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Problems using UserTransaction
You can't use your own threads in ejbs. It's against spec and
doesn't work
with transactions, as you have discovered.
david jencks
On 2002.06.03 13:37:54 -0400 Patrícia Soares Canela wrote:
Hi there!
I have this EJB, bean managed wich controls client's request and invokes
other beans.
I'm lauching threads to invilke these other beans.
Supose that I have this transaction that needs to resort to three
diferent
beans; supose that the second bean fails and transaction must be rolled
back.
Well, this isn´t happening! In fact, transaction is rolled back, but all
previous data has been persisted in database.
Is it because of using threads or is it something in transactions that
I´m
doing wrong.
Thank you for your atention
Patrícia
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
