[EMAIL PROTECTED] wrote : I am unsure why resources at the root of the ear
are still working.
It's due to this flag we added, specially for you. ;-)
- EarStructure::includeEarRootInClasspath
-
http://anonsvn.jboss.org/repos/jbossas/trunk/server/src/main/org/jboss/deployment/EARStructure.java
[EMAIL PROTECTED] wrote : The resources need to go inside a jar under the
EAR/lib directory.
Anil,
So does this mean that the dynamic login config xml file can no longer be
packaged individually? It always has to be part of a jar file(inside the
EAR/lib)?
In general, assuming that in
[EMAIL PROTECTED] wrote : Do you know we scan there (I mean the ear
classpath) for the beans?
No, we only scan true deployments for metadata resources.
Ear classpath != true deployment.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4183491#4183491
Reply to
So, if an user wants to bundle beans inside EARs, where does he need to put? I
personally deploy beans outside of the EARs (as a separate deployment).
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4183492#4183492
Reply to the post :
Ales, if I put beans inside xxx-jboss-beans.xml and place it inside a jar
in the EAR/lib, I saw that it was not getting deployed. Do you know we scan
there (I mean the ear classpath) for the beans?
View the original post :
[EMAIL PROTECTED] wrote : So, if an user wants to bundle beans inside EARs,
where does he need to put?
Plain jar inside ear?
e.g. someapp.ear/my-beans.jar
- META-INF/mybeans-jboss-beans.xml
- com|org|net|si| ...
View the original post :
The resources need to go inside a jar under the EAR/lib directory. I am
unsure why resources at the root of the ear are still working. I need to ping
Adrian on this one.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4183320#4183320
Reply to the post :
I tried this on JBoss-5 CR1 and even JBoss-5 Beta4. Looks like something
changed between Beta 4 and CR1. The application that works on Beta 4, does not
work on CR1. However, i could get the application to work on CR1 too by placing
the xml at a different location.
Here are the details. I have
I think that this behavior reflects the closing of a hole in the classloading
architecture. Essentially, classes within a war should be isolated and not
accessible from outside the war. This includes resources. Therefore, the
behavior for beta4 was incorrect, while the behavior for CR1 is
So is this a bug in CR1? Has anybody been able to get dynamic login to work?
If possible, could somebody point me to where the unit tests might be for this,
because I couldn't seem to find them.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4173834#4173834
OK, I just tried this out on CR1, using the same code that I got to work on
Beta4, and it doesn't seem to work. Did something change again?
Here is the service:
| server
| mbean code=org.jboss.security.auth.login.DynamicLoginConfig
| name=jboss:service=DynamicLoginConfig
|
I had a WAR file, but that is what the problem was. I had to move the
dynamic-login.xml file to the WEB-INF/classes directory.
One thing that should be noted is that (I think) the default file that the
dynamic login config service looks for is not available in this new strict
classpath.
View
There was a change in the classloaders from Unified Classloader to VFS
Classloader. What it basically means is that resources are detected in a
strict spec compliant way.
For an ear, if you have a war underneath the resource(xml file) can be under
WEB-INF/classes. If not, you can have
Does anybody know if this is a known issue, or should I open a bug?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4131879#4131879
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4131879
14 matches
Mail list logo
