March 2008 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Build System] - Re: EJB client launcher

by pgier

I think the testsuite is still compiling against the ClientLauncher in the ejb-core jar, since the snapshot ejb build in the thirdparty repository still contains this class. What does the testsuite compile classpath need to include for this? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138617#4138617 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138617

18 years

1
0
0 / 0

[Design of POJO Server] - Re: @RunAs annotations on Servlet Classes

by scott.stark＠jboss.org

Seems familiar, but would need to validate the unit class loader. I thought I saw this when there was a destroyed class loader being used. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138616#4138616 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138616

18 years

1
0
0 / 0

[Design of POJO Server] - Re: @RunAs annotations on Servlet Classes

by anil.saldhana＠jboss.com

| ===================================================== | Caused by: java.lang.NoClassDefFoundError: javax/servlet/http/HttpServlet | at java.lang.ClassLoader.defineClass1(Native Method) | at java.lang.ClassLoader.defineClass(ClassLoader.java:620) | at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLo | ader.java:63) | at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader. | java:502) | at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader. | java:462) | at java.security.AccessController.doPrivileged(Native Method) | at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseC | lassLoader.java:460) | at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseC | lassLoader.java:437) | ..... | at java.lang.ClassLoader.loadClass(ClassLoader.java:251) | at org.jboss.wsf.container.jboss50.JAXWSDeployerHookPreJSE.getRelevantSe | rvlets(JAXWSDeployerHookPreJSE.java:122) | at org.jboss.wsf.container.jboss50.JAXWSDeployerHookPreJSE.isWebServiceD | eployment(JAXWSDeployerHookPreJSE.java:98) | at org.jboss.wsf.container.jboss50.ArchiveDeployerHook.deploy(ArchiveDep | loyerHook.java:84) | =============================== | | Does this ring any bells, Scott? I need to verify the ejb3 security integration code a little bit further before I commit my ejb3 project changes. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138615#4138615 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138615

18 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: Upgrading GPD

by clandestino_bgd

Hi, a month after, I am still getting the same error like in my previous post on this thread. I have checked out the HEAD revision yesterday and today (no difference). My env is: windows XP, java sun 1.5, ant 1.7.0. Could somebody please take a look, confirm this or tell that problem is only mine. But please, reply something.... I would really need to take a look at GPD code and try to extend it as soon as possible. Is there any documentation how to add new Node, similar to ESB Node in GPD? Thank you. Milan View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138614#4138614 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138614

18 years

1
0
0 / 0

[Design of Security on JBoss] - Re: Encrypting attributes/properties of beans

by scott.stark＠jboss.org

Its an aspectization of the JaasSecurityDomain.encode/decode operations, applied to one or more bean properties. How the cipher/parameters for the attribute encryption are integrated into the aspect metadata is one issue. Before the hitting the write aspect of an encrypted property its clear-text, after its encrypted and this is what is stored in the bean. Likewise, before hitting the read aspect of an encrypted property its encrypted, clear-text after. The aspect also needs to be applied to metadata sources of the property if were worried about those being saved as can be the case for the profile service. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138613#4138613 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138613

18 years

1
0
0 / 0

[Design of POJO Server] - Re: @RunAs annotations on Servlet Classes

by scott.stark＠jboss.org

The annotation deployer has to run after parsing deployer as it needs the deployment class loader. We need to get rid of the old xml only based assertions to allow for web.xml, jboss-web.xml and annotations (possibly other deployers) providing metadata input. So, you came to the right solution. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138612#4138612 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138612

18 years

1
0
0 / 0

[Design of JBoss Build System] - Re: EJB client launcher

by scott.stark＠jboss.org

ClientLauncher is now in the jbossas ejb3 project jboss-appclient.jar and the jbossall-client.jar. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138611#4138611 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138611

18 years

1
0
0 / 0

[Design of JBossCache] - Refactorings for JBC2.2 (JBCACHE-1222)

by mircea.markus

There are some code refactoring ideas being discussed, which would have impact on JBossCache core architecture. We've set up an wiki with our observations here: http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheRefactoring22 Any suggestion/observation on this is welcomed! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138604#4138604 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138604

18 years

1
0
0 / 0

[Design of POJO Server] - Re: @RunAs annotations on Servlet Classes

by anil.saldhana＠jboss.com

http://jira.jboss.com/jira/browse/JBMETA-10 I have made JBossWebMetaData merge to ignore the web xml runas. A final merge done by the AnnotationMetaDatadeployer is the complete merge. The metadata project test case has been updated to test this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138600#4138600 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138600

18 years

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - JBPAPP-653

by bstansberry＠jboss.com

Discussion (perhaps with myself) re: logs attached to http://jira.jboss.com/jira/browse/JBPAPP-653. Couple indications point to a problem with perf02 receiving messages. 1) perf04, which would use perf02 as a buddy no longer logs remoting's "closing" messages after this: 2008-02-21 08:33:32,828 DEBUG [org.jboss.remoting.transport.socket.SocketWrapper] ServerSocketWrapper[Socket[addr=/172.17.68.254,port=33698,localport=3873].4d8918] closing Those messages are logged at the end of an EJB request; not logging means the request isn't completed yet. Lot's of logging of intermediate steps in request, but no completion. The cache is REPL_ASYNC, so that implies to me the requests are blocking in JGroups FC. (No JBC locking issues reported). 2) On perf03, a similar pattern of no "closing" begins at 08:33:35,130. But then you get a few of these: 2008-02-21 08:34:01,393 WARN [org.jgroups.protocols.FC] Received two credit requests from 172.17.65.39:40890 without any intervening messages; sending 1999633 credits Indicates perf02 is not getting FC credits from perf03. Then this: 2008-02-21 08:34:53,627 WARN [org.jgroups.protocols.FD] I was suspected by 172.17.65.39:40890; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK again indicating non-delivery of heartbeat responses to perf02.FD. All 3 live nodes begin at roughly 08:33:30 a pattern of logging EJB request activity but no "closing". Looks like everyone is blocking waiting for FC credits. Any multicasts in the message mix? Only one that comes to mind is data gravitation. But the troublesome logging pattern begins nearly a minute after perf01 is stopped, so why would there still be a lot of data gravitation going on? Another weird thing: when perf01 restarts, its Tomcat cache (not the EJB3 SFSB one under load) has trouble joining the group: 2008-02-21 08:34:41,546 WARN [org.jgroups.protocols.pbcast.GMS] join(172.17.64.39:52927) sent to 172.17.65.39:40883 timed out, retrying 2008-02-21 08:34:48,553 WARN [org.jgroups.protocols.pbcast.GMS] join(172.17.64.39:52927) sent to 172.17.65.39:40883 timed out, retrying 2008-02-21 08:34:55,559 WARN [org.jgroups.protocols.pbcast.GMS] join(172.17.64.39:52927) sent to 172.17.65.39:40883 timed out, retrying Non-responsive node is again perf02, but this is a completely different channel. Just a CPU overload on perf02? Perf02's Tomcat cache does finally issue a view with perf01 in it, but only after logging this: 2008-02-21 08:35:11,784 WARN [org.jgroups.protocols.pbcast.GMS] failed to collect all ACKs (3) for view [172.17.65.39:40883|5] [172.17.65.39:40883, 172.17.66.39:35267, 172.17.67.39:39896, 172.17.64.39:52927] after 5000ms, missing ACKs from [172.17.65.39:40883, 172.17.66.39:35267, 172.17.67.39:39896] (received=[]), local_addr=172.17.65.39:40883 Note it doesn't get an ACK from itself! Eventually, perf03's sfsb cache channel excludes perf02: 2008-02-21 08:35:03,233 INFO [org.jboss.cache.TreeCache] viewAccepted(): [172.17.66.39:35274|5] [172.17.66.39:35274, 172.17.67.39:39903] But perf04 doesn't acknowledge the new view: 2008-02-21 08:35:08,202 WARN [org.jgroups.protocols.pbcast.GMS] failed to collect all ACKs (2) for view [172.17.66.39:35274|5] [172.17.66.39:35274, 172.17.67.39:39903] after 5000ms, missing ACKs from [172.17.67.39:39903] (received=[172.17.66.39:35274]), local_addr=172.17.66.39:35274 No viewAccepted() with the new view ever appears on the perf04 logs. perf02 also doesn't know it's been excluded, continuing to send suspect messages to perf03: 2008-02-21 08:35:11,785 WARN [org.jgroups.protocols.FD] I was suspected by 172.17.65.39:40890; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138599#4138599 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138599

18 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums March 2008