You would have to get them from the tomcat download. We have our own jmx admin console
so we don't use these and I don't even know if they will work.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3826747#3826747";>View
the original post
http://www.jboss.org/index.html?module=bb&op=po
Validate that the keystore file is valid on windows using the keytool to print the
server cert. If its valid, enable debugging of the jsse layer by adding the
-Djavax.net.debug=all system property to the run.bat command line or by setting the
JAVA_OPTS="-Djavax.net.debug=all" env variable.
http
The descriptors won't be of any help. You have to post the full stack trace of the
security exception to see what invocation layers are involved. If you have an example
ear that demonstrates the problem create bug report on sourceforge and attach the ear
to the report.
http://www.jboss.org/ind
You can specify a keyAlias attribute on the connector to choose a specific key, else
the key will be choosen based on the first key that matches the ssl handshake
parameters.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3826743#3826743";>View
the original post
http://www.jboss.org
Put the applet classes in a jar under webmod.war and do not use a codebase. Specify
the jar via the archive attribute. This is how the web-console.war applet is deployed:
|
| ...
|
|
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3826739#3826739";>View
the original post
h
JBossCache supports clustering, although its not clear how this is an approriate
replacement for a singleton.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3826738#3826738";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3826738>Reply
to the
Yes, you will have to track this, or your singleton service can create a link to the
RMIAdaptor under a unqiue JNDI name such that when a client looks this up through
HA-JNDI, it finds the RMIAdaptor on the same node as the singleton.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3826
This also occurs if the javac compiler is not on the jboss server classpath. This is
typically found in the jre/lib/tools.jar.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3826734#3826734";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3826
A serverless jms prototype has been made available from the JBoss sourceforge project
site:
http://sourceforge.net/project/showfiles.php?group_id=22866&package_id=26210&release_id=224938
Discussion should take place in the Messaging, JMS & JBossMQ forum or the
JMS on JBoss (JMS/JBoss) depending
The serverless jms release has also been made availble from the JBossMQ section of the
sourceforge JBoss project page:
http://sourceforge.net/project/showfiles.php?group_id=22866&package_id=26210&release_id=224938
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3826628#3826628";>View
Your hook is the interception of the ejb method call. You can do whatever you want to
determine who the caller is. You cannot change the roles assigned to the user at
authentication time. You permission access based on the derivced manager role and
either allow the call or fail it with a Securit
If the security check depends on the data coming in with the call then you really need
to use a custom security interceptor. This can be handled by the current custom
security proxy, or via your own custom security interceptor.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3826595#38
Yes, I just fixed this for the 3.2.4RC2 or 3.2.4 relase, whichever comes first.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3826589#3826589";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3826589>Reply
to the post
---
Look up the MBeanServer via the MBeanServerFactory and invoke away.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3826588#3826588";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3826588>Reply
to the post
---
This is why the use of singletons/static blocks in frameworks used by application code
is bad. The org.apache.log4j.LogManager is reloading the conf/log4j.xml file and is
loading jboss specific appenders which have already been linked against the log4j
classes loaded outside of the ear.
Set the
Show the full exception stack trace
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3825941#3825941";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3825941>Reply
to the post
---
This SF.Net
You appears to be trying to use the java: context in the client without correctly
setting up the j2ee app client, including the application-client.xml descriptor. Try
showing some details of the jndi usage causing the problem. The java: context is not
usable by clients unless there as been an ap
This was fixed in the 3.2.4RC1 release by scoping the web console jars. Download this
release to see how it was done as the same setup can be applied to 3.2.3.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3825937#3825937";>View
the original post
http://www.jboss.org/index.html?modul
If your running with the HA-JNDI service then the shutdown.sh lookup of the RMIAdaptor
will fail to find the localhost JNDI service after the shtudown of the first instance,
and will do a discovery broadcast to find an HA-JNDI service and will discover the
remote node and issue a shutdown agains
No, jboss uses its only configuration implementation that parses the login-config.xml
file.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3825861#3825861";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3825861>Reply
to the post
-
Sounds like an address resolution issue. Take thread dumps of the two sides to see
where the delay appears to be.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3825830#3825830";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3825830>Reply
to
Not without a jboss version and how the shutdown is being performed.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3825829#3825829";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3825829>Reply
to the post
--
No.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3825828#3825828";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3825828>Reply
to the post
---
This SF.Net email is sponsored by: IBM Linu
There is a conflict with the version of jdom you compiled against that the jdom.jar
found in jboss-3.2.3/lib/jdom.jar. Try replacing this with your version of jdom, or
add a jboss-web.xml to your war to override the
jboss version of the classes.
mydomain:war=mywar.war
jboss-3.2.4RC1 uses tomcat5 by default now.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3825827#3825827";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3825827>Reply
to the post
---
Thi
There is a conflict with the loaded log4j.jar version coming from somewhere. If your
bundling your own log4j.jar in the web and need this version, then you have to enable
class loader overrides using a jboss-web.xml setup like:
|
|
|
| jboss.test:war=log4j113.war
You would have to define multiple Service elements, one per SSL connector with a
different server certificate.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3825823#3825823";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3825823>Reply
to th
You are either using an incorrect IntialContext environment or have included a
jndi.properties file that is incorrect to see the naming exception shown.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3825822#3825822";>View
the original post
http://www.jboss.org/index.html?module=bb&op
you missing the jbossall-client.jar from your classpath.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3825821#3825821";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3825821>Reply
to the post
--
You have added no new information in the last few additions to this thread, so try
showing the server.log messages from the login. To get more out of the security layer
enable trace level logging and ensure the server.log FILE appender does not have a
Threshold setting.
|
|
|
It was in 3.2.3, try it out.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3825816#3825816";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3825816>Reply
to the post
---
This SF.Net email
No, the JAAS login needs to be triggered by the web container. Anything is possible
with sufficiently deep integration with tomcat, but this is a non-trivial
customization.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3825815#3825815";>View
the original post
http://www.jboss.org/i
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3825696#3825696
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3825817#3825817";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3825817>Reply
to the post
The AbstractServerLoginModule.loginOk field must be set to true in order for commit to
do anything as documented in the javadoc. The setting of the TRACE level is incorrect,
use:
|
|
|
|
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3825813#3825813";>View
You have commented out the FILE appender, and the CONSOLE appender has a threshold of
INFO, so there will be no output to server.log at any threshold. Try checking your
server.log timestamps next time.
|
|
|
|
|
http://www.jboss.org/index.html?module=bb&op=vie
It was available in 3.2.3 as described in this post:
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=45801
jbossweb-tomcat50.sar/server.xml has a similar valve to uncomment:
|
|
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3825761#3825761";>View
the original
The read about configuration of the class loader architecture to see the options for
deployment visibility. There is an excerpt from the 3.0.7
admin/devl guide here:
http://sourceforge.net/docman/display_doc.php?docid=14516&group_id=22866
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3
Your login-config.xml is invalid. The module-option elements need to be child elements
of login-module. Just indenting them does not make this so.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3825713#3825713";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posti
There is a problem with the 3.2.4RC1 jmx-console.war/inspectMBean.jsp page that
prevents one from inspecting MBeans. A replacement is available from the sourceforge
download section. The inspectMBean.jsp fix location is also shown here:
http://prdownloads.sourceforge.net/jboss/inspectMBean.jsp?
No. Its printed out as an INFO level message, but we should be maing it available via
JMX.
12:35:25,541 INFO [CorbaNamingService] Naming:
[IOR:002B49444C3A6F6D672E6F72672F436F734E616D696E672F4E616D696E67436F6E746578744578743A312E32006C0001020F36342E32
Its not possible as the way JAAS is used to perform authentication/authorization is
not defined by the J2EE specs. J2EE 1.4 introduces a new authorization contract, but
still does not define how authentication using JAAS is performed.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3825
To authenticate with a login username of user1, a principalDNPrefix='uid=' and a
principalDNSuffix='ou=Group1,ou=People,dc=mycompany,dc=com' is required.
Configurations based on users is not supported by the LdapLoginModule so your schema
is not supported since users are not under a single conte
For the config you show, you would need a binding like the following for fsmit to the
seen in the Member_admin role:
| dn: cn=Member_admin,ou=Roles,dc=iqtech,dc=pl
| objectClass: top
| objectClass: groupOfUniqueNames
| cn: Member_admin
| uniqueMember: uid=fsmith,ou=People,dc=iqtech,dc=
Access to the getUserPrincipal does not depend on the auth method used. It works for
basic and form auth.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3825553#3825553";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3825553>Reply
to the pos
Works fine for me. I have moved the files to the conf directory, renamed them
jmx-users.properties, jmx-roles.properties to make sure only these would be used, and
secured the jmx-console using the following login-config.xml entry:
|
|
|
| jmx-users.
We are in the process of taking over the fulfillment oursevles.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3825524#3825524";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3825524>Reply
to the post
---
>From listing 2.9, page 66 of the admin devl guide:
|
|
|
|
|
|
|
|
|
|
|
|
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3825523#3825523";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=re
The jboss-3.2.4RC1 release is available here:
http://sourceforge.net/project/showfiles.php?group_id=22866&package_id=16942&release_id=223319
Change notes are here:
http://sourceforge.net/docman/display_doc.php?docid=21888&group_id=22866
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3
Its the J2EE application client deployer service which handles the ear
META-INF/application-client.xml descriptors.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3825397#3825397";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3825397>Reply
There is no RMIConnector interface. There is an org.jboss.jmx.adaptor.rmi.RMIAdaptor
interface in the jbossall-client.jar.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3825395#3825395";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3825395>
| import java.security.Principal;
|
| public class SnoopServlet extends HttpServlet
| {
|protected void doGet(HttpServletRequest request, HttpServletResponse response)
| throws ServletException, IOException
|{
| // getUserPrincipal returns non-null only when t
You need to use a DynamicMBean to supply this information. The JBoss XMBean is the
easiest way to to this.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3825278#3825278";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3825278>Reply
to the p
The jndi properties needed to connect to the server need to be passed in as
SRPLoginModule options.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3824899#3824899";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3824899>Reply
to the post
--
The coyote connector does not support any ssl socket factory other than its own so the
keystore approach is the only way to configure ssl.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3824898#3824898";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=
The keystore deals with string aliases. Using the Principal.getName() as the alias in
the keystore solves this.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3824897#3824897";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3824897>Reply
to t
The login-config.xml file has an error in it that will be logged to the server.log at
debug level. The exception here results when the file is parsed as a sun text file
format due to the previous xml error. Check the server.log for the xml format problem.
http://www.jboss.org/index.html?module=b
See the following topic:
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=45724
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3824604#3824604";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3824604>Reply
to the post
--
If you write the jca adaptor you can. We have no jca adaptor which performs this
function.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3824603#3824603";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3824603>Reply
to the post
--
The jboss-3.2.3/docs/examples/jca/postgres-ds.xml shows this configuration.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3824601#3824601";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3824601>Reply
to the post
---
No, you have to arrange the web site urls into secured and unsecured sections as you
cannot exclude urls from a resource collection.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3824599#3824599";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&
A custom principal is used in the tomcat layer as of 3.2.4RC1 is the login module
provides a group named CallerPrincpal that contains the custom principal.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3824597#3824597";>View
the original post
http://www.jboss.org/index.html?module=b
Yes, its a type that was not being handled. This has been corrected for 3.2.4RC1.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3824545#3824545";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3824545>Reply
to the post
-
You need the java command in your PATH for javacc for some reason.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3824535#3824535";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3824535>Reply
to the post
For the XMBean represented by the xml descriptor there is no path for specifying the
mbean.metadata.xml.validate property.
I'll look into the perf issue some more, but the xerces parser shipped with 3.2.3 is
the one bundled with an old xalan xalan-j_2_4_D1 release and definitely has
performance
All the LoginInitialContextFactory does is encapsulate the JAAS login into the
InitialContext creation. This class is in the server/default/lib/jbosssx.jar. See the
JAAS Howto post on the top of the forum for more into on the client side login process.
http://www.jboss.org/index.html?module=bb&o
I'm not following your question here, but if you security model does not fit into the
standard role to uri based access model, you'll have to implement a custom model using
filters and/or tomcat valves.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3824419#3824419";>View
the original
No, you would have to create your own login module which created a
java.security.acl.Group implementation named 'Roles' which support this via its
isMember(Principal) method.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3824417#3824417";>View
the original post
http://www.jboss.org/
Logout is called when the cache entry is dropped so that the LoginModule which
populated the associated Subject can to cleanup or tracking or whatever. There is no
other mechanism that triggers a LoginModule logout on the server side.
If you want access to the cache, supply your own cache implem
Works fine for me. See the description in the following FAQ entry:
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3824409#3824409
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3824410#3824410";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=
As described in the admin/devl guide, do the following.
Step 1: Define the hosts in the jbossweb-tomcat41.sar/META-INF/jboss-service.xml
Config attribute fragment:
|
|
|
|
|
|
|
|
There have been reports of leaks with the ibm vm and opennms. Remove the
snmp-adaptor.sar from the deploy directory to disable the service shown in the stack
trace.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3824400#3824400";>View
the original post
http://www.jboss.org/index.html
There is no jboss-3.2.3.gz. There is a jboss-3.2.3.bz2 which when bunzip2 produces a
tar file that is missing the .tar extension.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3824389#3824389";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3
There is a bug report on this on sourceforge:
http://sourceforge.net/tracker/index.php?func=detail&aid=909473&group_id=22866&atid=376685
When someone can actually provide a testcase which demonstrates the problem progress
on this issue can be made. The NPE is due to something holding on to the Cl
This occurs when JAVA_HOME points to a JRE which does not have the required javac
compiler. You need JAVA_HOME pointing to a JDK installation.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3824273#3824273";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&
You cannot override/change existing configurations. You can only add new ones on
startup of the service with removal on shutdown of the server.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3824241#3824241";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&
This occurs when another deployment is using stale classes from deployment which has
been replaced. In this case, the jdbc driver container deployment has presumably been
redeployed which the datasource configuration has not.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3824236#38242
JMX has no meanignful security contract so your on your own and living outside of the
spec. The admin/devl guide talks about using the XMBean impl of the ModelMBean to add
security on top of a service. See the
testsuite/src/resource/jmx/interceptors/secured-xbmean.xml descriptor for another
exa
Use the recently added 3.2 DynamicLoginConfig service:
jboss-service.xml:
|
|
|
| META-INF/jaas-test-config.xml
|
| jboss.security:service=XMLLoginConfig
|
|
|
|
|
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3824083
I added a test of getting the user principal from the web request and it did have a
problem with returning the customer CallerPrincipal value. This has been fixed for the
3.2.4RC1 release.
The code changed was in the org.jboss.web.tomcat.security.JBossSecurityMgrRealm class.
http://www.jboss.o
You don't appear to be setting the groups correctly. This fixed version works fine
with my ejb testcase:
| package org.jboss.test.security.ejb;
|
| import java.security.acl.Group;
| import javax.security.auth.login.LoginException;
| import org.jboss.security.auth.spi.UsernamePasswordL
For an introduction to the use of JAAS in JBoss, see the following article:
http://sourceforge.net/docman/display_doc.php?docid=18240&group_id=22866
You should read this if you are having security issues related to JAAS configurations.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3824
anonymous wrote : The question is 'can' or really propagates??
Its depends on whether a thread pool is used and if the entry
point resets the security associated based on the caller.
anonymous wrote : But I couldn't find what the method set(null) from ThreadLocal
really do?? There is no info i
You currently cannot. See:
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=45863
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3823987#3823987";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3823987>Reply
to the post
---
You cannot set the java.security.auth.login.config system property to pickup a the
JAAS config. You have to use the server/xxx/conf/login-config.xml version. See the
JAAS howto:
http://sourceforge.net/docman/display_doc.php?docid=18240&group_id=22866
http://www.jboss.org/index.html?module=bb
Show the image tag for the favico.ico icon and indicate the jboss version.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3823983#3823983";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3823983>Reply
to the post
I don't use eclipse, so try the JBossIDE forum.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3823982#3823982";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3823982>Reply
to the post
---
There is a link to the web security manager under the name
"java:comp/env/security/security-domain". If you want the security manager you can
look it up:
| import org.jboss.security.SubjectSecurityManager;
|
|InitialContext ctx = new InitialContext();
|Context envCtx = (Context
Read the following JAAS howto:
http://sourceforge.net/docman/display_doc.php?docid=18240&group_id=22866
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3823978#3823978";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3823978>Reply
to the post
Try reading the following JAAS howto:
http://sourceforge.net/docman/display_doc.php?docid=18240&group_id=22866
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3823976#3823976";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3823976>Reply
to the
You have to provide your custom Principal as the "CallerPrincipal" binding in the
Subject. The testcase for the custom principal uses a login config of:
|
|
|
| anonymous
| org.jboss.test.security.ejb.CustomPrincipalImpl
|
JBoss has a flat default class loading model described here:
http://sourceforge.net/docman/display_doc.php?docid=14516&group_id=22866
If you are deploying multiple versions of the same classes in an ear, you need to
isolate the classes using an ear/META-INF/jboss-app.xml descriptor with a unique
Correct.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3823819#3823819
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3823819
---
SF.Net is sponsored by: Speed Start
Without a specfication and configuration of a security-domain in a jboss.xml
descriptor there is no security. Validate that the eclipse plugin in correctly
configuring the jboss.xml descriptor.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3823814#3823814
Re
Look at the jboss codebase for the org.jboss.security.auth.spiUsersRolesLoginModule
and its base class org.jboss.security.auth.spi.UsernamePasswordLoginModule in the
jboss-3.2/security/src/main tree for the commit behavior used with the example
testcase. It will take 24 hours for this code to be
This works fine for me. I have updated the UsernamePasswordLoginModule baseclass to
support an external Principal implementation and added a testcase that uses a custom
principal class and this is seen as the ejb getCallerPrincipal type:
| public class CustomPrincipalBean implements SessionBe
There is no setting that will prevent this. The properties that are dumped needs to
have the password masked. This will be added for the 3.2.4RC1 release.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3823661#3823661
Reply to the post :
http://www.jboss.org/
The enforce-ejb-restriction never has had any effect. You would have to run with a
security manager and configure the permissions to disallow this.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3823603#3823603
Reply to the post :
http://www.jboss.org/index.h
Dependencies do not affect when components are created. The service either needs to be
moved into the ear or the service classes moved out of the ear.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3823605#3823605
Reply to the post :
http://www.jboss.org/inde
You can't. There is no standard way for accessing the caller of a component other than
the ejb context.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3823602#3823602
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=382360
Read the following JAAS Howto:
https://sourceforge.net/docman/display_doc.php?docid=18240&group_id=22866
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3823600#3823600
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=38236
1 - 100 of 145 matches
Mail list logo
