Thanks for the reply!
Your explanation makes sense, however, it seems conflict with sample in the
[url=http://www.jboss.org/file-access/default/members/jbosscache/freezone/docs/3.2.0.GA/userguide_en/html_single/index.html#configuration.options]user
guide section
3.4.1. (Overriding the
mircea.markus wrote : it only makes sense to use setForceWriteLock(true) on
read. Normally when you do an cache.get(fqn) an read lock is aquired, but
setting the forceWriteLock to true would force a write lock acquisition. when
you do a put(fqn)(generally a write), a WL (write lock) is acquired
Thanks for the reply.
So if I need to read a node, then write to it, such as:
| tm.begin();
| // force write lock even on read operations
|
cache.getInvocationContext().getOptionOverrides().setForceWriteLock(true);
|
After some trial and error, I finally located the problem. It seems that the
org.jboss.util.naming.NonSerializableFactory class in the required
jboss-common-core.jar dependent library is causing any JNDI lookup to fail.
I've created a issue with the JBoss Common project:
I'd appreciate some clarification regarding the Invocation concept. What is
considered an invocation?
It looks like JBC uses ThreadLocal to store transaction and InvocationContext,
so it appears to me that a invocation is basically having the same lifespan as
a thread. Is this correct? What
I am using:
- JBoss AS 4.2.3.GA
- JBoss Cache 3.2.0
in the configuration, I am setting the loader as:
| loaders passivation=false shared=false
| loader class=org.jboss.cache.loader.JDBCCacheLoader async=true
fetchPersistentState=true ignoreModifications=false
I put a simple test class to lookup the java:/DefaultDS and it failed as
well. It seems more of a JNDI naming issue, so I'll post a new thread in the
JNDI forum.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4257495#4257495
Reply to the post :
So I created a test EAR that contains only one simple Servlet that looks up the
DataSource using the JNDI name to verify that the problem is with JNDI lookup.
This time it worked just fine. I am guessing that my problem is related to the
EAR. I'll post my updates after I examine the EAR
Thanks for the reply, I just realized that you answered the questions before my
last post :)
I am still not clear with two of the answers and wonder if you can help:
manik.surt...@jboss.com wrote :
| ae wrote :
| | - With REPEATABLE_READ isolation, is the write skew still a
problem
Yes, I read that thread and yes, the use case is similar. We want a easy way to
block for write operation rather capturing exceptions. The thing is that I
don't want to use pessimistic locking from your test code there as it is
deprecated now.
View the original post :
manik.surt...@jboss.com wrote : You can force write locks for a read. There
is an Option for this (see the Options API). When used with MVCC, this gives
you an exclusive (write) lock, when when you are reading. And when combined
with a transaction, this means you hold the write lock until the
Thanks for the reply.
I have the same concern regarding the deprecated pessimistic locking. The JBC
documents keeps talking about the benefit of mvcc, but failed to address this
common use case.
Note that the concurrent write is not really an exception in this scenario, it
is expected to
I just started using JBoss Cache and went through the doc and searched the
forum but didn't find the answer for my question. I am using JBossCache
3.2.0.GA.
I need to perform the following operation frequently in a clustered caching
environment:
| Node node =
Looks like the LockManager.lock() is not directly accessible from client code,
as I didn't find any public API that retrieves the LockManager instance.
So is there anyway that allows me to obtain a write lock before reading a node?
Thanks,
View the original post :
I read a post in this forum showing that with READ_COMMITTED, the following may
occur:
1. tx1 and tx2 both read node value 10
2. tx1 set the value to (value+1), which is 11
3. tx2 set the value to (value+1), which is also 11, while the desired behavior
is 12, and there is no exception thrown
JIRA ticket: https://jira.jboss.org/jira/browse/JBWS-2369
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4183998#4183998
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4183998
___
During my testing, I used smartsniff to check the HTTP requests / responses
between my WS Client and the SOAP server. I was surprised to discover that the
dynamic WS client would first download the remote WSDL multiple times to create
the service object, which I use to get the port object, then
Just want to bump this, can someone from JBoss confirm if this is a bug? I can
create a JIRA ticket for this so it can be fixed.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4180930#4180930
Reply to the post :
I have tried enable TRACE logging as well as using the JBossWS records
discussed
http://jbossws.jboss.org/mediawiki/index.php?title=Records_management, both of
them only show the message with the encryption / signing, not the decrypted
message.
I wonder if there is any logging from the
I think the timestamp-verification tag is out side of the config tag. Something
like this:
jboss-ws-security xmlns=http://www.jboss.com/ws-security/config;
|xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
|
I am using JBossWS WS-Security. Server side has settings like this:
jboss-wsse-server.xml
| jboss-ws-security xmlns=http://www.jboss.com/ws-security/config;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
| xsi:schemaLocation=http://www.jboss.com/ws-security/config
|
I would suggest you to grab the source and trace into it. That would be what I
would be doing if I were you :)
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4165071#4165071
Reply to the post :
It is invoking the jboss ldap authentication logic, but there is some problem
between that class and your ldap server. I don't have much experiences on this
and won't be able to help on this topic :(
View the original post :
I see. Thank you for the explanation. Now I see how everything is connected.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4164874#4164874
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4164874
When thinking about it, it occurs to me that the referer does not seem to be
a reliable way of determine the issuing site.
1. The Referer site might not be the original issuer of the token, when more
than 2 sites are participating in the SSO.
2. If integrate with 3rd party application /
Just want to bump this thread as it is still not clear to me that when a
federate server receives a SAML token, how does it know the URL to contact to
in order to validate the token? The token itself only has the issuer ID,
which is set in the context.xml file. The federate server wouldn't be
celle2006 wrote : Hi oozoo!
|
| I think you forgot to set the realm-name to value MyTestApp.
|
| Greetz celle2006
Hi, just want to post a quick comment to see if it will help.
I think the realm element in web.xml file is only used to prompt for user name
and password in the HTTP
[EMAIL PROTECTED] wrote :
| the SAML token validation between site2 and site1 involves a Trust callback
between the federation servers of site1 and site2.
|
And this trust callback happens directly between the federate server in the
backend on the server side, no browser redirection
Yes, I am using CR1.
Thank you for the quick response, and it's great to know it's already fixed!
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4163680#4163680
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4163680
Thank you for the detailed explanation.
There is one thing that is still not clear to me: when validating a token, how
does it know which partner issued the token? There is a issuer element in the
SAML xml (in my demo, the token shows Issuer=ssodemo:site1). But this issuer
value is what I
I think I found a bug in JBoss SSO SAML token validation but I'd like to post
it here to get a confirmation first before creating a ticket.
I've got two SSO partner sites setup and it works fine. I am using the default
demo IdentityProvider so the valid users are user1, user2, user3, hpotter,
I want to understand how the JBoss SSO SAML token is validated
1. between JBoss federation servers?
2. with a 3rd party federation server?
With some testing, I think how it works between JBoss federation servers, when
authenticated at sso site1 and try to access sso site2, is:
1. With the help
Thank you for the reply.
I changed the domain to ssosite1 and ssosite2, and all other locations
(login-config.xml, jboss-web.xml, as the security domain names), but that
didn't help.
Is that true the domain in the server.cfg.xml file should match the security
domain associated with the web
[EMAIL PROTECTED] wrote : Just to be clear, the values in server.cfg.xml
should be ssosite1.com and ssosite2.com and not just ssosite1, and ssosite2.
I think this did the trick. I did have only ssosite1 as the domain name
instead of ssosite1.com. I changed it and it is now working! I saw the
Hi,
I'm trying out the JBoss SSO and got stuck with cross domain SSO setup. I
wonder if anyone can point out what I was doing wrong.
I am running two JBoss instances on the local box, with JBoss config name
sso-site1 and sso-site2. For sso-site2, I've changed all the ports it uses
by
First, thanks for the reply.
I don't have the https enabled. Is it a requirement? I don't remember seeing it
in the SSO wiki pages.
I'll give it a try anyway.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4161644#4161644
Reply to the post :
So I enabled the HTTPS on both sites. Now the
jboss-federation-server.sar/conf/server.cfg.xml file looks like this:
| federation-server
| partners
| partner domain=ssodemo-site1
server=https://www.ssosite1.com:8443/federate/
|
There are many issues that has been fixed in the JBoss AS release 4.2.3.GA
according to the JIRA. However, this release does not show up in the download.
Has it been released yet? If not, what is the expected release date?
In the JIRA, under RoadMap for All Versions, this release shows up with
Thank you for the information.
Will there still be a 4.2.3.GA release?
And is there a place where I can get news updates regarding this release?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4157547#4157547
Reply to the post :
According to the wiki, the latest update to this class works with Tomcat
SingleSignOn.
Does it also work with the SingleSignOn in the JBoss clustered environment?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4157548#4157548
Reply to the post :
I think you will have better chance to get some help if you open a new thread
as it seems like a different issue.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4133366#4133366
Reply to the post :
degerhar wrote : Thank you very much! Had the same problem and your patch
solved the issue!!
|
| Thanx for supplying the zip file, made things much easier
You are welcome. Glad it helped you. It is a pain to setup project just to
compile a small class change :)
View the original post :
Given the many options I can use to start a new conversation, I am still not
sure what is the correct way for my situation.
I have a page that shows the summary info, no long-running conversation. It
contains a s:link to a editing page that should starts a long-running
conversation. In
After many tries and errors, I feel method annotated with @Begin is very
confusing to use.
First of all, JavaDoc of @Begin says:
- If method is void type, a new conversation always starts, even a join is
specified.
- If method is not void type, @Begin only triggers if the method returns a Not
EricJava wrote : On your method annotated with @Begin, do you have
@Begin(join=true)? I know you have join on the s:link but I think it needs to
be on the @Begin annotation.
Yes, I did have join=true. I think the things I mentioned about @Begin, like
always start conversation if void type
nickarls wrote : ae wrote : So it is already fixed in 2.0.2GA? That was
amazingly fast!
|
| Even better - since it is marked as Fixed it probably means that it is
committed into the current trunk and you can get it NOW! ;-)
That is good but I will have to wait till it is included
Yep, it works now.
Thanks for fix!
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4126349#4126349
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4126349
___
jboss-user mailing list
So it is already fixed in 2.0.2GA? That was amazingly fast!
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4126346#4126346
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4126346
___
Well said. I agree that if it's just a series of hash table lookup, it is
unlikely to surface as a performance problem. I also agree on the concern with
indexing, given the dynamic nature of the seam contexts.
Toward the end of my current project, I might need to do some profiling and
will
I think the use case is slightly different. The way I enabled the HTTP basic
auth is based on the reference doc by editing the components.xml file:
| web:authentication-filter url-pattern=*.seam auth-type=basic
realm=My App/
|
All pages are protected already with the url-pattern
Say in the following statement:
| log.info(Saved article ##{article.id} successfully);
|
It will print Saved article ##{article.id} successfully directly, as seam
found the first # sign and thinks ## is not an EL and skips both # signs.
What I am doing now as workaround is:
|
I did lots of search but not able to find the answer.
In chapter 28 of the reference doc, quote Note also that even though all the
built in components use a qualified name, most of them are aliased to
unqualified names by default.. I checked the
jboss-seam.jar/META-INF/components.xml file and
[EMAIL PROTECTED] wrote : This should be fixed in CVS now, please let me know
if there's any further issues with HTTP authentication.
Has this been tested? Because when I look at the code in the latest trunk, I
didn't see any code that would fix the second problem I mentioned (see the
Problem
Thank you for the quick reply.
So if I understand you right, with an import statement like
org.jboss.seam.core
org.jboss.seam.transaction
in the seam.jar components.xml file, when I use #{contexts}, seam will:
1. try to find the contexts component in all the available contexts
2. if failed,
[EMAIL PROTECTED] wrote : The authentication should be triggered when
calling/accessing a restricted Seam component, doing the chain.doFilter() call.
It can't happen in the filter as not all contexts exist at that point in time.
My point might not be right as I am not as familiar to the
[EMAIL PROTECTED] wrote : If you're invoking a restricted method and the
credentials are set (which is what the AuthenticationFilter does) then a silent
login will automatically occur, with no need to explicitly call
Identity.authenticate(). Digest authentication is a special case, with a
Thanks for the clarification, really appreciate it.
I don't have the required insight knowledge in order to provide a good
solution. One suggestion I have would be: it seems that the components need to
registered with seam first in order to be used. Theoretically, a map from the
component's
I had the same problem and found out that the BASIC auth code is pretty much
borken in Seam 2.0GA (not sure about early versions).
[The Problems]
The code that causing the problem is in
AuthenticationFilter.processBasicAuth(). The current code looks like:
|private void
As promised, the JIRA issue:
http://jira.jboss.com/jira/browse/JBSEAM-2558
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4124924#4124924
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4124924
skanky78 wrote : hi,
|
| try the following in your pages.xml
|
|
| | page view-id=/home.jsp
| | navigation
| | rule if-outcome=viewArticle
| | redirect view-id=/article.jsp
| | param name=articleId value=#{param.articleId} /
| |
[EMAIL PROTECTED] wrote : The page param should allow you to do this.
|
Could you elaborate it a little bit more? As described in the previous posts in
this thread, the default behavior does not append articleId=xx to the URL
redirected. what do I need to change to have the articleId=xx
dustismo wrote : Maybe this is just a typo on your part, but your page action
will not work as written.. should be:
|
|
| | page view-id=/firstpage.xhtml action=#{actionComponent.begin}
| | descriptionCreate new Itemdescription
| | .
| |
And that was the
Thanks,
It seems that this occurs when there is exception thrown in my code during the
invoke application phase, such as a DB constraint violation when persisting an
object. Otherwise, the debug.seam will come up okay. - hope this helps.
View the original post :
I have the same question.
The page param works fine with current window but it's not bookmarkable. In
other words, user won't be able to locate this page 2 days later using
http://localhost:8080/app/article.xhtml?conversationId=2
The conversationId will be long gone by that time. The parameter
If I specify the following:
| @In(create=true, scope=-any scope here)
| private MyEntityClass bean;
|
I get a Seam exception that the create=true is not valid with the explicit
scope. I don't understand the reasoning behind it. I am thinking it is common
for the following scenario
I just started using Seam. With the great potential it offers, I do run into
some problems, partly due to my specific configuration, and partly due to that
I missing some basic understanding of its concept.
Here are some questions I have and any help is appreciated:
1. How to use, and what is
One more followup question regarding the default scope of a component. If I set
a component's scope to be Conversation and use the @AutoCreate annotation, will
it be automatically created for each new conversation, even if I do not refer
to it in my code?
View the original post :
I think this one definitely needs some insights from the Seam team.
I have to use a Hibernate mapping file instead of EJB3 Entity class in order to
take advantage of my existing project code.
When persisting a Seam annotated POJO, which is mapped in the Hibernate mapping
file, I receives a
I encountered this problem while developing a JBoss Seam based application, and
I wonder if anyone monitors this forum can provide some assistance.
I have a class mapped to Hibernate via the Hibernate mapping file. It loads
okay. However, it seems that using Seam annotation causes the class
Seam 2.0.0GA in JBoss 4.2.2GA
It was working but suddenly, I cannot view the conversation debug page via the
debug.seam?cid=xxx URL.
In browser, the /debug.seam still works. But when I click on the link select
conversation context for a specific conversation, I got an error saying the
justkeys wrote : Works great!
Good, that confirms that your problem is caused by the same bug.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4110758#4110758
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4110758
aborland wrote : Is there currently any other solution/workaround for this?
I'd prefer not to hack in such a change. I'm using 4.2.0.GA_CP01 and having
this exact problem.
This fix is pretty safe and should not have any impact to the rest of the
system.
As for other workaround, I guess it
After tracing into the deployment code, I believe I found the bug that caused
this problem, at least for my case.
My EAR contains a MDB and the persistence.xml file for configuring the
EntityManager.
Two classes are involved in this deployment problem:
org.jboss.ejb3.EJBContainer and
If you are having the same problem, you may need the patched class file (I
haven't find any workaround). To compile it from the source is a very tedious
work so I'll post it here, hope this will save you some time.
Since the forum does not allow attachment, I encoded the patch in Base64. You
forgot to mention that you should merge this above patched MessagingContainer
class into the SERVER_CONFIG/deploy/ejb3.deployer/jboss-ejb3.jar file.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4110307#4110307
Reply to the post :
Create JIRA ticket:
http://jira.jboss.com/jira/browse/JBAS-5049
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4110308#4110308
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4110308
ae wrote : ... You can copy the text below and go to this site to decode
it. It's a zip file that contains the patched MessagingContainer class
|
And since I can't edit the original post, here is the link I forgot to post to
the site that does the base64 encode/decode online for free
What I did as a solution is to create a separate jar for the SEAM action EJB's
which are accessed only via local interfaces. There is no security constraints
specified for this jar file and therefore, won't trigger the exception.
View the original post :
Forgot to mention that I was using SEAM. And I compared all the configuration
files with one of the SEAM examples, didn't see any differences other than name
references.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4109481#4109481
Reply to the post :
I wonder if anyone has encountered the same problem described here?
I am having the same problem. My EAR contains a module app.jar, which contains
the persistence.xml file:
| persistence
| persistence-unit name=myDB
| providerorg.hibernate.ejb.HibernatePersistence/provider
Using SEAM 2.0.0GA on JBoss AS 4.2.2GA.
My SEAM components are packaged in a JAR that is configured to use a security
policy in the META-INF/jboss.xml file of the JAR as follows:
jboss
|security-domainmySecurityDomain/security-domain
| /jboss
|
This security domain is using a
Problem solved after trace into JBoss code.
The reason is that I created the InitialContext at the time when the MDB is
created and try to reuse it when the onMessage() is invoked. What happens
behind the scene is that JBoss saves the username / password into a ThreadLocal
variable in server
Problem solved after trace into JBoss code.
The reason is that I created the InitialContext at the time when the MDB is
created and try to reuse it when the onMessage() is invoked. What happens
behind the scene is that JBoss saves the username / password into a ThreadLocal
variable in server
I am consistently getting this exception with my deployed application.
I have a MDB that accesses other local EJB. I coded the MDB to lookup the other
EJB using the InitialContext with its own username and password. The code looks
like this:
| HashtableString, Object env = new
JBoss AS 4.0.5GA and JBoss Messaging 1.0.4 SP4.
I am having problem to invoke local EJB from a MDB due to authentication
problem. I used the following to create the InitialContext object:
| HashtableString, Object env = new HashtableString, Object ();
| env.put(Context.SECURITY_PRINCIPAL,
I think this should be a bug, but want to get your thoughts before submiting
any ticket.
This is JBoss AS 4.0.5GA, and I am using EJB3.
When I start the JBoss, if there is leftover timers, JBoss will invoke the
corresponding timeout() method on the EJB before the EAR is fully deployed. The
[EMAIL PROTECTED] wrote : Guys,
|
| Did you use a *fresh* eclipse installation with the 3.0.13 plugin installed?
| Don't try to 'upgrade' as there is probably trash in your
installation/workspace that produces the problem.
|
| Regards,
| Koen
Mine is not an upgrade of GPD. I
I think the freeze problem is still there. I am using the GPD 3.0.13 and the
eclipse IDE freezes (with 100% CPU usage) every time I save the process
definition xml file.
I did a couple console thread dump after the saving and it seems that the
problem is related to that the classes in the jbpm
Thank you for the reply!
Since posting the question, I thought it might help to try the latest stable
release of JBoss, so I upgraded from 4.0.4GA to 4.0.5GA and added the messaging
as I did on 4.0.4GA. All messaging examples run fine so I deployed my app and
it worked!
I didn't experience
I am using the jboss-messaging-1.0.1.SP2.
I remember I tracked into JBoss authentication code before and the
username/password are stored in a Thread local variable of type
SecurityAssociation. I think that is the reason why this happened: The JMS
client overwrites the SecurityAssociation with
I have some SLSB that uses container managed default transaction settings. I
also configured the JBoss DefaultDS to a separated production database.
What happens is when I invoke
SessionContext.getTimerService().createTimer()
|
I will get the following Warning message:
01:20:46,065 WARN
When my SLSB is invoked, it has the caller principal set to the client supplied
username. Inside my SLSB, I send out a JMS message to a topic using a different
user/pass specified in the JMS configuration. It is done via
ConnectionFactory.createConnection(user, pass). However, after the message
Just a quick note for the final resolution I used:
I took the big jboss-messaging-client.jar file, ripped every thing out except
the following packages:
- org.w3c.dom
- org.jboss.util.*
- org.jboss.serial.*
- org.jboss.net.*
- org.jboss.mx.*
- org.jboss.logging.*
- EDU.oswego.*
I then put this
Alright, after many many hours of digging around, I found out the JBoss
extension of the EJB3 MDB annotations from wiki. I cleared the jboss.xml and
ejb-jar.xml file and used only the EJB3 annotations. My MDB now looks like:
| @MessageDriven(name = notificationMDB, activationConfig = {
|
You are right, it started as EJB3 question, but now is a messaging problem.
Thanks for pointing it out.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4009013#4009013
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4009013
JBoss 4.0.4GA + Messaging 1.0.1SP2
I created a simple MDB that listen to a topic. When deployed, it all looks
okay. But about 30 seconds later after the deployment, the JBoss console dumps
out an warning message followed by error stack trace. It seems that the
messaging service is trying to
It seems that it is actually a lease / renew problem for MDB.
After look into the source code of JBoss remoting, it seems that the Messaging
simply removes the client connection endpoint when it is notified by the jboss
remoting.Lease class. The Lease class has a timer that checks if the client
Link to the new thread in the Messaging forum:
http://www.jboss.com/index.html?module=bbop=viewtopicp=4009158#4009158
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4009196#4009196
Reply to the post :
I am using JBoss 4.04GA SP2 and JBoss Messaging 1.0.2SP2.
I want to create a MDB in EJB3 that creates durable subscription to a topic.
Since the topic requires a valid user/pass, EJB3 annotation along was not
sufficient. I therefore, created the ejb-jar.xml and jboss.xml file that are
packaged
PeterJ wrote : All I did was follow the installation instructions that came
with Messaging (ran the util/release-admin.xml Ant script). Well, I also switch
databases to MySQL or PostgreSQL. However, the only messaging client I am using
in the app server is a message-driven EJB.
Yep, I used the
1 - 100 of 108 matches
Mail list logo
