Cool. I actually messed with this a bit before with the vague intention of
having the newer deployers I was writing be pre-fitted with
jboss-classloading.xml, so as to be "ready" for the new paradigm, but was
confounded by the inability to figure out how to assign classloading
information to JARs that were part of the boot classpath before the server
had booted (such as the MC JARs themselves). That's the point when I gave
up - we'd need a way to "pre-prime" the container with classloading
deployments.
- DML
On 06/03/2009 06:08 PM, Scott Stark wrote:
Adding jboss-classloading.xml and generating bundle manifest headers
is
something I'll start looking at as soon as the current management tools
push for the EAP 5 freeze is complete.
David M. Lloyd wrote:
> Theoretically, it would be completely transparent for regular
> JavaEE-style deployment types at least. For plain JAR deployments I
> guess it would depend on how we decide to implement it - would
> dependencies be explicitly listed? Would we have a base classpath
> that is supplemented by user-specified dependencies? Etc.
>
> Right now it appears that nobody is pursuing modularization.
> Hopefully we can find a way to get this prioritized.
>
> - DML
>
> On 06/03/2009 05:28 PM, Emmanuel Bernard wrote:
>> Naive question, wouldn't it be impractical/annoying to enforce that?
>>
>> On Jun 3, 2009, at 08:43, David M. Lloyd wrote:
>>
>>> But of course in AS 6, private APIs won't be accessible to customer
>>> deployments anyway, since we'll have nice API/impl separation and
>>> we'll be fully modularized.
>>>
>>> Right guys?
>>>
>>> RIGHT?!?
>>>
>>> - DML
>>>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development