[JBoss-dev] 3.2.0RC1 release on hold
The 3.2.0RC1 release is on hold until the stale cvs locks are cleared out of the repository. I have been waiting for 3 hours now to synch a snapshot so I could build and tag the release, but this lock it holding up the show: ... cvs server: [00:34:44] waiting for anoncvs_jboss's lock in /cvsroot/jboss/jmx/src/main/javax/management cvs server: [00:35:14] waiting for anoncvs_jboss's lock in /cvsroot/jboss/jmx/src/main/javax/management I have requested it be removed. Scott Stark Chief Technology Officer JBoss Group, LLC --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-667341 ] Initial Session AUTH failure
Bugs item #667341, was opened at 2003-01-13 19:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=667341&group_id=22866 Category: JBossWeb Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Peter Luttrell (objec) Assigned to: Nobody/Anonymous (nobody) Summary: Initial Session AUTH failure Initial Comment: JBoss3.0.5 - release with jdk1.4.1_01 Before this I was using JBoss3.0.5RC1 and this problem did NOT occur. After I startup JBoss or redeploy my ear, which contains a war which uses authentication (my login module), the very first session that attempts to authenticate fails. If i try it again in the same browser window it still fails. If i open a new window (new sesison id), it works. This happens every time i deploy. I have tried opening a new browser after i deploy but the problem still happens. This is a problem introduced between JBoss3.0.5-RC1 and 3.0.5-Release. -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-01-14 09:53 Message: Logged In: YES user_id=44062 This issue is not so much security related, but URL processing of path parameters like ;jsessionid. If you are writing your webapp correctly, you will be rewriting your URLs. If the server has not seen a cookie from the client it will insert such a path parameter. The problem is that path parameters are only being correctly decoded on the first request of a persistent connection. For all other requests, they are being seen as part of the URL rather than as something extra. Thus my own test harnesses for this past without a problem as they were the first request on a connection. Webapps that do not rewrite URLs (many) or who have apps that create a session before authetication takes place - will probably not be effective. So it's not totally broken - just significantly so. I'm done a fixed release of Jetty (4.2.5) and Jules is lined up to make a replacement jbossweb.sar -- Comment By: Scott M Stark (starksm) Date: 2003-01-14 01:27 Message: Logged In: YES user_id=175228 So is security totally broken in the 3.0.5 release? What is the exact issue so I can add a testcase for this? -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-01-13 22:45 Message: Logged In: YES user_id=44062 This is an optimization bug introduced in JBossWeb. URL path parameters, such as ;jsessionid are not handled correctly for persistent connections. A fix is on it's way -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=667341&group_id=22866 --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] My fuck up
thank you, this will sum up my expiriences over the last three years with these php guys, they have to taken seriously, because of their market position ... bax > Von: "marc fleury" <[EMAIL PROTECTED]> > Antworten an: [EMAIL PROTECTED] > Datum: Mon, 13 Jan 2003 17:53:48 -0500 > An: "Jboss-Development@Lists. Sourceforge. Net" > <[EMAIL PROTECTED]> > Cc: "'JBoss Group'" <[EMAIL PROTECTED]> > Betreff: [JBoss-dev] My fuck up > > I got nuked by postnuke. > > The stuff just doesn't scale. Either that or we are doing something > really wrong. In any case the site is UN-USABLE. We will continue with > our port of postnuke and see if we can come with a real forums/nukes on > jboss project. > > My bad. I make mistakes, I should have tested this under heavier load, > PHP plain doesn't work as is. We will get the website back to its > former state. Bear with us. > > A humbler, > > marcf > > xx > Marc Fleury, Ph.D. > President, Founder > JBoss Group, LLC > xx > > > > --- > This SF.NET email is sponsored by: FREE SSL Guide from Thawte > are you planning your Web Server Security? Click here to get a FREE > Thawte SSL guide and find the answers to all your SSL security issues. > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re[2]: [JBoss-dev] My fuck up
you can explain that by the fact that 1.they have no cache (already said) 2.each invocation reload from the DB what it needs !!! for instance with permissions, if a user come and PN needs to check permissions, then it will retrieve permission from DB, serve the user and then these data are throwed away if you count the number of table PN needs, you understand quickly the problem. julien HB> thank you, this will sum up my expiriences over the last three years with HB> these php guys, they have to taken seriously, because of their market HB> position ... HB> bax >> Von: "marc fleury" <[EMAIL PROTECTED]> >> Antworten an: [EMAIL PROTECTED] >> Datum: Mon, 13 Jan 2003 17:53:48 -0500 >> An: "Jboss-Development@Lists. Sourceforge. Net" >> <[EMAIL PROTECTED]> >> Cc: "'JBoss Group'" <[EMAIL PROTECTED]> >> Betreff: [JBoss-dev] My fuck up >> >> I got nuked by postnuke. >> >> The stuff just doesn't scale. Either that or we are doing something >> really wrong. In any case the site is UN-USABLE. We will continue with >> our port of postnuke and see if we can come with a real forums/nukes on >> jboss project. >> >> My bad. I make mistakes, I should have tested this under heavier load, >> PHP plain doesn't work as is. We will get the website back to its >> former state. Bear with us. >> >> A humbler, >> >> marcf >> >> xx >> Marc Fleury, Ph.D. >> President, Founder >> JBoss Group, LLC >> xx >> >> >> >> --- >> This SF.NET email is sponsored by: FREE SSL Guide from Thawte >> are you planning your Web Server Security? Click here to get a FREE >> Thawte SSL guide and find the answers to all your SSL security issues. >> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en >> ___ >> Jboss-development mailing list >> [EMAIL PROTECTED] >> https://lists.sourceforge.net/lists/listinfo/jboss-development >> HB> --- HB> This SF.NET email is sponsored by: FREE SSL Guide from Thawte HB> are you planning your Web Server Security? Click here to get a FREE HB> Thawte SSL guide and find the answers to all your SSL security issues. HB> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en HB> ___ HB> Jboss-development mailing list HB> [EMAIL PROTECTED] HB> https://lists.sourceforge.net/lists/listinfo/jboss-development -- Best regards, julienmailto:[EMAIL PROTECTED] ___ 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: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Thaks, and may i am of a little help? was: Re: Re[2]: [JBoss-dev]My fuck up
thanks you julien for your explanation - now i see clearly ... ;-) bax > Von: julien viet <[EMAIL PROTECTED]> > Antworten an: [EMAIL PROTECTED] > Datum: Tue, 14 Jan 2003 14:52:35 +0100 > An: Holger Baxmann <[EMAIL PROTECTED]> > Betreff: Re[2]: [JBoss-dev] My fuck up > > you can explain that by the fact that > > 1.they have no cache (already said) > > 2.each invocation reload from the DB what it needs !!! > for instance with permissions, if a user come > and PN needs to check permissions, then it will retrieve > permission from DB, serve the user and then these data > are throwed away > > if you count the number of table PN needs, you understand > quickly the problem. > > julien > > HB> thank you, this will sum up my expiriences over the last three years with > HB> these php guys, they have to taken seriously, because of their market > HB> position ... > > HB> bax > >>> Von: "marc fleury" <[EMAIL PROTECTED]> >>> Antworten an: [EMAIL PROTECTED] >>> Datum: Mon, 13 Jan 2003 17:53:48 -0500 >>> An: "Jboss-Development@Lists. Sourceforge. Net" >>> <[EMAIL PROTECTED]> >>> Cc: "'JBoss Group'" <[EMAIL PROTECTED]> >>> Betreff: [JBoss-dev] My fuck up >>> >>> I got nuked by postnuke. >>> >>> The stuff just doesn't scale. Either that or we are doing something >>> really wrong. In any case the site is UN-USABLE. We will continue with >>> our port of postnuke and see if we can come with a real forums/nukes on >>> jboss project. >>> >>> My bad. I make mistakes, I should have tested this under heavier load, >>> PHP plain doesn't work as is. We will get the website back to its >>> former state. Bear with us. >>> >>> A humbler, >>> >>> marcf >>> >>> xx >>> Marc Fleury, Ph.D. >>> President, Founder >>> JBoss Group, LLC >>> xx >>> >>> >>> >>> --- >>> This SF.NET email is sponsored by: FREE SSL Guide from Thawte >>> are you planning your Web Server Security? Click here to get a FREE >>> Thawte SSL guide and find the answers to all your SSL security issues. >>> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en >>> ___ >>> Jboss-development mailing list >>> [EMAIL PROTECTED] >>> https://lists.sourceforge.net/lists/listinfo/jboss-development >>> > > > > HB> --- > HB> This SF.NET email is sponsored by: FREE SSL Guide from Thawte > HB> are you planning your Web Server Security? Click here to get a FREE > HB> Thawte SSL guide and find the answers to all your SSL security issues. > HB> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en > HB> ___ > HB> Jboss-development mailing list > HB> [EMAIL PROTECTED] > HB> https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > -- > Best regards, > julienmailto:[EMAIL PROTECTED] > > ___ > 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: FREE SSL Guide from Thawte > are you planning your Web Server Security? Click here to get a FREE > Thawte SSL guide and find the answers to all your SSL security issues. > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re[4]: [JBoss-dev] URLConnection and opened files
I'm a bit confused. I wrote a simple standalone test. - main public static void main(String[] args) throws Exception { // set handler pkgs System.out.println("java.protocol.handler.pkgs: " + System.getProperty("java.protocol.handler.pkgs")); URL url = new URL("file", null, args[0]); System.out.println("url: " + url); URLConnection urlCon = url.openConnection(); System.out.println("connection class: " + urlCon.getClass().getName()); url = new URL("other", null, args[0]); System.out.println("url: " + url); urlCon = url.openConnection(); System.out.println("connection class: " + urlCon.getClass().getName()); } - run java -Djava.protocol.handler.pkgs=org.avoka.test.files.protocol -classpath %cp% org.avoka.test.files.FilesTest build.xml - output java.protocol.handler.pkgs: org.avoka.test.files.protocol url: file:build.xml connection class: sun.net.www.protocol.file.FileURLConnection url: other:build.xml connection class: org.avoka.test.files.protocol.other.OtherURLConnection I do have org.avoka.test.files.protocol.file.Handler and org.avoka.test.files.protocol.file.FileURLConnection on the classpath. My file.Handler isn't called. Am I missing something? This same thing happens with JBoss-3.2 and HEAD but not JBoss-3.0 (my 3.0 is not up to date). JDK1.3.1_05, J2SDK1.4.0 Win2K Thanks, alex --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-664635 ] Too many open files causes JBoss 3.0 to crash
Bugs item #664635, was opened at 2003-01-08 15:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664635&group_id=22866 Category: None Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Paul Morris (rpmorris) Assigned to: Scott M Stark (starksm) Summary: Too many open files causes JBoss 3.0 to crash Initial Comment: OS: Linux 7.1 JDK: Occurs with Sun j2SDK 1.4.0 and IBM Java2 1.4 Occurs on JBoss v 3.0.0 & 3.0.4 The JVM process ends with the message "too many open files". It can be recreated simply by opening and closing files for a long enough period of time . Once a file handle is allocated it doesn't appear to go away. I've attached the console output as requestd in the bug report instructions. I have captured the output from the lsof command showing system file handles at various stages of my JBoss app operation. This output indicates that file handles don't go way even when the files are closed or deleted. I can send this lsof output to whoever investigates this problem (the web form only allows one file to be attached to the bug report). A number of developers have reported similar problems in the forum. For an example see http://www.jboss.org/forums/thread.jsp? forum=61&thread=24687 -- >Comment By: Paul Morris (rpmorris) Date: 2003-01-14 10:12 Message: Logged In: YES user_id=683772 I wrote a testcase as suggested and discovered that the code didn't cause a file handle leak either in the JVM alone or in the JBoss environment. On further investigation, I discovered that a 3rd party, native code library we are using was failing to close a file which was the cause of our problem. I never really understood how JBoss could be the source of the problem, but I was out of ideas when I wrote the bug. Writing the test case jarred my brain enough to think of other possible causes. Thanks. As far as my case is concerned this problem is resolved. -- Comment By: Scott M Stark (starksm) Date: 2003-01-10 14:31 Message: Logged In: YES user_id=175228 That should be fine. -- Comment By: Michael Kloster (mikekloster) Date: 2003-01-10 14:03 Message: Logged In: YES user_id=685435 Scott M Stark, You wrote: "If you have a sample program that runs in a standalone VM fine, but fails when deployed to JBoss using the same VM then submit that." I have a a sample web application that can reproduce this problem (over time). The application consists only of JSP pages and images and has no dynamic content (unless you count the use of server side jsp includes). If I can show that this web application runs fine under Tomcat 4.x alone or JBoss 2.4, but does have the cause the submitters problem in JBoss 3.0.x will that satify your above stated requirement that this must be shown, in fact, to be a JBoss issue? If so, I will take the time to create and document this senario for you. thank you for your time and effort. Jboss is a wonderful product! Michael Kloster -- Comment By: Paul Morris (rpmorris) Date: 2003-01-10 11:18 Message: Logged In: YES user_id=683772 Of course, you're right Scott. I didn't provide nearly enough information. My first hunch was that this is a JVM problem so I switch from the Sun to the IBM JVM. It occurs with both the Sun and the IBM JVM (versions 1.4). Perhaps they share some common code, I don't know. I checked the Sun and IBM sites and no such bug has been reported for either JVM.That said, I'll will right a test case, as Scott suggested. In the meantime, here are more details of what my JBoss app is doing. I have a stateful session bean which opens a temporary file during its processing. The stream is declared transient. The stream is closed on passivate and reopened on activate. At the end of the bean's life the stream is closed and the temp file is deleted. The code releases it reference to the File instance, so it can be garbage collected. The file handles to the deleted files just don't go away (according to the lsof command output). Every thread in the process has a handle to every deleted file. I don't know if this helps, at this point. I'll report back with the results of the JVM test you suggested. -- Comment By: Scott M Stark (starksm) Date: 2003-01-08 16:16 Message: Logged In: YES user_id=175228 How is the fact that opening and closing files files still leaves the descriptor open a JBoss problem? We don't do anything to intercept filesystem calls so the issue seems VM related. If you have a sample program that runs in a standalone VM fine, but fails when deployed to JBoss using the same
[JBoss-dev] [ jboss-Bugs-667825 ] Add NOPAUSE option to build.bat files
Bugs item #667825, was opened at 2003-01-14 16:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=667825&group_id=22866 Category: Build System Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rod Burgett (rodburgett) Assigned to: Jason Dillon (user57) Summary: Add NOPAUSE option to build.bat files Initial Comment: Unlike the run.bat and shutdown.bat files, the build.bat files end with an unconditional pause command. Replacing the pause line with if "%NOPAUSE%" == "" pause will not change the default behavior of the build.bat files, but will make them easier to combine with ant and other .bat files to automate common processes. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=667825&group_id=22866 --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JNuke dev
hi folks, JNuke adventure has started. After analysis of PostNuke I've began the development, still early though. I keep everything that's good in PostNuke and throw all the shit away : modules, blocks, permissions system, url system and themes. JMX is used for PostNuke components : themes, modules and blocks are all JMX mbeans. Here are my reasons : A : general 1.we need a component structure, why not JMX ? after all another forum say that's lightweight. 2.theses components do not have to scale, i.e the number of modules, blocks and themes is very small. B : for modules 1.Ability to deploy/undeploy when application is running. 2.It's easy to deploy additional modules as a separate deployment and have them register in the same registry. 3.PostNuke is all about invoking module functions. Url like index.php?module=User&op=register means that the PN must call the method register on module User. For me that means that the servlet retrieves the mbean under the name jnuke:publicmodules:name=User and invokes the operation register(). 4.When a module is installed and configured it plug block mbeans in the JMX. C : for blocks, same reasons as above except 3 and 4 as invocation is typed for 3. D : for themes, same reasons as above except 3 and 4 as invocation is typed for 3. EJB are used for the model : UserEJB, GroupEJB, UserPermissionEJB, UserGroupEJB will be CMP 2.0 beans. We'll use local invocations and same trick as in forum to make them faster. Plus more beans. Each module is made of : 1.ModuleMBean : is the module itself, does not provide fucntionnalities, it's used to manager the PublicModule. Main operations are lifecycle (initialize, activate, unactivate, uninitialize) 2.PublicModuleMBean : is created when ModuleMBean activates and is responsible for serving requests. The MBean is dynamic and operations with no arguments and no returns are served. It's up to the module to do as he wants : if he wants MVC it can, it it wants to mix HTML and code, it can. First modules won't be MVC as they simply don't need. It's up to the model to have the persistence mecanisms it wants. First modules will use EJB. With lifecycle operations, each module can install itself, for instance : a ModuleMBean is plugged : 1.module configuration, setup of variables 2.initialize : module can creates table, deploy EJB, plugs block. 3.activate : module then go to block admin and creates instances of blocks (if module use blocks), display them on the page. Each block is made of : 1.BlockMBean : manages BlockInstanceMBean. 2.BlockInstanceMBean : is a block instance, it contains a title and a position on web page + 3 operations : display(), edit(), update(). display() : displays the block instance edit() : used to edit the block in block administration update() : used to upate the block in block admin Each them is made of various callbacks that displays HTML on the page. It has to provide location of files like css, gifs, etc... THe first them I did is made of a servlet that register to JMX and the doGet operation serves the files. It's default theme. To make the thing simpler, it will be possible to make theme with JSP because I want to keep post nuke spirit. Ideally, even Module and Blocks could be made as JSP of things like that, that keeps PHP easy to do spirit. I did not thought a lot about permissions. In PostNuke, each module is responsible for checking security. I know that could be done with AOP but I don't know if it's gonna now, later or never :-) One problem is the configuration persistence. I don't know how our JMX implementation is far there. But if there is a restart, all config must be re-done. JMX persistence will save us there. Even though it's plain file and not JDBC. I will check out later (now it's a true mess), but I can say what works : Themes + default theme is done block modules and module invocation. That means that yes, it displays me something that's nice to watch and I can invoke some operations although it's very early. So now, I am going back to code because time matters. julien ___ 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: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Thaks, and may i am of a little help? was: Re: Re[2]: [JBoss-dev] My fuck up
> > you can explain that by the fact that > > > > 1.they have no cache (already said) > > > > 2.each invocation reload from the DB what it needs !!! > > for instance with permissions, if a user come > > and PN needs to check permissions, then it will retrieve permission > > from DB, serve the user and then these data are throwed away The 2 points are the same in EJB. 1- PHP BADLY needs a notion like EJB. Smart Caches. 2- Don't underestimate the power of the underground these guys have an app. We may call them "script kiddies", they have an app, we don't. It is our duty to solidify it and I hope those of you that have expressed interest will be helping Julien in "nukes on jboss". more music less talk marcf --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] can't enlist error on concurrent invocations of resource adapter
(i posted the following to the user list without a response. it was suggested to me by someone with jboss to post to the dev list) hi, in a previous post with subject "[JBoss-user] "can't enlist" error on second pass through resource adapter" i described a problem i was having with multiple, non-concurrent invocations of a resource adapter via a stateless session bean. the responder's suggestion (swapping the order of UserTransaction.begin() and ConnectionFactory.getConnection()) got me past this problem. i still have an outstanding question out as to why this should be required, but we'll leave that as a separate thread. my new problem is that i can't perform multiple, concurrent invocations of the resource adapter. during the 2nd call to ConnectionFactory.getConnection(), i get the "Can't enlist - already a tx!" error. in case it's helpful, this is the same error i got before i flipped the order of UserTransaction.begin() and ConnectionFactory.getConnection(). i put some comments in the EJB method that invokes the resource adapter to help me track down what state caused the problem. i also threw in a sleep call to assist as well. same environment as in my previous post, which i'll repeat here: i'm using jboss 3.0.4 with tomcat 4.1.12. my jdk is 1.3.1.06. platform is w2kp sp3. the resource adapter supports XA. res-sharing-scope is set to Unshareable in the ejb-jar.xml file of the EJB that uses the resource adapter. res-sharing-scope of Shareable causes other problems that i'm currently trying to debug. i've found minimal documentation on res-sharing-scope - perhaps the Unshareable setting is the problem? this use case works fine under oc4j 9.0.3 and TeS 7.3, albeit without res-sharing-scope set. any assistance would be appreciated. i'm trying to understand the feasibility/cost of a port of our resource adapter to jboss - an inability to use the resource adapter in a concurrent fashion would likely prevent us from using jboss. thanks. -mike ejb code snippets: javax.resource.cci.ConnectionFactory conFac = (javax.resource.cci.ConnectionFactory) ctx.lookup ("java:comp/env/HPIARM");System.out.println("getting connection"); cx = conFac.getConnection(); System.out.println("got connection"); tran = (UserTransaction) context.getUserTransaction(); System.out.println("beginning transaction"); tran.begin(); System.out.println("begun transaction"); try { Thread.sleep(5000); } catch (InterruptedException ie) { } // do some work on cs via Interaction interface tran.commit(); System.out.println("commited transaction"); cx.close(); System.out.println("closed connection"); output in server.log: 2003-01-10 13:31:18,286 INFO [STDOUT] getting connection2003-01-10 13:31:18,286 INFO [STDOUT] got connection2003-01-10 13:31:18,286 INFO [STDOUT] beginning transaction2003-01-10 13:31:18,306 INFO [STDOUT] begun transaction2003-01-10 13:31:18,406 INFO [STDOUT] getting connection2003-01-10 13:31:18,436 WARN [org.jboss.resource.connectionmanager.XATxConnectionManager$XAConnectionEventListener] in Enlisting tx, illegal state: TransactionImpl:XidImpl [FormatId=257, GlobalId=fcmgrove//8, BranchQual=]2003-01-10 13:31:18,436 ERROR [STDERR] java.lang.IllegalStateException: Can't enlist - already a tx!2003-01-10 13:31:18,446 ERROR [STDERR] at org.jboss.resource.connectionmanager.XATxConnectionManager$XAConnectionEventListener.enlist(XATxConnectionManager.java:250)2003-01-10 13:31:18,446 ERROR [STDERR] at org.jboss.resource.connectionmanager.XATxConnectionManager.managedConnectionReconnected(XATxConnectionManager.java:202)2003-01-10 13:31:18,446 ERROR [STDERR] at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:534)2003-01-10 13:31:18,466 ERROR [STDERR] at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:814)2003-01-10 13:31:18,466 ERROR [STDERR] at com.hp.ov.activator.resmgr.connector.HPIAConnectionFactory.getConnection(Unknown Source)2003-01-10 13:31:18,476 ERROR [STDERR] at com.hp.ov.activator.resmgr.ejb.ServiceActivationBean.executeService(Unknown Source)2003-01-10 13:31:18,476 ERROR [STDERR] at java.lang.reflect.Method.invoke(Native Method)2003-01-10 13:31:18,476 ERROR [STDERR] at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:660)2003-01-10 13:31:18,486 ERROR [STDERR] at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:186)2003-01-10 13:31:18,486 ERROR [STDERR] at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:107)2003-01-10 13:31:18,486 ERROR [STDERR] at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:144)2003-01-10 13:31:18,496 ERROR [STDE
Re[2]: [JBoss-dev] JNuke dev
I do simply with a ThreadLocal : Page.getPage() and you can output HTML even though have ServletRequest and Response. I do like that because the request thread goes through modules, blocks, and themes and it's a mess that each one pass some parameter when calling another one. julien JH> Julien, JH> JH> Makes sense so far >> 3.PostNuke is all about invoking module functions. >>Url like index.php?module=User&op=register means >>that the PN must call the method register on module User. >>For me that means that the servlet retrieves the mbean >>under the name jnuke:publicmodules:name=User >>and invokes the operation register(). JH> So, how would you pass arguments from the request to the method in the JH> module mbean? Do you plan to just have each method take a hashmap that JH> you have constructed from the request? Knowing that modules may need JH> arguments for performing work, like a URL to an RSS feed or something. JH> Thanks, JH> James JH> --- JH> This SF.NET email is sponsored by: FREE SSL Guide from Thawte JH> are you planning your Web Server Security? Click here to get a FREE JH> Thawte SSL guide and find the answers to all your SSL security issues. JH> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en JH> ___ JH> Jboss-development mailing list JH> [EMAIL PROTECTED] JH> https://lists.sourceforge.net/lists/listinfo/jboss-development -- Best regards, julienmailto:[EMAIL PROTECTED] ___ 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: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JNuke dev
Julien, Makes sense so far > 3.PostNuke is all about invoking module functions. >Url like index.php?module=User&op=register means >that the PN must call the method register on module User. >For me that means that the servlet retrieves the mbean >under the name jnuke:publicmodules:name=User >and invokes the operation register(). So, how would you pass arguments from the request to the method in the module mbean? Do you plan to just have each method take a hashmap that you have constructed from the request? Knowing that modules may need arguments for performing work, like a URL to an RSS feed or something. Thanks, James --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JNuke dev
The only negative comment I have in using JMX is that the PHP community may have a tough time switching over to Nukes on JBoss if you have to have a package structure like a SAR or a WAR. I hate to say it, but does it need to be "dumbed-down" for the PHP community? This type of community needs to be able to edit a JSP and immediately see the change on the webserver. Is it possible to be all JSP based for themes, modules and blocks? You could use a URL fragement and JSP:Include to decide what theme to use. Just a thought. Maybe JMX and such is the way to go. Just want to give you something to think about. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > julien viet > Sent: Tuesday, January 14, 2003 11:31 AM > To: SourceForge.net > Subject: [JBoss-dev] JNuke dev > > > hi folks, > > JNuke adventure has started. > After analysis of PostNuke I've began the development, still early though. > > I keep everything that's good in PostNuke and throw all the shit away : > > modules, blocks, permissions system, url system and themes. > > JMX is used for PostNuke components : themes, > modules and blocks are all JMX mbeans. Here are my reasons : > > A : general > > 1.we need a component structure, why not JMX ? after all >another forum say that's lightweight. > > 2.theses components do not have to scale, i.e the number of modules, >blocks and themes is very small. > > B : for modules > > 1.Ability to deploy/undeploy when application is running. > > 2.It's easy to deploy additional modules as a separate deployment and >have them register in the same registry. > > 3.PostNuke is all about invoking module functions. >Url like index.php?module=User&op=register means >that the PN must call the method register on module User. >For me that means that the servlet retrieves the mbean >under the name jnuke:publicmodules:name=User >and invokes the operation register(). > > 4.When a module is installed and configured it plug >block mbeans in the JMX. > > C : for blocks, same reasons as above except 3 and 4 > as invocation is typed for 3. > > D : for themes, same reasons as above except 3 and 4 > as invocation is typed for 3. > > > EJB are used for the model : > > UserEJB, GroupEJB, UserPermissionEJB, UserGroupEJB will > be CMP 2.0 beans. We'll use local invocations and same trick > as in forum to make them faster. Plus more beans. > > Each module is made of : > > 1.ModuleMBean : is the module itself, does not provide fucntionnalities, > it's used to manager the PublicModule. Main operations are lifecycle > (initialize, activate, unactivate, uninitialize) > > 2.PublicModuleMBean : is created when ModuleMBean activates and is >responsible for serving requests. The MBean is dynamic and operations >with no arguments and no returns are served. > > It's up to the module to do as he wants : if he wants MVC it can, it > it wants to mix HTML and code, it can. First modules won't be MVC > as they simply don't need. > > It's up to the model to have the persistence mecanisms it wants. First > modules will use EJB. With lifecycle operations, each module can install > itself, for instance : > > a ModuleMBean is plugged : > 1.module configuration, setup of variables > 2.initialize : module can creates table, deploy EJB, plugs block. > 3.activate : module > then go to block admin and creates instances of blocks (if module > use blocks), display them on the page. > > Each block is made of : > > 1.BlockMBean : manages BlockInstanceMBean. > 2.BlockInstanceMBean : is a block instance, it contains a title > and a position >on web page + 3 operations : display(), edit(), update(). >display() : displays the block instance >edit() : used to edit the block in block administration >update() : used to upate the block in block admin > > Each them is made of various callbacks that displays HTML on the page. > It has to provide location of files like css, gifs, etc... > THe first them I did is made of a servlet that register to JMX > and the doGet operation serves the files. It's default theme. > To make the thing simpler, it will be possible to make theme with JSP > because I want to keep post nuke spirit. > > Ideally, even Module and Blocks could be made as JSP of things > like that, that keeps > PHP easy to do spirit. > > I did not thought a lot about permissions. In PostNuke, each > module is responsible > for checking security. I know that could be done with AOP but I > don't know if it's > gonna now, later or never :-) > > One problem is the configuration persistence. I don't know how > our JMX implementation > is far there. But if there is a restart, all config must be > re-done. JMX persistence > will save us there. Even though it's plain file and not JDBC. > > I will check out later (now it's a true mess), but I can say what works : > Themes + default theme is
RE: [JBoss-dev] JNuke dev
Also, you can't call it JNuke. You must call it Nukes on Java or something like that. JNuke is trademarked. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Bill > Burke > Sent: Tuesday, January 14, 2003 1:51 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] JNuke dev > > > The only negative comment I have in using JMX is that the PHP > community may > have a tough time switching over to Nukes on JBoss if you have to have a > package structure like a SAR or a WAR. I hate to say it, but does it need > to be "dumbed-down" for the PHP community? This type of > community needs to > be able to edit a JSP and immediately see the change on the webserver. Is > it possible to be all JSP based for themes, modules and blocks? You could > use a URL fragement and JSP:Include to decide what theme to use. > > Just a thought. Maybe JMX and such is the way to go. Just want > to give you > something to think about. > > Bill > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of > > julien viet > > Sent: Tuesday, January 14, 2003 11:31 AM > > To: SourceForge.net > > Subject: [JBoss-dev] JNuke dev > > > > > > hi folks, > > > > JNuke adventure has started. > > After analysis of PostNuke I've began the development, still > early though. > > > > I keep everything that's good in PostNuke and throw all the shit away : > > > > modules, blocks, permissions system, url system and themes. > > > > JMX is used for PostNuke components : themes, > > modules and blocks are all JMX mbeans. Here are my reasons : > > > > A : general > > > > 1.we need a component structure, why not JMX ? after all > >another forum say that's lightweight. > > > > 2.theses components do not have to scale, i.e the number of modules, > >blocks and themes is very small. > > > > B : for modules > > > > 1.Ability to deploy/undeploy when application is running. > > > > 2.It's easy to deploy additional modules as a separate deployment and > >have them register in the same registry. > > > > 3.PostNuke is all about invoking module functions. > >Url like index.php?module=User&op=register means > >that the PN must call the method register on module User. > >For me that means that the servlet retrieves the mbean > >under the name jnuke:publicmodules:name=User > >and invokes the operation register(). > > > > 4.When a module is installed and configured it plug > >block mbeans in the JMX. > > > > C : for blocks, same reasons as above except 3 and 4 > > as invocation is typed for 3. > > > > D : for themes, same reasons as above except 3 and 4 > > as invocation is typed for 3. > > > > > > EJB are used for the model : > > > > UserEJB, GroupEJB, UserPermissionEJB, UserGroupEJB will > > be CMP 2.0 beans. We'll use local invocations and same trick > > as in forum to make them faster. Plus more beans. > > > > Each module is made of : > > > > 1.ModuleMBean : is the module itself, does not provide > fucntionnalities, > > it's used to manager the PublicModule. Main operations are lifecycle > > (initialize, activate, unactivate, uninitialize) > > > > 2.PublicModuleMBean : is created when ModuleMBean activates and is > >responsible for serving requests. The MBean is dynamic and operations > >with no arguments and no returns are served. > > > > It's up to the module to do as he wants : if he wants MVC it can, it > > it wants to mix HTML and code, it can. First modules won't be MVC > > as they simply don't need. > > > > It's up to the model to have the persistence mecanisms it wants. First > > modules will use EJB. With lifecycle operations, each module > can install > > itself, for instance : > > > > a ModuleMBean is plugged : > > 1.module configuration, setup of variables > > 2.initialize : module can creates table, deploy EJB, plugs block. > > 3.activate : module > > then go to block admin and creates instances of blocks (if module > > use blocks), display them on the page. > > > > Each block is made of : > > > > 1.BlockMBean : manages BlockInstanceMBean. > > 2.BlockInstanceMBean : is a block instance, it contains a title > > and a position > >on web page + 3 operations : display(), edit(), update(). > >display() : displays the block instance > >edit() : used to edit the block in block administration > >update() : used to upate the block in block admin > > > > Each them is made of various callbacks that displays HTML on the page. > > It has to provide location of files like css, gifs, etc... > > THe first them I did is made of a servlet that register to JMX > > and the doGet operation serves the files. It's default theme. > > To make the thing simpler, it will be possible to make theme with JSP > > because I want to keep post nuke spirit. > > > > Ideally, even Module and Blocks could be made as JSP of things > > like that, that keeps > > PHP easy to do sp
RE: [JBoss-dev] JNuke dev
Are we developing this for the PHP community or the Java community? Or more important for the JBoss community? To me it seems that it would depend on who you are targeting for your user base. If you want to target the PHP users to bring them to JBoss, then Bill could be right. If we do not care about the PHP community, we go down the JMX way. I think the PHP community will never want to do anything with JSP. They believe they have what they need to be successful and will continue to innovate in their own circle. For most of the PHP community, what they have built is scalable to their needs. > -Original Message- > From: [EMAIL PROTECTED] [mailto:jboss- > [EMAIL PROTECTED]] On Behalf Of Bill Burke > Sent: Tuesday, January 14, 2003 1:51 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] JNuke dev > > The only negative comment I have in using JMX is that the PHP community > may > have a tough time switching over to Nukes on JBoss if you have to have a > package structure like a SAR or a WAR. I hate to say it, but does it need > to be "dumbed-down" for the PHP community? This type of community needs > to > be able to edit a JSP and immediately see the change on the webserver. Is > it possible to be all JSP based for themes, modules and blocks? You could > use a URL fragement and JSP:Include to decide what theme to use. > > Just a thought. Maybe JMX and such is the way to go. Just want to give > you > something to think about. > > Bill > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of > > julien viet > > Sent: Tuesday, January 14, 2003 11:31 AM > > To: SourceForge.net > > Subject: [JBoss-dev] JNuke dev > > > > > > hi folks, > > > > JNuke adventure has started. > > After analysis of PostNuke I've began the development, still early > though. > > > > I keep everything that's good in PostNuke and throw all the shit away : > > > > modules, blocks, permissions system, url system and themes. > > > > JMX is used for PostNuke components : themes, > > modules and blocks are all JMX mbeans. Here are my reasons : > > > > A : general > > > > 1.we need a component structure, why not JMX ? after all > >another forum say that's lightweight. > > > > 2.theses components do not have to scale, i.e the number of modules, > >blocks and themes is very small. > > > > B : for modules > > > > 1.Ability to deploy/undeploy when application is running. > > > > 2.It's easy to deploy additional modules as a separate deployment and > >have them register in the same registry. > > > > 3.PostNuke is all about invoking module functions. > >Url like index.php?module=User&op=register means > >that the PN must call the method register on module User. > >For me that means that the servlet retrieves the mbean > >under the name jnuke:publicmodules:name=User > >and invokes the operation register(). > > > > 4.When a module is installed and configured it plug > >block mbeans in the JMX. > > > > C : for blocks, same reasons as above except 3 and 4 > > as invocation is typed for 3. > > > > D : for themes, same reasons as above except 3 and 4 > > as invocation is typed for 3. > > > > > > EJB are used for the model : > > > > UserEJB, GroupEJB, UserPermissionEJB, UserGroupEJB will > > be CMP 2.0 beans. We'll use local invocations and same trick > > as in forum to make them faster. Plus more beans. > > > > Each module is made of : > > > > 1.ModuleMBean : is the module itself, does not provide fucntionnalities, > > it's used to manager the PublicModule. Main operations are lifecycle > > (initialize, activate, unactivate, uninitialize) > > > > 2.PublicModuleMBean : is created when ModuleMBean activates and is > >responsible for serving requests. The MBean is dynamic and operations > >with no arguments and no returns are served. > > > > It's up to the module to do as he wants : if he wants MVC it can, it > > it wants to mix HTML and code, it can. First modules won't be MVC > > as they simply don't need. > > > > It's up to the model to have the persistence mecanisms it wants. First > > modules will use EJB. With lifecycle operations, each module can > install > > itself, for instance : > > > > a ModuleMBean is plugged : > > 1.module configuration, setup of variables > > 2.initialize : module can creates table, deploy EJB, plugs block. > > 3.activate : module > > then go to block admin and creates instances of blocks (if module > > use blocks), display them on the page. > > > > Each block is made of : > > > > 1.BlockMBean : manages BlockInstanceMBean. > > 2.BlockInstanceMBean : is a block instance, it contains a title > > and a position > >on web page + 3 operations : display(), edit(), update(). > >display() : displays the block instance > >edit() : used to edit the block in block administration > >update() : used to upate the block in block admin > > > > Each them i
Re[2]: [JBoss-dev] JNuke dev
Bill, first of all PostNuke HTML is closer to servlet than JSP. You don't see often HTML with PHP inside, that's the converse thing. You see functions with echo inside. then yes, I want to do that, at least with JSP : <%@page %> <%! public void register() { } other module functions ... %> Then JSP can be compiled and become a module. Same with Themes and Blocks. I want to do that, don't worry. I try to keep as close to PostNuke spirit as possible. julien BB> The only negative comment I have in using JMX is that the PHP community may BB> have a tough time switching over to Nukes on JBoss if you have to have a BB> package structure like a SAR or a WAR. I hate to say it, but does it need BB> to be "dumbed-down" for the PHP community? This type of community needs to BB> be able to edit a JSP and immediately see the change on the webserver. Is BB> it possible to be all JSP based for themes, modules and blocks? You could BB> use a URL fragement and JSP:Include to decide what theme to use. BB> Just a thought. Maybe JMX and such is the way to go. Just want to give you BB> something to think about. BB> Bill >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED]]On Behalf Of >> julien viet >> Sent: Tuesday, January 14, 2003 11:31 AM >> To: SourceForge.net >> Subject: [JBoss-dev] JNuke dev >> >> >> hi folks, >> >> JNuke adventure has started. >> After analysis of PostNuke I've began the development, still early though. >> >> I keep everything that's good in PostNuke and throw all the shit away : >> >> modules, blocks, permissions system, url system and themes. >> >> JMX is used for PostNuke components : themes, >> modules and blocks are all JMX mbeans. Here are my reasons : >> >> A : general >> >> 1.we need a component structure, why not JMX ? after all >>another forum say that's lightweight. >> >> 2.theses components do not have to scale, i.e the number of modules, >>blocks and themes is very small. >> >> B : for modules >> >> 1.Ability to deploy/undeploy when application is running. >> >> 2.It's easy to deploy additional modules as a separate deployment and >>have them register in the same registry. >> >> 3.PostNuke is all about invoking module functions. >>Url like index.php?module=User&op=register means >>that the PN must call the method register on module User. >>For me that means that the servlet retrieves the mbean >>under the name jnuke:publicmodules:name=User >>and invokes the operation register(). >> >> 4.When a module is installed and configured it plug >>block mbeans in the JMX. >> >> C : for blocks, same reasons as above except 3 and 4 >> as invocation is typed for 3. >> >> D : for themes, same reasons as above except 3 and 4 >> as invocation is typed for 3. >> >> >> EJB are used for the model : >> >> UserEJB, GroupEJB, UserPermissionEJB, UserGroupEJB will >> be CMP 2.0 beans. We'll use local invocations and same trick >> as in forum to make them faster. Plus more beans. >> >> Each module is made of : >> >> 1.ModuleMBean : is the module itself, does not provide fucntionnalities, >> it's used to manager the PublicModule. Main operations are lifecycle >> (initialize, activate, unactivate, uninitialize) >> >> 2.PublicModuleMBean : is created when ModuleMBean activates and is >>responsible for serving requests. The MBean is dynamic and operations >>with no arguments and no returns are served. >> >> It's up to the module to do as he wants : if he wants MVC it can, it >> it wants to mix HTML and code, it can. First modules won't be MVC >> as they simply don't need. >> >> It's up to the model to have the persistence mecanisms it wants. First >> modules will use EJB. With lifecycle operations, each module can install >> itself, for instance : >> >> a ModuleMBean is plugged : >> 1.module configuration, setup of variables >> 2.initialize : module can creates table, deploy EJB, plugs block. >> 3.activate : module >> then go to block admin and creates instances of blocks (if module >> use blocks), display them on the page. >> >> Each block is made of : >> >> 1.BlockMBean : manages BlockInstanceMBean. >> 2.BlockInstanceMBean : is a block instance, it contains a title >> and a position >>on web page + 3 operations : display(), edit(), update(). >>display() : displays the block instance >>edit() : used to edit the block in block administration >>update() : used to upate the block in block admin >> >> Each them is made of various callbacks that displays HTML on the page. >> It has to provide location of files like css, gifs, etc... >> THe first them I did is made of a servlet that register to JMX >> and the doGet operation serves the files. It's default theme. >> To make the thing simpler, it will be possible to make theme with JSP >> because I want to keep post nuke spirit. >> >> Ideally, even Module and Blocks could be made as JSP of thin
[JBoss-dev] [ jboss-Bugs-667341 ] Initial Session AUTH failure
Bugs item #667341, was opened at 2003-01-13 11:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=667341&group_id=22866 Category: JBossWeb Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Peter Luttrell (objec) Assigned to: Nobody/Anonymous (nobody) Summary: Initial Session AUTH failure Initial Comment: JBoss3.0.5 - release with jdk1.4.1_01 Before this I was using JBoss3.0.5RC1 and this problem did NOT occur. After I startup JBoss or redeploy my ear, which contains a war which uses authentication (my login module), the very first session that attempts to authenticate fails. If i try it again in the same browser window it still fails. If i open a new window (new sesison id), it works. This happens every time i deploy. I have tried opening a new browser after i deploy but the problem still happens. This is a problem introduced between JBoss3.0.5-RC1 and 3.0.5-Release. -- >Comment By: Scott M Stark (starksm) Date: 2003-01-14 11:17 Message: Logged In: YES user_id=175228 I have created a servlet that creates a session and that is secured and returns a page with a URL to itself with URL that is encoded to enable URL rewriting. I don't have a problem accessing this servlet on the first attempt when there is no session, or on any subsequent attempt. I have disabled cookies in my browser so I know the URL rewriting is taking place. In the absence of a testcase that demonstrates the problem I can't judge whether this problem warrents a new 3.0.6 release. -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-01-14 01:53 Message: Logged In: YES user_id=44062 This issue is not so much security related, but URL processing of path parameters like ;jsessionid. If you are writing your webapp correctly, you will be rewriting your URLs. If the server has not seen a cookie from the client it will insert such a path parameter. The problem is that path parameters are only being correctly decoded on the first request of a persistent connection. For all other requests, they are being seen as part of the URL rather than as something extra. Thus my own test harnesses for this past without a problem as they were the first request on a connection. Webapps that do not rewrite URLs (many) or who have apps that create a session before authetication takes place - will probably not be effective. So it's not totally broken - just significantly so. I'm done a fixed release of Jetty (4.2.5) and Jules is lined up to make a replacement jbossweb.sar -- Comment By: Scott M Stark (starksm) Date: 2003-01-13 17:27 Message: Logged In: YES user_id=175228 So is security totally broken in the 3.0.5 release? What is the exact issue so I can add a testcase for this? -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-01-13 14:45 Message: Logged In: YES user_id=44062 This is an optimization bug introduced in JBossWeb. URL path parameters, such as ;jsessionid are not handled correctly for persistent connections. A fix is on it's way -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=667341&group_id=22866 --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re[2]: [JBoss-dev] JNuke dev
I want best of both worlds that's one of my main concerns, a user that like doing java will do and a user that want thing as simple as editing a JSP will do. I don't say JMX is the way to go, but if I don't choose that, I will have to mimic parts of it. so ? They have kind of registries for modules, themes and blocks in postnuke : with directories. They have a component model, just function call. JMX provide it and it's possible to have still PHP style directories with JSP or similar things inside. julien BS> Are we developing this for the PHP community or the Java community? Or BS> more important for the JBoss community? To me it seems that it would BS> depend on who you are targeting for your user base. If you want to BS> target the PHP users to bring them to JBoss, then Bill could be right. BS> If we do not care about the PHP community, we go down the JMX way. I BS> think the PHP community will never want to do anything with JSP. They BS> believe they have what they need to be successful and will continue to BS> innovate in their own circle. For most of the PHP community, what they BS> have built is scalable to their needs. >> -Original Message- >> From: [EMAIL PROTECTED] [mailto:jboss- >> [EMAIL PROTECTED]] On Behalf Of Bill Burke >> Sent: Tuesday, January 14, 2003 1:51 PM >> To: [EMAIL PROTECTED] >> Subject: RE: [JBoss-dev] JNuke dev >> >> The only negative comment I have in using JMX is that the PHP BS> community >> may >> have a tough time switching over to Nukes on JBoss if you have to have BS> a >> package structure like a SAR or a WAR. I hate to say it, but does it BS> need >> to be "dumbed-down" for the PHP community? This type of community BS> needs >> to >> be able to edit a JSP and immediately see the change on the webserver. BS> Is >> it possible to be all JSP based for themes, modules and blocks? You BS> could >> use a URL fragement and JSP:Include to decide what theme to use. >> >> Just a thought. Maybe JMX and such is the way to go. Just want to BS> give >> you >> something to think about. >> >> Bill >> >> > -Original Message- >> > From: [EMAIL PROTECTED] >> > [mailto:[EMAIL PROTECTED]]On Behalf Of >> > julien viet >> > Sent: Tuesday, January 14, 2003 11:31 AM >> > To: SourceForge.net >> > Subject: [JBoss-dev] JNuke dev >> > >> > >> > hi folks, >> > >> > JNuke adventure has started. >> > After analysis of PostNuke I've began the development, still early >> though. >> > >> > I keep everything that's good in PostNuke and throw all the shit BS> away : >> > >> > modules, blocks, permissions system, url system and themes. >> > >> > JMX is used for PostNuke components : themes, >> > modules and blocks are all JMX mbeans. Here are my reasons : >> > >> > A : general >> > >> > 1.we need a component structure, why not JMX ? after all >> >another forum say that's lightweight. >> > >> > 2.theses components do not have to scale, i.e the number of BS> modules, >> >blocks and themes is very small. >> > >> > B : for modules >> > >> > 1.Ability to deploy/undeploy when application is running. >> > >> > 2.It's easy to deploy additional modules as a separate deployment BS> and >> >have them register in the same registry. >> > >> > 3.PostNuke is all about invoking module functions. >> >Url like index.php?module=User&op=register means >> >that the PN must call the method register on module User. >> >For me that means that the servlet retrieves the mbean >> >under the name jnuke:publicmodules:name=User >> >and invokes the operation register(). >> > >> > 4.When a module is installed and configured it plug >> >block mbeans in the JMX. >> > >> > C : for blocks, same reasons as above except 3 and 4 >> > as invocation is typed for 3. >> > >> > D : for themes, same reasons as above except 3 and 4 >> > as invocation is typed for 3. >> > >> > >> > EJB are used for the model : >> > >> > UserEJB, GroupEJB, UserPermissionEJB, UserGroupEJB will >> > be CMP 2.0 beans. We'll use local invocations and same trick >> > as in forum to make them faster. Plus more beans. >> > >> > Each module is made of : >> > >> > 1.ModuleMBean : is the module itself, does not provide BS> fucntionnalities, >> > it's used to manager the PublicModule. Main operations are BS> lifecycle >> > (initialize, activate, unactivate, uninitialize) >> > >> > 2.PublicModuleMBean : is created when ModuleMBean activates and is >> >responsible for serving requests. The MBean is dynamic and BS> operations >> >with no arguments and no returns are served. >> > >> > It's up to the module to do as he wants : if he wants MVC it can, BS> it >> > it wants to mix HTML and code, it can. First modules won't be MVC >> > as they simply don't need. >> > >> > It's up to the model to have the persistence mecanisms it wants. BS> First >> > modules will use EJB. With lifecycle operations, each module can >> install >> > itself, for instance : >> > >> >
Re: [JBoss-dev] JNuke dev
Bill, This reminds me of an I deal I has last night (couldn't sleep). I was thinking of the script based MBean support Sacha added, and I thought can we make plain old java work like a scripting language. Here is what I came up with: + The user writes a class BlahService.java + This source file is places in our deployment directory + We run Xdoclet on it to generate the MBean deployment descriptor + We compile the java file + Deploy Java as a scripting language. What do you think? -dain On Tuesday, January 14, 2003, at 12:50 PM, Bill Burke wrote: The only negative comment I have in using JMX is that the PHP community may have a tough time switching over to Nukes on JBoss if you have to have a package structure like a SAR or a WAR. I hate to say it, but does it need to be "dumbed-down" for the PHP community? This type of community needs to be able to edit a JSP and immediately see the change on the webserver. Is it possible to be all JSP based for themes, modules and blocks? You could use a URL fragement and JSP:Include to decide what theme to use. Just a thought. Maybe JMX and such is the way to go. Just want to give you something to think about. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of julien viet Sent: Tuesday, January 14, 2003 11:31 AM To: SourceForge.net Subject: [JBoss-dev] JNuke dev hi folks, JNuke adventure has started. After analysis of PostNuke I've began the development, still early though. I keep everything that's good in PostNuke and throw all the shit away : modules, blocks, permissions system, url system and themes. JMX is used for PostNuke components : themes, modules and blocks are all JMX mbeans. Here are my reasons : A : general 1.we need a component structure, why not JMX ? after all another forum say that's lightweight. 2.theses components do not have to scale, i.e the number of modules, blocks and themes is very small. B : for modules 1.Ability to deploy/undeploy when application is running. 2.It's easy to deploy additional modules as a separate deployment and have them register in the same registry. 3.PostNuke is all about invoking module functions. Url like index.php?module=User&op=register means that the PN must call the method register on module User. For me that means that the servlet retrieves the mbean under the name jnuke:publicmodules:name=User and invokes the operation register(). 4.When a module is installed and configured it plug block mbeans in the JMX. C : for blocks, same reasons as above except 3 and 4 as invocation is typed for 3. D : for themes, same reasons as above except 3 and 4 as invocation is typed for 3. EJB are used for the model : UserEJB, GroupEJB, UserPermissionEJB, UserGroupEJB will be CMP 2.0 beans. We'll use local invocations and same trick as in forum to make them faster. Plus more beans. Each module is made of : 1.ModuleMBean : is the module itself, does not provide fucntionnalities, it's used to manager the PublicModule. Main operations are lifecycle (initialize, activate, unactivate, uninitialize) 2.PublicModuleMBean : is created when ModuleMBean activates and is responsible for serving requests. The MBean is dynamic and operations with no arguments and no returns are served. It's up to the module to do as he wants : if he wants MVC it can, it it wants to mix HTML and code, it can. First modules won't be MVC as they simply don't need. It's up to the model to have the persistence mecanisms it wants. First modules will use EJB. With lifecycle operations, each module can install itself, for instance : a ModuleMBean is plugged : 1.module configuration, setup of variables 2.initialize : module can creates table, deploy EJB, plugs block. 3.activate : module then go to block admin and creates instances of blocks (if module use blocks), display them on the page. Each block is made of : 1.BlockMBean : manages BlockInstanceMBean. 2.BlockInstanceMBean : is a block instance, it contains a title and a position on web page + 3 operations : display(), edit(), update(). display() : displays the block instance edit() : used to edit the block in block administration update() : used to upate the block in block admin Each them is made of various callbacks that displays HTML on the page. It has to provide location of files like css, gifs, etc... THe first them I did is made of a servlet that register to JMX and the doGet operation serves the files. It's default theme. To make the thing simpler, it will be possible to make theme with JSP because I want to keep post nuke spirit. Ideally, even Module and Blocks could be made as JSP of things like that, that keeps PHP easy to do spirit. I did not thought a lot about permissions. In PostNuke, each module is responsible for checking security. I know that could be done with AOP but I don't
Re: [JBoss-dev] JNuke dev
I think you are dreaming, if you think you will every recruit php developers to any java based solution. Ben, remember the Orielly OS convention? The php guys are perl guys. -dain On Tuesday, January 14, 2003, at 01:03 PM, Ben Sabrin wrote: Are we developing this for the PHP community or the Java community? Or more important for the JBoss community? To me it seems that it would depend on who you are targeting for your user base. If you want to target the PHP users to bring them to JBoss, then Bill could be right. If we do not care about the PHP community, we go down the JMX way. I think the PHP community will never want to do anything with JSP. They believe they have what they need to be successful and will continue to innovate in their own circle. For most of the PHP community, what they have built is scalable to their needs. -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Bill Burke Sent: Tuesday, January 14, 2003 1:51 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JNuke dev The only negative comment I have in using JMX is that the PHP community may have a tough time switching over to Nukes on JBoss if you have to have a package structure like a SAR or a WAR. I hate to say it, but does it need to be "dumbed-down" for the PHP community? This type of community needs to be able to edit a JSP and immediately see the change on the webserver. Is it possible to be all JSP based for themes, modules and blocks? You could use a URL fragement and JSP:Include to decide what theme to use. Just a thought. Maybe JMX and such is the way to go. Just want to give you something to think about. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of julien viet Sent: Tuesday, January 14, 2003 11:31 AM To: SourceForge.net Subject: [JBoss-dev] JNuke dev hi folks, JNuke adventure has started. After analysis of PostNuke I've began the development, still early though. I keep everything that's good in PostNuke and throw all the shit away : modules, blocks, permissions system, url system and themes. JMX is used for PostNuke components : themes, modules and blocks are all JMX mbeans. Here are my reasons : A : general 1.we need a component structure, why not JMX ? after all another forum say that's lightweight. 2.theses components do not have to scale, i.e the number of modules, blocks and themes is very small. B : for modules 1.Ability to deploy/undeploy when application is running. 2.It's easy to deploy additional modules as a separate deployment and have them register in the same registry. 3.PostNuke is all about invoking module functions. Url like index.php?module=User&op=register means that the PN must call the method register on module User. For me that means that the servlet retrieves the mbean under the name jnuke:publicmodules:name=User and invokes the operation register(). 4.When a module is installed and configured it plug block mbeans in the JMX. C : for blocks, same reasons as above except 3 and 4 as invocation is typed for 3. D : for themes, same reasons as above except 3 and 4 as invocation is typed for 3. EJB are used for the model : UserEJB, GroupEJB, UserPermissionEJB, UserGroupEJB will be CMP 2.0 beans. We'll use local invocations and same trick as in forum to make them faster. Plus more beans. Each module is made of : 1.ModuleMBean : is the module itself, does not provide fucntionnalities, it's used to manager the PublicModule. Main operations are lifecycle (initialize, activate, unactivate, uninitialize) 2.PublicModuleMBean : is created when ModuleMBean activates and is responsible for serving requests. The MBean is dynamic and operations with no arguments and no returns are served. It's up to the module to do as he wants : if he wants MVC it can, it it wants to mix HTML and code, it can. First modules won't be MVC as they simply don't need. It's up to the model to have the persistence mecanisms it wants. First modules will use EJB. With lifecycle operations, each module can install itself, for instance : a ModuleMBean is plugged : 1.module configuration, setup of variables 2.initialize : module can creates table, deploy EJB, plugs block. 3.activate : module then go to block admin and creates instances of blocks (if module use blocks), display them on the page. Each block is made of : 1.BlockMBean : manages BlockInstanceMBean. 2.BlockInstanceMBean : is a block instance, it contains a title and a position on web page + 3 operations : display(), edit(), update(). display() : displays the block instance edit() : used to edit the block in block administration update() : used to upate the block in block admin Each them is made of various callbacks that displays HTML on the page. It has to provide location of files like css, gifs, etc.
RE: [JBoss-dev] JNuke dev
I am all for JMX if it works . Also the idea is to port the modules we like bit by bit to the sar format and this is CLEARLY a microkernel job. I think julien stroke on something interesting when he noticed the URL:command mapping to interfaces. What this means is that modules will expose interfaces as mbeans and that is all it takes. Difficult? yeah for php guys, heck they must get EJB first. But for us? we are doing the port anyway... let's go julien, speed speed my friend, marcf > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On > Behalf Of Dain Sundstrom > Sent: Tuesday, January 14, 2003 2:19 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] JNuke dev > > > I think you are dreaming, if you think you will every recruit php > developers to any java based solution. Ben, remember the Orielly OS > convention? The php guys are perl guys. > > -dain > > On Tuesday, January 14, 2003, at 01:03 PM, Ben Sabrin wrote: > > > Are we developing this for the PHP community or the Java > community? > > Or more important for the JBoss community? To me it seems that it > > would depend on who you are targeting for your user base. > If you want > > to target the PHP users to bring them to JBoss, then Bill could be > > right. If we do not care about the PHP community, we go > down the JMX > > way. I think the PHP community will never want to do anything with > > JSP. They believe they have what they need to be > successful and will > > continue to innovate in their own circle. For most of the PHP > > community, what they have built is scalable to their needs. > > > >> -Original Message- > >> From: [EMAIL PROTECTED] [mailto:jboss- > >> [EMAIL PROTECTED]] On Behalf Of Bill Burke > >> Sent: Tuesday, January 14, 2003 1:51 PM > >> To: [EMAIL PROTECTED] > >> Subject: RE: [JBoss-dev] JNuke dev > >> > >> The only negative comment I have in using JMX is that the PHP > > community > >> may > >> have a tough time switching over to Nukes on JBoss if you have to > >> have > > a > >> package structure like a SAR or a WAR. I hate to say it, > but does it > > need > >> to be "dumbed-down" for the PHP community? This type of community > > needs > >> to > >> be able to edit a JSP and immediately see the change on the > >> webserver. > > Is > >> it possible to be all JSP based for themes, modules and > blocks? You > > could > >> use a URL fragement and JSP:Include to decide what theme to use. > >> > >> Just a thought. Maybe JMX and such is the way to go. Just want to > > give > >> you > >> something to think about. > >> > >> Bill > >> > >>> -Original Message- > >>> From: [EMAIL PROTECTED] > >>> [mailto:[EMAIL PROTECTED]]On > Behalf Of > >>> julien viet > >>> Sent: Tuesday, January 14, 2003 11:31 AM > >>> To: SourceForge.net > >>> Subject: [JBoss-dev] JNuke dev > >>> > >>> > >>> hi folks, > >>> > >>> JNuke adventure has started. > >>> After analysis of PostNuke I've began the development, still early > >> though. > >>> > >>> I keep everything that's good in PostNuke and throw all the shit > > away : > >>> > >>> modules, blocks, permissions system, url system and themes. > >>> > >>> JMX is used for PostNuke components : themes, > >>> modules and blocks are all JMX mbeans. Here are my reasons : > >>> > >>> A : general > >>> > >>> 1.we need a component structure, why not JMX ? after all > >>>another forum say that's lightweight. > >>> > >>> 2.theses components do not have to scale, i.e the number of > > modules, > >>>blocks and themes is very small. > >>> > >>> B : for modules > >>> > >>> 1.Ability to deploy/undeploy when application is running. > >>> > >>> 2.It's easy to deploy additional modules as a separate deployment > > and > >>>have them register in the same registry. > >>> > >>> 3.PostNuke is all about invoking module functions. > >>>Url like index.php?module=User&op=register means > >>>that the PN must call the method register on module User. > >>>For me that means that the servlet retrieves the mbean > >>>under the name jnuke:publicmodules:name=User > >>>and invokes the operation register(). > >>> > >>> 4.When a module is installed and configured it plug > >>>block mbeans in the JMX. > >>> > >>> C : for blocks, same reasons as above except 3 and 4 > >>> as invocation is typed for 3. > >>> > >>> D : for themes, same reasons as above except 3 and 4 > >>> as invocation is typed for 3. > >>> > >>> > >>> EJB are used for the model : > >>> > >>> UserEJB, GroupEJB, UserPermissionEJB, UserGroupEJB will > >>> be CMP 2.0 beans. We'll use local invocations and same > trick as in > >>> forum to make them faster. Plus more beans. > >>> > >>> Each module is made of : > >>> > >>> 1.ModuleMBean : is the module itself, does not provide > > fucntionnalities, > >>> it's used to manager the PublicModule. Main operations are > > lifecycle > >>> (initialize, activate, unactivate, uninitia
Re: Re[4]: [JBoss-dev] URLConnection and opened files
Oh, I now remeber looking at this but I can't remember the context. There is a cache of handlers as the URL level. If the file protocol is referenced before the custom JBoss handler is available then the default Sun one will be used. Is there a difference between 3.0 and 3.2 with regard to when the custom protocol handlers are installed? I'll check later today. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Alex Loubyansky" <[EMAIL PROTECTED]> To: "Scott M Stark" <[EMAIL PROTECTED]> Sent: Tuesday, January 14, 2003 7:07 AM Subject: Re[4]: [JBoss-dev] URLConnection and opened files > I'm a bit confused. I wrote a simple standalone test. > > - main > public static void main(String[] args) throws Exception > { >// set handler pkgs >System.out.println("java.protocol.handler.pkgs: " + >System.getProperty("java.protocol.handler.pkgs")); > >URL url = new URL("file", null, args[0]); >System.out.println("url: " + url); >URLConnection urlCon = url.openConnection(); >System.out.println("connection class: " + urlCon.getClass().getName()); > >url = new URL("other", null, args[0]); >System.out.println("url: " + url); >urlCon = url.openConnection(); >System.out.println("connection class: " + urlCon.getClass().getName()); > } > > - run > java -Djava.protocol.handler.pkgs=org.avoka.test.files.protocol -classpath %cp% >org.avoka.test.files.FilesTest build.xml > > - output > java.protocol.handler.pkgs: org.avoka.test.files.protocol > url: file:build.xml > connection class: sun.net.www.protocol.file.FileURLConnection > url: other:build.xml > connection class: org.avoka.test.files.protocol.other.OtherURLConnection > > I do have org.avoka.test.files.protocol.file.Handler and > org.avoka.test.files.protocol.file.FileURLConnection on the classpath. > My file.Handler isn't called. Am I missing something? > > This same thing happens with JBoss-3.2 and HEAD but not JBoss-3.0 (my > 3.0 is not up to date). > > JDK1.3.1_05, J2SDK1.4.0 > Win2K > > Thanks, > alex > > > > > --- > This SF.NET email is sponsored by: FREE SSL Guide from Thawte > are you planning your Web Server Security? Click here to get a FREE > Thawte SSL guide and find the answers to all your SSL security issues. > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JNuke dev
I would think that we'd want to make this a J2EE application so it can run on ANY J2EE application server. Therefore, I would elect to go down a pure J2EE route instead of a JBoss only JMX route. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Ben Sabrin Sent: Tuesday, January 14, 2003 1:04 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JNuke dev Are we developing this for the PHP community or the Java community? Or more important for the JBoss community? To me it seems that it would depend on who you are targeting for your user base. If you want to target the PHP users to bring them to JBoss, then Bill could be right. If we do not care about the PHP community, we go down the JMX way. I think the PHP community will never want to do anything with JSP. They believe they have what they need to be successful and will continue to innovate in their own circle. For most of the PHP community, what they have built is scalable to their needs. > -Original Message- > From: [EMAIL PROTECTED] [mailto:jboss- > [EMAIL PROTECTED]] On Behalf Of Bill Burke > Sent: Tuesday, January 14, 2003 1:51 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] JNuke dev > > The only negative comment I have in using JMX is that the PHP community > may > have a tough time switching over to Nukes on JBoss if you have to have a > package structure like a SAR or a WAR. I hate to say it, but does it need > to be "dumbed-down" for the PHP community? This type of community needs > to > be able to edit a JSP and immediately see the change on the webserver. Is > it possible to be all JSP based for themes, modules and blocks? You could > use a URL fragement and JSP:Include to decide what theme to use. > > Just a thought. Maybe JMX and such is the way to go. Just want to give > you > something to think about. > > Bill > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of > > julien viet > > Sent: Tuesday, January 14, 2003 11:31 AM > > To: SourceForge.net > > Subject: [JBoss-dev] JNuke dev > > > > > > hi folks, > > > > JNuke adventure has started. > > After analysis of PostNuke I've began the development, still early > though. > > > > I keep everything that's good in PostNuke and throw all the shit away : > > > > modules, blocks, permissions system, url system and themes. > > > > JMX is used for PostNuke components : themes, > > modules and blocks are all JMX mbeans. Here are my reasons : > > > > A : general > > > > 1.we need a component structure, why not JMX ? after all > >another forum say that's lightweight. > > > > 2.theses components do not have to scale, i.e the number of modules, > >blocks and themes is very small. > > > > B : for modules > > > > 1.Ability to deploy/undeploy when application is running. > > > > 2.It's easy to deploy additional modules as a separate deployment and > >have them register in the same registry. > > > > 3.PostNuke is all about invoking module functions. > >Url like index.php?module=User&op=register means > >that the PN must call the method register on module User. > >For me that means that the servlet retrieves the mbean > >under the name jnuke:publicmodules:name=User > >and invokes the operation register(). > > > > 4.When a module is installed and configured it plug > >block mbeans in the JMX. > > > > C : for blocks, same reasons as above except 3 and 4 > > as invocation is typed for 3. > > > > D : for themes, same reasons as above except 3 and 4 > > as invocation is typed for 3. > > > > > > EJB are used for the model : > > > > UserEJB, GroupEJB, UserPermissionEJB, UserGroupEJB will > > be CMP 2.0 beans. We'll use local invocations and same trick as in > > forum to make them faster. Plus more beans. > > > > Each module is made of : > > > > 1.ModuleMBean : is the module itself, does not provide fucntionnalities, > > it's used to manager the PublicModule. Main operations are lifecycle > > (initialize, activate, unactivate, uninitialize) > > > > 2.PublicModuleMBean : is created when ModuleMBean activates and is > >responsible for serving requests. The MBean is dynamic and operations > >with no arguments and no returns are served. > > > > It's up to the module to do as he wants : if he wants MVC it can, it > > it wants to mix HTML and code, it can. First modules won't be MVC > > as they simply don't need. > > > > It's up to the model to have the persistence mecanisms it wants. First > > modules will use EJB. With lifecycle operations, each module can > install > > itself, for instance : > > > > a ModuleMBean is plugged : > > 1.module configuration, setup of variables > > 2.initialize : module can creates table, deploy EJB, plugs block. > > 3.activate : module > > then go to block admin and creates instances of blocks (if module > > use blocks), display them on the page. > > > > Each block is
Re[2]: [JBoss-dev] JNuke dev
so far I am not using jboss specific feature : j2ee and jmx. nuke use its own mbean server. I'll try to keep that. NP> I would think that we'd want to make this a J2EE application so it can NP> run on ANY J2EE application server. Therefore, I would elect to go down NP> a pure J2EE route instead of a JBoss only JMX route. NP> -Original Message- NP> From: [EMAIL PROTECTED] NP> [mailto:[EMAIL PROTECTED]] On Behalf Of Ben NP> Sabrin NP> Sent: Tuesday, January 14, 2003 1:04 PM NP> To: [EMAIL PROTECTED] NP> Subject: RE: [JBoss-dev] JNuke dev NP> Are we developing this for the PHP community or the Java community? Or NP> more important for the JBoss community? To me it seems that it would NP> depend on who you are targeting for your user base. If you want to NP> target the PHP users to bring them to JBoss, then Bill could be right. NP> If we do not care about the PHP community, we go down the JMX way. I NP> think the PHP community will never want to do anything with JSP. They NP> believe they have what they need to be successful and will continue to NP> innovate in their own circle. For most of the PHP community, what they NP> have built is scalable to their needs. >> -Original Message- >> From: [EMAIL PROTECTED] [mailto:jboss- >> [EMAIL PROTECTED]] On Behalf Of Bill Burke >> Sent: Tuesday, January 14, 2003 1:51 PM >> To: [EMAIL PROTECTED] >> Subject: RE: [JBoss-dev] JNuke dev >> >> The only negative comment I have in using JMX is that the PHP NP> community >> may >> have a tough time switching over to Nukes on JBoss if you have to have NP> a >> package structure like a SAR or a WAR. I hate to say it, but does it NP> need >> to be "dumbed-down" for the PHP community? This type of community NP> needs >> to >> be able to edit a JSP and immediately see the change on the webserver. NP> Is >> it possible to be all JSP based for themes, modules and blocks? You NP> could >> use a URL fragement and JSP:Include to decide what theme to use. >> >> Just a thought. Maybe JMX and such is the way to go. Just want to NP> give >> you >> something to think about. >> >> Bill >> >> > -Original Message- >> > From: [EMAIL PROTECTED] >> > [mailto:[EMAIL PROTECTED]]On Behalf Of >> > julien viet >> > Sent: Tuesday, January 14, 2003 11:31 AM >> > To: SourceForge.net >> > Subject: [JBoss-dev] JNuke dev >> > >> > >> > hi folks, >> > >> > JNuke adventure has started. >> > After analysis of PostNuke I've began the development, still early >> though. >> > >> > I keep everything that's good in PostNuke and throw all the shit NP> away : >> > >> > modules, blocks, permissions system, url system and themes. >> > >> > JMX is used for PostNuke components : themes, >> > modules and blocks are all JMX mbeans. Here are my reasons : >> > >> > A : general >> > >> > 1.we need a component structure, why not JMX ? after all >> >another forum say that's lightweight. >> > >> > 2.theses components do not have to scale, i.e the number of NP> modules, >> >blocks and themes is very small. >> > >> > B : for modules >> > >> > 1.Ability to deploy/undeploy when application is running. >> > >> > 2.It's easy to deploy additional modules as a separate deployment NP> and >> >have them register in the same registry. >> > >> > 3.PostNuke is all about invoking module functions. >> >Url like index.php?module=User&op=register means >> >that the PN must call the method register on module User. >> >For me that means that the servlet retrieves the mbean >> >under the name jnuke:publicmodules:name=User >> >and invokes the operation register(). >> > >> > 4.When a module is installed and configured it plug >> >block mbeans in the JMX. >> > >> > C : for blocks, same reasons as above except 3 and 4 >> > as invocation is typed for 3. >> > >> > D : for themes, same reasons as above except 3 and 4 >> > as invocation is typed for 3. >> > >> > >> > EJB are used for the model : >> > >> > UserEJB, GroupEJB, UserPermissionEJB, UserGroupEJB will >> > be CMP 2.0 beans. We'll use local invocations and same trick as in >> > forum to make them faster. Plus more beans. >> > >> > Each module is made of : >> > >> > 1.ModuleMBean : is the module itself, does not provide NP> fucntionnalities, >> > it's used to manager the PublicModule. Main operations are NP> lifecycle >> > (initialize, activate, unactivate, uninitialize) >> > >> > 2.PublicModuleMBean : is created when ModuleMBean activates and is >> >responsible for serving requests. The MBean is dynamic and NP> operations >> >with no arguments and no returns are served. >> > >> > It's up to the module to do as he wants : if he wants MVC it can, NP> it >> > it wants to mix HTML and code, it can. First modules won't be MVC >> > as they simply don't need. >> > >> > It's up to the model to have the persistence mecanisms it wants. NP> First >> > modules will use EJB. With lifecycle operations, each module can >> install
RE: [JBoss-dev] JNuke dev
I remember a few months ago that some people were talking about writing a killer jboss app to prove what could be done with the server. Let Julien write it the way he prefers, using all Jboss capabilities first. The nice thing is that open source allows someone to take it and make it fully j2ee 1.3 compliant if they want, and reciprocate the code back.. Let Jboss shine! Go Julien Go! James > -Original Message- > From: Nathan Phelps [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 14, 2003 1:48 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] JNuke dev > > > I would think that we'd want to make this a J2EE application > so it can run on ANY J2EE application server. Therefore, I > would elect to go down a pure J2EE route instead of a JBoss > only JMX route. > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On > Behalf Of Ben Sabrin > Sent: Tuesday, January 14, 2003 1:04 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] JNuke dev > > > Are we developing this for the PHP community or the Java > community? Or more important for the JBoss community? To me > it seems that it would depend on who you are targeting for > your user base. If you want to target the PHP users to bring > them to JBoss, then Bill could be right. If we do not care > about the PHP community, we go down the JMX way. I think the > PHP community will never want to do anything with JSP. They > believe they have what they need to be successful and will > continue to innovate in their own circle. For most of the > PHP community, what they have built is scalable to their needs. > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:jboss- > > [EMAIL PROTECTED]] On Behalf Of Bill Burke > > Sent: Tuesday, January 14, 2003 1:51 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] JNuke dev > > > > The only negative comment I have in using JMX is that the PHP > community > > may > > have a tough time switching over to Nukes on JBoss if you > have to have > a > > package structure like a SAR or a WAR. I hate to say it, > but does it > need > > to be "dumbed-down" for the PHP community? This type of community > needs > > to > > be able to edit a JSP and immediately see the change on the > webserver. > Is > > it possible to be all JSP based for themes, modules and blocks? You > could > > use a URL fragement and JSP:Include to decide what theme to use. > > > > Just a thought. Maybe JMX and such is the way to go. Just want to > give > > you > > something to think about. > > > > Bill > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On Behalf Of > > > julien viet > > > Sent: Tuesday, January 14, 2003 11:31 AM > > > To: SourceForge.net > > > Subject: [JBoss-dev] JNuke dev > > > > > > > > > hi folks, > > > > > > JNuke adventure has started. > > > After analysis of PostNuke I've began the development, still early > > though. > > > > > > I keep everything that's good in PostNuke and throw all the shit > away : > > > > > > modules, blocks, permissions system, url system and themes. > > > > > > JMX is used for PostNuke components : themes, > > > modules and blocks are all JMX mbeans. Here are my reasons : > > > > > > A : general > > > > > > 1.we need a component structure, why not JMX ? after all > > >another forum say that's lightweight. > > > > > > 2.theses components do not have to scale, i.e the number of > modules, > > >blocks and themes is very small. > > > > > > B : for modules > > > > > > 1.Ability to deploy/undeploy when application is running. > > > > > > 2.It's easy to deploy additional modules as a separate deployment > and > > >have them register in the same registry. > > > > > > 3.PostNuke is all about invoking module functions. > > >Url like index.php?module=User&op=register means > > >that the PN must call the method register on module User. > > >For me that means that the servlet retrieves the mbean > > >under the name jnuke:publicmodules:name=User > > >and invokes the operation register(). > > > > > > 4.When a module is installed and configured it plug > > >block mbeans in the JMX. > > > > > > C : for blocks, same reasons as above except 3 and 4 > > > as invocation is typed for 3. > > > > > > D : for themes, same reasons as above except 3 and 4 > > > as invocation is typed for 3. > > > > > > > > > EJB are used for the model : > > > > > > UserEJB, GroupEJB, UserPermissionEJB, UserGroupEJB will > > > be CMP 2.0 beans. We'll use local invocations and same trick as in > > > forum to make them faster. Plus more beans. > > > > > > Each module is made of : > > > > > > 1.ModuleMBean : is the module itself, does not provide > fucntionnalities, > > > it's used to manager the PublicModule. Main operations are > lifecycle > > > (initialize, activate, unactivate, uninitialize) > > > > > > 2.PublicModuleMBean : is created when
RE: [JBoss-dev] JNuke dev
> I would think that we'd want to make this a J2EE application > so it can run on ANY J2EE application server. no we wouldn't. > Therefore, I > would elect to go down a pure J2EE route instead of a JBoss > only JMX route. JMX will be J2EE. Nathan wake up. marcf --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JNuke dev
You need to think in a one dimensional world. J2EE = JBOSS ! That is the future, "learn it, live it, love it" A quote from Fast Times at Ridgemont High. Ben Sabrin Director of Sales and Business Development JBoss Group, LLC 404-467-8555 - office 404-664-9466 - cell 404-948-1496 - fax [EMAIL PROTECTED] > -Original Message- > From: [EMAIL PROTECTED] [mailto:jboss- > [EMAIL PROTECTED]] On Behalf Of Nathan Phelps > Sent: Tuesday, January 14, 2003 2:48 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] JNuke dev > > I would think that we'd want to make this a J2EE application so it can > run on ANY J2EE application server. Therefore, I would elect to go down > a pure J2EE route instead of a JBoss only JMX route. > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of Ben > Sabrin > Sent: Tuesday, January 14, 2003 1:04 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] JNuke dev > > > Are we developing this for the PHP community or the Java community? Or > more important for the JBoss community? To me it seems that it would > depend on who you are targeting for your user base. If you want to > target the PHP users to bring them to JBoss, then Bill could be right. > If we do not care about the PHP community, we go down the JMX way. I > think the PHP community will never want to do anything with JSP. They > believe they have what they need to be successful and will continue to > innovate in their own circle. For most of the PHP community, what they > have built is scalable to their needs. > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:jboss- > > [EMAIL PROTECTED]] On Behalf Of Bill Burke > > Sent: Tuesday, January 14, 2003 1:51 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] JNuke dev > > > > The only negative comment I have in using JMX is that the PHP > community > > may > > have a tough time switching over to Nukes on JBoss if you have to have > a > > package structure like a SAR or a WAR. I hate to say it, but does it > need > > to be "dumbed-down" for the PHP community? This type of community > needs > > to > > be able to edit a JSP and immediately see the change on the webserver. > Is > > it possible to be all JSP based for themes, modules and blocks? You > could > > use a URL fragement and JSP:Include to decide what theme to use. > > > > Just a thought. Maybe JMX and such is the way to go. Just want to > give > > you > > something to think about. > > > > Bill > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On Behalf Of > > > julien viet > > > Sent: Tuesday, January 14, 2003 11:31 AM > > > To: SourceForge.net > > > Subject: [JBoss-dev] JNuke dev > > > > > > > > > hi folks, > > > > > > JNuke adventure has started. > > > After analysis of PostNuke I've began the development, still early > > though. > > > > > > I keep everything that's good in PostNuke and throw all the shit > away : > > > > > > modules, blocks, permissions system, url system and themes. > > > > > > JMX is used for PostNuke components : themes, > > > modules and blocks are all JMX mbeans. Here are my reasons : > > > > > > A : general > > > > > > 1.we need a component structure, why not JMX ? after all > > >another forum say that's lightweight. > > > > > > 2.theses components do not have to scale, i.e the number of > modules, > > >blocks and themes is very small. > > > > > > B : for modules > > > > > > 1.Ability to deploy/undeploy when application is running. > > > > > > 2.It's easy to deploy additional modules as a separate deployment > and > > >have them register in the same registry. > > > > > > 3.PostNuke is all about invoking module functions. > > >Url like index.php?module=User&op=register means > > >that the PN must call the method register on module User. > > >For me that means that the servlet retrieves the mbean > > >under the name jnuke:publicmodules:name=User > > >and invokes the operation register(). > > > > > > 4.When a module is installed and configured it plug > > >block mbeans in the JMX. > > > > > > C : for blocks, same reasons as above except 3 and 4 > > > as invocation is typed for 3. > > > > > > D : for themes, same reasons as above except 3 and 4 > > > as invocation is typed for 3. > > > > > > > > > EJB are used for the model : > > > > > > UserEJB, GroupEJB, UserPermissionEJB, UserGroupEJB will > > > be CMP 2.0 beans. We'll use local invocations and same trick as in > > > forum to make them faster. Plus more beans. > > > > > > Each module is made of : > > > > > > 1.ModuleMBean : is the module itself, does not provide > fucntionnalities, > > > it's used to manager the PublicModule. Main operations are > lifecycle > > > (initialize, activate, unactivate, uninitialize) > > > > > > 2.PublicModuleMBean : is created when ModuleMBean activates and is > > >responsible for serving requests. The MBean i
RE: [JBoss-dev] JNuke dev
Oh I remember, which is why I feel that we need to concentrate this app towards the Java people not the interesting Perl Mongers:) Ben Sabrin Director of Sales and Business Development JBoss Group, LLC 404-467-8555 - office 404-664-9466 - cell 404-948-1496 - fax [EMAIL PROTECTED] > -Original Message- > From: [EMAIL PROTECTED] [mailto:jboss- > [EMAIL PROTECTED]] On Behalf Of Dain Sundstrom > Sent: Tuesday, January 14, 2003 2:19 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] JNuke dev > > I think you are dreaming, if you think you will every recruit php > developers to any java based solution. Ben, remember the Orielly OS > convention? The php guys are perl guys. > > -dain > > On Tuesday, January 14, 2003, at 01:03 PM, Ben Sabrin wrote: > > > Are we developing this for the PHP community or the Java community? Or > > more important for the JBoss community? To me it seems that it would > > depend on who you are targeting for your user base. If you want to > > target the PHP users to bring them to JBoss, then Bill could be right. > > If we do not care about the PHP community, we go down the JMX way. I > > think the PHP community will never want to do anything with JSP. They > > believe they have what they need to be successful and will continue to > > innovate in their own circle. For most of the PHP community, what they > > have built is scalable to their needs. > > > >> -Original Message- > >> From: [EMAIL PROTECTED] [mailto:jboss- > >> [EMAIL PROTECTED]] On Behalf Of Bill Burke > >> Sent: Tuesday, January 14, 2003 1:51 PM > >> To: [EMAIL PROTECTED] > >> Subject: RE: [JBoss-dev] JNuke dev > >> > >> The only negative comment I have in using JMX is that the PHP > > community > >> may > >> have a tough time switching over to Nukes on JBoss if you have to have > > a > >> package structure like a SAR or a WAR. I hate to say it, but does it > > need > >> to be "dumbed-down" for the PHP community? This type of community > > needs > >> to > >> be able to edit a JSP and immediately see the change on the webserver. > > Is > >> it possible to be all JSP based for themes, modules and blocks? You > > could > >> use a URL fragement and JSP:Include to decide what theme to use. > >> > >> Just a thought. Maybe JMX and such is the way to go. Just want to > > give > >> you > >> something to think about. > >> > >> Bill > >> > >>> -Original Message- > >>> From: [EMAIL PROTECTED] > >>> [mailto:[EMAIL PROTECTED]]On Behalf Of > >>> julien viet > >>> Sent: Tuesday, January 14, 2003 11:31 AM > >>> To: SourceForge.net > >>> Subject: [JBoss-dev] JNuke dev > >>> > >>> > >>> hi folks, > >>> > >>> JNuke adventure has started. > >>> After analysis of PostNuke I've began the development, still early > >> though. > >>> > >>> I keep everything that's good in PostNuke and throw all the shit > > away : > >>> > >>> modules, blocks, permissions system, url system and themes. > >>> > >>> JMX is used for PostNuke components : themes, > >>> modules and blocks are all JMX mbeans. Here are my reasons : > >>> > >>> A : general > >>> > >>> 1.we need a component structure, why not JMX ? after all > >>>another forum say that's lightweight. > >>> > >>> 2.theses components do not have to scale, i.e the number of > > modules, > >>>blocks and themes is very small. > >>> > >>> B : for modules > >>> > >>> 1.Ability to deploy/undeploy when application is running. > >>> > >>> 2.It's easy to deploy additional modules as a separate deployment > > and > >>>have them register in the same registry. > >>> > >>> 3.PostNuke is all about invoking module functions. > >>>Url like index.php?module=User&op=register means > >>>that the PN must call the method register on module User. > >>>For me that means that the servlet retrieves the mbean > >>>under the name jnuke:publicmodules:name=User > >>>and invokes the operation register(). > >>> > >>> 4.When a module is installed and configured it plug > >>>block mbeans in the JMX. > >>> > >>> C : for blocks, same reasons as above except 3 and 4 > >>> as invocation is typed for 3. > >>> > >>> D : for themes, same reasons as above except 3 and 4 > >>> as invocation is typed for 3. > >>> > >>> > >>> EJB are used for the model : > >>> > >>> UserEJB, GroupEJB, UserPermissionEJB, UserGroupEJB will > >>> be CMP 2.0 beans. We'll use local invocations and same trick > >>> as in forum to make them faster. Plus more beans. > >>> > >>> Each module is made of : > >>> > >>> 1.ModuleMBean : is the module itself, does not provide > > fucntionnalities, > >>> it's used to manager the PublicModule. Main operations are > > lifecycle > >>> (initialize, activate, unactivate, uninitialize) > >>> > >>> 2.PublicModuleMBean : is created when ModuleMBean activates and is > >>>responsible for serving requests. The MBean is dynamic and > > operations > >>>with no arguments and no returns are served. > >>> > >>> It's up to the module to
RE: [JBoss-dev] JNuke dev
Again, The type of developer writing content is usually a different calaber than those writing server software. IMHO, it needs to be dumbed-down. The reason why these things like postnuke become so popular is that they are so easy to hack for even the least experienced coder. Copy, cut, paste. Not, write xml, compile, jar, maintain ANT files, etc... You get what I'm saying? This is just something to think about and I'm not advocating any specific approach. And again, BTW, JNuke is already trademarked. You must call in Nukes on JBoss or think of a better name. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of marc > fleury > Sent: Tuesday, January 14, 2003 2:40 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] JNuke dev > > > I am all for JMX if it works . Also the idea is to port the modules we > like bit by bit to the sar format and this is CLEARLY a microkernel job. > I think julien stroke on something interesting when he noticed the > URL:command mapping to interfaces. What this means is that modules will > expose interfaces as mbeans and that is all it takes. Difficult? yeah > for php guys, heck they must get EJB first. But for us? we are doing > the port anyway... > > let's go julien, speed speed my friend, > > marcf > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]] On > > Behalf Of Dain Sundstrom > > Sent: Tuesday, January 14, 2003 2:19 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] JNuke dev > > > > > > I think you are dreaming, if you think you will every recruit php > > developers to any java based solution. Ben, remember the Orielly OS > > convention? The php guys are perl guys. > > > > -dain > > > > On Tuesday, January 14, 2003, at 01:03 PM, Ben Sabrin wrote: > > > > > Are we developing this for the PHP community or the Java > > community? > > > Or more important for the JBoss community? To me it seems that it > > > would depend on who you are targeting for your user base. > > If you want > > > to target the PHP users to bring them to JBoss, then Bill could be > > > right. If we do not care about the PHP community, we go > > down the JMX > > > way. I think the PHP community will never want to do anything with > > > JSP. They believe they have what they need to be > > successful and will > > > continue to innovate in their own circle. For most of the PHP > > > community, what they have built is scalable to their needs. > > > > > >> -Original Message- > > >> From: [EMAIL PROTECTED] [mailto:jboss- > > >> [EMAIL PROTECTED]] On Behalf Of Bill Burke > > >> Sent: Tuesday, January 14, 2003 1:51 PM > > >> To: [EMAIL PROTECTED] > > >> Subject: RE: [JBoss-dev] JNuke dev > > >> > > >> The only negative comment I have in using JMX is that the PHP > > > community > > >> may > > >> have a tough time switching over to Nukes on JBoss if you have to > > >> have > > > a > > >> package structure like a SAR or a WAR. I hate to say it, > > but does it > > > need > > >> to be "dumbed-down" for the PHP community? This type of community > > > needs > > >> to > > >> be able to edit a JSP and immediately see the change on the > > >> webserver. > > > Is > > >> it possible to be all JSP based for themes, modules and > > blocks? You > > > could > > >> use a URL fragement and JSP:Include to decide what theme to use. > > >> > > >> Just a thought. Maybe JMX and such is the way to go. Just want to > > > give > > >> you > > >> something to think about. > > >> > > >> Bill > > >> > > >>> -Original Message- > > >>> From: [EMAIL PROTECTED] > > >>> [mailto:[EMAIL PROTECTED]]On > > Behalf Of > > >>> julien viet > > >>> Sent: Tuesday, January 14, 2003 11:31 AM > > >>> To: SourceForge.net > > >>> Subject: [JBoss-dev] JNuke dev > > >>> > > >>> > > >>> hi folks, > > >>> > > >>> JNuke adventure has started. > > >>> After analysis of PostNuke I've began the development, still early > > >> though. > > >>> > > >>> I keep everything that's good in PostNuke and throw all the shit > > > away : > > >>> > > >>> modules, blocks, permissions system, url system and themes. > > >>> > > >>> JMX is used for PostNuke components : themes, > > >>> modules and blocks are all JMX mbeans. Here are my reasons : > > >>> > > >>> A : general > > >>> > > >>> 1.we need a component structure, why not JMX ? after all > > >>>another forum say that's lightweight. > > >>> > > >>> 2.theses components do not have to scale, i.e the number of > > > modules, > > >>>blocks and themes is very small. > > >>> > > >>> B : for modules > > >>> > > >>> 1.Ability to deploy/undeploy when application is running. > > >>> > > >>> 2.It's easy to deploy additional modules as a separate deployment > > > and > > >>>have them register in the same registry. > > >>> > > >>> 3.PostNuke is all about invoking module functions. > > >>>Url like index.php?module=User&op=register means > > >>>that the PN must call the method
RE: [JBoss-dev] JNuke dev
Its a good idea. Anybody want to implement this? JBossScript we can call it. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Dain > Sundstrom > Sent: Tuesday, January 14, 2003 2:16 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] JNuke dev > > > Bill, > > This reminds me of an I deal I has last night (couldn't sleep). I was > thinking of the script based MBean support Sacha added, and I thought > can we make plain old java work like a scripting language. Here is > what I came up with: >+ The user writes a class BlahService.java >+ This source file is places in our deployment directory >+ We run Xdoclet on it to generate the MBean deployment descriptor >+ We compile the java file >+ Deploy > > Java as a scripting language. > > What do you think? > > -dain > > On Tuesday, January 14, 2003, at 12:50 PM, Bill Burke wrote: > > > The only negative comment I have in using JMX is that the PHP > > community may > > have a tough time switching over to Nukes on JBoss if you have to have > > a > > package structure like a SAR or a WAR. I hate to say it, but does it > > need > > to be "dumbed-down" for the PHP community? This type of community > > needs to > > be able to edit a JSP and immediately see the change on the webserver. > > Is > > it possible to be all JSP based for themes, modules and blocks? You > > could > > use a URL fragement and JSP:Include to decide what theme to use. > > > > Just a thought. Maybe JMX and such is the way to go. Just want to > > give you > > something to think about. > > > > Bill > > > >> -Original Message- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED]]On Behalf Of > >> julien viet > >> Sent: Tuesday, January 14, 2003 11:31 AM > >> To: SourceForge.net > >> Subject: [JBoss-dev] JNuke dev > >> > >> > >> hi folks, > >> > >> JNuke adventure has started. > >> After analysis of PostNuke I've began the development, still early > >> though. > >> > >> I keep everything that's good in PostNuke and throw all the shit > >> away : > >> > >> modules, blocks, permissions system, url system and themes. > >> > >> JMX is used for PostNuke components : themes, > >> modules and blocks are all JMX mbeans. Here are my reasons : > >> > >> A : general > >> > >> 1.we need a component structure, why not JMX ? after all > >>another forum say that's lightweight. > >> > >> 2.theses components do not have to scale, i.e the number of modules, > >>blocks and themes is very small. > >> > >> B : for modules > >> > >> 1.Ability to deploy/undeploy when application is running. > >> > >> 2.It's easy to deploy additional modules as a separate deployment and > >>have them register in the same registry. > >> > >> 3.PostNuke is all about invoking module functions. > >>Url like index.php?module=User&op=register means > >>that the PN must call the method register on module User. > >>For me that means that the servlet retrieves the mbean > >>under the name jnuke:publicmodules:name=User > >>and invokes the operation register(). > >> > >> 4.When a module is installed and configured it plug > >>block mbeans in the JMX. > >> > >> C : for blocks, same reasons as above except 3 and 4 > >> as invocation is typed for 3. > >> > >> D : for themes, same reasons as above except 3 and 4 > >> as invocation is typed for 3. > >> > >> > >> EJB are used for the model : > >> > >> UserEJB, GroupEJB, UserPermissionEJB, UserGroupEJB will > >> be CMP 2.0 beans. We'll use local invocations and same trick > >> as in forum to make them faster. Plus more beans. > >> > >> Each module is made of : > >> > >> 1.ModuleMBean : is the module itself, does not provide > >> fucntionnalities, > >> it's used to manager the PublicModule. Main operations are lifecycle > >> (initialize, activate, unactivate, uninitialize) > >> > >> 2.PublicModuleMBean : is created when ModuleMBean activates and is > >>responsible for serving requests. The MBean is dynamic and > >> operations > >>with no arguments and no returns are served. > >> > >> It's up to the module to do as he wants : if he wants MVC it can, it > >> it wants to mix HTML and code, it can. First modules won't be MVC > >> as they simply don't need. > >> > >> It's up to the model to have the persistence mecanisms it wants. > >> First > >> modules will use EJB. With lifecycle operations, each module can > >> install > >> itself, for instance : > >> > >> a ModuleMBean is plugged : > >> 1.module configuration, setup of variables > >> 2.initialize : module can creates table, deploy EJB, plugs block. > >> 3.activate : module > >> then go to block admin and creates instances of blocks (if module > >> use blocks), display them on the page. > >> > >> Each block is made of : > >> > >> 1.BlockMBean : manages BlockInstanceMBean. > >> 2.BlockInstanceMBean : is a block instance, it contains a title > >> and a position >
RE: [JBoss-dev] JNuke dev
What I should have said is content developers. Sorry for the snub, but they do requiring a dumbing down of software. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Dain > Sundstrom > Sent: Tuesday, January 14, 2003 2:19 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] JNuke dev > > > I think you are dreaming, if you think you will every recruit php > developers to any java based solution. Ben, remember the Orielly OS > convention? The php guys are perl guys. > > -dain > > On Tuesday, January 14, 2003, at 01:03 PM, Ben Sabrin wrote: > > > Are we developing this for the PHP community or the Java community? Or > > more important for the JBoss community? To me it seems that it would > > depend on who you are targeting for your user base. If you want to > > target the PHP users to bring them to JBoss, then Bill could be right. > > If we do not care about the PHP community, we go down the JMX way. I > > think the PHP community will never want to do anything with JSP. They > > believe they have what they need to be successful and will continue to > > innovate in their own circle. For most of the PHP community, what they > > have built is scalable to their needs. > > > >> -Original Message- > >> From: [EMAIL PROTECTED] [mailto:jboss- > >> [EMAIL PROTECTED]] On Behalf Of Bill Burke > >> Sent: Tuesday, January 14, 2003 1:51 PM > >> To: [EMAIL PROTECTED] > >> Subject: RE: [JBoss-dev] JNuke dev > >> > >> The only negative comment I have in using JMX is that the PHP > > community > >> may > >> have a tough time switching over to Nukes on JBoss if you have to have > > a > >> package structure like a SAR or a WAR. I hate to say it, but does it > > need > >> to be "dumbed-down" for the PHP community? This type of community > > needs > >> to > >> be able to edit a JSP and immediately see the change on the webserver. > > Is > >> it possible to be all JSP based for themes, modules and blocks? You > > could > >> use a URL fragement and JSP:Include to decide what theme to use. > >> > >> Just a thought. Maybe JMX and such is the way to go. Just want to > > give > >> you > >> something to think about. > >> > >> Bill > >> > >>> -Original Message- > >>> From: [EMAIL PROTECTED] > >>> [mailto:[EMAIL PROTECTED]]On Behalf Of > >>> julien viet > >>> Sent: Tuesday, January 14, 2003 11:31 AM > >>> To: SourceForge.net > >>> Subject: [JBoss-dev] JNuke dev > >>> > >>> > >>> hi folks, > >>> > >>> JNuke adventure has started. > >>> After analysis of PostNuke I've began the development, still early > >> though. > >>> > >>> I keep everything that's good in PostNuke and throw all the shit > > away : > >>> > >>> modules, blocks, permissions system, url system and themes. > >>> > >>> JMX is used for PostNuke components : themes, > >>> modules and blocks are all JMX mbeans. Here are my reasons : > >>> > >>> A : general > >>> > >>> 1.we need a component structure, why not JMX ? after all > >>>another forum say that's lightweight. > >>> > >>> 2.theses components do not have to scale, i.e the number of > > modules, > >>>blocks and themes is very small. > >>> > >>> B : for modules > >>> > >>> 1.Ability to deploy/undeploy when application is running. > >>> > >>> 2.It's easy to deploy additional modules as a separate deployment > > and > >>>have them register in the same registry. > >>> > >>> 3.PostNuke is all about invoking module functions. > >>>Url like index.php?module=User&op=register means > >>>that the PN must call the method register on module User. > >>>For me that means that the servlet retrieves the mbean > >>>under the name jnuke:publicmodules:name=User > >>>and invokes the operation register(). > >>> > >>> 4.When a module is installed and configured it plug > >>>block mbeans in the JMX. > >>> > >>> C : for blocks, same reasons as above except 3 and 4 > >>> as invocation is typed for 3. > >>> > >>> D : for themes, same reasons as above except 3 and 4 > >>> as invocation is typed for 3. > >>> > >>> > >>> EJB are used for the model : > >>> > >>> UserEJB, GroupEJB, UserPermissionEJB, UserGroupEJB will > >>> be CMP 2.0 beans. We'll use local invocations and same trick > >>> as in forum to make them faster. Plus more beans. > >>> > >>> Each module is made of : > >>> > >>> 1.ModuleMBean : is the module itself, does not provide > > fucntionnalities, > >>> it's used to manager the PublicModule. Main operations are > > lifecycle > >>> (initialize, activate, unactivate, uninitialize) > >>> > >>> 2.PublicModuleMBean : is created when ModuleMBean activates and is > >>>responsible for serving requests. The MBean is dynamic and > > operations > >>>with no arguments and no returns are served. > >>> > >>> It's up to the module to do as he wants : if he wants MVC it can, > > it > >>> it wants to mix HTML and code, it can. First modules won't be MVC > >>> as they simply don't need. > >>> >
Re[2]: [JBoss-dev] JNuke dev
ok, do you have a name shorter though ? just nuke for instance ? BB> Again, BB> The type of developer writing content is usually a different calaber than BB> those writing server software. IMHO, it needs to be dumbed-down. The BB> reason why these things like postnuke become so popular is that they are so BB> easy to hack for even the least experienced coder. Copy, cut, paste. Not, BB> write xml, compile, jar, maintain ANT files, etc... You get what I'm BB> saying? BB> This is just something to think about and I'm not advocating any specific BB> approach. BB> And again, BTW, JNuke is already trademarked. You must call in Nukes on BB> JBoss or think of a better name. BB> Bill >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED]]On Behalf Of marc >> fleury >> Sent: Tuesday, January 14, 2003 2:40 PM >> To: [EMAIL PROTECTED] >> Subject: RE: [JBoss-dev] JNuke dev >> >> >> I am all for JMX if it works . Also the idea is to port the modules we >> like bit by bit to the sar format and this is CLEARLY a microkernel job. >> I think julien stroke on something interesting when he noticed the >> URL:command mapping to interfaces. What this means is that modules will >> expose interfaces as mbeans and that is all it takes. Difficult? yeah >> for php guys, heck they must get EJB first. But for us? we are doing >> the port anyway... >> >> let's go julien, speed speed my friend, >> >> marcf >> >> > -Original Message- >> > From: [EMAIL PROTECTED] >> > [mailto:[EMAIL PROTECTED]] On >> > Behalf Of Dain Sundstrom >> > Sent: Tuesday, January 14, 2003 2:19 PM >> > To: [EMAIL PROTECTED] >> > Subject: Re: [JBoss-dev] JNuke dev >> > >> > >> > I think you are dreaming, if you think you will every recruit php >> > developers to any java based solution. Ben, remember the Orielly OS >> > convention? The php guys are perl guys. >> > >> > -dain >> > >> > On Tuesday, January 14, 2003, at 01:03 PM, Ben Sabrin wrote: >> > >> > > Are we developing this for the PHP community or the Java >> > community? >> > > Or more important for the JBoss community? To me it seems that it >> > > would depend on who you are targeting for your user base. >> > If you want >> > > to target the PHP users to bring them to JBoss, then Bill could be >> > > right. If we do not care about the PHP community, we go >> > down the JMX >> > > way. I think the PHP community will never want to do anything with >> > > JSP. They believe they have what they need to be >> > successful and will >> > > continue to innovate in their own circle. For most of the PHP >> > > community, what they have built is scalable to their needs. >> > > >> > >> -Original Message- >> > >> From: [EMAIL PROTECTED] [mailto:jboss- >> > >> [EMAIL PROTECTED]] On Behalf Of Bill Burke >> > >> Sent: Tuesday, January 14, 2003 1:51 PM >> > >> To: [EMAIL PROTECTED] >> > >> Subject: RE: [JBoss-dev] JNuke dev >> > >> >> > >> The only negative comment I have in using JMX is that the PHP >> > > community >> > >> may >> > >> have a tough time switching over to Nukes on JBoss if you have to >> > >> have >> > > a >> > >> package structure like a SAR or a WAR. I hate to say it, >> > but does it >> > > need >> > >> to be "dumbed-down" for the PHP community? This type of community >> > > needs >> > >> to >> > >> be able to edit a JSP and immediately see the change on the >> > >> webserver. >> > > Is >> > >> it possible to be all JSP based for themes, modules and >> > blocks? You >> > > could >> > >> use a URL fragement and JSP:Include to decide what theme to use. >> > >> >> > >> Just a thought. Maybe JMX and such is the way to go. Just want to >> > > give >> > >> you >> > >> something to think about. >> > >> >> > >> Bill >> > >> >> > >>> -Original Message- >> > >>> From: [EMAIL PROTECTED] >> > >>> [mailto:[EMAIL PROTECTED]]On >> > Behalf Of >> > >>> julien viet >> > >>> Sent: Tuesday, January 14, 2003 11:31 AM >> > >>> To: SourceForge.net >> > >>> Subject: [JBoss-dev] JNuke dev >> > >>> >> > >>> >> > >>> hi folks, >> > >>> >> > >>> JNuke adventure has started. >> > >>> After analysis of PostNuke I've began the development, still early >> > >> though. >> > >>> >> > >>> I keep everything that's good in PostNuke and throw all the shit >> > > away : >> > >>> >> > >>> modules, blocks, permissions system, url system and themes. >> > >>> >> > >>> JMX is used for PostNuke components : themes, >> > >>> modules and blocks are all JMX mbeans. Here are my reasons : >> > >>> >> > >>> A : general >> > >>> >> > >>> 1.we need a component structure, why not JMX ? after all >> > >>>another forum say that's lightweight. >> > >>> >> > >>> 2.theses components do not have to scale, i.e the number of >> > > modules, >> > >>>blocks and themes is very small. >> > >>> >> > >>> B : for modules >> > >>> >> > >>> 1.Ability to deploy/undeploy when application is running. >> > >>> >> > >>> 2.It's easy to deploy additional modules as a separate deploym
JBossScript was RE: [JBoss-dev] JNuke dev
Anybody want to take this on? Could be an interesting project. I think the idea has merit Dain. Great thought. Bill Burke Chief Architect JBoss Group, LLC > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Bill > Burke > Sent: Tuesday, January 14, 2003 3:26 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] JNuke dev > > > Its a good idea. Anybody want to implement this? JBossScript we can call > it. > > Bill > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Dain > > Sundstrom > > Sent: Tuesday, January 14, 2003 2:16 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] JNuke dev > > > > > > Bill, > > > > This reminds me of an I deal I has last night (couldn't sleep). I was > > thinking of the script based MBean support Sacha added, and I thought > > can we make plain old java work like a scripting language. Here is > > what I came up with: > >+ The user writes a class BlahService.java > >+ This source file is places in our deployment directory > >+ We run Xdoclet on it to generate the MBean deployment descriptor > >+ We compile the java file > >+ Deploy > > > > Java as a scripting language. > > > > What do you think? > > > > -dain > > > > On Tuesday, January 14, 2003, at 12:50 PM, Bill Burke wrote: > > > > > The only negative comment I have in using JMX is that the PHP > > > community may > > > have a tough time switching over to Nukes on JBoss if you have to have > > > a > > > package structure like a SAR or a WAR. I hate to say it, but does it > > > need > > > to be "dumbed-down" for the PHP community? This type of community > > > needs to > > > be able to edit a JSP and immediately see the change on the webserver. > > > Is > > > it possible to be all JSP based for themes, modules and blocks? You > > > could > > > use a URL fragement and JSP:Include to decide what theme to use. > > > > > > Just a thought. Maybe JMX and such is the way to go. Just want to > > > give you > > > something to think about. > > > > > > Bill > > > > > >> -Original Message- > > >> From: [EMAIL PROTECTED] > > >> [mailto:[EMAIL PROTECTED]]On Behalf Of > > >> julien viet > > >> Sent: Tuesday, January 14, 2003 11:31 AM > > >> To: SourceForge.net > > >> Subject: [JBoss-dev] JNuke dev > > >> > > >> > > >> hi folks, > > >> > > >> JNuke adventure has started. > > >> After analysis of PostNuke I've began the development, still early > > >> though. > > >> > > >> I keep everything that's good in PostNuke and throw all the shit > > >> away : > > >> > > >> modules, blocks, permissions system, url system and themes. > > >> > > >> JMX is used for PostNuke components : themes, > > >> modules and blocks are all JMX mbeans. Here are my reasons : > > >> > > >> A : general > > >> > > >> 1.we need a component structure, why not JMX ? after all > > >>another forum say that's lightweight. > > >> > > >> 2.theses components do not have to scale, i.e the number of modules, > > >>blocks and themes is very small. > > >> > > >> B : for modules > > >> > > >> 1.Ability to deploy/undeploy when application is running. > > >> > > >> 2.It's easy to deploy additional modules as a separate > deployment and > > >>have them register in the same registry. > > >> > > >> 3.PostNuke is all about invoking module functions. > > >>Url like index.php?module=User&op=register means > > >>that the PN must call the method register on module User. > > >>For me that means that the servlet retrieves the mbean > > >>under the name jnuke:publicmodules:name=User > > >>and invokes the operation register(). > > >> > > >> 4.When a module is installed and configured it plug > > >>block mbeans in the JMX. > > >> > > >> C : for blocks, same reasons as above except 3 and 4 > > >> as invocation is typed for 3. > > >> > > >> D : for themes, same reasons as above except 3 and 4 > > >> as invocation is typed for 3. > > >> > > >> > > >> EJB are used for the model : > > >> > > >> UserEJB, GroupEJB, UserPermissionEJB, UserGroupEJB will > > >> be CMP 2.0 beans. We'll use local invocations and same trick > > >> as in forum to make them faster. Plus more beans. > > >> > > >> Each module is made of : > > >> > > >> 1.ModuleMBean : is the module itself, does not provide > > >> fucntionnalities, > > >> it's used to manager the PublicModule. Main operations are > lifecycle > > >> (initialize, activate, unactivate, uninitialize) > > >> > > >> 2.PublicModuleMBean : is created when ModuleMBean activates and is > > >>responsible for serving requests. The MBean is dynamic and > > >> operations > > >>with no arguments and no returns are served. > > >> > > >> It's up to the module to do as he wants : if he wants MVC > it can, it > > >> it wants to mix HTML and code, it can. First modules won't be MVC > > >> as they simply don't need. > > >> > > >> I
AutoDeploy Source Development ( Was:Re: [JBoss-dev] JNuke dev)
tisdagen den 14 januari 2003 kl 20.16 skrev Dain Sundstrom: I was thinking of the script based MBean support Sacha added, and I thought can we make plain old java work like a scripting language. Here is what I came up with: + The user writes a class BlahService.java + This source file is places in our deployment directory + We run Xdoclet on it to generate the MBean deployment descriptor + We compile the java file + Deploy Java as a scripting language. What do you think? I think it is smoking and remember talking around with David and others using ant for the same functionality ... it is a killer develop feature ... This would be great for the kick-start-demos mentioned at around the same time ... The Deploy folder today has CoreContainerComponents and ApplicationDeployments confusing ordering. Maybe separated as sub folders together with a kick-start folder ? ... to help the Deployer in choosing roles ? ... --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JNuke dev
Who is doing the XDoclet integration? I think it would be a good project for that person. -dain On Tuesday, January 14, 2003, at 02:27 PM, Bill Burke wrote: What I should have said is content developers. Sorry for the snub, but they do requiring a dumbing down of software. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dain Sundstrom Sent: Tuesday, January 14, 2003 2:19 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JNuke dev I think you are dreaming, if you think you will every recruit php developers to any java based solution. Ben, remember the Orielly OS convention? The php guys are perl guys. -dain On Tuesday, January 14, 2003, at 01:03 PM, Ben Sabrin wrote: Are we developing this for the PHP community or the Java community? Or more important for the JBoss community? To me it seems that it would depend on who you are targeting for your user base. If you want to target the PHP users to bring them to JBoss, then Bill could be right. If we do not care about the PHP community, we go down the JMX way. I think the PHP community will never want to do anything with JSP. They believe they have what they need to be successful and will continue to innovate in their own circle. For most of the PHP community, what they have built is scalable to their needs. -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Bill Burke Sent: Tuesday, January 14, 2003 1:51 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JNuke dev The only negative comment I have in using JMX is that the PHP community may have a tough time switching over to Nukes on JBoss if you have to have a package structure like a SAR or a WAR. I hate to say it, but does it need to be "dumbed-down" for the PHP community? This type of community needs to be able to edit a JSP and immediately see the change on the webserver. Is it possible to be all JSP based for themes, modules and blocks? You could use a URL fragement and JSP:Include to decide what theme to use. Just a thought. Maybe JMX and such is the way to go. Just want to give you something to think about. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of julien viet Sent: Tuesday, January 14, 2003 11:31 AM To: SourceForge.net Subject: [JBoss-dev] JNuke dev hi folks, JNuke adventure has started. After analysis of PostNuke I've began the development, still early though. I keep everything that's good in PostNuke and throw all the shit away : modules, blocks, permissions system, url system and themes. JMX is used for PostNuke components : themes, modules and blocks are all JMX mbeans. Here are my reasons : A : general 1.we need a component structure, why not JMX ? after all another forum say that's lightweight. 2.theses components do not have to scale, i.e the number of modules, blocks and themes is very small. B : for modules 1.Ability to deploy/undeploy when application is running. 2.It's easy to deploy additional modules as a separate deployment and have them register in the same registry. 3.PostNuke is all about invoking module functions. Url like index.php?module=User&op=register means that the PN must call the method register on module User. For me that means that the servlet retrieves the mbean under the name jnuke:publicmodules:name=User and invokes the operation register(). 4.When a module is installed and configured it plug block mbeans in the JMX. C : for blocks, same reasons as above except 3 and 4 as invocation is typed for 3. D : for themes, same reasons as above except 3 and 4 as invocation is typed for 3. EJB are used for the model : UserEJB, GroupEJB, UserPermissionEJB, UserGroupEJB will be CMP 2.0 beans. We'll use local invocations and same trick as in forum to make them faster. Plus more beans. Each module is made of : 1.ModuleMBean : is the module itself, does not provide fucntionnalities, it's used to manager the PublicModule. Main operations are lifecycle (initialize, activate, unactivate, uninitialize) 2.PublicModuleMBean : is created when ModuleMBean activates and is responsible for serving requests. The MBean is dynamic and operations with no arguments and no returns are served. It's up to the module to do as he wants : if he wants MVC it can, it it wants to mix HTML and code, it can. First modules won't be MVC as they simply don't need. It's up to the model to have the persistence mecanisms it wants. First modules will use EJB. With lifecycle operations, each module can install itself, for instance : a ModuleMBean is plugged : 1.module configuration, setup of variables 2.initialize : module can creates table, deploy EJB, plugs block. 3.activate : module then go to block admin and creates instances of blocks (if module use blocks), display them on the page. Ea
RE: [JBoss-dev] JNuke dev
bill, you are about as blue blood system as it gets, you are the one doing AOP inline and staring at the SUN... stop recommending stuff for content developers. Again module developers, even in PHP, are of a different caliber and it is not that bad. They can deal with an MBean... let it be, trust them :) HECK they CREATED POSTNUKE, we got JACK! Also I find the "nukes on JBoss" name appealing. The name "nukes" has a light and futuristic feel. Like it goes "woosh" and "frfrrrfr" at the same time. marcf --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: JBossScript was RE: [JBoss-dev] JNuke dev
dain :) marcf > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On > Behalf Of Bill Burke > Sent: Tuesday, January 14, 2003 3:32 PM > To: [EMAIL PROTECTED] > Subject: JBossScript was RE: [JBoss-dev] JNuke dev > > > Anybody want to take this on? Could be an interesting > project. I think the idea has merit Dain. Great thought. > > > Bill Burke > Chief Architect > JBoss Group, LLC > > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of > > Bill Burke > > Sent: Tuesday, January 14, 2003 3:26 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] JNuke dev > > > > > > Its a good idea. Anybody want to implement this? > JBossScript we can > > call it. > > > > Bill > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On > Behalf Of > > > Dain Sundstrom > > > Sent: Tuesday, January 14, 2003 2:16 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: [JBoss-dev] JNuke dev > > > > > > > > > Bill, > > > > > > This reminds me of an I deal I has last night (couldn't > sleep). I > > > was thinking of the script based MBean support Sacha added, and I > > > thought can we make plain old java work like a scripting > language. > > > Here is what I came up with: > > >+ The user writes a class BlahService.java > > >+ This source file is places in our deployment directory > > >+ We run Xdoclet on it to generate the MBean > deployment descriptor > > >+ We compile the java file > > >+ Deploy > > > > > > Java as a scripting language. > > > > > > What do you think? > > > > > > -dain > > > > > > On Tuesday, January 14, 2003, at 12:50 PM, Bill Burke wrote: > > > > > > > The only negative comment I have in using JMX is that the PHP > > > > community may have a tough time switching over to Nukes > on JBoss > > > > if you have to have a > > > > package structure like a SAR or a WAR. I hate to say > it, but does it > > > > need > > > > to be "dumbed-down" for the PHP community? This type > of community > > > > needs to > > > > be able to edit a JSP and immediately see the change on > the webserver. > > > > Is > > > > it possible to be all JSP based for themes, modules and > blocks? You > > > > could > > > > use a URL fragement and JSP:Include to decide what theme to use. > > > > > > > > Just a thought. Maybe JMX and such is the way to go. > Just want > > > > to give you something to think about. > > > > > > > > Bill > > > > > > > >> -Original Message- > > > >> From: [EMAIL PROTECTED] > > > >> > [mailto:[EMAIL PROTECTED]]On Behalf > > > >> Of julien viet > > > >> Sent: Tuesday, January 14, 2003 11:31 AM > > > >> To: SourceForge.net > > > >> Subject: [JBoss-dev] JNuke dev > > > >> > > > >> > > > >> hi folks, > > > >> > > > >> JNuke adventure has started. > > > >> After analysis of PostNuke I've began the development, still > > > >> early though. > > > >> > > > >> I keep everything that's good in PostNuke and throw > all the shit > > > >> away : > > > >> > > > >> modules, blocks, permissions system, url system and themes. > > > >> > > > >> JMX is used for PostNuke components : themes, > > > >> modules and blocks are all JMX mbeans. Here are my reasons : > > > >> > > > >> A : general > > > >> > > > >> 1.we need a component structure, why not JMX ? after all > > > >>another forum say that's lightweight. > > > >> > > > >> 2.theses components do not have to scale, i.e the > number of modules, > > > >>blocks and themes is very small. > > > >> > > > >> B : for modules > > > >> > > > >> 1.Ability to deploy/undeploy when application is running. > > > >> > > > >> 2.It's easy to deploy additional modules as a separate > > deployment and > > > >>have them register in the same registry. > > > >> > > > >> 3.PostNuke is all about invoking module functions. > > > >>Url like index.php?module=User&op=register means > > > >>that the PN must call the method register on module User. > > > >>For me that means that the servlet retrieves the mbean > > > >>under the name jnuke:publicmodules:name=User > > > >>and invokes the operation register(). > > > >> > > > >> 4.When a module is installed and configured it plug > > > >>block mbeans in the JMX. > > > >> > > > >> C : for blocks, same reasons as above except 3 and 4 > > > >> as invocation is typed for 3. > > > >> > > > >> D : for themes, same reasons as above except 3 and 4 > > > >> as invocation is typed for 3. > > > >> > > > >> > > > >> EJB are used for the model : > > > >> > > > >> UserEJB, GroupEJB, UserPermissionEJB, UserGroupEJB > will be CMP > > > >> 2.0 beans. We'll use local invocations and same trick > as in forum > > > >> to make them faster. Plus more beans. > > > >> > > > >> Each module is made of : > > > >> > > > >> 1.ModuleMBean : is the module itself, does not provide > > > >> fucntionnalities
RE: Re[2]: [JBoss-dev] JNuke dev
JBossNuke ? > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > julien viet > Sent: Tuesday, January 14, 2003 12:35 PM > To: Bill Burke > Subject: Re[2]: [JBoss-dev] JNuke dev > > > ok, do you have a name shorter though ? just nuke for instance ? > > BB> Again, > > BB> The type of developer writing content is usually a different > calaber than > BB> those writing server software. IMHO, it needs to be dumbed-down. The > BB> reason why these things like postnuke become so popular is > that they are so > BB> easy to hack for even the least experienced coder. Copy, > cut, paste. Not, > BB> write xml, compile, jar, maintain ANT files, etc... You get what I'm > BB> saying? > > BB> This is just something to think about and I'm not advocating > any specific > BB> approach. > > BB> And again, BTW, JNuke is already trademarked. You must call > in Nukes on > BB> JBoss or think of a better name. > > BB> Bill > > >> -Original Message- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED]]On Behalf Of marc > >> fleury > >> Sent: Tuesday, January 14, 2003 2:40 PM > >> To: [EMAIL PROTECTED] > >> Subject: RE: [JBoss-dev] JNuke dev > >> > >> > >> I am all for JMX if it works . Also the idea is to port the modules we > >> like bit by bit to the sar format and this is CLEARLY a > microkernel job. > >> I think julien stroke on something interesting when he noticed the > >> URL:command mapping to interfaces. What this means is that modules will > >> expose interfaces as mbeans and that is all it takes. Difficult? yeah > >> for php guys, heck they must get EJB first. But for us? we are doing > >> the port anyway... > >> > >> let's go julien, speed speed my friend, > >> > >> marcf > >> > >> > -Original Message- > >> > From: [EMAIL PROTECTED] > >> > [mailto:[EMAIL PROTECTED]] On > >> > Behalf Of Dain Sundstrom > >> > Sent: Tuesday, January 14, 2003 2:19 PM > >> > To: [EMAIL PROTECTED] > >> > Subject: Re: [JBoss-dev] JNuke dev > >> > > >> > > >> > I think you are dreaming, if you think you will every recruit php > >> > developers to any java based solution. Ben, remember the Orielly OS > >> > convention? The php guys are perl guys. > >> > > >> > -dain > >> > > >> > On Tuesday, January 14, 2003, at 01:03 PM, Ben Sabrin wrote: > >> > > >> > > Are we developing this for the PHP community or the Java > >> > community? > >> > > Or more important for the JBoss community? To me it seems that it > >> > > would depend on who you are targeting for your user base. > >> > If you want > >> > > to target the PHP users to bring them to JBoss, then Bill could be > >> > > right. If we do not care about the PHP community, we go > >> > down the JMX > >> > > way. I think the PHP community will never want to do anything with > >> > > JSP. They believe they have what they need to be > >> > successful and will > >> > > continue to innovate in their own circle. For most of the PHP > >> > > community, what they have built is scalable to their needs. > >> > > > >> > >> -Original Message- > >> > >> From: [EMAIL PROTECTED] [mailto:jboss- > >> > >> [EMAIL PROTECTED]] On Behalf Of Bill Burke > >> > >> Sent: Tuesday, January 14, 2003 1:51 PM > >> > >> To: [EMAIL PROTECTED] > >> > >> Subject: RE: [JBoss-dev] JNuke dev > >> > >> > >> > >> The only negative comment I have in using JMX is that the PHP > >> > > community > >> > >> may > >> > >> have a tough time switching over to Nukes on JBoss if you have to > >> > >> have > >> > > a > >> > >> package structure like a SAR or a WAR. I hate to say it, > >> > but does it > >> > > need > >> > >> to be "dumbed-down" for the PHP community? This type of community > >> > > needs > >> > >> to > >> > >> be able to edit a JSP and immediately see the change on the > >> > >> webserver. > >> > > Is > >> > >> it possible to be all JSP based for themes, modules and > >> > blocks? You > >> > > could > >> > >> use a URL fragement and JSP:Include to decide what theme to use. > >> > >> > >> > >> Just a thought. Maybe JMX and such is the way to go. > Just want to > >> > > give > >> > >> you > >> > >> something to think about. > >> > >> > >> > >> Bill > >> > >> > >> > >>> -Original Message- > >> > >>> From: [EMAIL PROTECTED] > >> > >>> [mailto:[EMAIL PROTECTED]]On > >> > Behalf Of > >> > >>> julien viet > >> > >>> Sent: Tuesday, January 14, 2003 11:31 AM > >> > >>> To: SourceForge.net > >> > >>> Subject: [JBoss-dev] JNuke dev > >> > >>> > >> > >>> > >> > >>> hi folks, > >> > >>> > >> > >>> JNuke adventure has started. > >> > >>> After analysis of PostNuke I've began the development, > still early > >> > >> though. > >> > >>> > >> > >>> I keep everything that's good in PostNuke and throw all the shit > >> > > away : > >> > >>> > >> > >>> modules, blocks, permissions system, url system and themes. > >> > >>> > >> > >>> JMX is used for PostNuke components : themes, > >> > >>> modules and blocks are all JMX mbeans. Here are my reasons
[JBoss-dev] [ jboss-Bugs-667341 ] Initial Session AUTH failure
Bugs item #667341, was opened at 2003-01-13 19:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=667341&group_id=22866 Category: JBossWeb Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Peter Luttrell (objec) Assigned to: Nobody/Anonymous (nobody) Summary: Initial Session AUTH failure Initial Comment: JBoss3.0.5 - release with jdk1.4.1_01 Before this I was using JBoss3.0.5RC1 and this problem did NOT occur. After I startup JBoss or redeploy my ear, which contains a war which uses authentication (my login module), the very first session that attempts to authenticate fails. If i try it again in the same browser window it still fails. If i open a new window (new sesison id), it works. This happens every time i deploy. I have tried opening a new browser after i deploy but the problem still happens. This is a problem introduced between JBoss3.0.5-RC1 and 3.0.5-Release. -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-01-14 20:56 Message: Logged In: YES user_id=44062 A simple test case would be to have a servlet that looks at getPathInfo to see if a path param is included in it. I had thought it would effect all requests - but in retesting it only appears to be effecting connections via mod_jk and AJP13 I'll do some extra tests and see if I can come up with a normal HTTP test case. -- Comment By: Scott M Stark (starksm) Date: 2003-01-14 19:17 Message: Logged In: YES user_id=175228 I have created a servlet that creates a session and that is secured and returns a page with a URL to itself with URL that is encoded to enable URL rewriting. I don't have a problem accessing this servlet on the first attempt when there is no session, or on any subsequent attempt. I have disabled cookies in my browser so I know the URL rewriting is taking place. In the absence of a testcase that demonstrates the problem I can't judge whether this problem warrents a new 3.0.6 release. -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-01-14 09:53 Message: Logged In: YES user_id=44062 This issue is not so much security related, but URL processing of path parameters like ;jsessionid. If you are writing your webapp correctly, you will be rewriting your URLs. If the server has not seen a cookie from the client it will insert such a path parameter. The problem is that path parameters are only being correctly decoded on the first request of a persistent connection. For all other requests, they are being seen as part of the URL rather than as something extra. Thus my own test harnesses for this past without a problem as they were the first request on a connection. Webapps that do not rewrite URLs (many) or who have apps that create a session before authetication takes place - will probably not be effective. So it's not totally broken - just significantly so. I'm done a fixed release of Jetty (4.2.5) and Jules is lined up to make a replacement jbossweb.sar -- Comment By: Scott M Stark (starksm) Date: 2003-01-14 01:27 Message: Logged In: YES user_id=175228 So is security totally broken in the 3.0.5 release? What is the exact issue so I can add a testcase for this? -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-01-13 22:45 Message: Logged In: YES user_id=44062 This is an optimization bug introduced in JBossWeb. URL path parameters, such as ;jsessionid are not handled correctly for persistent connections. A fix is on it's way -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=667341&group_id=22866 --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re[4]: [JBoss-dev] JNuke dev
what about "Nukes on JBoss" shortname nukes4j ? JB> JBossNuke ? >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED]]On Behalf Of >> julien viet >> Sent: Tuesday, January 14, 2003 12:35 PM >> To: Bill Burke >> Subject: Re[2]: [JBoss-dev] JNuke dev >> >> >> ok, do you have a name shorter though ? just nuke for instance ? >> >> BB> Again, >> >> BB> The type of developer writing content is usually a different >> calaber than >> BB> those writing server software. IMHO, it needs to be dumbed-down. The >> BB> reason why these things like postnuke become so popular is >> that they are so >> BB> easy to hack for even the least experienced coder. Copy, >> cut, paste. Not, >> BB> write xml, compile, jar, maintain ANT files, etc... You get what I'm >> BB> saying? >> >> BB> This is just something to think about and I'm not advocating >> any specific >> BB> approach. >> >> BB> And again, BTW, JNuke is already trademarked. You must call >> in Nukes on >> BB> JBoss or think of a better name. >> >> BB> Bill >> >> >> -Original Message- >> >> From: [EMAIL PROTECTED] >> >> [mailto:[EMAIL PROTECTED]]On Behalf Of marc >> >> fleury >> >> Sent: Tuesday, January 14, 2003 2:40 PM >> >> To: [EMAIL PROTECTED] >> >> Subject: RE: [JBoss-dev] JNuke dev >> >> >> >> >> >> I am all for JMX if it works . Also the idea is to port the modules we >> >> like bit by bit to the sar format and this is CLEARLY a >> microkernel job. >> >> I think julien stroke on something interesting when he noticed the >> >> URL:command mapping to interfaces. What this means is that modules will >> >> expose interfaces as mbeans and that is all it takes. Difficult? yeah >> >> for php guys, heck they must get EJB first. But for us? we are doing >> >> the port anyway... >> >> >> >> let's go julien, speed speed my friend, >> >> >> >> marcf >> >> >> >> > -Original Message- >> >> > From: [EMAIL PROTECTED] >> >> > [mailto:[EMAIL PROTECTED]] On >> >> > Behalf Of Dain Sundstrom >> >> > Sent: Tuesday, January 14, 2003 2:19 PM >> >> > To: [EMAIL PROTECTED] >> >> > Subject: Re: [JBoss-dev] JNuke dev >> >> > >> >> > >> >> > I think you are dreaming, if you think you will every recruit php >> >> > developers to any java based solution. Ben, remember the Orielly OS >> >> > convention? The php guys are perl guys. >> >> > >> >> > -dain >> >> > >> >> > On Tuesday, January 14, 2003, at 01:03 PM, Ben Sabrin wrote: >> >> > >> >> > > Are we developing this for the PHP community or the Java >> >> > community? >> >> > > Or more important for the JBoss community? To me it seems that it >> >> > > would depend on who you are targeting for your user base. >> >> > If you want >> >> > > to target the PHP users to bring them to JBoss, then Bill could be >> >> > > right. If we do not care about the PHP community, we go >> >> > down the JMX >> >> > > way. I think the PHP community will never want to do anything with >> >> > > JSP. They believe they have what they need to be >> >> > successful and will >> >> > > continue to innovate in their own circle. For most of the PHP >> >> > > community, what they have built is scalable to their needs. >> >> > > >> >> > >> -Original Message- >> >> > >> From: [EMAIL PROTECTED] [mailto:jboss- >> >> > >> [EMAIL PROTECTED]] On Behalf Of Bill Burke >> >> > >> Sent: Tuesday, January 14, 2003 1:51 PM >> >> > >> To: [EMAIL PROTECTED] >> >> > >> Subject: RE: [JBoss-dev] JNuke dev >> >> > >> >> >> > >> The only negative comment I have in using JMX is that the PHP >> >> > > community >> >> > >> may >> >> > >> have a tough time switching over to Nukes on JBoss if you have to >> >> > >> have >> >> > > a >> >> > >> package structure like a SAR or a WAR. I hate to say it, >> >> > but does it >> >> > > need >> >> > >> to be "dumbed-down" for the PHP community? This type of community >> >> > > needs >> >> > >> to >> >> > >> be able to edit a JSP and immediately see the change on the >> >> > >> webserver. >> >> > > Is >> >> > >> it possible to be all JSP based for themes, modules and >> >> > blocks? You >> >> > > could >> >> > >> use a URL fragement and JSP:Include to decide what theme to use. >> >> > >> >> >> > >> Just a thought. Maybe JMX and such is the way to go. >> Just want to >> >> > > give >> >> > >> you >> >> > >> something to think about. >> >> > >> >> >> > >> Bill >> >> > >> >> >> > >>> -Original Message- >> >> > >>> From: [EMAIL PROTECTED] >> >> > >>> [mailto:[EMAIL PROTECTED]]On >> >> > Behalf Of >> >> > >>> julien viet >> >> > >>> Sent: Tuesday, January 14, 2003 11:31 AM >> >> > >>> To: SourceForge.net >> >> > >>> Subject: [JBoss-dev] JNuke dev >> >> > >>> >> >> > >>> >> >> > >>> hi folks, >> >> > >>> >> >> > >>> JNuke adventure has started. >> >> > >>> After analysis of PostNuke I've began the development, >> still early >> >> > >> though. >> >> > >>> >> >> > >>> I keep everything that's good in PostNuke and throw all the shit >> >> > > away : >> >> > >>> >> >> > >>> modu
RE: JBossScript was RE: [JBoss-dev] JNuke dev
Hello, And what would be the goal for that? Could you give examples? regards, WS --- marc fleury <[EMAIL PROTECTED]> a écrit : > dain :) > > marcf > > > -Original Message- > > From: > [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]] > On > > Behalf Of Bill Burke > > Sent: Tuesday, January 14, 2003 3:32 PM > > To: [EMAIL PROTECTED] > > Subject: JBossScript was RE: [JBoss-dev] JNuke dev > > > > > > Anybody want to take this on? Could be an > interesting > > project. I think the idea has merit Dain. Great > thought. > > > > > > Bill Burke > > Chief Architect > > JBoss Group, LLC > > > > > > > > > -Original Message- > > > From: > [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED]]On > Behalf Of > > > Bill Burke > > > Sent: Tuesday, January 14, 2003 3:26 PM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [JBoss-dev] JNuke dev > > > > > > > > > Its a good idea. Anybody want to implement > this? > > JBossScript we can > > > call it. > > > > > > Bill > > > > > > > -Original Message- > > > > From: > [EMAIL PROTECTED] > > > > > [mailto:[EMAIL PROTECTED]]On > > > Behalf Of > > > > Dain Sundstrom > > > > Sent: Tuesday, January 14, 2003 2:16 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: [JBoss-dev] JNuke dev > > > > > > > > > > > > Bill, > > > > > > > > This reminds me of an I deal I has last night > (couldn't > > sleep). I > > > > was thinking of the script based MBean support > Sacha added, and I > > > > thought can we make plain old java work like a > scripting > > language. > > > > Here is what I came up with: > > > >+ The user writes a class BlahService.java > > > >+ This source file is places in our > deployment directory > > > >+ We run Xdoclet on it to generate the > MBean > > deployment descriptor > > > >+ We compile the java file > > > >+ Deploy > > > > > > > > Java as a scripting language. > > > > > > > > What do you think? > > > > > > > > -dain > > > > > > > > On Tuesday, January 14, 2003, at 12:50 PM, > Bill Burke wrote: > > > > > > > > > The only negative comment I have in using > JMX is that the PHP > > > > > community may have a tough time switching > over to Nukes > > on JBoss > > > > > if you have to have a > > > > > package structure like a SAR or a WAR. I > hate to say > > it, but does it > > > > > need > > > > > to be "dumbed-down" for the PHP community? > This type > > of community > > > > > needs to > > > > > be able to edit a JSP and immediately see > the change on > > the webserver. > > > > > Is > > > > > it possible to be all JSP based for themes, > modules and > > blocks? You > > > > > could > > > > > use a URL fragement and JSP:Include to > decide what theme to use. > > > > > > > > > > Just a thought. Maybe JMX and such is the > way to go. > > Just want > > > > > to give you something to think about. > > > > > > > > > > Bill > > > > > > > > > >> -Original Message- > > > > >> From: > [EMAIL PROTECTED] > > > > >> > > > [mailto:[EMAIL PROTECTED]]On > Behalf > > > > >> Of julien viet > > > > >> Sent: Tuesday, January 14, 2003 11:31 AM > > > > >> To: SourceForge.net > > > > >> Subject: [JBoss-dev] JNuke dev > > > > >> > > > > >> > > > > >> hi folks, > > > > >> > > > > >> JNuke adventure has started. > > > > >> After analysis of PostNuke I've began the > development, still > > > > >> early though. > > > > >> > > > > >> I keep everything that's good in PostNuke > and throw > > all the shit > > > > >> away : > > > > >> > > > > >> modules, blocks, permissions system, url > system and themes. > > > > >> > > > > >> JMX is used for PostNuke components : > themes, > > > > >> modules and blocks are all JMX mbeans. Here > are my reasons : > > > > >> > > > > >> A : general > > > > >> > > > > >> 1.we need a component structure, why not > JMX ? after all > > > > >>another forum say that's lightweight. > > > > >> > > > > >> 2.theses components do not have to scale, > i.e the > > number of modules, > > > > >>blocks and themes is very small. > > > > >> > > > > >> B : for modules > > > > >> > > > > >> 1.Ability to deploy/undeploy when > application is running. > > > > >> > > > > >> 2.It's easy to deploy additional modules > as a separate > > > deployment and > > > > >>have them register in the same registry. > > > > >> > > > > >> 3.PostNuke is all about invoking module > functions. > > > > >>Url like > index.php?module=User&op=register means > > > > >>that the PN must call the method > register on module User. > > > > >>For me that means that the servlet > retrieves the mbean > > > > >>under the name > jnuke:publicmodules:name=User > > > > >>and invokes the operation register(). > > > > >> > > > > >> 4.When a module is installed and > configured it plug > > > > >>block mbeans in the JMX. > > > > >> > > > > >> C : for blocks, same reasons as above > except 3 and 4 > > > > >> as invocation is typed for 3. > > > > >>
RE: JBossScript was RE: [JBoss-dev] JNuke dev
Do you use XDoclet to generate your EJB files? Think of writing your Bean.java file, plopping it in the jboss deploy directory, and magically, the bean is ready for use. Edit the Bean.java file in the deploy directory and the bean magically gets redeployed with your changes. Think of JSPs. That is a good analogy. JSPs get compiled into Java servlet code, then compiled into a class. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > wonder sonic > Sent: Tuesday, January 14, 2003 4:19 PM > To: [EMAIL PROTECTED] > Subject: RE: JBossScript was RE: [JBoss-dev] JNuke dev > > > Hello, > And what would be the goal for that? > Could you give examples? > > regards, > WS > > --- marc fleury <[EMAIL PROTECTED]> a écrit : > > dain :) > > > > marcf > > > > > -Original Message- > > > From: > > [EMAIL PROTECTED] > > > > > > [mailto:[EMAIL PROTECTED]] > > On > > > Behalf Of Bill Burke > > > Sent: Tuesday, January 14, 2003 3:32 PM > > > To: [EMAIL PROTECTED] > > > Subject: JBossScript was RE: [JBoss-dev] JNuke dev > > > > > > > > > Anybody want to take this on? Could be an > > interesting > > > project. I think the idea has merit Dain. Great > > thought. > > > > > > > > > Bill Burke > > > Chief Architect > > > JBoss Group, LLC > > > > > > > > > > > > > -Original Message- > > > > From: > > [EMAIL PROTECTED] > > > > > > > [mailto:[EMAIL PROTECTED]]On > > Behalf Of > > > > Bill Burke > > > > Sent: Tuesday, January 14, 2003 3:26 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: RE: [JBoss-dev] JNuke dev > > > > > > > > > > > > Its a good idea. Anybody want to implement > > this? > > > JBossScript we can > > > > call it. > > > > > > > > Bill > > > > > > > > > -Original Message- > > > > > From: > > [EMAIL PROTECTED] > > > > > > > > [mailto:[EMAIL PROTECTED]]On > > > > > Behalf Of > > > > > Dain Sundstrom > > > > > Sent: Tuesday, January 14, 2003 2:16 PM > > > > > To: [EMAIL PROTECTED] > > > > > Subject: Re: [JBoss-dev] JNuke dev > > > > > > > > > > > > > > > Bill, > > > > > > > > > > This reminds me of an I deal I has last night > > (couldn't > > > sleep). I > > > > > was thinking of the script based MBean support > > Sacha added, and I > > > > > thought can we make plain old java work like a > > scripting > > > language. > > > > > Here is what I came up with: > > > > >+ The user writes a class BlahService.java > > > > >+ This source file is places in our > > deployment directory > > > > >+ We run Xdoclet on it to generate the > > MBean > > > deployment descriptor > > > > >+ We compile the java file > > > > >+ Deploy > > > > > > > > > > Java as a scripting language. > > > > > > > > > > What do you think? > > > > > > > > > > -dain > > > > > > > > > > On Tuesday, January 14, 2003, at 12:50 PM, > > Bill Burke wrote: > > > > > > > > > > > The only negative comment I have in using > > JMX is that the PHP > > > > > > community may have a tough time switching > > over to Nukes > > > on JBoss > > > > > > if you have to have a > > > > > > package structure like a SAR or a WAR. I > > hate to say > > > it, but does it > > > > > > need > > > > > > to be "dumbed-down" for the PHP community? > > This type > > > of community > > > > > > needs to > > > > > > be able to edit a JSP and immediately see > > the change on > > > the webserver. > > > > > > Is > > > > > > it possible to be all JSP based for themes, > > modules and > > > blocks? You > > > > > > could > > > > > > use a URL fragement and JSP:Include to > > decide what theme to use. > > > > > > > > > > > > Just a thought. Maybe JMX and such is the > > way to go. > > > Just want > > > > > > to give you something to think about. > > > > > > > > > > > > Bill > > > > > > > > > > > >> -Original Message- > > > > > >> From: > > [EMAIL PROTECTED] > > > > > >> > > > > > > [mailto:[EMAIL PROTECTED]]On > > Behalf > > > > > >> Of julien viet > > > > > >> Sent: Tuesday, January 14, 2003 11:31 AM > > > > > >> To: SourceForge.net > > > > > >> Subject: [JBoss-dev] JNuke dev > > > > > >> > > > > > >> > > > > > >> hi folks, > > > > > >> > > > > > >> JNuke adventure has started. > > > > > >> After analysis of PostNuke I've began the > > development, still > > > > > >> early though. > > > > > >> > > > > > >> I keep everything that's good in PostNuke > > and throw > > > all the shit > > > > > >> away : > > > > > >> > > > > > >> modules, blocks, permissions system, url > > system and themes. > > > > > >> > > > > > >> JMX is used for PostNuke components : > > themes, > > > > > >> modules and blocks are all JMX mbeans. Here > > are my reasons : > > > > > >> > > > > > >> A : general > > > > > >> > > > > > >> 1.we need a component structure, why not > > JMX ? after all > > > > > >>another forum say that's lightweight. > > > > > >> > > > > > >> 2.theses components do not have to scale, > > i.e the > > > number of modules, > > > > > >>blocks and them
Re[2]: JBossScript was RE: [JBoss-dev] JNuke dev
that would be nice if deployer could create bean metadata directly without creating descriptors and then directly deploy the bean with metadata. reuse xdoclet code and generate metadata instead of writing DD that would be reparsed anyway to generate same data later. BB> Do you use XDoclet to generate your EJB files? BB> Think of writing your Bean.java file, plopping it in the jboss deploy BB> directory, and magically, the bean is ready for use. BB> Edit the Bean.java file in the deploy directory and the bean magically gets BB> redeployed with your changes. BB> Think of JSPs. That is a good analogy. JSPs get compiled into Java servlet BB> code, then compiled into a class. BB> Bill >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED]]On Behalf Of >> wonder sonic >> Sent: Tuesday, January 14, 2003 4:19 PM >> To: [EMAIL PROTECTED] >> Subject: RE: JBossScript was RE: [JBoss-dev] JNuke dev >> >> >> Hello, >> And what would be the goal for that? >> Could you give examples? >> >> regards, >> WS >> >> --- marc fleury <[EMAIL PROTECTED]> a écrit : > >> dain :) >> > >> > marcf >> > >> > > -Original Message- >> > > From: >> > [EMAIL PROTECTED] >> > > >> > >> [mailto:[EMAIL PROTECTED]] >> > On >> > > Behalf Of Bill Burke >> > > Sent: Tuesday, January 14, 2003 3:32 PM >> > > To: [EMAIL PROTECTED] >> > > Subject: JBossScript was RE: [JBoss-dev] JNuke dev >> > > >> > > >> > > Anybody want to take this on? Could be an >> > interesting >> > > project. I think the idea has merit Dain. Great >> > thought. >> > > >> > > >> > > Bill Burke >> > > Chief Architect >> > > JBoss Group, LLC >> > > >> > > >> > > >> > > > -Original Message- >> > > > From: >> > [EMAIL PROTECTED] >> > > > >> > >> [mailto:[EMAIL PROTECTED]]On >> > Behalf Of >> > > > Bill Burke >> > > > Sent: Tuesday, January 14, 2003 3:26 PM >> > > > To: [EMAIL PROTECTED] >> > > > Subject: RE: [JBoss-dev] JNuke dev >> > > > >> > > > >> > > > Its a good idea. Anybody want to implement >> > this? >> > > JBossScript we can >> > > > call it. >> > > > >> > > > Bill >> > > > >> > > > > -Original Message- >> > > > > From: >> > [EMAIL PROTECTED] >> > > > > >> > >> [mailto:[EMAIL PROTECTED]]On >> > >> > > Behalf Of >> > > > > Dain Sundstrom >> > > > > Sent: Tuesday, January 14, 2003 2:16 PM >> > > > > To: [EMAIL PROTECTED] >> > > > > Subject: Re: [JBoss-dev] JNuke dev >> > > > > >> > > > > >> > > > > Bill, >> > > > > >> > > > > This reminds me of an I deal I has last night >> > (couldn't >> > > sleep). I >> > > > > was thinking of the script based MBean support >> > Sacha added, and I >> > > > > thought can we make plain old java work like a >> > scripting >> > > language. >> > > > > Here is what I came up with: >> > > > >+ The user writes a class BlahService.java >> > > > >+ This source file is places in our >> > deployment directory >> > > > >+ We run Xdoclet on it to generate the >> > MBean >> > > deployment descriptor >> > > > >+ We compile the java file >> > > > >+ Deploy >> > > > > >> > > > > Java as a scripting language. >> > > > > >> > > > > What do you think? >> > > > > >> > > > > -dain >> > > > > >> > > > > On Tuesday, January 14, 2003, at 12:50 PM, >> > Bill Burke wrote: >> > > > > >> > > > > > The only negative comment I have in using >> > JMX is that the PHP >> > > > > > community may have a tough time switching >> > over to Nukes >> > > on JBoss >> > > > > > if you have to have a >> > > > > > package structure like a SAR or a WAR. I >> > hate to say >> > > it, but does it >> > > > > > need >> > > > > > to be "dumbed-down" for the PHP community? >> > This type >> > > of community >> > > > > > needs to >> > > > > > be able to edit a JSP and immediately see >> > the change on >> > > the webserver. >> > > > > > Is >> > > > > > it possible to be all JSP based for themes, >> > modules and >> > > blocks? You >> > > > > > could >> > > > > > use a URL fragement and JSP:Include to >> > decide what theme to use. >> > > > > > >> > > > > > Just a thought. Maybe JMX and such is the >> > way to go. >> > > Just want >> > > > > > to give you something to think about. >> > > > > > >> > > > > > Bill >> > > > > > >> > > > > >> -Original Message- >> > > > > >> From: >> > [EMAIL PROTECTED] >> > > > > >> >> > > >> > >> [mailto:[EMAIL PROTECTED]]On >> > Behalf >> > > > > >> Of julien viet >> > > > > >> Sent: Tuesday, January 14, 2003 11:31 AM >> > > > > >> To: SourceForge.net >> > > > > >> Subject: [JBoss-dev] JNuke dev >> > > > > >> >> > > > > >> >> > > > > >> hi folks, >> > > > > >> >> > > > > >> JNuke adventure has started. >> > > > > >> After analysis of PostNuke I've began the >> > development, still >> > > > > >> early though. >> > > > > >> >> > > > > >> I keep everything that's good in PostNuke >> > and throw >> > > all the shit >> > > > > >> away : >> > > > > >> >> > > > > >> modules, blocks, permissions system, url >> > system and themes. >>
[JBoss-dev] Anyone able to access cvs?
CVS is still acting up on me. After clearing two more locks I now cannot even get an update. Is it just my route or is this seen by everyone jboss-3.2 38>date -u Tue Jan 14 22:42:56 2003 jboss-3.2 39>ping cvs.jboss.sourceforge.net Pinging cvs.sourceforge.net [66.35.250.207] with 32 bytes of data: Reply from 66.35.250.207: bytes=32 time=31ms TTL=49 Request timed out. Request timed out. Reply from 66.35.250.207: bytes=32 time=31ms TTL=49 Ping statistics for 66.35.250.207: Packets: Sent = 4, Received = 2, Lost = 2 (50% loss), Approximate round trip times in milli-seconds: Minimum = 31ms, Maximum = 31ms, Average = 15ms jboss-3.2 40> Scott Stark Chief Technology Officer JBoss Group, LLC --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] TransactionInterceptor in HEAD
We need to talk about this... If the client is standalone and using UserTx, then all the calls in one tx MUST go to the same jboss server, since the client "tm" doesn't handle 2pc distributed tx or much of anything-- just committing one branch. In other words, you probably shouldn't be using UT on the client with clustering at the moment. Is there some way to make this sticky? If the server fails, I guess an exception should be thrown on the client and the client should know enough to start the tx over?? If the client is a jboss instance, then this should be looking for the real jboss tm on that server. This is not yet implemented as I recall. Comments? thanks david jencks On Monday, January 13, 2003, at 10:49 AM, Sacha Labourey wrote: Hello, The code for TransactionInterceptor (client side) in HEAD does this at one point (in the invoke): transactionManagerServiceName = new ObjectName (DEFAULT_CLIENT_TM_NAME_STUB) + invoker.getServerID().toObjectNameClause()); In the standard scenario, that is fine, but in the clustering case, what do you expect invoker.getServerID() will return? This is problematic because when the invocation goes through the interceptor, we still cannot say which will be the target server (it is elected in the ... invoker itself! Cheers, sacha --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Transaction propagation change
On Monday, January 13, 2003, at 08:58 AM, Barlow, Dustin wrote: Will this fix also be back ported to the 3.x series as well? This is a huge issue for those of us who are or plan to use more then one jboss node in our applications. Which fix? Not propagating anything is easy to port. Enabling distributed transactions is a lot of work that is not all done and may not be easy to backport. I certainly don't want to try with 3.0, I might consider 3.2. david jencks Dustin -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 12, 2003 4:19 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Transaction propagation change Regarding bug: [ 663114 ] MarshallException when accessing remote bean, this is due to a change made to store the transaction context of an Invocation in the as_is_payload rather than the transient_payload map about the time of the 3.0.0 release. Our tx info never has been serializable, and the marshalled form of the tpc is handled at the MarshalledInvocation layer anyway rather than relying on the correct form of the tx context being placed into the Invocation. In the case of this particular bug, an EJB A on host 1 calls an EJB B on host 2. Both EJBs uses REQUIRED transaction attributes for all methods, so according to the EJB spec this call should actually fail since the expectation a client can assume is that the existing transaction context of EJB A will be propagated. However, we fail all calls regardless of the transaction attributes. If EJB B was using RequiresNew the call should succeed. I'm inclined to move the transaction context into the transient_payload map to allow valid calls to succeed. This does raise the possibility that the application data can become corrupted if it does expected distributed transaction semantics on inter-server EJB calls. We need to cleanup the tx propagation so that its consistent with the spec. Both for the case of not supporting tx propagation and the case of supporting it. Is this being included in the 4.0 changes concerning the distributed transaction support? Scott Stark Chief Technology Officer JBoss Group, LLC --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Anyone able to access cvs?
I can. bash-2.05a$ cvs -n update [EMAIL PROTECTED]'s password: cvs server: Updating . cvs server: Updating bridge M bridge/EntityBridgeInvocationHandler.java cvs server: Updating ejbql cvs server: Updating jdbc U jdbc/JDBCCommandFactory.java U jdbc/JDBCCreateEntityCommand.java U jdbc/JDBCEJBQLCompiler.java On Tuesday, January 14, 2003, at 04:47 PM, Scott M Stark wrote: CVS is still acting up on me. After clearing two more locks I now cannot even get an update. Is it just my route or is this seen by everyone jboss-3.2 38>date -u Tue Jan 14 22:42:56 2003 jboss-3.2 39>ping cvs.jboss.sourceforge.net Pinging cvs.sourceforge.net [66.35.250.207] with 32 bytes of data: Reply from 66.35.250.207: bytes=32 time=31ms TTL=49 Request timed out. Request timed out. Reply from 66.35.250.207: bytes=32 time=31ms TTL=49 Ping statistics for 66.35.250.207: Packets: Sent = 4, Received = 2, Lost = 2 (50% loss), Approximate round trip times in milli-seconds: Minimum = 31ms, Maximum = 31ms, Average = 15ms jboss-3.2 40> Scott Stark Chief Technology Officer JBoss Group, LLC --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Anyone able to access cvs?
hi scott, here in germany no problems at all: holgerbaxmann@Holger-Baxmanns-Computer:~ $ uname -a Darwin Holger-Baxmanns-Computer.local. 6.3 Darwin Kernel Version 6.3: Sat Dec 14 03:11:25 PST 2002; root:xnu/xnu-344.23.obj~4/RELEASE_PPC Power Macintosh powerpc holgerbaxmann@Holger-Baxmanns-Computer:~ $ ping cvs.jboss.sourceforge.net PING cvs.sourceforge.net (66.35.250.207): 56 data bytes 64 bytes from 66.35.250.207: icmp_seq=0 ttl=48 time=236.075 ms 64 bytes from 66.35.250.207: icmp_seq=1 ttl=48 time=234.639 ms 64 bytes from 66.35.250.207: icmp_seq=2 ttl=48 time=234.241 ms 64 bytes from 66.35.250.207: icmp_seq=3 ttl=48 time=234.728 ms 64 bytes from 66.35.250.207: icmp_seq=4 ttl=48 time=235.069 ms 64 bytes from 66.35.250.207: icmp_seq=5 ttl=48 time=235.187 ms 64 bytes from 66.35.250.207: icmp_seq=7 ttl=48 time=233.94 ms 64 bytes from 66.35.250.207: icmp_seq=8 ttl=48 time=236.483 ms ^C --- cvs.sourceforge.net ping statistics --- 9 packets transmitted, 8 packets received, 11% packet loss round-trip min/avg/max = 233.94/235.045/236.483 ms holgerbaxmann@Holger-Baxmanns-Computer:~ $ btw: how do you get the counter on your prompt ??? bax > Von: "Scott M Stark" <[EMAIL PROTECTED]> > Organisation: JBoss Group, LLC > Antworten an: [EMAIL PROTECTED] > Datum: Tue, 14 Jan 2003 14:47:48 -0800 > An: <[EMAIL PROTECTED]> > Betreff: [JBoss-dev] Anyone able to access cvs? > > CVS is still acting up on me. After clearing two more locks I now cannot > even get an update. Is it just my route or is this seen by everyone > > jboss-3.2 38>date -u > Tue Jan 14 22:42:56 2003 > jboss-3.2 39>ping cvs.jboss.sourceforge.net > > Pinging cvs.sourceforge.net [66.35.250.207] with 32 bytes of data: > > Reply from 66.35.250.207: bytes=32 time=31ms TTL=49 > Request timed out. > Request timed out. > Reply from 66.35.250.207: bytes=32 time=31ms TTL=49 > > Ping statistics for 66.35.250.207: > Packets: Sent = 4, Received = 2, Lost = 2 (50% loss), > Approximate round trip times in milli-seconds: > Minimum = 31ms, Maximum = 31ms, Average = 15ms > jboss-3.2 40> > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > > --- > This SF.NET email is sponsored by: Take your first step towards giving > your online business a competitive advantage. Test-drive a Thawte SSL > certificate - our easy online guide will show you how. Click here to get > started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Anyone able to access cvs?
I can't confirm this, also sitting in germany. cvs gives me a "connection refused", trying for about two hours now. before this the update's were waiting for locks. traceroute to cvs.jboss.sourceforge.net (66.35.250.207), 30 hops max, 80 byte packets 1 router.lafr.de (172.31.18.254) 20 ms 2 ms 1 ms 2 212.95.98.248 (212.95.98.248) 25 ms 24 ms 26 ms 3 212.95.98.66 (212.95.98.66) 24 ms 23 ms 24 ms 4 80.228.21.106 (80.228.21.106) 26 ms 135 ms 26 ms 5 80.228.21.90 (80.228.21.90) 25 ms 25 ms 26 ms 6 80.228.21.6 (80.228.21.6) 49 ms 47 ms 49 ms 7 aer1-gigabitethernet4-3.Londonlnt.cw.net (208.175.240.9) 55 ms 68 ms 52 ms 8 zcr2-ge-3-0-0.Londonlnt.cw.net (166.63.222.89) 53 ms 53 ms 53 ms 9 bcr2.Thamesside.cw.net (166.63.210.62) 55 ms 55 ms 193 ms 10 dcr2-loopback.SantaClara.cw.net (208.172.146.100) 210 ms 212 ms 210 ms 11 cable-and-wireless-internal-isp.SantaClara.cw.net (208.172.156.198) 208 ms 209 ms 209 ms 12 66.35.194.4 (66.35.194.4) 218 ms 213 ms 205 ms 13 66.35.194.43 (66.35.194.43) 208 ms 215 ms 210 ms 14 66.35.210.202 (66.35.210.202) 211 ms 210 ms 212 ms 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * root@ebm1:/ date Wed Jan 15 00:26:41 MET 2003 Holger Baxmann wrote: hi scott, here in germany no problems at all: holgerbaxmann@Holger-Baxmanns-Computer:~ $ uname -a Darwin Holger-Baxmanns-Computer.local. 6.3 Darwin Kernel Version 6.3: Sat Dec 14 03:11:25 PST 2002; root:xnu/xnu-344.23.obj~4/RELEASE_PPC Power Macintosh powerpc holgerbaxmann@Holger-Baxmanns-Computer:~ $ ping cvs.jboss.sourceforge.net PING cvs.sourceforge.net (66.35.250.207): 56 data bytes 64 bytes from 66.35.250.207: icmp_seq=0 ttl=48 time=236.075 ms 64 bytes from 66.35.250.207: icmp_seq=1 ttl=48 time=234.639 ms 64 bytes from 66.35.250.207: icmp_seq=2 ttl=48 time=234.241 ms 64 bytes from 66.35.250.207: icmp_seq=3 ttl=48 time=234.728 ms 64 bytes from 66.35.250.207: icmp_seq=4 ttl=48 time=235.069 ms 64 bytes from 66.35.250.207: icmp_seq=5 ttl=48 time=235.187 ms 64 bytes from 66.35.250.207: icmp_seq=7 ttl=48 time=233.94 ms 64 bytes from 66.35.250.207: icmp_seq=8 ttl=48 time=236.483 ms ^C --- cvs.sourceforge.net ping statistics --- 9 packets transmitted, 8 packets received, 11% packet loss round-trip min/avg/max = 233.94/235.045/236.483 ms holgerbaxmann@Holger-Baxmanns-Computer:~ $ btw: how do you get the counter on your prompt ??? bax Von: "Scott M Stark" <[EMAIL PROTECTED]> Organisation: JBoss Group, LLC Antworten an: [EMAIL PROTECTED] Datum: Tue, 14 Jan 2003 14:47:48 -0800 An: <[EMAIL PROTECTED]> Betreff: [JBoss-dev] Anyone able to access cvs? CVS is still acting up on me. After clearing two more locks I now cannot even get an update. Is it just my route or is this seen by everyone jboss-3.2 38>date -u Tue Jan 14 22:42:56 2003 jboss-3.2 39>ping cvs.jboss.sourceforge.net Pinging cvs.sourceforge.net [66.35.250.207] with 32 bytes of data: Reply from 66.35.250.207: bytes=32 time=31ms TTL=49 Request timed out. Request timed out. Reply from 66.35.250.207: bytes=32 time=31ms TTL=49 Ping statistics for 66.35.250.207: Packets: Sent = 4, Received = 2, Lost = 2 (50% loss), Approximate round trip times in milli-seconds: Minimum = 31ms, Maximum = 31ms, Average = 15ms jboss-3.2 40> Scott Stark Chief Technology Officer JBoss Group, LLC --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-developme
Re: [JBoss-dev] Anyone able to access cvs?
Set the PS1 variable: jboss-head 746>echo $PS1 \W \!> Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Holger Baxmann" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, January 14, 2003 3:08 PM Subject: Re: [JBoss-dev] Anyone able to access cvs? > > btw: how do you get the counter on your prompt ??? > > bax --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Fw: [jboss-cvs] jboss-common/src/main/org/jboss/net/protocol/resource ResourceURLConnection.java
Here is the context in which I looked into the JBoss file protocol handler not being used. As far as I remember, the issue was that very early on there are file URLs being created and these were picking up the default file protocol handler. Recreating the URL after the URLStreamHandlerFactory was installed resulted in the JBoss file protocol handler being used. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Scott M Stark" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, September 29, 2002 12:05 PM Subject: [jboss-cvs] jboss-common/src/main/org/jboss/net/protocol/resource ResourceURLConnection.java > User: starksm > Date: 02/09/29 13:05:18 > > Modified:src/main/org/jboss/net/protocol/resource Tag: Branch_3_0 > ResourceURLConnection.java > Log: > Recreate the URL obtained from the class loader as the file URLs are not > using the org.jboss.net.protocol.file handler for some reason. Creating a > new URL from the CL URL string does use our URLStreamHandlerFactory. This > fixes a problem with the log4j.xml file changes not being seen due to > the invalid lastModified of the default sun file protocol handler. > > Revision ChangesPath > No revision > > > No revision > > > 1.2.2.2 +17 -5 >jboss-common/src/main/org/jboss/net/protocol/resource/ResourceURLConnection.java > > Index: ResourceURLConnection.java > === > RCS file: >/cvsroot/jboss/jboss-common/src/main/org/jboss/net/protocol/resource/ResourceURLConnection.java,v > retrieving revision 1.2.2.1 > retrieving revision 1.2.2.2 > diff -u -r1.2.2.1 -r1.2.2.2 > --- ResourceURLConnection.java 17 May 2002 22:25:41 - 1.2.2.1 > +++ ResourceURLConnection.java 29 Sep 2002 20:05:18 - 1.2.2.2 > @@ -22,7 +22,7 @@ >/** > * Provides access to system resources as a URLConnection. > * > - * @version $Revision: 1.2.2.1 $ > + * @version $Revision: 1.2.2.2 $ > * @author mailto:[EMAIL PROTECTED]";>Jason Dillon > */ >public class ResourceURLConnection > @@ -50,7 +50,8 @@ > ClassLoader cl = Thread.currentThread().getContextClassLoader(); > URL target = cl.getResource(name); > > - if (target == null) { > + if (target == null) > + { > cl = ClassLoader.getSystemClassLoader(); > target = cl.getResource(name); > } > @@ -58,12 +59,23 @@ > if (target == null) > throw new FileNotFoundException("Could not locate resource: " + name); > > - if (log.isTraceEnabled()) { > + /* The file URLs being returned by the class loaders are not using the > + org.jboss.net.protocol.file handler for some reason so here we > + recreate the url to make sure it goes through our > + URLStreamHandlerFactory. The cause should be tracked down but this > + works for now. > + */ > + String urlStr = target.toString(); > + target = new URL(urlStr); > + if (log.isTraceEnabled()) > + { > log.trace("Target resource URL: " + target); > - try { > + try > + { >log.trace("Target resource URL connection: " + >target.openConnection()); > } > - catch (Exception ignore) {} > + catch (Exception ignore) > + {} > } > > return target; --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Anyone able to access cvs?
now i got them both, the goods and the ugly : 149 packets transmitted, 36 packets received, 75% packet loss round-trip min/avg/max = 234.52/238.608/261.337 ms holgerbaxmann@Holger-Baxmanns-Computer:~/jboss-cvs 516 $ btw: i now get a connection refused by cvs.sf.net thanks, scott for the counting prompt :) bax > Von: "Scott M Stark" <[EMAIL PROTECTED]> > Organisation: JBoss Group, LLC > Antworten an: [EMAIL PROTECTED] > Datum: Tue, 14 Jan 2003 15:33:56 -0800 > An: <[EMAIL PROTECTED]> > Betreff: Re: [JBoss-dev] Anyone able to access cvs? > > Set the PS1 variable: > > jboss-head 746>echo $PS1 > \W \!> > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > - Original Message - > From: "Holger Baxmann" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, January 14, 2003 3:08 PM > Subject: Re: [JBoss-dev] Anyone able to access cvs? > > >> >> btw: how do you get the counter on your prompt ??? >> >> bax > > > > --- > This SF.NET email is sponsored by: Take your first step towards giving > your online business a competitive advantage. Test-drive a Thawte SSL > certificate - our easy online guide will show you how. Click here to get > started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBossMQ
Hi, I want to make sure I understand the asynchronous delivery mechanism. I've implemented my MessageConsumer to do the following: Add self to Connection's message consumer list While(consumer is open){ while(server is delivering synchronously){ Send Receive Requests until the Server is Drained } Wait for Asynch Delivery } Is this the proper pattern? Thanks, fawce -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Hiram Chirino Sent: Friday, January 10, 2003 6:50 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JBossMQ Your kinda right. the loop is there for the case where the destination is queue based (p2p and durable subs). The polling happens when the queue is full. Now when the queue is not full (or in the pub sub case, there is no queue), then the thread goes into asynch mode and it waits for the message to get delivered async via the ClientIL.receive method. I'll comment the code a little: // gets the next message in queue or registers us for asynch delivery if none available. mes = session.connection.receive( subscription, 0 ); if ( mes == null ) // should always be null for pub-sub case. { // start waiting for the message to get delivered asynch waitingForMessage = true; while ( ( messages.isEmpty() && !closed ) || ( !session.running ) ) { try { // messages gets signaled once ClientIL.receive finishes processing the message. messages.wait(); } catch ( InterruptedException e ) { } } if ( closed ) { waitingForMessage = false; break outer; } // the message sent via ClientIL.receive should now be sitting in messages mes = ( SpyMessage )messages.removeFirst(); waitingForMessage = false; } I hope that helped! I think the XIL is great idea! We might even be able to develop a c base API to access mq services (important in the integration space). Regards, Hiram > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > John Fawcett > Sent: Thursday, January 09, 2003 8:09 PM > To: [EMAIL PROTECTED] > Subject: [JBoss-dev] JBossMQ > > > Hi, > > I am working on a new invocation layer (IL) for JbossMQ that encodes > all communication in Xml (XIL). I've got the IL pretty near > completion, and I am working on a C# jbossmq client. I am trying to > develop the TopicSubsciber, which is an extension of MessageConsumer. > In reviewing the code in the jbossmq java sources, it looks to me like > the client to a topic actually runs a loop sending receive requests to > the server regularly. > > Is this really necessary? Once the connection has been established, > why can't the server just invoke the ClientIL.receive method (which > actually sends the message to the client) when a message arrives at > the destination? It looks to me like the current implementation is not > truly asynchronous... > What am I missing? > > Thanks, > fawce > > > - > John Fawcett > CTO, Tamale Software, LLC > 26 Fox Road > Waltham, MA 02451 > > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > ___ > Jboss-development mailing list [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-667341 ] Initial Session AUTH failure
Bugs item #667341, was opened at 2003-01-13 13:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=667341&group_id=22866 Category: JBossWeb Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Peter Luttrell (objec) Assigned to: Nobody/Anonymous (nobody) Summary: Initial Session AUTH failure Initial Comment: JBoss3.0.5 - release with jdk1.4.1_01 Before this I was using JBoss3.0.5RC1 and this problem did NOT occur. After I startup JBoss or redeploy my ear, which contains a war which uses authentication (my login module), the very first session that attempts to authenticate fails. If i try it again in the same browser window it still fails. If i open a new window (new sesison id), it works. This happens every time i deploy. I have tried opening a new browser after i deploy but the problem still happens. This is a problem introduced between JBoss3.0.5-RC1 and 3.0.5-Release. -- >Comment By: Peter Luttrell (objec) Date: 2003-01-14 20:25 Message: Logged In: YES user_id=472835 Based on gregs comments, it sounds like this is reproduceable via much simplier means then my case. My case: i am hitting my webapp by http: based on my deployment descriptor index.html jetty should take me to http:index.html, which is this: My Company Name So somewhere there's a problem. I'm doing this rerouting becase i've secured index.jsp and i can't make this the welcome page because Jetty does not check security on this page. I would prefer that it did, however i believe that this is an unspeced part of the spec. I don't know any other way to do this: I need to log in directly from the page that results from hitting the context directly. -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-01-14 14:56 Message: Logged In: YES user_id=44062 A simple test case would be to have a servlet that looks at getPathInfo to see if a path param is included in it. I had thought it would effect all requests - but in retesting it only appears to be effecting connections via mod_jk and AJP13 I'll do some extra tests and see if I can come up with a normal HTTP test case. -- Comment By: Scott M Stark (starksm) Date: 2003-01-14 13:17 Message: Logged In: YES user_id=175228 I have created a servlet that creates a session and that is secured and returns a page with a URL to itself with URL that is encoded to enable URL rewriting. I don't have a problem accessing this servlet on the first attempt when there is no session, or on any subsequent attempt. I have disabled cookies in my browser so I know the URL rewriting is taking place. In the absence of a testcase that demonstrates the problem I can't judge whether this problem warrents a new 3.0.6 release. -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-01-14 03:53 Message: Logged In: YES user_id=44062 This issue is not so much security related, but URL processing of path parameters like ;jsessionid. If you are writing your webapp correctly, you will be rewriting your URLs. If the server has not seen a cookie from the client it will insert such a path parameter. The problem is that path parameters are only being correctly decoded on the first request of a persistent connection. For all other requests, they are being seen as part of the URL rather than as something extra. Thus my own test harnesses for this past without a problem as they were the first request on a connection. Webapps that do not rewrite URLs (many) or who have apps that create a session before authetication takes place - will probably not be effective. So it's not totally broken - just significantly so. I'm done a fixed release of Jetty (4.2.5) and Jules is lined up to make a replacement jbossweb.sar -- Comment By: Scott M Stark (starksm) Date: 2003-01-13 19:27 Message: Logged In: YES user_id=175228 So is security totally broken in the 3.0.5 release? What is the exact issue so I can add a testcase for this? -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-01-13 16:45 Message: Logged In: YES user_id=44062 This is an optimization bug introduced in JBossWeb. URL path parameters, such as ;jsessionid are not handled correctly for persistent connections. A fix is on it's way -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=667341&group_id=22866 --- This SF.NET email is sp
RE: [JBoss-dev] any reason for -classic
forget it, somebody just forgot to comment out JPDA settings. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Bill > Burke > Sent: Tuesday, January 14, 2003 10:16 PM > To: Jboss-Dev > Subject: [JBoss-dev] any reason for -classic > > > Just saw -classic mode in jboss-head. Why are we running in > -classic mode? > > Another thing. Seems like JBoss is starting up much much slower > than usual. > Has somebody thrown in some crazy in? > > Bill > > > > --- > This SF.NET email is sponsored by: Take your first step towards giving > your online business a competitive advantage. Test-drive a Thawte SSL > certificate - our easy online guide will show you how. Click here to get > started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] any reason for -classic
Just saw -classic mode in jboss-head. Why are we running in -classic mode? Another thing. Seems like JBoss is starting up much much slower than usual. Has somebody thrown in some crazy in? Bill --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-668291 ] Jasper in release 3.0.5 is
Bugs item #668291, was opened at 2003-01-15 13:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=668291&group_id=22866 Category: JBossWeb Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Brian Bannister (beoch) Assigned to: Nobody/Anonymous (nobody) Summary: Jasper in release 3.0.5 is Initial Comment: Windows 2000 JDK 1.4.1_01 JBoss 3.0.5 I'm getting JSP compile errors that do not occur in JBoss 3.0.4. Jasper complains that it can't find a class that is definately in the deployed war. Using the same ear on JBoss 3.0.4 I get no problems. The traces from JBoss-3.0.5 and JBoss-3.0.4 are attached, as well as the war manifest showing the class that Jasper can't find. The exception thrown is: Time: 13:42:55 Priority: WARN Thread: PoolThread- 4 NDC: null Category: org.jboss.jbossweb Location: org.jboss.logging.Logger.warn(Logger.java:167) Message: WARNING: Exception for http://192.223.0.59:8080/itochu/newsticker/view/45/dyna micMedia/x-news-ticker.jsp org.apache.jasper.JasperException: Unable to compile class for JSPNote: sun.tools.javac.Main has been deprecated. An error occurred at line: 2 in the jsp file: /45/dynamicMedia/x-news-ticker.jsp Generated servlet error: C:\DOCUME~1\brianb\LOCALS~1 \Temp\Jetty_0_0_0_0_8080__itochu_newsticker\45 \dynamicMedia\x_0002dnews_0002dticker$jsp.java:65: Class com.activesky.itochu.newsticker.view.NewsTickerView not found. com.activesky.itochu.newsticker.view.NewsTickerView viewParameter = null; ^ An error occurred at line: 2 in the jsp file: /45/dynamicMedia/x-news-ticker.jsp Generated servlet error: C:\DOCUME~1\brianb\LOCALS~1 \Temp\Jetty_0_0_0_0_8080__itochu_newsticker\45 \dynamicMedia\x_0002dnews_0002dticker$jsp.java:68: Class com.activesky.itochu.newsticker.view.NewsTickerView not found. viewParameter= (com.activesky.itochu.newsticker.view.NewsTickerView) ^ An error occurred at line: 2 in the jsp file: /45/dynamicMedia/x-news-ticker.jsp Generated servlet error: C:\DOCUME~1\brianb\LOCALS~1 \Temp\Jetty_0_0_0_0_8080__itochu_newsticker\45 \dynamicMedia\x_0002dnews_0002dticker$jsp.java:73: Class com.activesky.itochu.newsticker.view.NewsTickerView not found. viewParameter = (com.activesky.itochu.newsticker.view.NewsTickerView) java.beans.Beans.instantiate(this.getClass ().getClassLoader (), "com.activesky.itochu.newsticker.view.NewsTickerVie w"); ^ 3 errors, 1 warning at org.apache.jasper.compiler.Compiler.compile (Compiler.java:289) at org.apache.jasper.servlet.JspServlet.loadJSP (JspServlet.java:548) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.l oadIfNecessary(JspServlet.java:176) at org.apache.jasper.servlet.JspServlet$JspServletWrapper. service(JspServlet.java:188) at org.apache.jasper.servlet.JspServlet.serviceJspFile (JspServlet.java:381) at org.apache.jasper.servlet.JspServlet.service (JspServlet.java:473) at javax.servlet.http.HttpServlet.service (HttpServlet.java:853) at org.mortbay.jetty.servlet.ServletHolder.handle (ServletHolder.java:360) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatc h(WebApplicationHandler.java:280) at org.mortbay.jetty.servlet.Dispatcher.dispatch (Dispatcher.java:194) at org.mortbay.jetty.servlet.Dispatcher.forward (Dispatcher.java:129) at com.activesky.servlet.FrontController.doGet (FrontController.java:46) at javax.servlet.http.HttpServlet.service (HttpServlet.java:740) at javax.servlet.http.HttpServlet.service (HttpServlet.java:853) at org.mortbay.jetty.servlet.ServletHolder.handle (ServletHolder.java:360) at org.mortbay.jetty.servlet.WebApplicationHandler$Chain.d oFilter(WebApplicationHandler.java:328) at com.activesky.aserver.mbroker.MediaBrokerFilter.doFilte r(MediaBrokerFilter.java:138) at org.mortbay.jetty.servlet.WebApplicationHandler$Chain.d oFilter(WebApplicationHandler.java:320) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatc h(WebApplicationHandler.java:272) at org.mortbay.jetty.servlet.ServletHandler.handle (ServletHandler.java:553) at org.mortbay.http.HttpContext.handle (HttpContext.java:1656) at org.mortbay.jetty.servlet.WebApplicationContext.handle (WebApplicationContext.java:549) at org.mortbay.http.HttpContext.handle (HttpContext.java:1606) at org.mortbay.http.HttpServer.service (HttpServer.java:862) at org.jboss.jetty.Jetty.service(Jetty.java:497) at org.mortbay.http.HttpConnection.service (HttpConnection.java:752) at org.mortbay.http.HttpConnection.handleNext (HttpConnection.java:916) at org.mortbay.http.HttpConnection.handle (Http
[JBoss-dev] [ jboss-Bugs-667341 ] Initial Session AUTH failure
Bugs item #667341, was opened at 2003-01-13 11:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=667341&group_id=22866 Category: JBossWeb Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Peter Luttrell (objec) Assigned to: Nobody/Anonymous (nobody) Summary: Initial Session AUTH failure Initial Comment: JBoss3.0.5 - release with jdk1.4.1_01 Before this I was using JBoss3.0.5RC1 and this problem did NOT occur. After I startup JBoss or redeploy my ear, which contains a war which uses authentication (my login module), the very first session that attempts to authenticate fails. If i try it again in the same browser window it still fails. If i open a new window (new sesison id), it works. This happens every time i deploy. I have tried opening a new browser after i deploy but the problem still happens. This is a problem introduced between JBoss3.0.5-RC1 and 3.0.5-Release. -- >Comment By: Scott M Stark (starksm) Date: 2003-01-14 20:41 Message: Logged In: YES user_id=175228 Edit jbossweb.sar/webdefault.xml and set the redirectWelcome init-param of the default servlet to true to have welcome pages secured. See bug 621521 for the details of what is going on. -- Comment By: Peter Luttrell (objec) Date: 2003-01-14 18:25 Message: Logged In: YES user_id=472835 Based on gregs comments, it sounds like this is reproduceable via much simplier means then my case. My case: i am hitting my webapp by http: based on my deployment descriptor index.html jetty should take me to http:index.html, which is this: My Company Name So somewhere there's a problem. I'm doing this rerouting becase i've secured index.jsp and i can't make this the welcome page because Jetty does not check security on this page. I would prefer that it did, however i believe that this is an unspeced part of the spec. I don't know any other way to do this: I need to log in directly from the page that results from hitting the context directly. -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-01-14 12:56 Message: Logged In: YES user_id=44062 A simple test case would be to have a servlet that looks at getPathInfo to see if a path param is included in it. I had thought it would effect all requests - but in retesting it only appears to be effecting connections via mod_jk and AJP13 I'll do some extra tests and see if I can come up with a normal HTTP test case. -- Comment By: Scott M Stark (starksm) Date: 2003-01-14 11:17 Message: Logged In: YES user_id=175228 I have created a servlet that creates a session and that is secured and returns a page with a URL to itself with URL that is encoded to enable URL rewriting. I don't have a problem accessing this servlet on the first attempt when there is no session, or on any subsequent attempt. I have disabled cookies in my browser so I know the URL rewriting is taking place. In the absence of a testcase that demonstrates the problem I can't judge whether this problem warrents a new 3.0.6 release. -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-01-14 01:53 Message: Logged In: YES user_id=44062 This issue is not so much security related, but URL processing of path parameters like ;jsessionid. If you are writing your webapp correctly, you will be rewriting your URLs. If the server has not seen a cookie from the client it will insert such a path parameter. The problem is that path parameters are only being correctly decoded on the first request of a persistent connection. For all other requests, they are being seen as part of the URL rather than as something extra. Thus my own test harnesses for this past without a problem as they were the first request on a connection. Webapps that do not rewrite URLs (many) or who have apps that create a session before authetication takes place - will probably not be effective. So it's not totally broken - just significantly so. I'm done a fixed release of Jetty (4.2.5) and Jules is lined up to make a replacement jbossweb.sar -- Comment By: Scott M Stark (starksm) Date: 2003-01-13 17:27 Message: Logged In: YES user_id=175228 So is security totally broken in the 3.0.5 release? What is the exact issue so I can add a testcase for this? -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-01-13 14:45 Message: Logged In: YES user_id=44062 This is an optimization bug introduced in JBossWeb. URL path parameters, such as
[JBoss-dev] Automated JBoss(JBoss_3_2_0_RC1 WonderLand) Testsuite Results: 14-January-2003
JBoss-3.2.0RC1 test results SUMMARY Number of tests run: 1053 Successful tests: 1048 Errors:4 Failures: 1 [time of test: 2003-01-15.03-48 GMT] [java.version: 1.3.1_05] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1_05-b02] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Windows 2000] [os.arch: x86] [os.version: 5.0] Useful resources: - http://users.jboss.org/~starksm/Branch_3_2/2003-01-15.03-48 for the junit report of this test. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: DeployXMBeanUnitTestCase Test:testDeployUserXMBean(org.jboss.test.jmx.test.DeployXMBeanUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: create operation failed for package file:/C:/usr/JBoss3.2/jboss-3.2/testsuite/output/lib/user-xmbean.sar; - nested throwable: (org.jboss.deployment.DeploymentException: Error parsing the XML file: org.xml.sax.SAXParseException: Attribute "persistPolicy" with value "Never" must have a value from the list "NEVER ONUPDATE NOMOREOFTENTHAN ONTIMER ".; - nested throwable: (javax.management.NotCompliantMBeanException: Error parsing the XML file: org.xml.sax.SAXParseException: Attribute "persistPolicy" with value "Never" must have a value from the list "NEVER ONUPDATE NOMOREOFTENTHAN ONTIMER ".)) - Suite: JarInSarJSR77UnitTestCase Test: testFakeParentCreatedAndRemoved(org.jboss.test.jmx.test.JarInSarJSR77UnitTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: fakeApp jsr-77 mbean is still present - Suite: MissingClassUnitTestCase Test: testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: create operation failed for package file:/C:/usr/JBoss3.2/jboss-3.2/testsuite/output/lib/missingclass-service.xml; - nested throwable: (javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not registered.) - Suite: JSR77SpecUnitTestCase Test:testNavigation(org.jboss.test.management.test.JSR77SpecUnitTestCase) Type:error Exception: java.lang.NullPointerException Message: - Suite: SRPUnitTestCase Test:testEchoArgs(org.jboss.test.security.test.SRPUnitTestCase) Type:error Exception: java.rmi.ServerError Message: Error occurred in server thread; nested exception is: java.lang.NoClassDefFoundError: Ljavax/crypto/Cipher; - --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-668313 ] jboss 3.0.5 can't redeploy tomcat
Bugs item #668313, was opened at 2003-01-15 05:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=668313&group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Adam Heath (doogie) Assigned to: Nobody/Anonymous (nobody) Summary: jboss 3.0.5 can't redeploy tomcat Initial Comment: Download jboss-3.0.5_tomcat-4.1.18.zip. Unpack. Start server. Touch server/default/deploy/tomcat41-service.xml. The wars, then tomcat undeploy. Tomcat then redeploys. however, when the wars try to reploy, there LinkageErrors. 2003-01-14 23:01:19,006 INFO [org.jboss.deployment.MainDeployer] Starting deployment of package: file:/home.local/adam/brainfood/jboss/p/jb oss-3.0.5_tomcat-4.1.18/server/default/deploy/http-invoker.sar/invoker.war/ 2003-01-14 23:01:19,126 INFO [org.jboss.web.catalina.EmbeddedCatalinaService41] deploy, ctxPath=/invoker, warUrl=file:/home.local/adam/brai nfood/jboss/p/jboss-3.0.5_tomcat-4.1.18/server/default/deploy/http-invoker.sar/invoker.war/ 2003-01-14 23:01:20,470 INFO [org.jboss.web.localhost.Engine] WebappLoader[/invoker]: Deploying class repositories to work directory /home. local/adam/brainfood/jboss/p/jboss-3.0.5_tomcat-4.1.18/tomcat-4.1.x/work/MainEngine/localhost/invoker 2003-01-14 23:01:20,520 INFO [org.jboss.web.localhost.Engine] WebappLoader[/invoker]: Deploy class files /WEB-INF/classes to /home.local/ad am/brainfood/jboss/p/jboss-3.0.5_tomcat-4.1.18/server/default/deploy/http-invoker.sar/invoker.war/WEB-INF/classes 2003-01-14 23:01:21,369 INFO [org.jboss.web.localhost.Engine] ContextConfig[/invoker]: Added certificates -> request attribute Valve 2003-01-14 23:01:21,635 INFO [org.jboss.web.localhost.Engine] ContextConfig[/invoker]: Configured an authenticator for method BASIC 2003-01-14 23:01:21,993 INFO [org.jboss.web.catalina.EmbeddedCatalinaService41] Using Java2 parent classloader delegation: true 2003-01-14 23:01:21,998 INFO [org.jboss.web.localhost.Engine] StandardManager[/invoker]: Seeding random number generator class java.securit y.SecureRandom 2003-01-14 23:01:22,003 INFO [org.jboss.web.localhost.Engine] StandardManager[/invoker]: Seeding of random number generator has been comple ted 2003-01-14 23:01:22,252 ERROR [org.jboss.web.localhost.Engine] StandardContext[/invoker]: Exception starting filter ReadOnlyAccessFilter java.lang.LinkageError: loader constraints violated when linking javax/servlet/FilterConfig class at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:254) at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:314) at org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFilterConfig.java:120) at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3158) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3602) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:821) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:579) at org.jboss.web.catalina.EmbeddedCatalinaService41.createWebContext(EmbeddedCatalinaService41.java:432) at org.jboss.web.catalina.EmbeddedCatalinaService41.performDeploy(EmbeddedCatalinaService41.java:306) at org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:300) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:814) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:627) at org.jboss.deployment.MainDeployer.addDeployer(MainDeployer.java:230) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.deployment.SubDeployerSupport.startService(SubDeployerSupport.java:98) at org.jboss.web.catalina.EmbeddedCatalinaService41.startService(EmbeddedCatalinaService41.java:263) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:165) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:1003) at $Proxy4.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:413) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.util.
RE: [JBoss-dev] Anyone able to access cvs?
cvs fucked up since 5PM for me :) marcf > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On > Behalf Of Holger Baxmann > Sent: Tuesday, January 14, 2003 7:33 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Anyone able to access cvs? > > > now i got them both, the goods and the ugly : > > > 149 packets transmitted, 36 packets received, 75% packet loss > round-trip min/avg/max = 234.52/238.608/261.337 ms > holgerbaxmann@Holger-Baxmanns-Computer:~/jboss-cvs 516 $ > > btw: i now get a connection refused by cvs.sf.net > > thanks, scott for the counting prompt :) > > bax > > Von: "Scott M Stark" <[EMAIL PROTECTED]> > > Organisation: JBoss Group, LLC > > Antworten an: [EMAIL PROTECTED] > > Datum: Tue, 14 Jan 2003 15:33:56 -0800 > > An: <[EMAIL PROTECTED]> > > Betreff: Re: [JBoss-dev] Anyone able to access cvs? > > > > Set the PS1 variable: > > > > jboss-head 746>echo $PS1 > > \W \!> > > > > > > Scott Stark > > Chief Technology Officer > > JBoss Group, LLC > > > > > > - Original Message - > > From: "Holger Baxmann" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Tuesday, January 14, 2003 3:08 PM > > Subject: Re: [JBoss-dev] Anyone able to access cvs? > > > > > >> > >> btw: how do you get the counter on your prompt ??? > >> > >> bax > > > > > > > > --- > > This SF.NET email is sponsored by: Take your first step > towards giving > > your online business a competitive advantage. Test-drive a > Thawte SSL > > certificate - our easy online guide will show you how. > Click here to > > get > > started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > --- > This SF.NET email is sponsored by: Take your first step > towards giving > your online business a competitive advantage. Test-drive a Thawte SSL > certificate - our easy online guide will show you how. Click > here to get > started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en > ___ > Jboss-development mailing list [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re[6]: [JBoss-dev] URLConnection and opened files
Yes, I thought about it too. There are two cases: - the thread creating URL can't find custom handlers; - Sun's handler was somehow initialized/used before (before setting the property or somehow else?) But I can't understand why my standalone test doesn't work. I set property in the command line and my handlers are in the classpath. I don't see any chance for Sun's handler to be used first. Ok, I'll update JBoss-3.0 and see. Thanks, alex Tuesday, January 14, 2003, 9:49:45 PM, you wrote: SMS> Oh, I now remeber looking at this but I can't remember the context. There SMS> is a cache of handlers as the URL level. If the file protocol is referenced SMS> before the custom JBoss handler is available then the default Sun one will SMS> be used. Is there a difference between 3.0 and 3.2 with regard to when the SMS> custom protocol handlers are installed? I'll check later today. SMS> SMS> Scott Stark SMS> Chief Technology Officer SMS> JBoss Group, LLC SMS> SMS> - Original Message - SMS> From: "Alex Loubyansky" <[EMAIL PROTECTED]> SMS> To: "Scott M Stark" <[EMAIL PROTECTED]> SMS> Sent: Tuesday, January 14, 2003 7:07 AM SMS> Subject: Re[4]: [JBoss-dev] URLConnection and opened files >> I'm a bit confused. I wrote a simple standalone test. >> >> - main >> public static void main(String[] args) throws Exception >> { >>// set handler pkgs >>System.out.println("java.protocol.handler.pkgs: " + >System.getProperty("java.protocol.handler.pkgs")); >> >>URL url = new URL("file", null, args[0]); >>System.out.println("url: " + url); >>URLConnection urlCon = url.openConnection(); >>System.out.println("connection class: " + urlCon.getClass().getName()); >> >>url = new URL("other", null, args[0]); >>System.out.println("url: " + url); >>urlCon = url.openConnection(); >>System.out.println("connection class: " + urlCon.getClass().getName()); >> } >> >> - run >> java -Djava.protocol.handler.pkgs=org.avoka.test.files.protocol -classpath %cp% >org.avoka.test.files.FilesTest build.xml >> >> - output >> java.protocol.handler.pkgs: org.avoka.test.files.protocol >> url: file:build.xml >> connection class: sun.net.www.protocol.file.FileURLConnection >> url: other:build.xml >> connection class: org.avoka.test.files.protocol.other.OtherURLConnection >> >> I do have org.avoka.test.files.protocol.file.Handler and >> org.avoka.test.files.protocol.file.FileURLConnection on the classpath. >> My file.Handler isn't called. Am I missing something? >> >> This same thing happens with JBoss-3.2 and HEAD but not JBoss-3.0 (my >> 3.0 is not up to date). >> >> JDK1.3.1_05, J2SDK1.4.0 >> Win2K >> >> Thanks, >> alex --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-668313 ] jboss 3.0.5 can't redeploy tomcat
Bugs item #668313, was opened at 2003-01-15 05:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=668313&group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Adam Heath (doogie) Assigned to: Nobody/Anonymous (nobody) Summary: jboss 3.0.5 can't redeploy tomcat Initial Comment: Download jboss-3.0.5_tomcat-4.1.18.zip. Unpack. Start server. Touch server/default/deploy/tomcat41-service.xml. The wars, then tomcat undeploy. Tomcat then redeploys. however, when the wars try to reploy, there LinkageErrors. 2003-01-14 23:01:19,006 INFO [org.jboss.deployment.MainDeployer] Starting deployment of package: file:/home.local/adam/brainfood/jboss/p/jb oss-3.0.5_tomcat-4.1.18/server/default/deploy/http-invoker.sar/invoker.war/ 2003-01-14 23:01:19,126 INFO [org.jboss.web.catalina.EmbeddedCatalinaService41] deploy, ctxPath=/invoker, warUrl=file:/home.local/adam/brai nfood/jboss/p/jboss-3.0.5_tomcat-4.1.18/server/default/deploy/http-invoker.sar/invoker.war/ 2003-01-14 23:01:20,470 INFO [org.jboss.web.localhost.Engine] WebappLoader[/invoker]: Deploying class repositories to work directory /home. local/adam/brainfood/jboss/p/jboss-3.0.5_tomcat-4.1.18/tomcat-4.1.x/work/MainEngine/localhost/invoker 2003-01-14 23:01:20,520 INFO [org.jboss.web.localhost.Engine] WebappLoader[/invoker]: Deploy class files /WEB-INF/classes to /home.local/ad am/brainfood/jboss/p/jboss-3.0.5_tomcat-4.1.18/server/default/deploy/http-invoker.sar/invoker.war/WEB-INF/classes 2003-01-14 23:01:21,369 INFO [org.jboss.web.localhost.Engine] ContextConfig[/invoker]: Added certificates -> request attribute Valve 2003-01-14 23:01:21,635 INFO [org.jboss.web.localhost.Engine] ContextConfig[/invoker]: Configured an authenticator for method BASIC 2003-01-14 23:01:21,993 INFO [org.jboss.web.catalina.EmbeddedCatalinaService41] Using Java2 parent classloader delegation: true 2003-01-14 23:01:21,998 INFO [org.jboss.web.localhost.Engine] StandardManager[/invoker]: Seeding random number generator class java.securit y.SecureRandom 2003-01-14 23:01:22,003 INFO [org.jboss.web.localhost.Engine] StandardManager[/invoker]: Seeding of random number generator has been comple ted 2003-01-14 23:01:22,252 ERROR [org.jboss.web.localhost.Engine] StandardContext[/invoker]: Exception starting filter ReadOnlyAccessFilter java.lang.LinkageError: loader constraints violated when linking javax/servlet/FilterConfig class at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:254) at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:314) at org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFilterConfig.java:120) at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3158) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3602) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:821) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:579) at org.jboss.web.catalina.EmbeddedCatalinaService41.createWebContext(EmbeddedCatalinaService41.java:432) at org.jboss.web.catalina.EmbeddedCatalinaService41.performDeploy(EmbeddedCatalinaService41.java:306) at org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:300) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:814) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:627) at org.jboss.deployment.MainDeployer.addDeployer(MainDeployer.java:230) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.deployment.SubDeployerSupport.startService(SubDeployerSupport.java:98) at org.jboss.web.catalina.EmbeddedCatalinaService41.startService(EmbeddedCatalinaService41.java:263) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:165) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:1003) at $Proxy4.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:413) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.util.
[JBoss-dev] [ jboss-Bugs-668313 ] jboss 3.0.5 can't redeploy tomcat
Bugs item #668313, was opened at 2003-01-14 21:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=668313&group_id=22866 >Category: CatalinaBundle >Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Adam Heath (doogie) Assigned to: Nobody/Anonymous (nobody) Summary: jboss 3.0.5 can't redeploy tomcat Initial Comment: Download jboss-3.0.5_tomcat-4.1.18.zip. Unpack. Start server. Touch server/default/deploy/tomcat41-service.xml. The wars, then tomcat undeploy. Tomcat then redeploys. however, when the wars try to reploy, there LinkageErrors. 2003-01-14 23:01:19,006 INFO [org.jboss.deployment.MainDeployer] Starting deployment of package: file:/home.local/adam/brainfood/jboss/p/jb oss-3.0.5_tomcat-4.1.18/server/default/deploy/http-invoker.sar/invoker.war/ 2003-01-14 23:01:19,126 INFO [org.jboss.web.catalina.EmbeddedCatalinaService41] deploy, ctxPath=/invoker, warUrl=file:/home.local/adam/brai nfood/jboss/p/jboss-3.0.5_tomcat-4.1.18/server/default/deploy/http-invoker.sar/invoker.war/ 2003-01-14 23:01:20,470 INFO [org.jboss.web.localhost.Engine] WebappLoader[/invoker]: Deploying class repositories to work directory /home. local/adam/brainfood/jboss/p/jboss-3.0.5_tomcat-4.1.18/tomcat-4.1.x/work/MainEngine/localhost/invoker 2003-01-14 23:01:20,520 INFO [org.jboss.web.localhost.Engine] WebappLoader[/invoker]: Deploy class files /WEB-INF/classes to /home.local/ad am/brainfood/jboss/p/jboss-3.0.5_tomcat-4.1.18/server/default/deploy/http-invoker.sar/invoker.war/WEB-INF/classes 2003-01-14 23:01:21,369 INFO [org.jboss.web.localhost.Engine] ContextConfig[/invoker]: Added certificates -> request attribute Valve 2003-01-14 23:01:21,635 INFO [org.jboss.web.localhost.Engine] ContextConfig[/invoker]: Configured an authenticator for method BASIC 2003-01-14 23:01:21,993 INFO [org.jboss.web.catalina.EmbeddedCatalinaService41] Using Java2 parent classloader delegation: true 2003-01-14 23:01:21,998 INFO [org.jboss.web.localhost.Engine] StandardManager[/invoker]: Seeding random number generator class java.securit y.SecureRandom 2003-01-14 23:01:22,003 INFO [org.jboss.web.localhost.Engine] StandardManager[/invoker]: Seeding of random number generator has been comple ted 2003-01-14 23:01:22,252 ERROR [org.jboss.web.localhost.Engine] StandardContext[/invoker]: Exception starting filter ReadOnlyAccessFilter java.lang.LinkageError: loader constraints violated when linking javax/servlet/FilterConfig class at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:254) at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:314) at org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFilterConfig.java:120) at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3158) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3602) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:821) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:579) at org.jboss.web.catalina.EmbeddedCatalinaService41.createWebContext(EmbeddedCatalinaService41.java:432) at org.jboss.web.catalina.EmbeddedCatalinaService41.performDeploy(EmbeddedCatalinaService41.java:306) at org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:300) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:814) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:627) at org.jboss.deployment.MainDeployer.addDeployer(MainDeployer.java:230) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.deployment.SubDeployerSupport.startService(SubDeployerSupport.java:98) at org.jboss.web.catalina.EmbeddedCatalinaService41.startService(EmbeddedCatalinaService41.java:263) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:165) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:1003) at $Proxy4.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:413) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
Re[2]: [JBoss-dev] JNuke dev
I also thought about support class/method/field level metadata attributes for aspects deploying the source file this way. But this could be a limiting solution for aspects development. alex Tuesday, January 14, 2003, 9:16:20 PM, you wrote: DS> Bill, DS> This reminds me of an I deal I has last night (couldn't sleep). I was DS> thinking of the script based MBean support Sacha added, and I thought DS> can we make plain old java work like a scripting language. Here is DS> what I came up with: DS>+ The user writes a class BlahService.java DS>+ This source file is places in our deployment directory DS>+ We run Xdoclet on it to generate the MBean deployment descriptor DS>+ We compile the java file DS>+ Deploy DS> Java as a scripting language. DS> What do you think? DS> -dain DS> On Tuesday, January 14, 2003, at 12:50 PM, Bill Burke wrote: >> The only negative comment I have in using JMX is that the PHP >> community may >> have a tough time switching over to Nukes on JBoss if you have to have >> a >> package structure like a SAR or a WAR. I hate to say it, but does it >> need >> to be "dumbed-down" for the PHP community? This type of community >> needs to >> be able to edit a JSP and immediately see the change on the webserver. >> Is >> it possible to be all JSP based for themes, modules and blocks? You >> could >> use a URL fragement and JSP:Include to decide what theme to use. >> >> Just a thought. Maybe JMX and such is the way to go. Just want to >> give you >> something to think about. >> >> Bill >> >>> -Original Message- >>> From: [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED]]On Behalf Of >>> julien viet >>> Sent: Tuesday, January 14, 2003 11:31 AM >>> To: SourceForge.net >>> Subject: [JBoss-dev] JNuke dev >>> >>> >>> hi folks, >>> >>> JNuke adventure has started. >>> After analysis of PostNuke I've began the development, still early >>> though. >>> >>> I keep everything that's good in PostNuke and throw all the shit >>> away : >>> >>> modules, blocks, permissions system, url system and themes. >>> >>> JMX is used for PostNuke components : themes, >>> modules and blocks are all JMX mbeans. Here are my reasons : >>> >>> A : general >>> >>> 1.we need a component structure, why not JMX ? after all >>>another forum say that's lightweight. >>> >>> 2.theses components do not have to scale, i.e the number of modules, >>>blocks and themes is very small. >>> >>> B : for modules >>> >>> 1.Ability to deploy/undeploy when application is running. >>> >>> 2.It's easy to deploy additional modules as a separate deployment and >>>have them register in the same registry. >>> >>> 3.PostNuke is all about invoking module functions. >>>Url like index.php?module=User&op=register means >>>that the PN must call the method register on module User. >>>For me that means that the servlet retrieves the mbean >>>under the name jnuke:publicmodules:name=User >>>and invokes the operation register(). >>> >>> 4.When a module is installed and configured it plug >>>block mbeans in the JMX. >>> >>> C : for blocks, same reasons as above except 3 and 4 >>> as invocation is typed for 3. >>> >>> D : for themes, same reasons as above except 3 and 4 >>> as invocation is typed for 3. >>> >>> >>> EJB are used for the model : >>> >>> UserEJB, GroupEJB, UserPermissionEJB, UserGroupEJB will >>> be CMP 2.0 beans. We'll use local invocations and same trick >>> as in forum to make them faster. Plus more beans. >>> >>> Each module is made of : >>> >>> 1.ModuleMBean : is the module itself, does not provide >>> fucntionnalities, >>> it's used to manager the PublicModule. Main operations are lifecycle >>> (initialize, activate, unactivate, uninitialize) >>> >>> 2.PublicModuleMBean : is created when ModuleMBean activates and is >>>responsible for serving requests. The MBean is dynamic and >>> operations >>>with no arguments and no returns are served. >>> >>> It's up to the module to do as he wants : if he wants MVC it can, it >>> it wants to mix HTML and code, it can. First modules won't be MVC >>> as they simply don't need. >>> >>> It's up to the model to have the persistence mecanisms it wants. >>> First >>> modules will use EJB. With lifecycle operations, each module can >>> install >>> itself, for instance : >>> >>> a ModuleMBean is plugged : >>> 1.module configuration, setup of variables >>> 2.initialize : module can creates table, deploy EJB, plugs block. >>> 3.activate : module >>> then go to block admin and creates instances of blocks (if module >>> use blocks), display them on the page. >>> >>> Each block is made of : >>> >>> 1.BlockMBean : manages BlockInstanceMBean. >>> 2.BlockInstanceMBean : is a block instance, it contains a title >>> and a position >>>on web page + 3 operations : display(), edit(), update(). >>>display() : displays the block instance >>>edit() : used to edit t
[JBoss-dev] [ jboss-Bugs-668313 ] jboss 3.0.5 can't redeploy tomcat
Bugs item #668313, was opened at 2003-01-14 21:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=668313&group_id=22866 Category: CatalinaBundle Group: v3.0 Rabbit Hole >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Adam Heath (doogie) >Assigned to: Scott M Stark (starksm) Summary: jboss 3.0.5 can't redeploy tomcat Initial Comment: Download jboss-3.0.5_tomcat-4.1.18.zip. Unpack. Start server. Touch server/default/deploy/tomcat41-service.xml. The wars, then tomcat undeploy. Tomcat then redeploys. however, when the wars try to reploy, there LinkageErrors. 2003-01-14 23:01:19,006 INFO [org.jboss.deployment.MainDeployer] Starting deployment of package: file:/home.local/adam/brainfood/jboss/p/jb oss-3.0.5_tomcat-4.1.18/server/default/deploy/http-invoker.sar/invoker.war/ 2003-01-14 23:01:19,126 INFO [org.jboss.web.catalina.EmbeddedCatalinaService41] deploy, ctxPath=/invoker, warUrl=file:/home.local/adam/brai nfood/jboss/p/jboss-3.0.5_tomcat-4.1.18/server/default/deploy/http-invoker.sar/invoker.war/ 2003-01-14 23:01:20,470 INFO [org.jboss.web.localhost.Engine] WebappLoader[/invoker]: Deploying class repositories to work directory /home. local/adam/brainfood/jboss/p/jboss-3.0.5_tomcat-4.1.18/tomcat-4.1.x/work/MainEngine/localhost/invoker 2003-01-14 23:01:20,520 INFO [org.jboss.web.localhost.Engine] WebappLoader[/invoker]: Deploy class files /WEB-INF/classes to /home.local/ad am/brainfood/jboss/p/jboss-3.0.5_tomcat-4.1.18/server/default/deploy/http-invoker.sar/invoker.war/WEB-INF/classes 2003-01-14 23:01:21,369 INFO [org.jboss.web.localhost.Engine] ContextConfig[/invoker]: Added certificates -> request attribute Valve 2003-01-14 23:01:21,635 INFO [org.jboss.web.localhost.Engine] ContextConfig[/invoker]: Configured an authenticator for method BASIC 2003-01-14 23:01:21,993 INFO [org.jboss.web.catalina.EmbeddedCatalinaService41] Using Java2 parent classloader delegation: true 2003-01-14 23:01:21,998 INFO [org.jboss.web.localhost.Engine] StandardManager[/invoker]: Seeding random number generator class java.securit y.SecureRandom 2003-01-14 23:01:22,003 INFO [org.jboss.web.localhost.Engine] StandardManager[/invoker]: Seeding of random number generator has been comple ted 2003-01-14 23:01:22,252 ERROR [org.jboss.web.localhost.Engine] StandardContext[/invoker]: Exception starting filter ReadOnlyAccessFilter java.lang.LinkageError: loader constraints violated when linking javax/servlet/FilterConfig class at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:254) at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:314) at org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFilterConfig.java:120) at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3158) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3602) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:821) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:579) at org.jboss.web.catalina.EmbeddedCatalinaService41.createWebContext(EmbeddedCatalinaService41.java:432) at org.jboss.web.catalina.EmbeddedCatalinaService41.performDeploy(EmbeddedCatalinaService41.java:306) at org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:300) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:814) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:627) at org.jboss.deployment.MainDeployer.addDeployer(MainDeployer.java:230) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.deployment.SubDeployerSupport.startService(SubDeployerSupport.java:98) at org.jboss.web.catalina.EmbeddedCatalinaService41.startService(EmbeddedCatalinaService41.java:263) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:165) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:1003) at $Proxy4.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:413) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
[JBoss-dev] JBoss 3.2.0RC1 available
The JBoss 3.2.0RC1 release is available from SourceForge here: http://sourceforge.net/project/showfiles.php?group_id=22866 Detailed but crude release notes are here: http://sourceforge.net/project/shownotes.php?release_id=13 Scott Stark Chief Technology Officer JBoss Group, LLC --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development