[JBoss Web Development] - JSP Pages are not compiling in JBoss5.1.0GA
by m.sudharsana
Hi Folks,
We have developed an webapplication and we deployed in JBoss4.0.1sp1 application is running fine.
One week back we downloaded JBoss5.1.0GA and we deployed the same application in JBoss5.1.0GA, but we are getting this eaception "org.apache.jasper.JasperException: Unable to compile class for JSP: "
please find the exception details below
====================================================================================================
HTTP Status 500 -
--------------------------------------------------------------------------------
type Exception report
message
description The server encountered an internal error () that prevented it from fulfilling this request.
exception
org.apache.jasper.JasperException: Unable to compile class for JSP:
An error occurred at line: 56 in the generated java file
The method getJspApplicationContext(ServletContext) is undefined for the type JspFactory
An error occurred at line: 17 in the jsp file: /pages/configset/createconfigset.jsp
The method setJspId(String) is undefined for the type ViewTag
14: <%@page import="com.cisco.wo.configui.beans.backing.configset.CreateConfigSetBackingBean"%>
15: <%@page import="com.cisco.wo.configui.utils.ConfigUIConst"%>
16:
17: <f:view>
18:
19:
20: <%
An error occurred at line: 45 in the jsp file: /pages/configset/createconfigset.jsp
The method setJspId(String) is undefined for the type SubviewTag
42:
43: <!-- Start header -->
44:
45: <f:subview id="configsetHeader">
46: <c:import url="configsetheader.jsp" />
47: </f:subview>
48:
An error occurred at line: 45 in the jsp file: /pages/configset/createconfigset.jsp
The method setBodyContent(BodyContent) is undefined for the type SubviewTag
42:
43: <!-- Start header -->
44:
45: <f:subview id="configsetHeader">
46: <c:import url="configsetheader.jsp" />
47: </f:subview>
48:
An error occurred at line: 45 in the jsp file: /pages/configset/createconfigset.jsp
The method doInitBody() is undefined for the type SubviewTag
42:
43: <!-- Start header -->
44:
45: <f:subview id="configsetHeader">
46: <c:import url="configsetheader.jsp" />
47: </f:subview>
48:
Thanks in Advance...!
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254432#4254432
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254432
16 years, 6 months
[JBoss AS Development] - JSP Pages are not compiling in JBoss5.1.0GA
by m.sudharsana
Hi Folks,
We have developed an webapplication and we deployed in JBoss4.0.1sp1 application is running fine.
One week back we downloaded JBoss5.1.0GA and we deployed the same application in JBoss5.1.0GA, but we are getting this eaception "org.apache.jasper.JasperException: Unable to compile class for JSP: "
please find the exception details below
====================================================================================================
HTTP Status 500 -
--------------------------------------------------------------------------------
type Exception report
message
description The server encountered an internal error () that prevented it from fulfilling this request.
exception
org.apache.jasper.JasperException: Unable to compile class for JSP:
An error occurred at line: 56 in the generated java file
The method getJspApplicationContext(ServletContext) is undefined for the type JspFactory
An error occurred at line: 17 in the jsp file: /pages/configset/createconfigset.jsp
The method setJspId(String) is undefined for the type ViewTag
14: <%@page import="com.cisco.wo.configui.beans.backing.configset.CreateConfigSetBackingBean"%>
15: <%@page import="com.cisco.wo.configui.utils.ConfigUIConst"%>
16:
17: <f:view>
18:
19:
20: <%
An error occurred at line: 45 in the jsp file: /pages/configset/createconfigset.jsp
The method setJspId(String) is undefined for the type SubviewTag
42:
43: <!-- Start header -->
44:
45: <f:subview id="configsetHeader">
46: <c:import url="configsetheader.jsp" />
47: </f:subview>
48:
An error occurred at line: 45 in the jsp file: /pages/configset/createconfigset.jsp
The method setBodyContent(BodyContent) is undefined for the type SubviewTag
42:
43: <!-- Start header -->
44:
45: <f:subview id="configsetHeader">
46: <c:import url="configsetheader.jsp" />
47: </f:subview>
48:
An error occurred at line: 45 in the jsp file: /pages/configset/createconfigset.jsp
The method doInitBody() is undefined for the type SubviewTag
42:
43: <!-- Start header -->
44:
45: <f:subview id="configsetHeader">
46: <c:import url="configsetheader.jsp" />
47: </f:subview>
48:
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254431#4254431
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254431
16 years, 6 months
[Management Development] - remote application deployment?
by drakee
Hi everyone, I hope I am posting to the correct forum; apologies if not!
I would like to be able to deploy applications to remote JBoss AS containers from a centralized location (I am specifically working on trying to create a TeamCity plugin, but in concept this could be done from anywhere). I am vaguely aware that one might be able to transmit application ears and wars via RMI through an existing JBoss API but I am having a difficult time finding tutorials or beginner overviews on how this would be accomplished programmatically, or if I'm correct in what I'm thinking.
I have found scattered references to mvn and ant plugins that may do what I'm looking for, as well as promising looking hints such as the org.jboss.jmx.service.RemoteDeployer class and the JBoss Remoting project, but I can't pinpoint exactly if these can do what I need.
The other alternative is for me simply to FTP or SCP the files over, but I was hoping for a more elegant solution. Any pointers or links would be much appreciated! Thanks.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254288#4254288
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254288
16 years, 7 months
[JBoss ESB Development] - Re: Supporting entry-point
by jeffdelong
BusinessRulesProcessor needs additional configuration parameters as well as code to support CEP. These include:
EventProcessingOption with values of STREAM or CLOUD
The code to use this would be something like:
|
| kconfig = KnowledgeBaseFactory.newKnowledgeBaseConfiguration();
| kconfig.setOption( EventProcessingOption.STREAM );
| kbase = readKnowledgeBase(kconfig);
| sconfig = KnowledgeBaseFactory.newKnowledgeSessionConfiguration();
| sconfig.setOption( ClockTypeOption.get( ClockType.REALTIME_CLOCK.getId() ) );
| ksession = kbase.newStatefulKnowledgeSession(sconfig, null);
|
|
Exit-points should also be supported. This would require configuration such as
|
| <action class="org.jboss.soa.esb.actions.BusinessRulesProcessor" name="OrderCountHistory">
| <property name="ruleSet" value="OrderCount.drl"/>
| <property name="ruleReload" value="true"/>
| <property name="stateful" value="true"/>
| <property name="object-paths">
| <object-path entry-point="OrderEntryPoint" esb="body.TheOrderHeader"/>
| </property>
| <property name="exitPoint value="OrderExitPoint"
| <route-to destination-name="x" service-category="y" service-name="z"/>
| <property name="set-payload-location" value="orderResultPayload"/>
| </property>
| </action>
|
|
The configuration of multiple exit points should be allowed. Not sure how to add the set-payload-location but something like this is needed.
A class would then need to be added that implemented the ExitPointInterface such as:
|
| public class RulesCallbackInvoker implements ExitPoint
| {
| public void insert(Object object) {
| try {
| ServiceInvoker invoker = new ServiceInvoker(service-category, service-name");
| Message requestMessage;
| requestMessage = MessageFactory.getInstance().getMessage(MessageType.JBOSS_XML);
| // add payload stuff
| requestMessage.getBody().add(object);
| invoker.deliverAsync(requestMessage);
| } catch (MessageDeliverException mde) {
| System.out.println("Eating this Exception: " + mde);
| }
| }
|
| }
|
|
|
Then the BRP would need to add:
|
| RulesCallbackInvoker exit = new RulesCallbackInvoker();
| KnowledgeRuntime kruntime = (KnowledgeRuntime) ksession.getEnvironment();
| kruntime.registerExitPoint("exit-point", exit);
|
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254281#4254281
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254281
16 years, 7 months
[JBoss OSGi Development] - Re: Cannot resolve circular dependencies
by thomas.diesler＠jboss.com
The bundles resolve now
| 21:17:00,207 INFO [FrameworkEventsPluginImpl] Bundle INSTALLED: Bundle{org.apache.felix.http.jetty:1.0.1}
| 21:17:00,585 INFO [FrameworkEventsPluginImpl] Bundle INSTALLED: Bundle{osgi.cmpn:4.2.0.200907101024}
| 21:17:00,967 INFO [OSGiBundleManager] Resolve: org.apache.felix.http.jetty:1.0.1
| 21:17:01,010 INFO [OSGiPackageCapabilityCache] Blacklist module associations
| [javax.servlet.http=org.apache.felix.http.jetty:1.0.1]
| [javax.servlet=org.apache.felix.http.jetty:1.0.1]
| [org.osgi.service.http=org.apache.felix.http.jetty:1.0.1]
| 21:17:01,011 INFO [OSGiPackageCapabilityCache] Unresolved requirements
| OSGiPackageRequirement{org.osgi.service.log [1.3.0,?) {version="1.3"}}
| OSGiPackageRequirement{org.osgi.util.tracker [1.3.0,?) {version="1.3"}}
| OSGiPackageRequirement{org.osgi.service.cm [1.2.0,?) {version="1.2"}}
| 21:17:01,011 INFO [OSGiBundleManager] Resolve: osgi.cmpn:4.2.0.200907101024
| 21:17:01,263 INFO [FrameworkEventsPluginImpl] Bundle RESOLVED: Bundle{osgi.cmpn:4.2.0.200907101024}
| 21:17:01,264 INFO [OSGiPackageCapabilityCache] Endorse module associations
| [org.osgi.service.blueprint.container=osgi.cmpn:4.2.0.200907101024]
| [org.osgi.util.gsm=osgi.cmpn:4.2.0.200907101024]
| [org.osgi.service.deploymentadmin.spi=osgi.cmpn:4.2.0.200907101024]
| [info.dmtree=osgi.cmpn:4.2.0.200907101024]
| [info.dmtree.spi=osgi.cmpn:4.2.0.200907101024]
| [org.osgi.service.component=osgi.cmpn:4.2.0.200907101024]
| [org.osgi.service.monitor=osgi.cmpn:4.2.0.200907101024]
| [org.osgi.service.wireadmin=osgi.cmpn:4.2.0.200907101024]
| [org.osgi.util.xml=osgi.cmpn:4.2.0.200907101024]
| [info.dmtree.registry=osgi.cmpn:4.2.0.200907101024]
| [info.dmtree.notification.spi=osgi.cmpn:4.2.0.200907101024]
| [org.osgi.service.log=osgi.cmpn:4.2.0.200907101024]
| [info.dmtree.security=osgi.cmpn:4.2.0.200907101024]
| [org.osgi.service.prefs=osgi.cmpn:4.2.0.200907101024]
| [org.osgi.application=osgi.cmpn:4.2.0.200907101024]
| [org.osgi.service.metatype=osgi.cmpn:4.2.0.200907101024]
| [org.osgi.service.io=osgi.cmpn:4.2.0.200907101024]
| [org.osgi.service.application=osgi.cmpn:4.2.0.200907101024]
| [org.osgi.service.http=osgi.cmpn:4.2.0.200907101024]
| [org.osgi.util.mobile=osgi.cmpn:4.2.0.200907101024]
| [org.osgi.util.measurement=osgi.cmpn:4.2.0.200907101024]
| [org.osgi.service.provisioning=osgi.cmpn:4.2.0.200907101024]
| [org.osgi.service.cm=osgi.cmpn:4.2.0.200907101024]
| [org.osgi.util.cdma=osgi.cmpn:4.2.0.200907101024]
| [org.osgi.service.blueprint.reflect=osgi.cmpn:4.2.0.200907101024]
| [org.osgi.service.deploymentadmin=osgi.cmpn:4.2.0.200907101024]
| [org.osgi.service.event=osgi.cmpn:4.2.0.200907101024]
| [org.osgi.service.upnp=osgi.cmpn:4.2.0.200907101024]
| [org.osgi.service.device=osgi.cmpn:4.2.0.200907101024]
| [org.osgi.util.tracker=osgi.cmpn:4.2.0.200907101024]
| [info.dmtree.notification=osgi.cmpn:4.2.0.200907101024]
| [org.osgi.service.useradmin=osgi.cmpn:4.2.0.200907101024]
| [org.osgi.util.position=osgi.cmpn:4.2.0.200907101024]
| 21:17:01,265 INFO [OSGiBundleManager] Resolve: org.apache.felix.http.jetty:1.0.1
| 21:17:01,389 INFO [FrameworkEventsPluginImpl] Bundle RESOLVED: Bundle{org.apache.felix.http.jetty:1.0.1}
| 21:17:01,390 INFO [OSGiPackageCapabilityCache] Endorse module associations
| [javax.servlet.http=org.apache.felix.http.jetty:1.0.1]
| [javax.servlet=org.apache.felix.http.jetty:1.0.1]
| 21:17:01,393 INFO [FrameworkEventsPluginImpl] Bundle STARTING: Bundle{org.apache.felix.http.jetty:1.0.1}
| 21:17:01,862 INFO [FrameworkEventsPluginImpl] Service REGISTERED: Service{id=4 bundle=org.apache.felix.http.jetty:1.0.1 classes=[org.osgi.service.cm.ManagedService]}
| 21:17:01,863 INFO [FrameworkEventsPluginImpl] Bundle STARTED: Bundle{org.apache.felix.http.jetty:1.0.1}
|
However there is a classloading issue for org.osgi.service.http.HttpService, which is expected to come from compendium.
AFAICS, The OSGiClassLoaderDomain uses DelegateLoaders backed by VFSClassLoaderPolicy delegates for both the http service bundle and the compendium. Since the DelegateLoader for the http service bundle comes first the class is loaded from there despite the fact that the package resolved against compendium.
I need to figure out how to filter the packages from the delegates such that it is in sync with how the modules got resolved.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254266#4254266
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254266
16 years, 7 months
[jBPM Development] - Re: Creating domain specific nodes into a jbpm-editor
by kukeltje
"barteljan" wrote : Hi :-),
|
| At first thank you for your detailed comments about this task,
| i'm trying to answer every point, please alert me if I miss one :-).
|
We will
"barteljan" wrote :
| @add extensibility to jpdl schema
| Althought I like the idea of an extendable schema for jpdl,I suspect this task is a bit of to much for our purpose, extending the schema means extending jpdl, which itself means extending the jpdl-core-engine. Since we want to use jbpm because of it's current stability, a modification of the engine itself should be avoided, because it holds a great danger for nasty bugs, which could be avoided by the "custom node approach". (Second approach noted by Ronald). I would prefer this approach because it looks like the easiest way to achieve extendebility. I would change my opinion if there are good arguments for doing that ;).
|
That would be my preference to. At first sight it indeed would leave the core as it is.
And it comes closest to what would be needed for BPMN2 as well.
"barteljan" wrote :
| @BPMN2
| I have to read more about it ....
| although I would propose to use an already existing node-type (java or custom),
| a new "service"-node would be acceptable for me.
|
I think it is not needed since the custom node (jpdl) and the service node (bpmn2) are close enough.
"barteljan" wrote :
| @specific node fuctionality
| I'm not quite shure what you mean with "generic", although we need a domain specific representation of our nodes (a stupid User should be able to differentiate two different "action-types" by sight ), It would be absolutly sufficient if those two different "action-types" are representated by the same node-type on xml-level.
| And at last I suppose that there should be a generic approach for adding such action-types.
|
With generic I meant an esb, ftp, ws, .... node, but I agree on the 'action-types'
"barteljan" wrote :
| @eclipse development
| My knowledge of eclipse-plugin-developement is quite limited,
| I know the concept of an extension point, but I wouldn't be able to define one,
| but this can be changed ;).
|
Then you are already further then I am ;-) Lets see how Koen can help, he is the 'master' ;-)
Might be interesting to also have a look at the RuleFlow editor (not sure if all the latest things are in the drools or jboss tools svn or there at all). Since we seem to be going to borrow/share something that Koen had an idea for a long time ago and Kris seems to have implemented it in quite a nice a way.
"barteljan" wrote :
| @timeline
| We are calculating with about two days for jbpm-developement per week,
| starting with evaluating the basics and targets in september.
| Active programming could start in october, hoping about first eyecatchers in november and a nearly working solution in december ....
| But that's only a rough calculation .... more time could be afforded if it is needed ....
|
The next release of jBPM is scheduled for the 1st of November, with a code freeze (at least of the core) 2 weeks before, so that seems a bit to early. But the next release of january 1st could be a nice target.
"barteljan" wrote :
| Thank you for your comments and your time,
|
| Jan
|
| P.S. I will configure and co the svn in the next days and cry for your help if I can't manage that :-)
|
Don't cry, it is better to shout it out loud, at least that would be my preference and I think Koen agrees.
So to summarize:
We need a way to specifiy
- A node type (name)
- reference to a pallet icon
- reference a node icon (process diagram level but could be the same as the palet icon)
- a reference to a custom node implementation (java class) that has to be included in the process archive
- some way to edit 'properties' of this node in a user friendly way (non-xml)
Designing these should be almost as easy as defining custom node, maybe by having the class implement a specific interface and find all implementing classes via reflection or use annotations or whatever and add them to the pallet on runtime. No XML hell... right ;-)
Would be good if we could break up all these things in jira and maybe some underlying things for Koen so it is clear what needs to be done etc.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254234#4254234
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254234
16 years, 7 months
[jBPM Development] - Re: Creating domain specific nodes into a jbpm-editor
by barteljan
Hi :-),
At first thank you for your detailed comments about this task,
i'm trying to answer every point, please alert me if I miss one :-).
@add extensibility to jpdl schema
Althought I like the idea of an extendable schema for jpdl,I suspect this task is a bit of to much for our purpose, extending the schema means extending jpdl, which itself means extending the jpdl-core-engine. Since we want to use jbpm because of it's current stability, a modification of the engine itself should be avoided, because it holds a great danger for nasty bugs, which could be avoided by the "custom node approach". (Second approach noted by Ronald). I would prefer this approach because it looks like the easiest way to achieve extendebility. I would change my opinion if there are good arguments for doing that ;).
@BPMN2
I have to read more about it ....
although I would propose to use an already existing node-type (java or custom),
a new "service"-node would be acceptable for me.
@specific node fuctionality
I'm not quite shure what you mean with "generic", although we need a domain specific representation of our nodes (a stupid User should be able to differentiate two different "action-types" by sight ), It would be absolutly sufficient if those two different "action-types" are representated by the same node-type on xml-level.
And at last I suppose that there should be a generic approach for adding such action-types.
@eclipse development
My knowledge of eclipse-plugin-developement is quite limited,
I know the concept of an extension point, but I wouldn't be able to define one,
but this can be changed ;).
@timeline
We are calculating with about two days for jbpm-developement per week,
starting with evaluating the basics and targets in september.
Active programming could start in october, hoping about first eyecatchers in november and a nearly working solution in december ....
But that's only a rough calculation .... more time could be afforded if it is needed ....
Thank you for your comments and your time,
Jan
P.S. I will configure and co the svn in the next days and cry for your help if I can't manage that :-)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4254224#4254224
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4254224
16 years, 7 months