[Design the new POJO MicroContainer] - Re: ClassLoader injection Scope issue
by alesj
"alesj" wrote :
| "adrian(a)jboss.org" wrote :
| | I quote "circular dependency" because it is not really a circular dependency,
| | what actually happens is that the classloader (which automatically has classloader=null)
| | gets re-ordered to be before the ClassLoading being deployed and so it won't get
| | registered using the incallback before you want to want to do
| | "ClassLoading".getClassLoader().
| |
| | Or more schematically:
| | 1) deploy ClassLoading
| | 2) deploy ClassLoader
| | 3) ClassLoading depends on ClassLoader (because classloader != null)
| | 4) ClassLoading Module for ClassLoader is created but not registered with
| | ClassLoading (no incallback yet)
| | 5) Try Configurator.getBeanMetaData("ClassLoading") // ERROR it didn't go through the ClassLoading!
| | 6) If (5) worked then it would register the incallback for "ClassLoading"
| | and the ClassLoader would properly be constructed.
| |
| | NOTE (5) could also be any request to get the classloader if its ClassLoadingModule
| | hasn't been registered with ClassLoading to resolve and create the classloader.
| Is this all about how classloader.xml is eventually deployed/installed?
| Since I don't see how it's related to my problem.
My problem of not getting this is mostly related to names. :-)
As I don't follow what exactly is classloader/ClassLoader.
e.g. when do you refer to classloader schema element, when to element, real/bean's cl, ... :-)
JBossAS's classloader.xml
| <deployment xmlns="urn:jboss:bean-deployer:2.0">
|
| <classloader><inject bean="bootstrap-classloader:0.0.0"/></classloader>
|
| <!--
| The classloader implementation
| -->
| <bean name="ClassLoaderSystem" class="org.jboss.classloader.spi.ClassLoaderSystem">
| <classloader><null/></classloader>
| <constructor factoryClass="org.jboss.classloader.spi.ClassLoaderSystem" factoryMethod="getInstance"/>
| </bean>
|
| <!--
| ClassLoader management and resolution
| -->
| <bean name="ClassLoading" class="org.jboss.classloading.spi.dependency.ClassLoading">
| <classloader><null/></classloader>
| <incallback method="addModule" state="Configured"/>
| <uncallback method="removeModule" state="Configured"/>
| </bean>
|
| <classloader name="bootstrap-classloader" xmlns="urn:jboss:classloader:1.0" export-all="NON_EMPTY" import-all="true">
| <!-- FIXME Move to Deployers -->
| <root>${jboss.lib.url}/jboss-deployers-core-spi.jar</root>
| <root>${jboss.lib.url}/jboss-deployers-core.jar</root>
| <root>${jboss.lib.url}/jboss-deployers-client-spi.jar</root>
| <root>${jboss.lib.url}/jboss-deployers-client.jar</root>
| <root>${jboss.lib.url}/jboss-deployers-structure-spi.jar</root>
| <root>${jboss.lib.url}/jboss-deployers-spi.jar</root>
| <root>${jboss.lib.url}/jboss-deployers-impl.jar</root>
| <root>${jboss.lib.url}/jboss-deployers-vfs-spi.jar</root>
| <root>${jboss.lib.url}/jboss-deployers-vfs.jar</root>
| <!-- System -->
| <root>${jboss.lib.url}/jboss-system.jar</root>
| <!-- FIXME Move to JMX -->
| <root>${jboss.lib.url}/jboss-j2se.jar</root>
| <root>${jboss.lib.url}/jboss-mbeans.jar</root>
| <root>${jboss.lib.url}/jboss-jmx.jar</root>
| <root>${jboss.lib.url}/jboss-system-jmx.jar</root>
| <root>${jboss.lib.url}/dom4j.jar</root>
| <!-- JAXB impl here, api is in endorsed -->
| <root>${jboss.lib.url}/jaxb-impl.jar</root>
| <!-- STAX2 impl here, api is in endorsed -->
| <root>${jboss.lib.url}/wstx.jar</root>
| </classloader>
|
| </deployment>
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185118#4185118
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185118
16 years, 2 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Status of LargeMessages work
by clebert.suconic@jboss.com
"timfox" wrote : "clebert.suconic(a)jboss.com" wrote : VIII - When sending very large messages, I need to make sure the server will not overuse the remoting connection running out of memory, so I've changed the ServerSide flow control to use a Semaphore instead of a AtomicInt.
| |
| | As the messages are chunked, I acquire the packetSize (or chunkSize) from availableCredits. When running out of credit ServerConsumerImpl will just wait until more credits are returned from the client.
| |
|
| Isn't that how it already works? I don't understand why you need to change this.
|
The current implementation is not using Semaphores, it is using just an AtomicInteger, and there are only two states on the Consumer... sending or not sending, as there is not need to wait during the sending of a message.
With the message chunk, we need to wait for credits during the chunk-sending. Say... if I'm sending a 1G file to the client, I need to wait for credits as the client is being able to receive bytes from the server.
Another point regarding flow control is, I'm aways sending BigMessages in a blocked way until we can have FlowControl re-enabled.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185115#4185115
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185115
16 years, 2 months
[Design of the JBoss EJB Container] - Re: NPE in JDBCStoreManager
by alex.loubyansky@jboss.com
"scott.stark(a)jboss.org" wrote : It looks like the EjbModule is starting the pm before the entity container has been started. Why don't we start the pm from the EntityContainer.startService?
It's dictated by the current logic behind the (CMP) persistence manager start:
- first every persistence manager in the EJB module performs its initStoreManager();
- then after all of them initialized, they can be started which includes resolution of CMR and foreign keys (which is the reason why they are started in this way).
So, calling start on one of the PMs won't actually start the PM. Only when the last PM in the EJB module receives the start call they get started.
So, if the PM.start() were in EntityContainer.startService() then after return from EntityContainer.startService(), the container's PM might not had been started and the container would not be usable.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185111#4185111
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185111
16 years, 2 months