I'm getting the following error for each of the publishable files in an
EAR-style project set when I publish:
| eclipse.buildId=unknown
| java.version=1.6.0_03
| java.vendor=Sun Microsystems Inc.
| BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
| Command-line
A few more details follow.
My JBoss Server is configured with:
Deploy Directory: C:\jboss-4.2.2.GA\server\default\deploy
Temporary Deploy Directory: C:\jboss-4.2.2.GA\server\default\tmp\jbosstoolsTemp
No files or directories show up in the temporary directory. The exploded ear
directory tree
I found the problem:
I had also cleaned up my default JBoss application server instance with a
fresh one from the install archive.
It appears that the Temporary Deploy Directory is created at the time when the
eclipse server instance is created for JBoss, and as soon as I recreated the
Done.
http://jira.jboss.com/jira/browse/JBIDE-1338
Thanks!
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4106158#4106158
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4106158
Huge ++ on making it easy to override conversation Ids.
The level of criticality is such that we'll have to make them secure regardless
of whether we have to do it as a hack or are supported by a Seam feature.
I was actually hoping that conversation Ids would start fresh from 1 for each
new
I just figured I should throw in my two-cents that our project is also hurting
from this change to not have the version number on the lib.
I know that lots of people say to just look at the maven descriptors, but
trying very hard not to start a religious war, we don't do Maven any more in
our
One more argument in favor of version-named jars: We often find ourselves for a
period of time with more than one version of a library so that our team can
test the upgrade in phases. Even more helpful, it lets various users chime in
before we make the change permanent in the .classpath and
If a component is created in components.xml with a new name, for instance:
| component name=newName
| class=com.xyz.OriginalName /
|
How can it find out its own name from within itself.
This is frequently needed when I outject a context variable, and at other
times.
That was obvious!
I hadn't noticed the change (rev 1.29) since the last time I checked that
method for this capability :-)
Thanks!
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4082812#4082812
Reply to the post :
Is there a way to get the metamodel org.jboss.seam.Component instance for a
class instance rather than for the original class?
For instance:
String realName = Seam.getComponentName(this); // doesn't work
Rather than:
String originalName = Seam.getComponentName(this.getClass());
I think I'm
I should mention just in case it wasn't clear that I realize the
org.jboss.seam.Seam class is not currently designed to support component
instances the way I wrote it. I'm just trying to express what I'm trying to
achieve.
View the original post :
In my experience so far, you need to have a real ear directory of some name,
under which your various wars and jars will be deployed by the native Eclipse
builder. Additionally, you need to put this under a deploy directory, so that
you can tell JBoss to poll that directory for deployable
Do the cluster issues with Entity beans go away if they are detached from the
hibernate session? In that case could I consider them for the most part to be
similar in behavior and safety to simple Javabeans?
View the original post :
I've had problems sharing jboss-seam.jar in the server-name/lib dir when I
have multiple WARs in separate EARs. This is because if a shared classloader
serves up the Seam classes then Seam doesn't shield the webapps from each
other. It's not like it doesn't work (AFAIK), namespacing just gets
Current it appears that when a Seam component is not found Seam will spit out a
debug message if debug is turned on. Otherwise it will just fail silently.
I can't figure out if I'm just not seeing the big picture, but it seems like
this should fail or at least warn instead of debug. Am I
I should have more clearly said that the current behavior for Seam is to
continue silently, not fail.
On a page with a incorrect component name, this just displays blank for that
expression, without other indications.
View the original post :
Good point, and that was the missing link that explains it to me.
On the other hand, at the EL level shouldn't the non-existence of a referenced
context variable typically indicate an error condition? I know it's not all
that uncommon to be rather sloppy with the contexts, but aren't these vars
bfo81, if you'd like to use Seam with a separate back-end layer of any sort,
it's quite easy to do so. Look at the CaveatEmptor CVS checkout from the
Hibernate in Action book web site for nice generic DAO layer abstract classes
if you're wanting to combine it with Hibernate.
I'd venture that
Preface: I'm quite certain that my usage patterns in Seam are not advanced yet,
so I might be looking at the problem of code redundancy in Seam components
completely wrong, so comments highly welcome.
I'm trying to work through strategies to eliminate repetitive code in a large
project, and
oops, ignore the Scope.SESSION lines from your reading of the above. That's an
oversight propagated from some experimenting I was doing.
thanks...
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3965254#3965254
Reply to the post :
more mistakes :-(... it really was supposed to be stateless. i promise. heh. i
gotta try not to do these things after my eyes get blurry.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3965331#3965331
Reply to the post :
bah, my confusion is palpable. please ignore the confusion. the original
questions are still the same, although i'm seeing where i'm misunderstanding
some of the difference between stateless and stateful components when it comes
to datamodel style results.
View the original post :
Thanks, Raja. Very much appreciate the info! And hurray for subversion. I
should have realized they switched.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3964833#3964833
Reply to the post :
23 matches
Mail list logo
