[JBossCache] - Re: No modification operations in CacheJmxWrapper?
by bstansberryï¼ jboss.com
Seems to me if someone wants to expose more operations via JMX it's a trivial exercise to subclass CacheJmxWrapper(MBean) and do it.
JBC should only support it directly if we agree that there's a good generally applicable use case for it that's compelling enough to trump the desire to not make CacheJmxWrapperMBean a control interface.
Re: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098262#4098262, Hibernate exposes an API for evict data from the 2nd level cache. If there is no JMX interface to that API, that seems like something that should be dealt with by Hibernate. Encouraging users to bypass Hibernate and directly operate on JBC is analogous to someone exposing the JBC transaction table in JMX and letting users directly operate on it.
Similar arguments apply to other AS usages of JBC. E.g. if I want to support a management layer that can remove a web session from the distributed web session cache, then that operation should be exposed by the web tier session manager. I don't want users directly going into the underlying cache and mucking around.
Re: create/start/stop/destroy, you're right -- they don't fit. They are only there to support letting people deploy legacy -service.xml files in AS 5 by just changing the mbean's code attribute from org.jboss.cache.TreeCache to org.jboss.cache.jmx.CacheJmxWrapper. If we didn't want to support that (i.e. people have to use -beans.xml), we could remove the methods from the mbean interface. (Note I'm not advocating removing them at this late date; just discussing why they are there.)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098387#4098387
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098387
18Â years, 8Â months
[JBossWS] - Re: Basic Authentication with WSSecureEndpoint on JBoss 4.2.
by ejb3workshop
I added a custom login module to debug this problem. It seems that the user and password are never passed to the login module.
| public boolean login() throws LoginException {
| logger.info("Login");
| NameCallback nameCallback = new NameCallback("User Name");
| PasswordCallback passwordCallback = new PasswordCallback("User Password", false);
| Callback[] callbacks = new Callback[2];
| callbacks[0] = nameCallback;
| callbacks[1] = passwordCallback;
| logger.info("Configured callbacks");
| try {
| logger.info("Handling callbacks");
| callbackHandler.handle(callbacks);
| logger.info("Handled callbacks");
| } catch (UnsupportedCallbackException ex) {
| ex.printStackTrace();
| } catch (IOException ex) {
| ex.printStackTrace();
| }
| String userid = "default";
| String password = "default";
| userid = nameCallback.getName();
| password = new String(passwordCallback.getPassword());
| logger.info("Processed callbacks");
| passwordCallback.clearPassword();
| logger.info("Attempt to login with :"+userid+" and "+password);
| JAASUser user = new JAASUser(1,userid);
| JAASRole role = new JAASRole("friends");
| subject.getPrincipals().add(user);
| subject.getPrincipals().add(role);
| return true;
| }
|
I am still a little confused on where I am supposed to configure which Principal implementation is a User or a Role.
I also tried adding a WebContext, but this resulted in a The request failed with HTTP status 401: Unauthorized. error without invoking the Login Module. Removing the WebContext annocation resulted in the Login Module being called, but without User / Password.
@WebContext(authMethod = "BASIC", transportGuarantee="NONE", secureWSDLAccess = false)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098385#4098385
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098385
18Â years, 8Â months
[Beginners Corner] - CachedConnection Manager exception
by SandeepDJboss
Hi,
I am using jboss-5.0.0.Beta2; I have recently migrated my application from weblogic to JBoss; I have been facing a strange issue.
This code works in production for weblogic; so I can believe it can be a problem with code.
I am using JBOSS connection pooling for connecting to database. It looks JBoss is closing some connections on its own throwing below exception:-
[200710281:043148][WorkerThread#0[10.253.58.131:2713]]com.ssp.tbo.fw.record.ThinCursorServer.removeOpenCursor:201> Removed cursor key 106973.2.2
2007-10-08 04:31:48,216 INFO [org.jboss.resource.connectionmanager.CachedConnectionManager] Closing a connection for you. Please close them yourself: org.jboss.resource.adapter.jdbc.WrappedConnection@15facb0
java.lang.Throwable: STACKTRACE
at org.jboss.resource.connectionmanager.CachedConnectionManager.registerConnection(CachedConnectionManager.java:290)
at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:415)
at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:838)
at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:88)
And the next thing is does is to fire the query on this connection; and I get following error
EXCEPTION WITH STACK TRACE FOLLOWS
java.sql.SQLException: Connection handle has been closed and is unusable
at org.jboss.resource.adapter.jdbc.WrappedConnection.checkStatus(WrappedConnection.java:537)
at org.jboss.resource.adapter.jdbc.WrappedConnection.checkTransaction(WrappedConnection.java:524)
at org.jboss.resource.adapter.jdbc.WrappedConnection.createStatement(WrappedConnection.java:142)
This is very strange behavior.. Why JBOSS closes the connections so early. We do close it pro grammatically when we are done with the connection. It all happens in very short period of time so JBOSS ideally should not close the connections.
This is irregular behavior as next time you fire a query it may work; and after couple of more attempts you may get to the same exception.
Any light on above exception would be greatly appreciated....
Thanks so much.
Sandeep
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098383#4098383
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098383
18Â years, 8Â months
[Beginners Corner] - CachedConnection Manager exception
by SandeepDJboss
Hi,
I am using jboss-5.0.0.Beta2; I have recently migrated my application from weblogic to JBoss; I have been facing a strange issue.
This code works in production for weblogic; so I can believe it can be a problem with code.
I am using JBOSS connection pooling for connecting to database. It looks JBoss is closing some connections on its own throwing below exception:-
[200710281:043148][WorkerThread#0[10.253.58.131:2713]]com.ssp.tbo.fw.record.ThinCursorServer.removeOpenCursor:201> Removed cursor key 106973.2.2
2007-10-08 04:31:48,216 INFO [org.jboss.resource.connectionmanager.CachedConnectionManager] Closing a connection for you. Please close them yourself: org.jboss.resource.adapter.jdbc.WrappedConnection@15facb0
java.lang.Throwable: STACKTRACE
at org.jboss.resource.connectionmanager.CachedConnectionManager.registerConnection(CachedConnectionManager.java:290)
at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:415)
at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:838)
at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:88)
And the next thing is does is to fire the query on this connection; and I get following error
EXCEPTION WITH STACK TRACE FOLLOWS
java.sql.SQLException: Connection handle has been closed and is unusable
at org.jboss.resource.adapter.jdbc.WrappedConnection.checkStatus(WrappedConnection.java:537)
at org.jboss.resource.adapter.jdbc.WrappedConnection.checkTransaction(WrappedConnection.java:524)
at org.jboss.resource.adapter.jdbc.WrappedConnection.createStatement(WrappedConnection.java:142)
This is very strange behavior.. Why JBOSS closes the connections so early. We do close it pro grammatically when we are done with the connection. It all happens in very short period of time so JBOSS ideally should not close the connections.
This is irregular behavior as next time you fire a query it may work; and after couple of more attempts you may get to the same exception.
Any light on above exception would be greatly appreciated....
Thanks so much.
Sandeep
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098382#4098382
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098382
18Â years, 8Â months
[JBoss Seam] - EntityQuery Restrictions
by griffitm
Hello All,
I have some components generated by seamgen, specifically the EntityQuery Lists that relate to a list of entity objects. The seam generated search form allows the restrictions to be passed to the query:
| public class StatusList extends EntityQuery {
|
| private static final String[] RESTRICTIONS = {"lower(status.description) like concat('%', concat(lower(#{statusList.status.description}),'%'))",};
| ...
| private Status status = new Status();
|
| @Override
| public String getEjbql() {
| return "select status from Status status order by status.sortOrder";
| }
| ...
The query works well if no parameters are passed to the restrictions, the list is returned in the correct order, however if I pass a parameter to the restrictions clause the predicates of where/order are mixed up and invalid SQL is executed, which of course produces an error.
What is the correct way to approach this?
Thanks in advance!
MG
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098380#4098380
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098380
18Â years, 8Â months