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

[Design of POJO Server] - Re: Exploded WAR archive with no web.xml is no longer suppor

by alesj

"adrian(a)jboss.org" wrote : "alesj" wrote : "adrian(a)jboss.org" wrote : | | | wouldn't have the correct classpath, etc. | | | | | Why wouldn't it have correct classpath? | | | | Because it the war has no WEB-INF/web.xml it is currently treated as a jar. | i.e. the root for the war will be the classpath which is clearly wrong. Hmmm ... WarStructure.relativeOrder == 1k JarStructure.relativeOrder == 10k Doesn't that mean .war file would be first recognized by WarS and not JarS? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181553#4181553 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181553

16 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: Exploded WAR archive with no web.xml is no longer suppor

by adrian＠jboss.org

"alesj" wrote : "adrian(a)jboss.org" wrote : | | wouldn't have the correct classpath, etc. | | | Why wouldn't it have correct classpath? | Because it the war has no WEB-INF/web.xml it is currently treated as a jar. i.e. the root for the war will be the classpath which is clearly wrong. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181549#4181549 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181549

16 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: Masking passwords in logs

by adrian＠jboss.org

Why doesn't this solve the problem? http://www.jboss.org/community/docs/DOC-9350 http://www.jboss.org/community/docs/DOC-9703 Even if you mask the password in the log, if it is an MBean attribute, it will be visible via JMX (and the user has access). Additionally since we recommend changing the log level to INFO for production anyway, none of this will appear in the log. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181548#4181548 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181548

16 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: Depends on @JMX mbean name

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | This really falls under the "missing deployer" category. | But I think this is broken We definitely need a test for this behaviour in the testsuite. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181547#4181547 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181547

16 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: Depends on @JMX mbean name

by adrian＠jboss.org

"anil.saldhana(a)jboss.com" wrote : | I spent 30 mins of my time yesterday in tracing the log wondering why my xxx-beans.xml was not getting processed. How can we help users with this? Maybe some warning message hinting at xxx-jboss-beans.xml? | This really falls under the "missing deployer" category. But I think this is broken because we are generating some default metadata regardless of whether other deployers actually process the deployment. AbstractDeployment has | public Object addAttachment(String name, Object attachment) | { | DeploymentContext deploymentContext = getDeploymentContext(); | deploymentContext.deployed(); | return deploymentContext.getTransientAttachments().addAttachment(name, attachment); | } | So when the classloader deployers adds attachments, e.g. create a default ClassLoadingMetaData for this top level deployment, it is treated as deployed. The same goes for the classpath deployer. I think to fix this, we need a new method that says the attachment we are adding should not be considered as flagging the deployment as really processed/deployed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181546#4181546 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181546

16 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: Dropping http-invoker.sar?

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : The http invoker service depends on the legacy jmx invoker approach as welling as naming service details that are not going to remain the same. I think we should drop this and just have a remoting via http configuration documented/tested in its place. | Like I said before, we should move all the old invoker configurations to docs/examples/legacy-remoting They're still required for 4.x <-> 5.x where 4.x doesn't have jboss-remoting or the unified invoker. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181542#4181542 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181542

16 years, 3 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Reimplementing ClassPools for AS

by adrian＠jboss.org

By the way, you should consider what will make things easier for you as changes to the classloader api. Although as you know I don't agree with using the classloader to determine what aspects apply, when I looked at it before, the basic information you are trying to work out is: "from this classloader where does it load this other class?" Then from that found class you go class -> classloader -> application/sub-deployment -> aspect config The basics of this query already exists at the jmx level, look at the jboss.classloader on the jmx console or BaseClassLoaderMBean | /** | * Find the classloader for a class | * | * @param name the class name | * @return the classloader or null if it is not loaded by a managed classloader | * @throws ClassNotFoundException when the class is not found | */ | ObjectName findClassLoaderForClass(String name) throws ClassNotFoundException; | I wouldn't have a problem with adding something like the following to the Module ClassLoader findClassLoaderForClass(String name) throws ClassNotFoundException; or Module findModuleForClass(String name) throws ClassNotFoundException; or other things that might be useful. Once you have the classloader/module you can work out the (sub-)deployment/aspect domain. Or equally if that is not useful to you, we can discuss other helpers that are. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181540#4181540 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181540

16 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: Exploded WAR archive with no web.xml is no longer suppor

by alesj

"adrian(a)jboss.org" wrote : | wouldn't have the correct classpath, etc. | Why wouldn't it have correct classpath? As you said, every .war file is recognized as a war, hence getting war-kind of classpath. This does the trick for me | public void deploy(DeploymentUnit unit) throws DeploymentException | { | if (unit.isAttachmentPresent(JBossWebMetaData.class)) | return; | | // only care about true deployments | if (unit instanceof VFSDeploymentUnit == false) | return; | | if (unit.getSimpleName().endsWith(".war")) | { | log.debug("Web archive doesn't contain web.xml: " + unit.getName()); | unit.getTransientManagedObjects().addAttachment(JBossWebMetaData.class, new JBossWebMetaData()); | } | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181539#4181539 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181539

16 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: new QueueBrowser implementation

by timfox

"ataylor" wrote : | If you remove a message from the head then next time you call next() on the iterator it will fail. you would then need to recreate the iterator and traverse back to the correct point. | | With the current iterator, yes. But no said you couldn't change the iterator implementation. In fact, you'll almost certainly have to do that. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181538#4181538 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181538

16 years, 3 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Reimplementing ClassPools for AS

by adrian＠jboss.org

"kabir.khan(a)jboss.com" wrote : "adrian(a)jboss.org" wrote : | | The requested rules are on the Module, e.g. importAll, exportAll and requirements/capabilities | | | So to get this straight I can get the exported packages from the ExportedPackages(PackageCapability) of the Modules's capabilites and the imported packages from the OptionalPackages(PackageRequirement/UsesPackageRequirement)? | Will these only be set if importAll and exportAll are false? | The exported packages have nothing to do with importAll. exportAll is just a convenience mechanism where you don't have to explicitly list all package capabilities. anonymous wrote : | What is the difference between PackageRequirement and UsesPackageRequirement? The method name is getOptionalPackageNames(). What does that mean? I also see that AbstractRequirement has an optional flag. If false, does that mean it is required? If that is the case, I don't really get what an optional import means. | Uses = Package + optional, see discussions in the MC forum for more details some of it is explained in the xsd. "adrian(a)jboss.org" wrote : | or by looking at the actual ClassLoaderPolicy used to create the classloader, | e.g getPackageNames() and getDelegates(). Are you saying I should really be using this instead of Module? How do I obtain this from a deployer? What about version ranges? How are they represented? In the requirement. anonymous wrote : | What I am doing is implementing one DelegatingClassPool per classloader, and having that backed by a ClassPoolDomain which corresponds to a classloading domain. If a CtClass cannot be found in a DelegatingClassPool it will delegate to the domain which will then look in the registered pools. | | Should things like parentFirst be handled on pool or domain level? I originally had that on the domain, but from what I gather the other settings importAll/exportAll/imports/exports should be handled on the pool level. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181537#4181537 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181537

16 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2008