[JBoss Seam] - Re: HTTPS redirection
by matt.drees
anonymous wrote : I'm now looking at trying to do a filter upstream of the Seam filter (sadly not an area I'm very familiar with) to change the HttpServletRequest URL (conditionally).
|
This is what we're planning to do. I haven't tested it yet (don't have an ssl cert set up yet), but I think it should work. I'll report back if it doesn't.
We use BIG-IP for loadbalancing and ssl decryption. For ssl requests, we've configured it to add a specific request header. I haven't tested this, but I think we only need to override Request.getScheme(), and not Request.getRequestURL().
|
| @Name("bigIpSslFilter")
| @Scope(ScopeType.APPLICATION)
| @BypassInterceptors
| @org.jboss.seam.annotations.web.Filter
| public class BigIpSslFilter implements Filter {
|
| public void destroy() {
| }
|
| public void doFilter(ServletRequest request, ServletResponse response,
| FilterChain filterChain) throws IOException, ServletException {
| if (request instanceof HttpServletRequest) {
| filterChain.doFilter(new BigIpSslRequest((HttpServletRequest) request), response);
| } else {
| filterChain.doFilter(request, response);
| }
| }
|
| public void init(FilterConfig filterConfig) throws ServletException {
| }
|
| public static class BigIpSslRequest extends HttpServletRequestWrapper {
|
| public BigIpSslRequest(HttpServletRequest request) {
| super(request);
| }
|
| @Override
| public String getScheme() {
| String forwardedScheme = getRequest().getHeader("HTTP_X_FORWARDED_PROTO");
| if (forwardedScheme != null && forwardedScheme.equals("https")) {
| return "https";
| }
| return super.getScheme();
| }
|
| @Override
| public HttpServletRequest getRequest() {
| return (HttpServletRequest) super.getRequest();
| }
| }
| }
|
(btw, it's the same header that rails looks for to determine proxied https requests, since we also have some rails apps)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101498#4101498
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101498
18 years, 5 months
[JBoss Seam] - Re: AbstractResource subclass gets ClientAbortException writ
by JakeC
I think you're on to something. I got a bit farther.
16:45:52,234 INFO [Util] 0: Writing 16,384 bytes of 57,567 to buffer
| 16:45:52,250 INFO [Util] 0: Writing 16,384 bytes of 57,567 to buffer
| 16:45:52,250 INFO [Util] 0: Writing 16,384 bytes of 57,567 to buffer
| 16:45:52,265 INFO [Util] 0: Writing 8,415 bytes of 57,567 to buffer
| 16:45:52,296 ERROR [Util] Error serving file: <path to file>
It got to the very last buffer full. In my code I added the following line after the rest of the response.set***() methods:
response.setContentLength((int)file.length());
Do I need to take the size of the header into account or something? It is called setContentLength().
Whoops, I take it back. I tried a larger file, and still get an exception way before the end of the file.
17:04:08,390 INFO [Util] 0: Writing 16,384 bytes of 265,076 to buffer
| 17:04:08,390 INFO [Util] 0: Writing 16,384 bytes of 265,076 to buffer
| 17:04:08,390 INFO [Util] 0: Writing 16,384 bytes of 265,076 to buffer
| 17:04:47,796 ERROR [Util] Error serving file: <path to file>
Any other ideas? I know that it works if the file is small enough, because it is used to display thumbnail images in another part of our app.
17:10:15,062 INFO [Util] 0: Writing 5,082 bytes of 5,082 to buffer
This is driving me nuts! It is absolutely essential we get our app working under SSL. :-(
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101496#4101496
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101496
18 years, 5 months
[JBoss Seam] - problem with @Redirect
by X490812
here is my custom exception
| @ApplicationException
| @Redirect(viewId="genericErrorPage.xhtml")
| public class FraudException extends Exception {
| public FraudException(){}
| }
|
here is my genericErrorPage.xhtml
| .
| .
| .
| <body>
| <h:messages
| globalOnly="true"
| styleClass="message"
| id="globalMessages" />
| </body>
|
| </html>
|
here is where I throw it:
| private void doQry(String qry) throws FraudException {
| Connection con = null;
| Statement st = null;
|
| try {
| con = ds.getConnection();
| st = con.createStatement();
| ResultSet rs = st.executeQuery(qry);
| caseList.clear();
| while (rs.next()) {
| caseList.add(new Tblcase(rs.getObject(1), rs.getObject(2), rs
| .getObject(3), rs.getObject(4), rs.getObject(5), rs
| .getObject(6), rs.getObject(7), rs.getObject(8), rs
| .getObject(9), rs.getObject(10), rs.getObject(11), rs
| .getObject(12)));
| }
| } catch (Exception e) {
| e.printStackTrace();
| log.error("ERROR: " + e.getMessage());
| facesMessages.add("ERROR RENDERING DATA: " + e.getMessage());
| throw new FraudException();
| } finally {
| try {
| con.close();
| st.close();
| } catch (Exception e) {
| e.printStackTrace();
| log.error("ERROR: " + e.getMessage());
| facesMessages.add("ERROR CLOSING CONNECTIONS: " + e.getMessage());
| throw new FraudException();
| }
| }
|
Why does the SEAM.debug (or facelets.debug - not sure which) come up when I deliberately force an exception instead of my genericErrorPage.xhtml?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101487#4101487
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101487
18 years, 5 months
[JBossCache] - Re: JDBCCacheLoader problem in java application
by gmeroz
Since we both agree that there shouldn't be a difference between pojo & core cache related to this issue, i decided to run more tests & managed to reproduce the problem.
i just changed the loop in your test to run up to 1000 & got the following error (only when using Oracle):
| java.lang.IllegalStateException: Failed to load node for fqn /C/487
| at org.jboss.cache.loader.AdjListJDBCCacheLoader.reportAndRethrowError(AdjListJDBCCacheLoader.java:652)
| at org.jboss.cache.loader.AdjListJDBCCacheLoader.loadNode(AdjListJDBCCacheLoader.java:408)
| at org.jboss.cache.loader.JDBCCacheLoader._put(JDBCCacheLoader.java:188)
| at org.jboss.cache.loader.JDBCCacheLoader.put(JDBCCacheLoader.java:69)
| at org.jboss.cache.interceptors.CacheStoreInterceptor.invoke(CacheStoreInterceptor.java:219)
| at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
| at org.jboss.cache.interceptors.CacheLoaderInterceptor.invoke(CacheLoaderInterceptor.java:180)
| at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
| at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:36)
| at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
| at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:201)
| at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
| at org.jboss.cache.interceptors.NotificationInterceptor.invoke(NotificationInterceptor.java:32)
| at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
| at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:299)
| at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:131)
| at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
| at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:97)
| at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:76)
| at org.jboss.cache.interceptors.InvocationContextInterceptor.invoke(InvocationContextInterceptor.java:62)
| at org.jboss.cache.CacheImpl.invokeMethod(CacheImpl.java:4019)
| at org.jboss.cache.CacheImpl.put(CacheImpl.java:1535)
| at org.jboss.cache.loader.JDBCCacheLoaderConnectionTest.testConnectionRelease(JDBCCacheLoaderConnectionTest.java:55)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)
| Caused by: java.lang.IllegalStateException: Failed to get connection for url=jdbc:oracle:thin:@dbms01:1521:besapp, user=gggg, password=gggg
| at org.jboss.cache.loader.NonManagedConnectionFactory.reportAndRethrowError(NonManagedConnectionFactory.java:236)
| at org.jboss.cache.loader.NonManagedConnectionFactory.getConnection(NonManagedConnectionFactory.java:85)
| at org.jboss.cache.loader.AdjListJDBCCacheLoader.loadNode(AdjListJDBCCacheLoader.java:373)
| ... 44 more
| Caused by: java.sql.SQLException: Io exception: The Network Adapter could not establish the connection
| at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:125)
| at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:162)
| at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:274)
| at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:328)
| at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:348)
| at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:151)
| at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:32)
| at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:563)
| at java.sql.DriverManager.getConnection(DriverManager.java:582)
| at java.sql.DriverManager.getConnection(DriverManager.java:185)
| at org.jboss.cache.loader.NonManagedConnectionFactory.checkoutConnection(NonManagedConnectionFactory.java:99)
| at org.jboss.cache.loader.NonManagedConnectionFactory.getConnection(NonManagedConnectionFactory.java:80)
| ... 45 more
|
|
Is there any workaround for hits?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101478#4101478
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101478
18 years, 5 months
[JBoss jBPM] - Repeating Timer job doesn't run again if first JobExecutorTh
by jeffj55374
Hi,
I have encountered one undesirable behavior and one bug related to repeating Timers. I'd like to hear what th experts think of my analysis. Assuming I haven't missed anything or have an incorrect understanding of the system, I'll submit an issue.
Note that I'm running JBPM as a standalone application using the JobExecutor mechanism to deal with Timers and async nodes. JBPM Ver. 3.2.2
The Issue
The second and subsequent executions of a timer's action can only be executed by the same JobExecutorThread instance that processed the first execution because the job (Timer) is never unlocked by that thread.
The Bad Behavior
Since only the initial JobExecutorThread can process the Timer, the second and subsequent executions of a repeating timer may be significantly delayed if the JobExecutorThread that processed the initial execution is processing long running tasks. Even if other threads are idle, the Timer will not be processed.
The Bug
The second and subsequent executions of the Timer's action will never occur if the thread that processed the initial execution terminates. Even though other JobExecutorThreads are running, the Timer will never fire again because it is locked by the initial thread which no longer exists.
The basic functionality of JobExecutorThread.run() is:
| while (active)
| determine available jobs. (jobs that are due and not locked by other threads)
| lock the job
| create JBPM context
| execute the job
| if the job is a ExecuteNodeJob
| delete the job
| if the job is a ExecuteActionJob
| delete the job
| if the job is a Timer
| if the timer is not a repeating timer
| delete the job (Timer)
| else
| // Nothing is done. Note that the timer is still locked
| // Really should job.setLockOwner(null);
| // and job.setLockTime(null);
| // This would allow any other job executor thread to
| // to process this Timer when it becomes due.
| close JBPM context // Commits the job deletion or the updated timer
|
| protected void executeJob(Job job) {
| JbpmContext jbpmContext = jbpmConfiguration.createJbpmContext();
| try {
| JobSession jobSession = jbpmContext.getJobSession();
| job = jobSession.loadJob(job.getId());
|
| try {
| log.debug("executing job "+job);
| if (job.execute(jbpmContext)) {
| jobSession.deleteJob(job);
| }
|
| // **** I think this code should be added:
| else {
| job.setLockOwner(null);
| job.setLockTime(null);
| }
| // ****
| } catch (Exception e) {
| // Exception handling code removed.
| }
|
| // if this job is locked too long
| long totalLockTimeInMillis = System.currentTimeMillis() - job.getLockTime().getTime();
| if (totalLockTimeInMillis>maxLockTime) {
| jbpmContext.setRollbackOnly();
| }
|
| } finally {
| try {
| jbpmContext.close();
| } catch (JbpmPersistenceException e) {
| // Exception handling code removed.
| }
| }
| }
|
Here's the task node definition that creates the timer.
| <task-node name="FileAvailableCheck">
| <task name="CheckForFile">
| <timer duedate="30 seconds" repeat="30 seconds"
| name="CheckForFileTimer" >
| <action class="com.digitalriver.mds.transform.FileAvailableCheckTask"/>
| </timer>
| </task>
| <transition name="FileReady" to="Transform"></transition>
| </task-node>
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101474#4101474
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101474
18 years, 5 months
[JBoss Seam] - actionListener vs action and redirect
by dkane
Dear colleagues,
I always used actionListener parameter when bind component method to a:commandLink. It was ok until I needed the event that not only trigger action but also redirect to another page.
I added redirect rule to pages.xml and specified action in it. But a:commandLink with actionListener worked only partially : action was performed without redirect. When I change actionListener to action, both method and redirect works well.
Now I want to understand the difference between those to attributes, when to use 1st and when 2nd. I don't understand this difference from standard manuals saying :
anonymous wrote : actionListener : MethodBinding pointing at method accepting an ActionEvent with return type void
anonymous wrote : action : MethodBinding pointing at the application action to be invoked, if this UIComponent is activated by the user, during the Apply Request Values or Invoke Application phase of the request processing lifecycle, depending on the value of the immediate property
Could anyone provide more human readable explanation please ?
TIA.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101465#4101465
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101465
18 years, 5 months