Re: [JBoss-dev] -service.xml generator

[Alex Loubyansky]

Thanks, Anatoly. I'll check it. Also I thought about Velocity which looks 
similar to Jelly from your description, though I am not familiar with the last 
one.

Could you, please, look at the following idea with XML/XSL, compare it with 
Jelly and give your opinion?
- before transformation, each MBean's attribute is set as a parameter to the 
Transformer with Transformer.setParameter(...) with the name equal to the 
corresponding parameter name used in XSL stylesheet;
- transform XML template with Transformer and XSL stylesheet.

As for me, XML/XSL requires two templates (XML and XSL) while Jelly/Velocity 
requires only one.

Also, I wouldn't add any thirdparty library unless it really helps. The JBoss 
becomes so heavy. I think it's problem.

Thanks.

alex

On Sat, 26 Oct 2002 20:08:08 -0400
 Anatoly Akkerman [EMAIL PROTECTED] wrote:
Alex Loubyansky wrote:
I am thinking about writting an MBean that will generate *-service.xml 
files for datasources.
I see it the following way.
- MBean attributes corresponding to values needed to construct 
-service.xml (such as url, driver, user, password, etc);
- XML template with dummy/default values;
- XSL stylesheet similar to what David wrote for -ds.xml;
- managed operation 'generate' that will transform XML template, 
probably, mostly substituting dummy values with managed attribute values.

Actually, I am looking for a nice way to configure datasources in 
FoeDeployer but I think it could be useful behind it.
Also the same way any -service.xml file can be generated.

Any thoughts?
Thanks.


I would strongly recommend using Jelly (from Apache) (found out about it 
from Rickard Oberg's weblog). You take your service-xml file and just 
replace values you might will need to change with expressions like 
${varname}. Then you can run the XML file as a script in Jelly in a 
JellyContext in which you set up all the needed variables, say, from the 
MBean's attributes. The result of running it through Jelly is XML with the 
expressions properly evaluated. (Jelly is a much better replacement to JSPs 
and similar things, what is good about it you can run it w/o any container 
nonsense). You can also create your custom tag libraries like in JSPs, 
though it is much better than JSPs. There is not much documentation but it 
is pretty straight forward. Get back to me if you are having difficulties.

(You would not need XSLT either, actually, I am using Jelly in this way to 
automatically reconfigure application components, like EJBs or others and 
system-level components, like MBeans. If anyone is interested, I can share 
some of that stuff)

Anatoly.

Free Mail http://ua.fm


---
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] -service.xml generator

[Anatoly Akkerman]

Hi, Alex

Jelly would give you similar ease of use but without having to write any 
XSL. You would initialize the JellyContext by creating in first and then 
setting variables in it from attributes like this:
ctx.setVariable(name, value);

(values can be any Java objects)

you load your modified *-service.xml script from a URL into Jelly and 
run it as a script in the context which you just set up. The result of 
this operation is XML again.

This is simplest usage of Jelly. You do need a library, though, and 
possibly, not one but a bunch from jakarta-commons.

I am using Jelly in a slightly more advanced fashion. I wrote a few very 
simple tags that allow output of Jelly to be a jar file. Something like:
j:jelly xmlns:j=jelly:core xmlns:zipper=jelly:mypackage.MyTagLib
zipper:zip
		zipper:entry name=META-INF/ejb-jar.xml 
			parametrized ejb-jar.xml contents go here
		/zipper:entry
		zipper:entry name=META-INF/jboss.xml 
			parametrized jboss-xml contents go here
		/zipper:entry		
/zipper:zip
/j:jelly

Set up the JellyContext for running this script with appropriately 
configured variables (say from a DB of configurations or from attributes 
of an MBean). Run the script in the context.
After running this script, the JellyContext contains a Jar archive (as a 
byte[] stored under some variable name) of reconfigured descriptors.

The way I use it is to have a servlet that parses its path request and 
deduces from the path request which script to run and which 
configuration to pull from storage. The servlet outputs either XML or 
JAR depending on the requested module and its script.

So, you can just point the JBoss deployer to deploy a URL of the kind:

myservlet/componentA/configX.jar
or
myservlet/serviceB/configY.xml
and the servlet automatically generates properly configured jar or xml
which the Deployer happily deploys.

Jelly has many usages this is just what I could come up with. It would 
be more than adequate for what you need to do, but if you are 
dissatisfied with JBoss library dependency growth, then, Jelly is out of 
the picture.

Alex Loubyansky wrote:
Thanks, Anatoly. I'll check it. Also I thought about Velocity which 
looks similar to Jelly from your description, though I am not familiar 
with the last one.

Could you, please, look at the following idea with XML/XSL, compare it 
with Jelly and give your opinion?
- before transformation, each MBean's attribute is set as a parameter to 
the Transformer with Transformer.setParameter(...) with the name equal 
to the corresponding parameter name used in XSL stylesheet;
- transform XML template with Transformer and XSL stylesheet.

As for me, XML/XSL requires two templates (XML and XSL) while 
Jelly/Velocity requires only one.

Also, I wouldn't add any thirdparty library unless it really helps. The 
JBoss becomes so heavy. I think it's problem.



---
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] -service.xml generator

[Werner Ramaekers]

Anatoly Akkerman wrote:


Alex Loubyansky wrote:


I am thinking about writting an MBean that will generate 
*-service.xml files for datasources.
I see it the following way.
- MBean attributes corresponding to values needed to construct 
-service.xml (such as url, driver, user, password, etc);
- XML template with dummy/default values;
- XSL stylesheet similar to what David wrote for -ds.xml;
- managed operation 'generate' that will transform XML template, 
probably, mostly substituting dummy values with managed attribute values.

Actually, I am looking for a nice way to configure datasources in 
FoeDeployer but I think it could be useful behind it.
Also the same way any -service.xml file can be generated.

Any thoughts?
Thanks.



I would strongly recommend using Jelly (from Apache) (found out about 
it from Rickard Oberg's weblog). You take your service-xml file and 
just replace values you might will need to change with expressions 
like ${varname}. Then you can run the XML file as a script in Jelly in 
a JellyContext in which you set up all the needed variables, say, from 
the MBean's attributes. The result of running it through Jelly is XML 
with the expressions properly evaluated. (Jelly is a much better 
replacement to JSPs and similar things, what is good about it you can 
run it w/o any container nonsense). You can also create your custom 
tag libraries like in JSPs, though it is much better than JSPs. There 
is not much documentation but it is pretty straight forward. Get back 
to me if you are having difficulties.

(You would not need XSLT either, actually, I am using Jelly in this 
way to automatically reconfigure application components, like EJBs or 
others and system-level components, like MBeans. If anyone is 
interested, I can share some of that stuff)

Anatoly.

Anatoly, I would be interested to know more about how you used it to 
automatically reconfigure your application components , so please share 
some of that if you can ;-))

thnx
Werner

--
--
ir. Werner Ramaekers
Enterprise Java Solutions Architect - Shift@
Sun Certified Java Programmer - BeJUG steering commitee member

May the source be with you.

Read my Blog at http://www.werner.be
--




---
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] Documentation

[Thomas Peuss]

Hello!

If I remember right we should provide docs for new pieces we add to 
JBoss. Where should I put this docs?

CU
Thomas



---
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] Documentation

[marc fleury]

just put a doc.txt with your code or put it in a doc directory somewhere

just put the doc

marc f

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:jboss-development-admin;lists.sourceforge.net] On 
 Behalf Of Thomas Peuss
 Sent: Sunday, October 27, 2002 11:49 AM
 To: [EMAIL PROTECTED]
 Subject: [JBoss-dev] Documentation
 
 
 Hello!
 
 If I remember right we should provide docs for new pieces we add to 
 JBoss. Where should I put this docs?
 
 CU
 Thomas
 
 
 
 ---
 This SF.net email is sponsored by: ApacheCon, November 18-21 
 in Las Vegas (supported by COMDEX), the only Apache event to 
 be fully supported by the ASF. http://www.apachecon.com 
 ___
 Jboss-development mailing list [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 



---
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 27-October-2002

[scott . stark]

Number of tests run:   984



Successful tests:  982
Errors:1
Failures:  1



[time of test: 27 October 2002 12:49 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
[java.vm.version: 1.3.1_03-69]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Mac OS X]
[os.arch: ppc]
[os.version: 10.2.1]

See http://lubega.com/testarchive/${build.uid} for details of this test.

See http://lubega.com for general test information.

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.
Remember - if a test becomes broken after your changes - fix it or fix the test!





Oh dear - still got some errors!



Thanks for all your effort - we really do love you!




---
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-627892 ] getUserRoles incorrectly returns null

[noreply]

Bugs item #627892, was opened at 2002-10-24 11:19
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=627892group_id=22866

Category: JBossSX
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Jon S Bratseth (bratseth)
Assigned to: Scott M Stark (starksm)
Summary: getUserRoles incorrectly returns null

Initial Comment:
See the first posting on this at
http://www.jboss.org/forums/thread.jsp?
forum=49thread=23370

The problem is that JaasSecurityManager.getUserRoles
returns null when it should have returned the pricipals 
roles:
[code]
   public Set getUserRoles(Principal principal)
   {
  HashSet userRoles = null;
  Subject subject = getActiveSubject();
  if( subject != null )
  {
 DomainInfo info = getCacheInfo(principal, false);
 Group roles = null;
 if( info != null )
roles = info.roles;
 if( roles != null )
 {
userRoles = new HashSet();
Enumeration members = roles.members();
while( members.hasMoreElements() )
{
   Principal role = (Principal) 
members.nextElement();
   userRoles.add(role);
}
 }
  }
  return userRoles;
   }
[/code]

This is an obfuscated way of saying
  if theres cached roles ( getCacheInfo(..).roles ),
 return them
  else
 return null

And when getCacheInfo is called with parameter false, it 
will peek() the cache, and thus not fetch the object if it's 
not present. 
Thus, if there's no cached roles, the roles returned for 
the principal is null.

This can't be what is intended, but how to correct it?
I could simply pass true instead of false to switch to get
() instead of peek(), but the JavaDoc of getCacheInfo 
warns about an error on getCacheInfo(..,true) which 
seesms to be to be the error one would get on sending 
false:

[code]
   /** An accessor method that synchronizes access on 
the domainCache
to avoid a race condition that can occur when the 
cache entry expires
in the presence of multi-threaded access. The 
allowRefresh flag should
be true for authentication accesses and false for 
authorization accesses.
If it were to be true for an authorization access a 
previously authenticated
user could be seen to not have their expected 
permissions due to a cache
expiration.

@param principal, the caller identity whose cached 
credentials are to
be accessed.
@param allowRefresh, a flag indicating if the cache 
access should flush
any expired entries.
*/
   private DomainInfo getCacheInfo(Principal principal, 
boolean allowRefresh)
   {
  if( domainCache == null )
 return null;

  DomainInfo cacheInfo = null;
  synchronized( domainCache )
  {
  if( allowRefresh == true )
cacheInfo = (DomainInfo) domainCache.get
(principal);
  else
cacheInfo = (DomainInfo) domainCache.peek
(principal);
  }
  return cacheInfo;
   }
[/code]

Is the problem simply that the cases which should allow 
refresh and thos which should have been mixed up?




--

Comment By: Jon S Bratseth (bratseth)
Date: 2002-10-28 00:11

Message:
Logged In: YES 
user_id=618121

The problem was a combination of the following:

- JAAS not always finding the client login config because i'm 
running through WebStart which uses it's own class loader 
which was not set as the context class loader

- ClientLoginModule using the old callback handler even if a 
new one is submitted:
  LoginContext(client-login,
  new CallbackHandler(misspelledname,pw)).
login();
  
  LoginContext(client-login,
  new CallbackHandler(correctedname,pw)).
 login();
will use the first handler also the second timenot wrong, 
only surprising, to me at least.

- The accidential server-side execution of some code involved 
in setting up the client login configuration.

Thanks for your time.


--

Comment By: Scott M Stark (starksm)
Date: 2002-10-25 22:08

Message:
Logged In: YES 
user_id=175228

That makes no sense. Flushing the cache resets the 
security domain state to its startup state. Describe how you 
can achieve a state where no one can login even after the 
cache is flushed.


--

Comment By: Marius Kotsbak (mkotsbak)
Date: 2002-10-25 20:31

Message:
Logged In: YES 
user_id=366650

This might be the problem that causes RunAsLoginModule not
to work. It doesn't work because there is principal=null.

--

Comment By: Jon S Bratseth (bratseth)
Date: 2002-10-25 14:39

Message:
Logged In: YES 
user_id=618121

Yes, I see that now. I was misled by the term 

[JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock

[noreply]

Bugs item #617574, was opened at 2002-10-03 00:20
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=617574group_id=22866

Category: JBossMX
Group: v3.2
Status: Open
Resolution: Fixed
Priority: 7
Submitted By: Michael Bartmann (bartmann)
Assigned to: Scott M Stark (starksm)
Summary: Classloader deadlock

Initial Comment:
We have for the third time in quite some weeks
experienced a partial lookup
of the JBoss server (some services responsive, others
not). The bug is not deterministically reproducible for us.
But this time we luckily had a debugger online and
drilled down
to what seems to be a classloader deadlock.

This was under NT4.0 (it happend before under W2000 also)
We used Branch_3_2 (checkout 12 hours before it went beta)
under JDK1.4.0-b92.

It happened when many separate ear-scoped mbeans
and dependent MDBs got deployed in a short time.
Many of the mbeans are JMSProviders and the MDBs
recieve external messages almost immediatelly after
startup, so they all try to load classes simultaneously.

Most of the threads were waiting for a lock at line 84
in the loadClass()
of HeirarchicalLoaderRepository2; only one threads was
locked
in loadClass() of  java.lang.ClassLoader.

The two threads which seem to have caused the deadlock were
Thread-47 (java.util.TimerThread) and
Thread Pool Worker-0 (EDU.oswego.blablaWorker),
both childs of the ThreadGroup ASF Session Pool Threads.

===
Thread-47 has the following trace:
loadClass() at line 84 of
org.jboss.mx.loading.HeirarchicalLoaderRepository2,
this=org.jboss.mx.loading.HeirarchicalLoaderRepository2@129c
...
loadClass() at line 262 of java.lang.ClassLoader,
this=org.jboss.mx.loading.UnifiedClassLoader@1299
...
===
Thread Pool Worker-0 has the following trace:
loadClass() at line 295 of java.lang.ClassLoader,
this=org.jboss.mx.loading.UnifiedClassLoader@1299
...
loadClass() at line 88 of
org.jboss.mx.loading.HeirarchicalLoaderRepository2,
this=org.jboss.mx.loading.HeirarchicalLoaderRepository2@129c
...
===

...so the deadlock seems evident. 


--

Comment By: Stephen Coy (scoy)
Date: 2002-10-28 14:40

Message:
Logged In: YES 
user_id=463096

UCL3 has broken our web application.

It appears to be hanging in the same loop shown for the main thread in 
Michael's thread dump.

ie. in line 152 of UnifiedClassLoader3.java



--

Comment By: Michael Bartmann (bartmann)
Date: 2002-10-25 21:48

Message:
Logged In: YES 
user_id=69300

The proposed fix (UCL3) hangs.
See attached threaddump

Regards,
Michael Bartmann

--

Comment By: Scott M Stark (starksm)
Date: 2002-10-04 06:59

Message:
Logged In: YES 
user_id=175228

See the changes added today to address this issue. I have 
not been able to come up with a testcase that reproduces 
the original deadlock so the completion of the fix is waiting 
that.

--

Comment By: Scott M Stark (starksm)
Date: 2002-10-03 05:58

Message:
Logged In: YES 
user_id=175228

Checkout the VM docs for your platform on how to generate 
a thread dump. Its Ctrl-Break on windows, Ctrl-\ or SIGQUIT 
on most *unix like systems for the sun based VMs.

Ok, I see what you are referring to reguarding the loadClass 
calls to UCL@1299. The call from Thread-47 is does not have 
a top level call through a UnifiedClassLoader2 at any point 
and this will violate the use condition for the 
UnfiedClassLoader entering loadClass. I'll look into that.


--

Comment By: Michael Bartmann (bartmann)
Date: 2002-10-03 05:42

Message:
Logged In: YES 
user_id=69300

Please forgive me. I write highly parallel code for years and
don't know how to generate a VM thread dump w/o the
debugger. Got to find out how.

What we did instead is:
we walked through the JBuilder debug thread list and
saved a stacktrace of every single thread that had a loadClass
anywhere in its stacktrace (as bmp, I can see you roll on
the floor...).

But there is one thing with your argument that I don't
understand:
At least in what JBuilder showed as the source of the
java.lang.ClassLoader we have a lock (synchronized..) in
the java.lang.ClassLoader too.
So I saw two synchronized sections locking on two different
ClassLoader instances, which are overcross in the two threads.

Shouldn't this deadlock?


--

Comment By: Scott M Stark (starksm)
Date: 2002-10-03 04:37

Message:
Logged In: YES 
user_id=175228

Can't you just provide the VM thread dump rather than having 
to run the server in a debugger? The thread dumps shown by 
the two images do not indicate to me that 

[JBoss-dev] [ jboss-Bugs-627405 ] LdapLoginModule accepts empty password

[noreply]

Bugs item #627405, was opened at 2002-10-23 04:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=627405group_id=22866

Category: JBossSX
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Erik Konijnenburg (konijnenburg)
Assigned to: Scott M Stark (starksm)
Summary: LdapLoginModule accepts empty password

Initial Comment:
Hi there,

When i login on my web site (i am using forms) using 
the LdapLoginModule I don't have to supply a password 
to login The LDAP server (netscape directory server 
4.12) seems to allow for anonymous authentication. 
Using the right password authenticates the user, using a 
wrong password (except empty) doesnot.




   application-policy name = LDAPRealm
authentication
   login-module code 
= org.jboss.security.auth.spi.LdapLoginModule flag 
= required
 module-option 
name=java.naming.factory.initialcom.sun.jndi.ldap.Lda
pCtxFactory/module-option
 module-option 
name=java.naming.provider.urlldap://NLRTMWS001:3
89//module-option
module-option 
name=java.naming.security.authenticationsimple/mo
dule-option
 module-option 
name=principalDNPrefixcn=/module-option
 module-option 
name=principalDNSuffix,cn=basic,cn=Signons,cn=def
ault,cn=Authentication Data,o=sdfsadf,c=NL/module-
option
  !--   module-option 
name=userRolesCtxDNAttributeNameauthid/module-
option --
module-option 
name=uidAttributeIDauthbasicsignonlist/module-
option
module-option 
name=roleAttributeIDauthuserclasslist/module-
option
 module-option 
name=rolesCtxDNcn=Users,cn=default,cn=Authentic
ation Data,o=vopakwst,c=nl/module-option
  !--   module-option 
name=hashAlgorithmSHA-1/module-option 
module-option 
name=hashEncodingbase64/module-option  --
  /login-module
  /authentication
   /application-policy

--

Comment By: Scott M Stark (starksm)
Date: 2002-10-27 19:54

Message:
Logged In: YES 
user_id=175228

This is an ldap server configuration issue. If you don't want 
anonymous bindings why allow it? I will add an option flag to 
treat empty passwords as null passwords in the event that 
the default ldap admin policy for anonymous users conflicts 
with a particular application usage, but this will default to true.

--

Comment By: Erik Konijnenburg (konijnenburg)
Date: 2002-10-23 05:27

Message:
Logged In: YES 
user_id=522939

A possible patch is:

protected boolean validatePassword(String inputPassword, 
String expectedPassword)
   {
  boolean isValid = false;
  if( inputPassword != null  inputPassword.length()  0 )
  {
    

Even better make this an option

--

Comment By: Erik Konijnenburg (konijnenburg)
Date: 2002-10-23 05:26

Message:
Logged In: YES 
user_id=522939

A possible patch is:

protected boolean validatePassword(String inputPassword, 
String expectedPassword)
   {
  boolean isValid = false;
  if( inputPassword != null  inputPassword.length()  0 )
  {
    

Even better make this an option

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=627405group_id=22866


---
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock

[noreply]

Bugs item #617574, was opened at 2002-10-02 07:20
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=617574group_id=22866

Category: JBossMX
Group: v3.2
Status: Closed
Resolution: Fixed
Priority: 7
Submitted By: Michael Bartmann (bartmann)
Assigned to: Scott M Stark (starksm)
Summary: Classloader deadlock

Initial Comment:
We have for the third time in quite some weeks
experienced a partial lookup
of the JBoss server (some services responsive, others
not). The bug is not deterministically reproducible for us.
But this time we luckily had a debugger online and
drilled down
to what seems to be a classloader deadlock.

This was under NT4.0 (it happend before under W2000 also)
We used Branch_3_2 (checkout 12 hours before it went beta)
under JDK1.4.0-b92.

It happened when many separate ear-scoped mbeans
and dependent MDBs got deployed in a short time.
Many of the mbeans are JMSProviders and the MDBs
recieve external messages almost immediatelly after
startup, so they all try to load classes simultaneously.

Most of the threads were waiting for a lock at line 84
in the loadClass()
of HeirarchicalLoaderRepository2; only one threads was
locked
in loadClass() of  java.lang.ClassLoader.

The two threads which seem to have caused the deadlock were
Thread-47 (java.util.TimerThread) and
Thread Pool Worker-0 (EDU.oswego.blablaWorker),
both childs of the ThreadGroup ASF Session Pool Threads.

===
Thread-47 has the following trace:
loadClass() at line 84 of
org.jboss.mx.loading.HeirarchicalLoaderRepository2,
this=org.jboss.mx.loading.HeirarchicalLoaderRepository2@129c
...
loadClass() at line 262 of java.lang.ClassLoader,
this=org.jboss.mx.loading.UnifiedClassLoader@1299
...
===
Thread Pool Worker-0 has the following trace:
loadClass() at line 295 of java.lang.ClassLoader,
this=org.jboss.mx.loading.UnifiedClassLoader@1299
...
loadClass() at line 88 of
org.jboss.mx.loading.HeirarchicalLoaderRepository2,
this=org.jboss.mx.loading.HeirarchicalLoaderRepository2@129c
...
===

...so the deadlock seems evident. 


--

Comment By: Scott M Stark (starksm)
Date: 2002-10-27 19:51

Message:
Logged In: YES 
user_id=175228

The problem was a lost class loading task notification due to 
non-CNFE errors during class loading. This has been fixed in 
the 3.0 and 3.2 branches.

--

Comment By: Stephen Coy (scoy)
Date: 2002-10-27 19:40

Message:
Logged In: YES 
user_id=463096

UCL3 has broken our web application.

It appears to be hanging in the same loop shown for the main thread in 
Michael's thread dump.

ie. in line 152 of UnifiedClassLoader3.java



--

Comment By: Michael Bartmann (bartmann)
Date: 2002-10-25 04:48

Message:
Logged In: YES 
user_id=69300

The proposed fix (UCL3) hangs.
See attached threaddump

Regards,
Michael Bartmann

--

Comment By: Scott M Stark (starksm)
Date: 2002-10-03 13:59

Message:
Logged In: YES 
user_id=175228

See the changes added today to address this issue. I have 
not been able to come up with a testcase that reproduces 
the original deadlock so the completion of the fix is waiting 
that.

--

Comment By: Scott M Stark (starksm)
Date: 2002-10-02 12:58

Message:
Logged In: YES 
user_id=175228

Checkout the VM docs for your platform on how to generate 
a thread dump. Its Ctrl-Break on windows, Ctrl-\ or SIGQUIT 
on most *unix like systems for the sun based VMs.

Ok, I see what you are referring to reguarding the loadClass 
calls to UCL@1299. The call from Thread-47 is does not have 
a top level call through a UnifiedClassLoader2 at any point 
and this will violate the use condition for the 
UnfiedClassLoader entering loadClass. I'll look into that.


--

Comment By: Michael Bartmann (bartmann)
Date: 2002-10-02 12:42

Message:
Logged In: YES 
user_id=69300

Please forgive me. I write highly parallel code for years and
don't know how to generate a VM thread dump w/o the
debugger. Got to find out how.

What we did instead is:
we walked through the JBuilder debug thread list and
saved a stacktrace of every single thread that had a loadClass
anywhere in its stacktrace (as bmp, I can see you roll on
the floor...).

But there is one thing with your argument that I don't
understand:
At least in what JBuilder showed as the source of the
java.lang.ClassLoader we have a lock (synchronized..) in
the java.lang.ClassLoader too.
So I saw two synchronized sections locking on two different
ClassLoader instances, which are overcross in the two threads.

Shouldn't this deadlock?

[JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock

[noreply]

Bugs item #617574, was opened at 2002-10-03 00:20
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=617574group_id=22866

Category: JBossMX
Group: v3.2
Status: Closed
Resolution: Fixed
Priority: 7
Submitted By: Michael Bartmann (bartmann)
Assigned to: Scott M Stark (starksm)
Summary: Classloader deadlock

Initial Comment:
We have for the third time in quite some weeks
experienced a partial lookup
of the JBoss server (some services responsive, others
not). The bug is not deterministically reproducible for us.
But this time we luckily had a debugger online and
drilled down
to what seems to be a classloader deadlock.

This was under NT4.0 (it happend before under W2000 also)
We used Branch_3_2 (checkout 12 hours before it went beta)
under JDK1.4.0-b92.

It happened when many separate ear-scoped mbeans
and dependent MDBs got deployed in a short time.
Many of the mbeans are JMSProviders and the MDBs
recieve external messages almost immediatelly after
startup, so they all try to load classes simultaneously.

Most of the threads were waiting for a lock at line 84
in the loadClass()
of HeirarchicalLoaderRepository2; only one threads was
locked
in loadClass() of  java.lang.ClassLoader.

The two threads which seem to have caused the deadlock were
Thread-47 (java.util.TimerThread) and
Thread Pool Worker-0 (EDU.oswego.blablaWorker),
both childs of the ThreadGroup ASF Session Pool Threads.

===
Thread-47 has the following trace:
loadClass() at line 84 of
org.jboss.mx.loading.HeirarchicalLoaderRepository2,
this=org.jboss.mx.loading.HeirarchicalLoaderRepository2@129c
...
loadClass() at line 262 of java.lang.ClassLoader,
this=org.jboss.mx.loading.UnifiedClassLoader@1299
...
===
Thread Pool Worker-0 has the following trace:
loadClass() at line 295 of java.lang.ClassLoader,
this=org.jboss.mx.loading.UnifiedClassLoader@1299
...
loadClass() at line 88 of
org.jboss.mx.loading.HeirarchicalLoaderRepository2,
this=org.jboss.mx.loading.HeirarchicalLoaderRepository2@129c
...
===

...so the deadlock seems evident. 


--

Comment By: Stephen Coy (scoy)
Date: 2002-10-28 15:28

Message:
Logged In: YES 
user_id=463096

I've just refreshed my Branch_3_0 from cvs, cleaned and rebuilt, but the 
problem is still  there:

SocketListener-3 prio=5 tid=0x48620b0 nid=0x4811140 runnable 
[0xf0d99000..0xf0d9aba0]
at java.lang.Object.wait(Native Method)
at 
org.jboss.mx.loading.UnifiedClassLoader3.loadClass(UnifiedClassLoader
3.java:152)
at java.lang.ClassLoader.loadClass(ClassLoader.java:250)
at java.beans.Introspector.instantiate(Introspector.java:1061)
at java.beans.Introspector.findInformant(Introspector.java:303)
at java.beans.Introspector.init(Introspector.java:251)
at java.beans.Introspector.getBeanInfo(Introspector.java:76)
at 
org.apache.struts.util.PropertyUtils.getPropertyDescriptors(PropertyUtils
.java:552)
at 
org.apache.struts.util.PropertyUtils.getPropertyDescriptor(PropertyUtils.j
ava:516)
at 
org.apache.struts.util.PropertyUtils.getSimpleProperty(PropertyUtils.java
:706)
at 
org.apache.struts.util.PropertyUtils.getNestedProperty(PropertyUtils.java
:426)
at 
org.apache.struts.util.PropertyUtils.getProperty(PropertyUtils.java:453)
at 
org.apache.struts.taglib.logic.CompareTagBase.condition(CompareTagB
ase.java:228)
at 
org.apache.struts.taglib.logic.EqualTag.condition(EqualTag.java:90)
at 
org.apache.struts.taglib.logic.ConditionalTagBase.doStartTag(Conditiona
lTagBase.java:218)
at 
JspServ.online.workList.actionBar._jspService(actionBar.java:309)
at 
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at 
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:366)
at 
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicatio
nHandler.java:293)
at 
org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:216)
at 
org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:151)
at 
org.apache.struts.action.ActionServlet.processActionForward(ActionSer
vlet.java:1759)
at 
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1596)
at 
org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:492)
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:366)
at 
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicatio
nHandler.java:293)
at 
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:581)
at 

[JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock

[noreply]

Bugs item #617574, was opened at 2002-10-02 07:20
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=617574group_id=22866

Category: JBossMX
Group: v3.2
Status: Closed
Resolution: Fixed
Priority: 7
Submitted By: Michael Bartmann (bartmann)
Assigned to: Scott M Stark (starksm)
Summary: Classloader deadlock

Initial Comment:
We have for the third time in quite some weeks
experienced a partial lookup
of the JBoss server (some services responsive, others
not). The bug is not deterministically reproducible for us.
But this time we luckily had a debugger online and
drilled down
to what seems to be a classloader deadlock.

This was under NT4.0 (it happend before under W2000 also)
We used Branch_3_2 (checkout 12 hours before it went beta)
under JDK1.4.0-b92.

It happened when many separate ear-scoped mbeans
and dependent MDBs got deployed in a short time.
Many of the mbeans are JMSProviders and the MDBs
recieve external messages almost immediatelly after
startup, so they all try to load classes simultaneously.

Most of the threads were waiting for a lock at line 84
in the loadClass()
of HeirarchicalLoaderRepository2; only one threads was
locked
in loadClass() of  java.lang.ClassLoader.

The two threads which seem to have caused the deadlock were
Thread-47 (java.util.TimerThread) and
Thread Pool Worker-0 (EDU.oswego.blablaWorker),
both childs of the ThreadGroup ASF Session Pool Threads.

===
Thread-47 has the following trace:
loadClass() at line 84 of
org.jboss.mx.loading.HeirarchicalLoaderRepository2,
this=org.jboss.mx.loading.HeirarchicalLoaderRepository2@129c
...
loadClass() at line 262 of java.lang.ClassLoader,
this=org.jboss.mx.loading.UnifiedClassLoader@1299
...
===
Thread Pool Worker-0 has the following trace:
loadClass() at line 295 of java.lang.ClassLoader,
this=org.jboss.mx.loading.UnifiedClassLoader@1299
...
loadClass() at line 88 of
org.jboss.mx.loading.HeirarchicalLoaderRepository2,
this=org.jboss.mx.loading.HeirarchicalLoaderRepository2@129c
...
===

...so the deadlock seems evident. 


--

Comment By: Scott M Stark (starksm)
Date: 2002-10-27 20:42

Message:
Logged In: YES 
user_id=175228

Enable tracing of the org.jboss.mx.loading category by 
adding a section like the following to the conf/log4j.xml file:

  category name=org.jboss.system
priority value=TRACE 
class=org.jboss.logging.XLevel/
  /category

and attach the log file of the TRACE level msgs.



--

Comment By: Stephen Coy (scoy)
Date: 2002-10-27 20:28

Message:
Logged In: YES 
user_id=463096

I've just refreshed my Branch_3_0 from cvs, cleaned and rebuilt, but the 
problem is still  there:

SocketListener-3 prio=5 tid=0x48620b0 nid=0x4811140 runnable 
[0xf0d99000..0xf0d9aba0]
at java.lang.Object.wait(Native Method)
at 
org.jboss.mx.loading.UnifiedClassLoader3.loadClass(UnifiedClassLoader
3.java:152)
at java.lang.ClassLoader.loadClass(ClassLoader.java:250)
at java.beans.Introspector.instantiate(Introspector.java:1061)
at java.beans.Introspector.findInformant(Introspector.java:303)
at java.beans.Introspector.init(Introspector.java:251)
at java.beans.Introspector.getBeanInfo(Introspector.java:76)
at 
org.apache.struts.util.PropertyUtils.getPropertyDescriptors(PropertyUtils
.java:552)
at 
org.apache.struts.util.PropertyUtils.getPropertyDescriptor(PropertyUtils.j
ava:516)
at 
org.apache.struts.util.PropertyUtils.getSimpleProperty(PropertyUtils.java
:706)
at 
org.apache.struts.util.PropertyUtils.getNestedProperty(PropertyUtils.java
:426)
at 
org.apache.struts.util.PropertyUtils.getProperty(PropertyUtils.java:453)
at 
org.apache.struts.taglib.logic.CompareTagBase.condition(CompareTagB
ase.java:228)
at 
org.apache.struts.taglib.logic.EqualTag.condition(EqualTag.java:90)
at 
org.apache.struts.taglib.logic.ConditionalTagBase.doStartTag(Conditiona
lTagBase.java:218)
at 
JspServ.online.workList.actionBar._jspService(actionBar.java:309)
at 
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at 
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:366)
at 
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicatio
nHandler.java:293)
at 
org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:216)
at 
org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:151)
at 
org.apache.struts.action.ActionServlet.processActionForward(ActionSer
vlet.java:1759)
at 
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1596)
at 

Re[2]: [JBoss-dev] -service.xml generator

[Alex Loubyansky]

Anatoly, this looks cool and draws other perspectives. I'm in thought.

Any other thoughts/comments?
Thanks.

alex

Sunday, October 27, 2002, 4:07:15 PM, you wrote:

AA Hi, Alex

AA Jelly would give you similar ease of use but without having to write any 
AA XSL. You would initialize the JellyContext by creating in first and then 
AA setting variables in it from attributes like this:
AA ctx.setVariable(name, value);

AA (values can be any Java objects)

AA you load your modified *-service.xml script from a URL into Jelly and 
AA run it as a script in the context which you just set up. The result of 
AA this operation is XML again.

AA This is simplest usage of Jelly. You do need a library, though, and 
AA possibly, not one but a bunch from jakarta-commons.

AA I am using Jelly in a slightly more advanced fashion. I wrote a few very 
AA simple tags that allow output of Jelly to be a jar file. Something like:
AA j:jelly xmlns:j=jelly:core xmlns:zipper=jelly:mypackage.MyTagLib
AA zipper:zip
AA zipper:entry name=META-INF/ejb-jar.xml 
AA parametrized ejb-jar.xml contents go here
AA /zipper:entry
AA zipper:entry name=META-INF/jboss.xml 
AA parametrized jboss-xml contents go here
AA /zipper:entry 
AA /zipper:zip
AA /j:jelly

AA Set up the JellyContext for running this script with appropriately 
AA configured variables (say from a DB of configurations or from attributes 
AA of an MBean). Run the script in the context.
AA After running this script, the JellyContext contains a Jar archive (as a 
AA byte[] stored under some variable name) of reconfigured descriptors.

AA The way I use it is to have a servlet that parses its path request and 
AA deduces from the path request which script to run and which 
AA configuration to pull from storage. The servlet outputs either XML or 
AA JAR depending on the requested module and its script.

AA So, you can just point the JBoss deployer to deploy a URL of the kind:

AA myservlet/componentA/configX.jar
AA or
AA myservlet/serviceB/configY.xml
AA and the servlet automatically generates properly configured jar or xml
AA which the Deployer happily deploys.

AA Jelly has many usages this is just what I could come up with. It would 
AA be more than adequate for what you need to do, but if you are 
AA dissatisfied with JBoss library dependency growth, then, Jelly is out of 
AA the picture.

AA Alex Loubyansky wrote:
 Thanks, Anatoly. I'll check it. Also I thought about Velocity which 
 looks similar to Jelly from your description, though I am not familiar 
 with the last one.
 
 Could you, please, look at the following idea with XML/XSL, compare it 
 with Jelly and give your opinion?
 - before transformation, each MBean's attribute is set as a parameter to 
 the Transformer with Transformer.setParameter(...) with the name equal 
 to the corresponding parameter name used in XSL stylesheet;
 - transform XML template with Transformer and XSL stylesheet.
 
 As for me, XML/XSL requires two templates (XML and XSL) while 
 Jelly/Velocity requires only one.
 
 Also, I wouldn't add any thirdparty library unless it really helps. The 
 JBoss becomes so heavy. I think it's problem.


-- 
Best regards,
 Alex Loubyansky




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

JBoss 3.0.4 ? (Re: [JBoss-dev] Upcoming releases)

[Andreas Kuckartz]

  I'm planning on the following releases so time your work accordingly:
 
  2002-10-25jboss-2.4.10
  2002-10-27jboss-3.0.4
  2002-11-03jboss-3.2.0beta2 [corrected]
  2002-12-22jboss-4.0alpha
 
  
  Scott Stark
  Chief Technology Officer
  JBoss Group, LLC
  

Due to this announcement of the precise release date of version 3.0.4 I have
delayed work till today but I can not find the version on sourceforge.net.

Any new date for the release of that version?

Andreas



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development