[JBoss-dev] 3.2.0RC1 release on hold

2003-01-14 Thread Scott M Stark
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

2003-01-14 Thread SourceForge.net
Bugs item #667341, was opened at 2003-01-13 19:24
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=667341group_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=detailatid=376685aid=667341group_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

2003-01-14 Thread Holger Baxmann
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

2003-01-14 Thread julien viet
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

2003-01-14 Thread Holger Baxmann
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

2003-01-14 Thread Alex Loubyansky
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

2003-01-14 Thread SourceForge.net
Bugs item #664635, was opened at 2003-01-08 15:33
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=664635group_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=61thread=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 VM 
then 

[JBoss-dev] [ jboss-Bugs-667825 ] Add NOPAUSE option to build.bat files

2003-01-14 Thread SourceForge.net
Bugs item #667825, was opened at 2003-01-14 16:16
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=667825group_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=detailatid=376685aid=667825group_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

2003-01-14 Thread julien viet
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=Userop=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

2003-01-14 Thread marc fleury
  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

2003-01-14 Thread GROVE,MIKE (HP-FtCollins,ex1)



(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 havingwith 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 [STDERR] at 
org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:62)2003-01-10 

Re[2]: [JBoss-dev] JNuke dev

2003-01-14 Thread julien viet
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 snip

JH Makes sense so far

  3.PostNuke is all about invoking module functions.
Url like index.php?module=Userop=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

2003-01-14 Thread James Higginbotham
Julien,

snip

Makes sense so far

  3.PostNuke is all about invoking module functions.
Url like index.php?module=Userop=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

2003-01-14 Thread Bill Burke
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=Userop=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 

RE: [JBoss-dev] JNuke dev

2003-01-14 Thread Bill Burke
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=Userop=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 

RE: [JBoss-dev] JNuke dev

2003-01-14 Thread Ben Sabrin
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=Userop=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 

Re[2]: [JBoss-dev] JNuke dev

2003-01-14 Thread julien viet
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=Userop=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 

[JBoss-dev] [ jboss-Bugs-667341 ] Initial Session AUTH failure

2003-01-14 Thread SourceForge.net
Bugs item #667341, was opened at 2003-01-13 11:24
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=667341group_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=detailatid=376685aid=667341group_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

2003-01-14 Thread julien viet
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=Userop=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 :
 
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 :

Re: [JBoss-dev] JNuke dev

2003-01-14 Thread Dain Sundstrom
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=Userop=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

2003-01-14 Thread Dain Sundstrom
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=Userop=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

2003-01-14 Thread marc fleury
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=Userop=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 

Re: Re[4]: [JBoss-dev] URLConnection and opened files

2003-01-14 Thread Scott M Stark
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

2003-01-14 Thread Nathan Phelps
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=Userop=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(), 

Re[2]: [JBoss-dev] JNuke dev

2003-01-14 Thread julien viet
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=Userop=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
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 

RE: [JBoss-dev] JNuke dev

2003-01-14 Thread James Higginbotham
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=Userop=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 

RE: [JBoss-dev] JNuke dev

2003-01-14 Thread marc fleury
 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

2003-01-14 Thread Ben Sabrin
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=Userop=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 

RE: [JBoss-dev] JNuke dev

2003-01-14 Thread Ben Sabrin
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=Userop=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

RE: [JBoss-dev] JNuke dev

2003-01-14 Thread Bill Burke
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=Userop=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
  

RE: [JBoss-dev] JNuke dev

2003-01-14 Thread Bill Burke
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=Userop=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, 

RE: [JBoss-dev] JNuke dev

2003-01-14 Thread Bill Burke
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=Userop=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

JBossScript was RE: [JBoss-dev] JNuke dev

2003-01-14 Thread Bill Burke
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=Userop=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), 

AutoDeploy Source Development ( Was:Re: [JBoss-dev] JNuke dev)

2003-01-14 Thread Peter Fagerlund

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

2003-01-14 Thread Dain Sundstrom
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=Userop=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 

RE: [JBoss-dev] JNuke dev

2003-01-14 Thread marc fleury
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

2003-01-14 Thread marc fleury
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=Userop=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 

RE: Re[2]: [JBoss-dev] JNuke dev

2003-01-14 Thread Jeremy Boynes
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 :
   
 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=Userop=register means

[JBoss-dev] [ jboss-Bugs-667341 ] Initial Session AUTH failure

2003-01-14 Thread SourceForge.net
Bugs item #667341, was opened at 2003-01-13 19:24
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=667341group_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=detailatid=376685aid=667341group_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

2003-01-14 Thread julien viet
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 :
   
 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.
 

RE: JBossScript was RE: [JBoss-dev] JNuke dev

2003-01-14 Thread wonder sonic
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=Userop=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 :
 
=== message truncated === 

___
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: 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: 

RE: JBossScript was RE: [JBoss-dev] JNuke dev

2003-01-14 Thread Bill Burke
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 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=Userop=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.

Re[2]: JBossScript was RE: [JBoss-dev] JNuke dev

2003-01-14 Thread julien viet
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.
 
   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=Userop=register means
 that the PN must call the method
  

[JBoss-dev] Anyone able to access cvs?

2003-01-14 Thread Scott M Stark
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 38date -u
Tue Jan 14 22:42:56  2003
jboss-3.2 39ping 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

2003-01-14 Thread David Jencks
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] Anyone able to access cvs?

2003-01-14 Thread Dain Sundstrom
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 38date -u
Tue Jan 14 22:42:56  2003
jboss-3.2 39ping 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?

2003-01-14 Thread Holger Baxmann
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 38date -u
 Tue Jan 14 22:42:56  2003
 jboss-3.2 39ping 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?

2003-01-14 Thread Langelage, Frank
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 38date -u
Tue Jan 14 22:42:56  2003
jboss-3.2 39ping 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-development


Re: [JBoss-dev] Anyone able to access cvs?

2003-01-14 Thread Scott M Stark
Set the PS1 variable:

jboss-head 746echo $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

2003-01-14 Thread Scott M Stark
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 tt$Revision: 1.2.2.1 $/tt
   + * @version tt$Revision: 1.2.2.2 $/tt
 * @author  a href=mailto:[EMAIL PROTECTED];Jason Dillon/a
 */
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?

2003-01-14 Thread Holger Baxmann
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 746echo $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

2003-01-14 Thread John Fawcett
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

2003-01-14 Thread SourceForge.net
Bugs item #667341, was opened at 2003-01-13 13:24
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=667341group_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://myserver/mycontext/

based on my deployment descriptor 
welcome-file-list
welcome-fileindex.html/welcome-file
/welcome-file-list
jetty should take me to
http://myserver/mycontext/index.html, which is this:

html
head
titleMy Company Name/title
meta http-equiv=refresh content=0;URL=index.jsp
 /head
 body
/body
/html

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 

RE: [JBoss-dev] any reason for -classic

2003-01-14 Thread Bill Burke
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

2003-01-14 Thread Bill Burke
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

2003-01-14 Thread SourceForge.net
Bugs item #668291, was opened at 2003-01-15 13:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=668291group_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

[JBoss-dev] Automated JBoss(JBoss_3_2_0_RC1 WonderLand) Testsuite Results: 14-January-2003

2003-01-14 Thread scott . stark


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

2003-01-14 Thread SourceForge.net
Bugs item #668313, was opened at 2003-01-15 05:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=668313group_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.init(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

RE: [JBoss-dev] Anyone able to access cvs?

2003-01-14 Thread marc fleury
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 746echo $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

2003-01-14 Thread Alex Loubyansky
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

2003-01-14 Thread SourceForge.net
Bugs item #668313, was opened at 2003-01-15 05:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=668313group_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.init(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

[JBoss-dev] [ jboss-Bugs-668313 ] jboss 3.0.5 can't redeploy tomcat

2003-01-14 Thread SourceForge.net
Bugs item #668313, was opened at 2003-01-14 21:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=668313group_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.init(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

2003-01-14 Thread Alex Loubyansky
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=Userop=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 

[JBoss-dev] [ jboss-Bugs-668313 ] jboss 3.0.5 can't redeploy tomcat

2003-01-14 Thread SourceForge.net
Bugs item #668313, was opened at 2003-01-14 21:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=668313group_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.init(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

2003-01-14 Thread Scott M Stark
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