[jboss-user] [Microcontainer] - Re: Injecting a classloader
Hmm, okay, it's starting to make sense. Essentially what I want is the ability for someone to put a jboss-logging.xml in their deployment unit somewhere, and if it contains a certain tag, then all that deployment unit's classloaders and children's classloaders will be registered with a callback that I specify somewhere. It looks like I won't be able to use the simple BeanMetaDataFactory that I was using before to do this though - unless I can use "inject fromContext" somehow? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4247314#4247314 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4247314 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Injecting a classloader
Ah, never mind that question, I see there's a visit() method. Now another question: do nested JARs which are just libraries qualify as deployment units? And, how can I get access to the DeploymentUnit instance from my deployer? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4247048#4247048 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4247048 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Injecting a classloader
Yeah, that should work for the parent. Is there any way to find all the nested deployment units though? I see the *Component(String) methods however there does not seem to be a way to list what the components are. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4247047#4247047 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4247047 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Injecting a classloader
In order to support per-deployment log contexts, I have to introspect the deployment unit which contains the jboss-logging.xml file that is being deployed, in order to inject any and all of the classloaders which correspond to the deployment unit and its children into the log context instance. Where is the classloader information stored in a deployment unit, and is there any way to access it from a BeanMetaDataFactory which is created via SchemaResolverDeployer? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246848#4246848 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246848 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Installing a context leads to resolve of other unrelated
Yeah, I don't buy this "implicit dependencies" business. The beauty of the MC deployer architecture is that when you deploy stuff, you can make dependencies which are implicit (as far as the user sees) translate to explicit dependencies before the container even sees the deployment. As for "depending" on JNDI, I think that should always translate into a real explicit dependency, which is filled by a special bean deployment that represents the JNDI binding. These special deployments can be implicitly created by the EJB and JCA deployers, much like how I bind logging handlers to logger categories. I think that the value of having a highly efficient (and simple) dependency resolution algorithm will far, far outweigh its support for edge cases that can be easily implemented in other ways. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4244482#4244482 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4244482 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: BeanMetaDataFactory and value-factory
Can you believe that I edited that post once as it is? Too much work, too little sleep. For now I'll just instantiate that class *directly*, and when the *BMDB* methods appear, I'll switch to those. Thanks :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242183#4242183 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4242183 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - BeanMetaDataFactory and value-factory
I want to define a property value to use a value-factory programmatically via BeanMetaDataBuilder. I can see that the XML tag for this maps to AbstractValueFactoryMetaData; can I just instantiate this class directory or will the lack of e.g. a KernalControllerContext get me in trouble? Or is there a BMDF method for this that I just didn't see? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242088#4242088 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4242088 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Why is kernel looking for default constructor?
Yeah, it should have been on the user forums. But give the guy a break, we've all been there. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241490#4241490 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241490 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: More trouble in the bean-deployer schema
I added a comment to that issue. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241192#4241192 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241192 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Locating the current DeploymentUnit
OK how about this. What is the mechanism to find the DeploymentUnit that a Class belongs to? Does jboss-cl give us something which does this? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4234507#4234507 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4234507 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Remoting, XNIO and JBoss 5.1.0 GA
Ah, ok, that explains it. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4234497#4234497 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4234497 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Remoting, XNIO and JBoss 5.1.0 GA
Hmmm, interesting. That's substantially different from my experiments. Thanks for the info. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4234485#4234485 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4234485 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Remoting, XNIO and JBoss 5.1.0 GA
Remoting 2.5.1 uses plain sockets. You can remove XNIO from your deploy and deployers folders if you wish; but the beans it defines are all "on-demand" so I wouldn't expect a huge savings in startup time or memory footprint. If you do see a difference of more than a few milliseconds, please let me know. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4234482#4234482 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4234482 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Locating the current DeploymentUnit
One challenge will be if and when one deployment unit calls into another. Maybe a reflection-based stack introspection would be better, but I don't believe there's a portable API to accomplish that. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4234016#4234016 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4234016 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Locating the current DeploymentUnit
Is there, or could we create, a mechanism by which the DeploymentUnit (if any) assocaited with the current executing thread can be located statically? Such a mechanism would possibly use a ThreadLocal which is set before calling any lifecycle or injection methods. Then I can use JBoss Threads to cover the other cases (tasks submitted to Executors). This will be necessary to make per-deployment logging setups work right. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4234008#4234008 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4234008 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Tool for documenting MC beans
"jesper.pedersen" wrote : David, show me the documentation for | | | | | | | and why it would be needed when building a container based on MC. | | Or should I just scan your projects and look for MC beans ? It's not needed when building a container based on MC. This is, in fact, only needed for JBAS 5.1.x because the old log service is still based on mbeans. So my point remains. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230913#4230913 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230913 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Tool for documenting MC beans
"jesper.pedersen" wrote : All I'm asking for here is a tool that can allow a project to document the MC beans they want to expose to other developers - or in case they don't have an up-to-date users guide to the end user. That's the error, right there. There should be zero such beans. There are a few types of usable APIs in an MC environment: publicly documented Java APIs and annotations (which both are documented via Javadoc), and publicly documented XML descriptors (which appear as XSD and their associated docs). Even if a class is designed to be used by a "bean" tag on a strictly internal basis (not that I would condone even that), the Javadoc of that class is sufficient to document it. Adding another layer is purely redundant. And by the way, TLD is a very poor example as the capabilities it provides are designed to document tags, not specific instances of tags. For example, you could have a TLD which describes, say, the "bean" tag, but what good would that do you? There are already documentation annotations on the bean-deployer XSD which do the same thing. This whole notion is basically flawed. Any effort is much better spent creating SchemaResolverDeployers for any services that currently do not have it, rather than shoring up an already less-than-optimal situation. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230910#4230910 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230910 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Tool for documenting MC beans
I think this approach is incorrect. Any jboss-beans.xml files that we include should be considered part of the private implementation of that service. A -beans.xml file is a script (a program) which is tied to implementation details of the service, like class structure, not a configuration file. As such, the appropriate way to document it is with plain XML comments. Any time we are exposing a service configuration to users as XML, we should be using a separate descriptor format which doesn't depend directly on the class structure of the service. This is the only way that we can avoid configuration incompatibility between AS releases. A separate descriptor implies a schema file, which can be annotated with documentation in a way that is supported by most XML authoring tools and IDEs. I recognize that we do currently have a lot of services using jboss-beans.xml as configuration; I think that rather than devoting effort to a documentation system, we ought to be busy creating descriptor formats for these services instead. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230892#4230892 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230892 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: How to prevent MC calling start/stop
There's "ignore-stop" and "ignore-start" tags or something similar - have a look in the MC user guide. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224131#4224131 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224131 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: More trouble in the bean-deployer schema
"alex.loubyan...@jboss.com" wrote : The parsing error seems to be clear enough? There is no bean in the schema type for parameter, hence it can't appear there. My point is, perhaps there should be. I believe that "bean" corresponds to BeanMetaData, which extends ValueMetaData, thus is should be usable anywhere a "value" is usable. "alex.loubyan...@jboss.com" wrote : As to the schema validation errors, the group appears to be not properly redefined. The way it's redefined is supposed to be a restriction, i.e. you should list a subset of the elements/groups of the group you are redefining. | If you want extension, you should reference the group you are redefining in the new group and add the elements you want. | Looking at the schemas, the groups are identical in both schemas (with bean element commented out, btw). So, you can just remove the group as a child of redefine. Hm. Maybe I'll have a look at that when I get time... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223327#4223327 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223327 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - More trouble in the bean-deployer schema
The following construct doesn't validate, even though it's allowed by the bean
deployer (which fortunately doesn't validate, but that's another thread):
|...
|
|
| ...
|
|
|...
|
The error is something like this (formatted for readability):
| Error:Error:line (15)cvc-complex-type.2.4.a: Invalid content was found
starting with element 'bean'.
| One of
| '{"urn:jboss:bean-deployer:2.0":value,
|"urn:jboss:bean-deployer:2.0":inject,
|"urn:jboss:bean-deployer:2.0":value-factory,
|"urn:jboss:bean-deployer:2.0":collection,
|"urn:jboss:bean-deployer:2.0":list,
|"urn:jboss:bean-deployer:2.0":set,
|"urn:jboss:bean-deployer:2.0":array,
|"urn:jboss:bean-deployer:2.0":map,
|"urn:jboss:bean-deployer:2.0":null,
|"urn:jboss:bean-deployer:2.0":this,
|WC[##other:"urn:jboss:bean-deployer:2.0"],
|"urn:jboss:bean-deployer:2.0":annotation}'
| is expected.
|
The xsd for bean-deployer is a bit too crazy for me to parse mentally, so I
don't know what the problem is.
Also, the following validation errors have been popping up lately:
|
/home/david/src/java/microcontainer/trunk/kernel/src/main/resources/schema/bean-deployer_2_0.xsd
| Error:Error:line (139)rcase-RecurseLax.2: There is not a complete
functional mapping between the particles.
| Error:Error:line (139)src-redefine.6.2.2: Group 'valueGroup' does not
properly restrict the group it redefines; constraint violated:
'rcase-RecurseLax.2'.
|
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223150#4223150
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223150
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Getting the MC to find a schema (xsd) file
Where can I put my .xsd file so that my SchemaResolverDeployer uses it for validation? If I put it in META-INF, will JBossXB (or something else) find and register it? Can't find anything that explains this. Thanks. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222783#4222783 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222783 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Socket invocator and long transactions
Though this isn't set in stone just yet, I'd like to have a better integration between transaction managers/resources and Remoting. Getting transaction timeouts to sync up is definitely part of this. But another key point with Remoting 3 is that the client-connection relationship is changed as well; you generally won't have a timeout associated with a connection anymore. The responsibility to time out a single request will be with the user code. See these methods for more info on that: http://docs.jboss.org/remoting/3.0.0.GA/api/org/jboss/remoting/Client.html#send(I) whose return value has this method: http://docs.jboss.org/xnio/1.2.0.GA/api/org/jboss/xnio/IoFuture.html#await(long,%20java.util.concurrent.TimeUnit) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4216405#4216405 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4216405 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Remoting 3 with Jboss AS 5
Not yet. I am as we speak working on developing a proper integration with JBossAS, but I strongly suspect that the earliest version of AS that will work with it will be 5.1.0 unless you want to do some serious JAR surgery. :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4212337#4212337 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4212337 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Possible bug in jboss-cl dep resolution
I'm deploying a couple of JARs in the "all" profile of a jbossas built from the
5.1 branch and getting a weird problem. I was originally getting that NPE bug,
so I updated jboss-cl to a 2.0.3-SNAPSHOT I built from svn and installed
locally. Having done so, my deployment now generates a very large number of:
18:48:26,025 WARN [RequirementDependencyItem]
VFSDeploymentClassLoaderPolicyModule :1.0.0.CR1 resolved
PackageRequirement{org.jboss.deployers.vfs.spi.deployer [0.0.0,?)} to
VFSClassLoaderPolicyModule deployers-classloader:0.0.0 which has
import-all=true. Cannot check its consistency.
| 18:48:26,068 WARN [RequirementDependencyItem]
VFSDeploymentClassLoaderPolicyModule :1.0.0.CR1 resolved
PackageRequirement{org.jboss.deployers.vfs.deployer.kernel [0.0.0,?)} to
VFSClassLoaderPolicyModule deployers-classloader:0.0.0 which has
import-all=true. Cannot check its consistency.
| 18:48:26,068 WARN [RequirementDependencyItem]
VFSDeploymentClassLoaderPolicyModule :1.0.0.CR1 resolved
PackageRequirement{org.jboss.deployers.vfs.spi.deployer [0.0.0,?)} to
VFSClassLoaderPolicyModule deployers-classloader:0.0.0 which has
import-all=true. Cannot check its consistency.
| 18:48:26,073 WARN [RequirementDependencyItem]
VFSDeploymentClassLoaderPolicyModule :1.0.0.CR1 resolved
PackageRequirement{org.jboss.deployers.vfs.deployer.kernel [0.0.0,?)} to
VFSClassLoaderPolicyModule deployers-classloader:0.0.0 which has
import-all=true. Cannot check its consistency.
| 18:48:26,073 WARN [RequirementDependencyItem]
VFSDeploymentClassLoaderPolicyModule :1.0.0.CR1 resolved
PackageRequirement{org.jboss.deployers.vfs.spi.deployer [0.0.0,?)} to
VFSClassLoaderPolicyModule deployers-classloader:0.0.0 which has
import-all=true. Cannot check its consistency.
| 18:48:26,078 WARN [RequirementDependencyItem]
VFSDeploymentClassLoaderPolicyModule :1.0.0.CR1 resolved
PackageRequirement{org.jboss.deployers.vfs.deployer.kernel [0.0.0,?)} to
VFSClassLoaderPolicyModule deployers-classloader:0.0.0 which has
import-all=true. Cannot check its consistency.
| 18:48:26,078 WARN [RequirementDependencyItem]
VFSDeploymentClassLoaderPolicyModule :1.0.0.CR1 resolved
PackageRequirement{org.jboss.deployers.vfs.spi.deployer [0.0.0,?)} to
VFSClassLoaderPolicyModule deployers-classloader:0.0.0 which has
import-all=true. Cannot check its consistency.
| 18:48:26,080 WARN [RequirementDependencyItem]
VFSDeploymentClassLoaderPolicyModule :1.0.0.CR1 resolved
PackageRequirement{org.jboss.deployers.vfs.deployer.kernel [0.0.0,?)} to
VFSClassLoaderPolicyModule deployers-classloader:0.0.0 which has
import-all=true. Cannot check its consistency.
| 18:48:26,080 WARN [RequirementDependencyItem]
VFSDeploymentClassLoaderPolicyModule :1.0.0.CR1 resolved
PackageRequirement{org.jboss.deployers.vfs.spi.deployer [0.0.0,?)} to
VFSClassLoaderPolicyModule deployers-classloader:0.0.0 which has
import-all=true. Cannot check its consistency.
| 18:48:26,080 WARN [RequirementDependencyItem]
VFSDeploymentClassLoaderPolicyModule :1.0.0.CR1 resolved
PackageRequirement{org.jboss.deployers.vfs.deployer.kernel [0.0.0,?)} to
VFSClassLoaderPolicyModule deployers-classloader:0.0.0 which has
import-all=true. Cannot check its consistency.
| 18:48:26,080 WARN [RequirementDependencyItem]
VFSDeploymentClassLoaderPolicyModule :1.0.0.CR1 resolved
PackageRequirement{org.jboss.deployers.vfs.spi.deployer [0.0.0,?)} to
VFSClassLoaderPolicyModule deployers-classloader:0.0.0 which has
import-all=true. Cannot check its consistency.
| 18:48:26,080 WARN [RequirementDependencyItem]
VFSDeploymentClassLoaderPolicyModule :1.0.0.CR1 resolved
PackageRequirement{org.jboss.deployers.vfs.deployer.kernel [0.0.0,?)} to
VFSClassLoaderPolicyModule deployers-classloader:0.0.0 which has
import-all=true. Cannot check its consistency.
| 18:48:26,081 WARN [RequirementDependencyItem]
VFSDeploymentClassLoaderPolicyModule :1.0.0.CR1 resolved
PackageRequirement{org.jboss.deployers.vfs.spi.deployer [0.0.0,?)} to
VFSClassLoaderPolicyModule deployers-classloader:0.0.0 which has
import-all=true. Cannot check its consistency.
| 18:48:26,081 WARN [RequirementDependencyItem]
VFSDeploymentClassLoaderPolicyModule :1.0.0.CR1 resolved
PackageRequirement{org.jboss.deployers.vfs.deployer.kernel [0.0.0,?)} to
VFSClassLoaderPolicyModule deployers-classloader:0.0.0 which has
import-all=true. Cannot check its consistency.
| 18:48:26,081 WARN [RequirementDependencyItem]
VFSDeploymentClassLoaderPolicyModule :1.0.0.CR1 resolved
PackageRequirement{org.jboss.deployers.vfs.spi.deployer [0.0.0,?)} to
VFSClassLoaderPolicyModule deployers-classloader:0.0.0 which has
import-all=true. Cannot check its consistency.
| 18:48:26,124 WARN [RequirementDependencyItem]
VFSDeploymentClassLoaderPolicyModule :1.0.0.CR1 resolved
PackageRequirement{org.jboss.deployers.vfs.deployer.kernel [0.0.0,?)} to
VFSClassLoaderPolicyModule deployers-classloader:0.0.0 which has
import-
[jboss-user] [Microcontainer] - Re: Deployment contextual information
We don't do it yet. I'm supposed to be working on it. :-) My thought was to keep it in a ThreadLocal and swap it in whenever a task is run on behalf of a deployment unit. Which is easy to say... Alternatively if there was already a way, from any given thread, to discover what DeploymentUnit is being executed, that could work too (the logging context could be stashed on the DeploymentUnit instance). Does the ControllerContext maintain this information? That would actually be generally cool, if so... the Threads module could hook into that to make sure that that information carries over into executed tasks. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209706#4209706 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209706 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Deployment contextual information
One of the requirements for the logging pojo service is to allow for separate handling for stdout/stderr (and by extension, other logging categories as well) on a per-deployment basis. Log4j and Logback, the two dominant non-JDK logging frameworks, do this with the notion of a "logging context" which allows the user to swap logging configuration at runtime. To support this, the proper logging context has to be selected whenever a deployment's classes are initialized or any code from a deployment is executed. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209701#4209701 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209701 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Deployment contextual information
I guess, on further thought, the only sensible policy would be to replicate the context of the caller, so that executor tasks uses the same context classloader, access control context, logging context etc. of the calling thread. That solves executors anyway. Next I just need to figure out how to make sure that bean methods are also called with the proper context (classloader stuff is probably already figured out, but what about logging and access control context, or future stuff we may think up? is there some AOP magic that does this already? etc)... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209678#4209678 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209678 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Deployment contextual information
Scratch the "implements MetaData" part. I didn't read what I thought I read :) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209267#4209267 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209267 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Deployment contextual information
I see - so I can attach any kind of MetaData, so long as it implements MetaData? Does the MDR (or any other project) define a convention for this? What is the lifespan of something I put in there? Can I cause leaks by attaching stuff? Is it removed on undeploy somehow? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209265#4209265 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209265 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Deployment contextual information
Do deployments have a notion of contextual information? Like, deployment X is associated with context classloader Y or security context Z? I'm struggling with this idea in the Threads module. The case I'm thinking of is that say you have two deployments, X and Y. They both use the same thread pool. But they need to have different contextual information - context classloader is just one example; logging context might be another, or security context or even something trivial like a temporary name attached to the thread name or something like that. When each deployment runs a task, that task should be run with the proper contextual information set. Is there any provision for accessing deployment contextual information at a MC level? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209230#4209230 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209230 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: How to hide a bean from other deployments?
I don't see any way to create a search injection with the BMDB API at all (it doesn't seem like an annotation can be used here; please correct me if I'm wrong). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206285#4206285 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206285 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Remoting 3.0.0 GA available?
As soon as I can. When I do release the protocol JAR(s), it will be a separate download from Remoting proper, so the bundle that is up there will still be valid (and necessary). Hopefully within a week? We'll see how much I can get done. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203770#4203770 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4203770 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Remoting 3.0.0 GA available?
Yes, it's the official release, minus the protocol implementations. I want to get the final version of the protocol implementations out there before I do an official announcement for it (because Remoting without a protocol is basically local-only... not very Remote :)), and hopefully get a good start on the user guide as well. However, if you wish to download it and mess with it, go ahead. The Javadoc is online as well at http://docs.jboss.org/remoting/3.0.0.GA/api/. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203767#4203767 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4203767 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JCA/JBoss] - Question about inflow and container managed transactions
The JCA spec covers importing a transaction (via inflow), and it also covers allowing the container to manage and control the transaction. But I'm having a hard time finding anything in the spec that covers letting the container manage a transaction, but allowing the EIS to *control* it (e.g. start it, perform some work inside the txn, and then commit the txn). Is this missing from the spec, or am I just blind? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4202239#4202239 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4202239 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Classloading question
I see. One more dumb question whose answer I can't ascertain from the code: If I specify a version on the "classloading" element, is that version number inherited by default to all the nested capabilities (package and module)? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201923#4201923 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201923 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Classloading question
This is probably a dumb question. In a jboss-classloading.xml file, the root "classloading" element has a name and version attribute. Is doing this: the same as doing this: | | | | ?? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201473#4201473 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201473 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: How to hide a bean from other deployments?
Is there any way to add scoping attributes to a bean using the BeanMetaDataBuilder API? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201132#4201132 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201132 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Compression marshalling
Suggestion for community members with free time on their hands - come up with a version of the compression marshaller that uses JZlib (http://www.jcraft.com/jzlib/). :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4198771#4198771 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4198771 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Re: Limit number of simultaneous executing calls.
What policy would you impose when there are too many concurrent requests? Block/enqueue the request? Reject it outright? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194072#4194072 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194072 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: How to auto-wire using BeanMetaDataBuilder?
Found it - BeanMetaDataBuilder.setAutowire*(). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193625#4193625 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193625 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Configuration deployments
How can I make the MC support configuration file deployments? A configuration file deployment would differ from a bean deployment in a couple ways. First, there is no undeploy - a configuration is read upon deployment, and that's the end of it. Either the configuration is accepted and applied, or rejected and ignored. Second, a configuration deployer would not yield BeanMetaData; rather the custom MetaData type would be installed directly into the application where it could be accepted or rejected. Is this possible to do? Maybe even using SchemaResolverDeployer to produce the custom metadata type, which is then handed to the program (perhaps with an install callback)? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191780#4191780 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191780 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
