September 2008 - jboss-dev-forums

[Design of POJO Server] - Re: JBAS-5895; Processing too many classes

by alesj

"scott.stark(a)jboss.org" wrote : The only child location we can exclude when an empty library-directory is specific is "lib". | Makes sense. But, like I said, we have parts of info in different places, empty-dir lib in EarStructure and Module filter in some real deployer. The only thing that I can think of, that binds them, is my hack. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176304#4176304 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176304

17 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: PackageInformation retrieved from wrong jar

by scott.stark＠jboss.org

Let me look into why we are returning org.jboss.seam package info from the jboss-seam-booking.jar first then. Is this the same jboss-seam-booking.ear we are pulling into the jbossas testsuite? | [525][valkyrie: testsuite]$ jar -tf output/lib/seam/jboss-seam-booking.ear | META-INF/ | META-INF/MANIFEST.MF | lib/ | META-INF/application.xml | META-INF/jboss-app.xml | jboss-seam.jar | lib/commons-beanutils.jar | lib/commons-digester.jar | lib/jboss-el.jar | lib/richfaces-api.jar | jboss-seam-booking.jar | jboss-seam-booking.war | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176287#4176287 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176287

17 years, 6 months

1
0
0 / 0

[Design of Clustering on JBoss] - Re: Removing SFSB in HttpSessionListener

by bstansberry＠jboss.com

Breaking the problem down, we have 3 different types of notifications emitted to servlet spec listeners as part of expiring a session: 1) HttpSessionListener.sessionDestroyed() 2) HttpSessionAttributeListener.attributeRemoved() 3) HttpSessionBindingListener.valueUnbound() The expiration-related notifications can be sent out for 3 reasons: 1) Application call to session.invalidate(). 2) Session expired by container background thread due to inactivity. 3) Session expired by deployer thread as part of undeploy. There are also 5 possible places on the cluster where the above can occur: 1) Node where the session is currently active (i.e. node that last handled a request for the session.) This node "owns" the session. 2) Node where the session has been active, but the client for whatever reason has failed over to a different, still running, node. 3) Node where data about the session is stored in the distributed cache (JBoss Cache) but where the session has never been instantiated locally. 4) Node where the session is no longer currently active, but where it at one time was, AND the node is now the "owner" of the session because the node where the session was last active is no longer alive. This is a special case of #2. 5) Node where data about the session is stored in the distributed cache but where the session has never been instantiated locally AND the node is now the "owner" of the session because the node where the session was last active is no longer alive. This is a special case of #3. In the above I introduce the concept of "ownership" wherein a node that "owns" a session *might* have special responsibilities with respect to invoking listener methods. Note that the servlet spec (SRV.10.7) states that "Distributed containers are not required to propagate either servlet context events or HttpSession events to other JVMs", so in all cases above I am totally about notifications arising due to local activity on a node, not due to remote activity. I am going to draw up a matrix of the above combinations, with alternatives for each slot, and see if from this a rational set of policies can be derived. Note that for any 4.x fix, the policies and related configuration will be very primitive (probably a couple simple boolean system properties). This matrix will be more to drive thinking about 5.x solutions, plus to surface any gotchas that might influence the more simple 4.x fix. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176265#4176265 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176265

17 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: PackageInformation retrieved from wrong jar

by stan.silvert＠jboss.com

"scott.stark(a)jboss.org" wrote : | For the two jars jboss-seam.jar, jboss-seam-booking.jar, they both have an org.jboss.seam package? | | No. They don't both have it. If they did then there would be no way to know which manifest to use. But in this case, jboss-seam.jar has all the org.jboss.seam.MyClass.class files and jboss-seam-booking.jar has all the org.jboss.seam.booking.MyClass.class files. Stan View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176264#4176264 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176264

17 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: PackageInformation retrieved from wrong jar

by scott.stark＠jboss.org

This is getting into the issue we are discussing here: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176244#4176244 where we are scanning too many files for classes, and picking up locations that should not be on the classpath. There is a standard lib location for libraries added to ears where these should be placed so that we are not recursively scanning too many locations. For the two jars jboss-seam.jar, jboss-seam-booking.jar, they both have an org.jboss.seam package? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176261#4176261 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176261

17 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-5895; Processing too many classes

by scott.stark＠jboss.org

"alesj" wrote : "scott.stark(a)jboss.org" wrote : If someone has a custom ear libx child, but excludes the directory via metadata, then would also have to disable the include root option as well. | | | Why? | Or why is this different from if (s)he has plain lib child? | Because there is no basis to identify libx as a lib directory that was excluded. In the metadata you either specify the lib directory or an empty name to indicate there is no lib directory. If there is no directory name, its assumed to be "lib". There is no way to say exclude libx as a lib directory other than reverting to jboss structure metadata. "alesj" wrote : | The problem I see for me is that in the deployers that are Module aware | don't know if underlying deployment unit is top ear deployment unit, | since it's only structure deployers that understand ear (war, jar, ...), | but they don't have a clue about Module. | | What about if I add a predetermined attachment to ear's top | deployment context and then grab it out in one of the deployers | that's just in between from Module-creating-deployer and AnnotationScanningDeployer? | e.g. if the attachment is there, then it means this deployment unit | is ear top deployment unit, hence apply root Module filter | Or too much of a hack? :-) | This is too much of a hack, and what I'm saying is that if someone wants an ear to include the root, but exclude non-standard lib directory, they has to use jboss specific metadata to do so. The only child location we can exclude when an empty library-directory is specific is "lib". View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176258#4176258 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176258

17 years, 6 months

1
0
0 / 0

[Design of Clustering on JBoss] - Re: Removing SFSB in HttpSessionListener

by bstansberry＠jboss.com

Note the above listener would handle session.invalidate() calls, which occur on a Tomcat connector thread, but not session invalidation due to timeout, which are on a tomcat background thread. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176254#4176254 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176254

17 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - PackageInformation retrieved from wrong jar

by stan.silvert＠jboss.com

Perhaps we should discuss this here instead of in the jira? https://jira.jboss.org/jira/browse/JBCL-43 Stan View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176246#4176246 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176246

17 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-5895; Processing too many classes

by alesj

"alesj" wrote : | The problem I see for me is that in the deployers that are Module aware | don't know if underlying deployment unit is top ear deployment unit, | since it's only structure deployers that understand ear (war, jar, ...), | but they don't have a clue about Module. | What about if I add a predetermined attachment to ear's top deployment context and then grab it out in one of the deployers that's just in between from Module-creating-deployer and AnnotationScanningDeployer? e.g. if the attachment is there, then it means this deployment unit is ear top deployment unit, hence apply root filter Or too much of a hack? :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176245#4176245 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176245

17 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-5895; Processing too many classes

by alesj

"scott.stark(a)jboss.org" wrote : If someone has a custom ear libx child, but excludes the directory via metadata, then would also have to disable the include root option as well. | Why? Or why is this different from if (s)he has plain lib child? e.g. you don't want lib to be part of classpath, but you still want to find xyz.properties file in ear's root as part of classpath The problem I see for me is that in the deployers that are Module aware don't know if underlying deployment unit is top ear deployment unit, since it's only structure deployers that understand ear (war, jar, ...), but they don't have a clue about Module. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176244#4176244 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176244

17 years, 6 months

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 September 2008